Ensuring authoritative dns answers only

[Mary Lark]

Is there a program that will yield authoritative dns answers or "failed" answers to a dns query?

I have about 5,000 websites I need to verify are on my server, yet I continually get differing results from nslookup

[Steven Schweda]

> I have about 5,000 websites I need to
> verify are on my server,

I don't know what that means.

> yet I continually get differing results
> from nslookup

What are you asking for from nslookup, and
what are you getting which you don't like?

Nslookup sends requests to DNS servers, and
tells you what it gets back. If the DNS
servers send back differing results, what do
you expect nslookup to do about that?

If you expect a detailed diagnosis of
symptoms which you don't reveal, then try a
psychic. Otherwise, showing actual commands
and their actual output can be more helpful
than vague descriptions and interpretations.

[Mary Lark]

Ouch. This is my first post on this site. Are the replies typically this demeaning? Try a psychic? Really?

If I understand the system correctly, DNS lookups return the first entry found. If that means it returns a non-authoritative entry that's fine. When you get an authoritative response you're talking to the actual nameserver of the site.

The problem with non-authoritative entries is that they're subject to inaccurate information. This is like being led down the wrong garden path.

When you get an authoritative response you're talking to the horse's mouth - the nameserver where the actual record resides.

I'm looking to cull out the non-authoritative answers from the authoritative answers.

Is there a way to specify that this is a DNS lookup that will yield only authoritative answers?

If you know the answer, but cannot talk without character assasinations or ridiculing me - I'd love it if you simply did not reply. No response is so much better than getting ridiculed.

[Steven Schweda]

> When you get an authoritative response
> you're talking to the actual nameserver of
> the site.

Not of the site, of the _domain_. If you
wish to query the nameserver of a particular
domain, you can find out what it is:

ALP $ nslookup -type=ns google.com
Server: alp-l.antinode.info
Address: 10.0.0.9

Non-authoritative answer:
google.com nameserver = ns4.google.com
google.com nameserver = ns1.google.com
google.com nameserver = ns2.google.com
google.com nameserver = ns3.google.com

Authoritative answers can be found from:
ns1.google.com internet address = 216.239.32.10

and then ask the nameserver of your choice:

ALP $ nslookup google.com ns1.google.com
Server: ns1.google.com
Address: 216.239.32.10

Name: google.com
Addresses: 74.125.67.100, 74.125.45.100, 74.125.127.100

> I'm looking to cull out the
> non-authoritative answers from the
> authoritative answers.

What makes you think that the locally cached
results are worse than the others?

Is there some actual problem which you are
trying to solve, or is the question one of
esthetics?

> No response is so much better than getting
> ridiculed.

A well formed question is good, too.

> What are you asking for from nslookup, and
> what are you getting which you don't like?

Still wondering.

> [...] showing actual commands
> and their actual output can be more helpful
> than vague descriptions and interpretations.

Still true.

> Try a psychic? Really?

Or show what you're talking about, or answer
specific questions. Or wait for the next
answer.

[Matti_Kurkela]

So. It seems you're in the middle of a web server migration (or something similar) and some of your sites seem to have incorrect information in the DNS. Right?

Sadly, many of the new members of this forum never seem to read Patrik Wallek's "ITRC Forums Etiquette Guideline" before posting. Steven just tends to voice his displeasure about it the most.

http://66.34.90.71/ITRCForumsEtiquette/index.html

In particular, the part about posting technical questions is regarded as pretty important here:

http://66.34.90.71/ITRCForumsEtiquette/post.html#tech

In short: it is easy to answer a question that has plenty of background information and all the relevant facts you have managed to find so far. It is *not* easy to answer a question if each fact must be separately drawn out of the poster with a pair of verbal pliers.

But I digress. Back to the question.
-------------------------

First, you should ensure that the master nameserver of each of your sites has the correct information. Whenever any DNS data is updated, the serial number of the relevant DNS zone should be incremented.

