NS Entry in DNS Servers

When you register a domain, you have to supply at least two name servers that will be the primary and secondary name servers for your domain. This information goes to the root servers for an initial lookup of xyz.com.

However, if you are looking for abc.xyz.com, or you are looking for the e-mail server for john@xyz.com, this information is NOT contained in the root. It is only contained in the domain's name servers.

Many DNS servers are needed for load balancing, redundancy, and to minimize traffic over congested links.

Say now you know that xyz.com is at IP address a.b.c.d.  That doesn't do you any good if you are looking for the E_MAIL server to send an e-mail to john@xyz.com. So instead you have to QUERY the domain name servers for xyz.com for an MX record, so you do this:

a) You retrieve the NS record(s) from xyz.com.

b) You retrieve the MX record(s) from one of the name servers (say dns1.xyz.com).  The MX record might be smtp.xyz.com.

Dave

This magazine article in two parts covers basic DNS pretty well. Including the main record types (SOA, A, NS, MX) and reverse lookup (PTR).

http://www.ntsystems.com/db_area/archive/1998/9801/201c1.shtml

http://www.ntsystems.com/db_area/archive/1998/9802/202c1.shtml

Hope this helps.

Dave

Read the articles, just some basic infos I already had, and no coverage of NS or SOA in perticuilar.

Probably I should clarify my question a little:

Microsoft DNS puts a NS into every primary zone I create automatically, the NS pointing to my own DNS computer. Sine I doubt that the machine uses the NS record to find itself, I guess that it is just there to be queried from other resolvers if someone wants to find out more about my name server. If this is true, what then is the information in the SOA record for, since it essentially contains the same info, plus the admin mailbox name and the TTL values. So why query an NS at all, since SOA contains more info?.

If the NS like described above was a mechanism to point either the querying resolver or the DNS servers's own resolver to another DNS if it cannot satisfy a request, why then didn't my setup work? Note: In this case I do not intend to delegate a subdomain, that's pretty straightforward. I intended to point to an entirely different DNS without my DNS going the usual way from the DNS top level domains down the namespace till it finds the second DNS.

...Armin

Oh.. But it DOES use the NS record to find itself. In fact, there is a bug report somewhere that is the result of a certain upgrade action from NT to 2K that results in that record not being there and it has to be added manually.

You have to remember that the client or resolver querying doesn't know anything initially about your domain, so they will request NS or SOA depending on what they are trying to do.

They also don't know if there are many different name servers or just one, so again, they have to get the NS records to see.

Your last paragraph seems a bit confusing. I guess I don't understand exactly what you are trying to accomplish.

".. I intend to point to an entirely different DNS without my DNS going the usual way from the DNS top level domains down the namespace till it finds the second DNS.."..

I don't understand. Can you clarify a bit more?

Dave

NS usage: well this may or may not be a special use of the NS by Microsofts setup, but I am more after everyday usage of the DNS record.

Resolver behaviour:

seems pretty easy to describe: I give it either a FQDN or a friendly name to resolve. If the latter is the case, the client appends his DNS suffix(es). So the DNS is always queried for a FQDN, e.g. www.mycompany.com. The DNS server IP is entered into the client IP settings, so to find its own nameserver it doesn't need any NS.

Leaving DNS cache lookups aside:

the DNS searches his own database to find out wether or not it has a zone named mycompany.com, and, if yes, checks wether there is a A record named www in it. Passes back either the IP of www.mycompany.com, or an error.

Q1: so the NS record automatically created by NT DNS Manager for my own zone is not queried and therefore useless?

If I, on the other hand, query my DNS to look up www.yourcompany.com, there are mutiple possible paths to follow:

If there is no zone yourcompany.com in my DNS database it needs to pass the query to someone else. So if there is a "forwarder" IP entered for my server, my server issues a recursive query to that DNS and patiently waits for an answer, and passes that answer, wether positive or negative, back to the client.

If there is no forwarder, my DNS would query the "." DNS server for the com name server(s), and then the com name server(s) for yourcompany.com, by issuing iterative queries. The DNS root hints loaded from cache.dns will shorten this process, so the actual query starts at the .com servers.

Q2: if there is a forwarder which doesn not find a match, will the DNS still try the root hints?

And again, my NS record has not been useful once more.

And now the clarification: for some reason (curiousity) I want to be able to resolve yourcompany.com. I don't have a forwarder, and yourcompany.com is not a registered Internet domain anyway. So what I'd try to do in this situation was create a zone yourcompany.com in my DNS, and enter a NS record pointing to your DNS IP. Desired result: the querying client gets redirected to ask your DNS server.

