There is an A record to point to the name associated with the NS record.

Something  like

In DNS zone domain.com

“Smartconnect zone”    NS   isi_sip.domain.com

isi_sip.domain.com A      

two common errors is to make an A record for the smartconnect name (which will point all connections to node 1)

or to name the right hand side of the NS record the smartconnect zone name (which again points all the connections to node 1)

note that the “isi_sip” name is completely arbitrary.

We highly recommend customers buy and take our Administration class as we do cover how to setup your Isilon Cluster for LDAP and then Active Directory.

This should help you out.

Thank you,

yes good point. An NS delegation is not the same as a forwarder. Bad example on my part. I meant to try to indicate that the address of the nameserver isn’t the same as the addresses the nameserver returns for the SC zone. I think I failed ;-)

There is no AD or LDAP problem. That works fine.

It was strictly a DNS issue. The DNS people put their own entries in DNS and we were just fixing it.

Yep, the SIP is not the same thing as the zone.

If you are configuring bind/named, you’d want something like

zone "sczone.cluster.example.org." in {

    type forward;

    forwarders { 10.9.165.219; };

};

Having a zone name that starts with “ns” suggests confusion. The nameserver that serves the zone is not the same thing as the zone itself.

Sounds good,

I am surprised they did not follow the SmartConnect instructions from the class as I walk them through creating the entries.

https://community.emc.com/docs/DOC-20498

Glad to hear you are getting them taken care of.

Hmmm.

This is what they are doing:

ns-xyz01 15 NS ns-xyz01.domain.com.

ns-xyz101 15 NS ns-xyz101.domain.com.

ns-xyz01 A 10.9.165.219

ns-xyz101 A 10.9.165.220

ns-xyz01.domain.com is the 10GE SmartConnect name

ns-xyz101.domain.com is the 1GE SmartConnect name

So if I read you correctly, the 10GE SmartConnect Name based on what they are doing should really be ns-xyz01.ns-xyz01.domain.com.

Correct?

The DNS people didn’t take the class.  They were behind a couple of months to make the changes requested.  When they did implement it, it was implemented the way they wanted and not what we asked for.

Now the exercise has been about fixing the problem.

I was making sure we got it right.

Thanks for clearing that up.

So to ensure they are happy with the naming, this would work, correct?

ns-xyz01                  15 NS xyz01.domain.com.

ns-xyz101 15 NS xyz101.domain.com.

xyz01 A 10.9.165.219

xyz101 A 10.9.165.220

Best Regards,

In this case, ns means Network Share, not name server. This a 99% Windows environment.

Interesting customer. They have some sharp people there in specific areas but they rarely talk.

Then they have some yahoos that shoot from hip and do things.

When I get the sharp people together and get them to look at a project as a whole we make progress.

It is a learning process for them and for me.

OK, I we opened a case with Isilon Support.

We went though that and now everything is resolving to a single node, including the ones that were working properly.

Everything looks right to me on the DNS side.

Does the Smart Connect Zone Name need to be something completely different?

They are using the fully qualified “A” record name as the SmartConnect Zone Name.

That might work but its not a true delegation as you get with an ns record.

The ns record almost always should be accompanied by and a record which is called a glue record in DNA vernacular.

The problem with a forward record is that it's not a true referral thus caching could interfere.

Same logic applies to using a stub zone.

  Also, underscores are not permitted in DNS hostnames per rfc 1123 so avoid using them in the SC name. There are exceptions per rfc 2181 but it comes down to a question of interoperability with certain resolvers that might only adhere to the older spec.