If the serial number is *not* incremented, the authoritative slave servers of that zone may not notice the update, and will happily give out obsolete information.

If the master DNS server is running an old version of the name server software that cannot use the NOTIFY extension of the DNS protocol, the changes may not be replicated to the slave servers immediately, but only when the slave server periodically queries the master to verify the zone's serial number. The length of this period is configurable: if it's set too long, it may take a long time for a DNS change to propagate from the master server to its slaves.

Each DNS record also includes a Time-To-Live value. When an authoritative server gives out DNS data, it uses the TTL value to set the "expiration date" for that data. If a DNS request and its response passes through any DNS caches (= any name servers that are not authoritative for that particular zone)

The serial number of the DNS zone, the default minimum TTL for that zone, and the time values related to communication between the master server and its slaves are all included in the SOA record of the zone.

So, what to do when a DNS query reports inconsistent information?

1.) Use "nslookup -type=ns google.com" -style requests to find out the list of authoritative DNS servers for that domain.

2.) Use nslookup to send queries directly to those authoritative servers to verify that their information is consistent:

nslookup site.domain.example authoritative.nameserver.example

2.1.) If the data is consistent on all public authoritative servers, the problem is probably caused by a long TTL value in the pre-change DNS records.

Resolution: Unfortunately, the only way to fix it would be to purge all DNS caches that have the old data. If these are public sites on the Internet, the only possible answer is to wait it out until the TTL of the old data expires.

Unfortunately, nslookup does not list the TTL values of the responses it gets. The "dig" tool can do that. Run "dig site.domain.example" a few times: if your DNS data comes from a cache, you'll see the TTL value ticking down. When the TTL drops to zero at your cache, only then your cache will again query the authoritative DNS servers to get updated data.

If you use "dig @authoritative.server.example site.domain.example" to get the data directly from the authoritative server, the TTL value does not decrease when a query is repeated.

2.2.) If the data is inconsistent between the authoritative servers, get the SOA records of that zone from each authoritative server:

nslookup -type=soa domain.example authoritative.nameserver.example

The answer should look like this:

Server: authoritative.nameserver.example
Address: 1.2.3.4#53

home
origin = domain.example
mail addr = hostmaster.domain.example
serial = 2008082701
refresh = 86400
retry = 3600
expire = 2419200
minimum = 10800

Here, "serial" is the serial number of the zone.

2.3.1) If the serial numbers match in all authoritative nameservers of a particular zone *and* the zone data is still inconsistent on the authoritative servers, the DNS admin of that zone has forgotten to update the serial number.

Resolution: contact that DNS admin and make him/her aware of the mistake, then wait until the TTL of the old data expires.

2.3.2) If the serial numbers don't match, how much time there has been since the DNS change?

2.3.2.1) If less than seconds has passed, the master server of this zone does not use DNS NOTIFY to make its slaves update immediately, and the slaves have not picked up the change yet.

Resolution: wait for seconds to pass, or request the appropriate DNS admin to trigger the slaves to update manually. Then wait until the TTL of the incorrect data expires.

2.3.2.2) If more than seconds has passed, the communication between the master server of this zone and its slaves is apparently not working.

Resolution: contact the appropriate DNS admin and make him/her aware of the problem.
Then wait until the TTL of the incorrect data expires.

MK

[Matti_Kurkela]

Oops, I forgot:

... and because you have thousands of sites to verify, you'll probably want an automated DNS checker/validator program to check for errors like this for you.

Your (unspecified!) Linux distribution most likely contains such a program in its standard package collection. On Debian, I run "apt-cache search dns | less" and see the following promising candidates:

dlint - Checks dns zone information using nameserver lookups

dnstracer - trace DNS queries to the source

dnswalk - Checks dns zone information using nameserver lookups

fpdns - remotely determine DNS server version

zonecheck - A DNS configuration checker

zonecheck-cgi - A DNS configuration checker, Web interface

MK