Seems not to work. Probably because of the way "recursive" queries work. They either expect to get an IP, or an error, but not the adress of another DNS to query. And this time the NS record automatically created in my yourcompany.dns zone has once more been useless.

Hope I helped to clarify what I want?

Armin

Ok. The clarification is good and the comment from vstamani is also good. The last piece of the question was how to "forward" a DNS query to a 2nd DNS when the domain is not registered on the internet right?

That is, the root servers have no idea where abc.xyz is.

Someone inquires for www.abc.xyz to your DNS and you want your DNS to either forward the request to a DNS that knows about abc.xyz or to return to the querier the address of the the abc.xyz DNS and let them query that in return.

Have you considered adding a root "." zone to your DNS server and adding an abc.xyz entry to the root zone?

If every internal DNS server contains in its Root Hints the address(es) of the private root DNS server(s), that guarantees that a company client is able to resolve any hostname from the external domain. The ?.? zone must contain delegations to the top-level zones of the external domain private namespaces.

Does that make sense?

Dave

If there are multiple NS records in the zonefile then a querying DNS server will try the query on all the DNS servers to see which one returns the record fastest and then remembers that this one should be queried next time.
Also it can be used to tell the master DNS server which slave DNS servers to send rfc1996 notifications to.

Thanks for all the input. Things start to clear up.

In my attempt to be able to describe my DNS behaviour to see wether I got it, I still feel I missed something, and so I beg your patience, carry on asking until I fully got it. Also hope I make correct use of the terms "beeing authoritative" and "delegating", my knowledge is a bit shaky in that area, please correct any wrong use of these terms without mercy.

Vijay and Dave have already helped a lot, things start to fall into their places. You'll get your fair share of the points cake :-). Anydyalder's comment is also very interesting, haven't worked with DNS notifications yet, just remember having read a short comment somewhere in the MS docs, need to check this out as soon as my basic setup works.

Let's assume I follow Dave's lead to solve the whole issue:

My dns has a zone mycompany.com (is authoritative for that domain). I also create a "." zone. To get this to be queried I assume that I will need to remove the root hints (delete cache.dns). Then I could delegate .com from the root, and yourcompany.com from the .com entry?

This is dark spot #1: I could create new zone files for ".", "com." and "mycompany.com.". The last one is irrelevant at the moment. Within "." I create a NS for com, pointing to my own DNS. Within com I create a NS for mycompany, pointing to the other DNS server. Sounds logical to me, but is this the correct procedure? Or could I, to simplify things, simply put a NS record for yourcompany.com's DNS into the "." zone?

Dark spot #2: if I implement the above scenario, obviously my DNS would never be able to query real Internet domains any more. Would in this case the forwarder entry help (which links this issue to the question I rised above: wether or not the forwarder is still used in case my own databases have failed to satisfy a query, but if my DNS has zones like "." and "com." that are normally assumed to be located in the Internet).

Dark spot #3: let's assume I do the following: I simply put a NS record for yourcompany.com into cache.dns. Sort of an atypical root hint, to give it a name. This would, given I get this done right and don't mess up the data file, put a NS entry pointing to yourcompany.com's DNS into my DNS cache, and therefore should satisfy my DNS server's needs to redirect the clients properly. I think this will work nicely, though I haven't already given it a try.

Assuming it will work, I wonder what the "." DNS is used for entirely. If every DNS on this planet has it's root hints, the "." DNS server(s) would never be queried, right? So is it just there in case someone fails to have root hints? Or do I also have a basic misunderstanding about how the root hints do work at all, which may be the case?

...Armin

Dark spot 1: If you simply put a NS record fot yourcompany.com into the . zone, it's technically an illegal delegation, but your dns server might still serve the correct answer, because it may be implemented in such a way that it tolerates this irregularity.

Dark spot 2: If you set up a fake . zone and a fake com. zone in your server, then as you say you will no longer be able to query the real dns. Suppose you ask your server for info on "microsoft.com" - it will answer that there is no such domain, and it won't use the forwarder, because you have told it that it is the authoritative server for all .com domains. So it knows for sure that there is no "microsoft.com" domain, and certainly won't ask any other servers, because they won't be authoritative. Remember the distinction between authoritative answers and non-authoritative answers - if the server can giove an authoritative answer, it will, and it won't use any forwarders, even if the authoritative answer is wrong.

Dark spot 3: There are no "." dns servers. That's why you need a root hints file, so that the nameserver has somewhere to start when looking up a top-level domain. So what you say is correct, but for the opposite reason: every nameserver in the world does have a root hints file, *because* there is no nameserver for the "." domain.


Vijay

Almost there :-)

Root hints:
I had a long and thoughtful look into the cache.dns file on my NT DNS. It contains a couple of root hints of the roughly the format

.                   NS           X.ROOT-SERVERS.NET
X.ROOT-SERVERS.NET  A            <ip adress>

So it seems to me that these actually ARE the servers that are authoritative for the "." zone, and, without ever having seen one of them, I assume they have zone delegations for the top level domains, and one of them is randomly selected as a starting point for my queries. If this is true, they have a lot of work to do to satisfy myriads of requests from other DNS servers asking to resolve just a handful of names: the name servers of the top level domains .com, .edu, ect. Did I finally get all the details sorted into the right places?

The forwarder:

Given I don't have a matching zone entry in my database my DNS has a lot of technically possible ways to get a name resolved:

* pass it to the forwarder. In this case the root hints were useless once I use a forwarder entry.
* ask a randomly selected server from the list of root hint servers, and then traverse the chain of subdomain DNS servers until I get to the desired domain. In this case the forwarder was useless.
* Try the root hints way, and if not successful, try the forwarder
* do it the other way round
* do something completely different what arminl cannot imagine :-)

Can you help me with this (last, I promise) issue?

...Armin

Hmm.. Doing some reading. This is going to have to be resolved with trial and error.

When Windows 2000 DNS is installed, the Wizard looks to see if your computer is connected to the internet. If it is, then a root-hints is created and the '.' zone is not.

If your computer is nOT connected to the internet, then root-hints are NOT created and a '.' zone is (so your DNS becomes a "root" server itself.

Depending on how this is all implemented it may be that this is not the right approach. But testing is the only way to figure it out.

Some alternative ways to think about the problem:

I've got to believe that the implementation of DNS allows for a multi-domain internal network that is also connected to the internet.

While most examples talk about sub-domain trees, such as:
eastcoast.mycompany.com and westcoast.mycompany.com, I've seen some examples in which two companies "merge" and their old domain names need to resolve each other.

One way to do this is to have a single name server that is authorative for both domains. With Win2K it is easy to setup a multi-domain name server.

It is also easy to delegate maintenance of the domain to another organization, with replication taking care of updating the "central" name server.

Another way is to consider is adding an entry to mycompany.com to the DNS CACHE with NO EXPIRATION DATE.

This would cause your DNS server to return a non-authorative answer. Cache entries have an expiration date usually of a few hours. This minimizes traffic to the name server while ensuring that if you change the IP address of a server no one is going to get the OLD address after a little while.

Dave

I'm getting fed up with having to go to win2000 servers and delete the "." zonefile before configuring forwarders or root hints.

In a win2000 environment you should use split-DNS:
2 servers, one for your internal records and one for the public records, no replication between them (or get the ISP to be the public DNS server. Best current practice is to have more than one public DNS server in geographically seperate locations but it's only a recommendation.

The forwarder function is still somehow a crucial thing for me to understand. I am more after understanding the shady spots in MS DNS software functionality, I didn't find the forwarder entry behaviour covered in any documentation available to me.

I meanwhile tested the cache.dns entry, and it works like a charm. I think that's the cleanest way to deal with this wicked situation.

...Armin

I believe if you configure both root hints and forwarders then the forwarders are tried in order until the timeout value and then a recursive lookup via root hints is tried.
 
Forwarders is just asking another DNS server to get the record for you similar to how your client PCs ask your DNS server to get the record for them. If you use forwarders then you can get non-authoratitive records because they come from your own or your ISP's cache and if a record is changed it takes longer for you to notice this change since there are 2 levels of caching.

If the MS server acts like BIND on Unix / Linux platforms, then by default it will first check to see whether it is authoritative for the zone being queried, then check its cache for the answer, and then ask the forwarders for the answer. Only if all of these strategies fail will it attempt to get the answer itself, by starting at the root servers and recursively querying nameservers until it gets an authoritative answer. (The answer will of course then go into its cache and remain there until expiry.)

Vijay

I give my points to vsamtani, I think he was the first one to show me the right direction to go.

Also leave points for dcgames and andyalder for their assistance in this forum.

Thanks,

Armin