Dns report explanation

Re: Dns report explanation

From:

Date:

Time:

At 12:52 AM -0800 11/2/04, Scott Haneda wrote:
>When DNS report lists a lame NS, and the IP, does that mean the zone in
>question is listed in the whois as a NS but the data in the lame server is
>not being pulled from the primary, or at least it is not current?

Something like that.

It means that either the zone's delegation records or its authority
records point to the server in question, but the server responds
non-authoritatively when queried iteratively about the zone.

Delegation records = the NS records in the parent zone, such as those
generated from the whois database.

Authority records = the NS records in the zone itself that have the
same name as the zone.

>How can I
>use dig to perform this test manually?

If you have dig version 9 (which you do, Scott):

First, use 'dig +trace domain.name' to find the delegation records.
Pay attention to what records you're getting from what server.

Next, use 'dig +norecurse domain.name soa @server.name' to query each
server listed in either delegation and/or authority records, in turn,
and check the response flags. Look for the 'aa' flag - any such
server that doesn't include the 'aa' flag in its response is lame (by
definition) with regard to this zone.

Order of options on the 'dig' command line is not important unless
you take advantage of its ability to perform multiple queries from a
single command.

>Can someone elaborate on this error to me:
>All nameservers report identical NS records

That's not an error. It's how things should be - all authoritative
name servers should report the same list of authoritative name
servers.

>Then there is the Glue at parent nameservers error, which I also need some
>explanation on.

Glue at parent name servers refers to glue records. A glue record is
an A record normally outside the scope of the zone that is required
for the purpose of a delegation. Some examples will be most useful:

Suppose example.com is delegated as follows from com:

example.com. NS ns1.example.com.
example.com. NS ns1.example.net.

The A records for these two servers are outside of the scope of the
com zone. In the first case, it's because ns1.example.com belongs to
a delegated subdomain, example.com. In the second case, it's because
the name is entirely outside of com - it's under net.

The problem is, you have a chicken-and-egg situation. You can't ask
ns1.example.com, which presumably has an authoritative version of the
zone, for its own address, since you don't know where to send the
query. Rather than send all such traffic to ns1.example.net (which
would therefore get all of the traffic for the zone, and could go
down and take the whole domain offline), an extra "glue" record is
required:

ns1.example.com. A 192.168.1.1

This record in the com zone should (in theory) be matched by a
similar record in the example.com zone. If there's no A record for
ns1.example.com in the example.com zone, BIND 9 (and any other
RFC-compliant name server) will fail to find the address of
ns1.example.com in spite of the glue record - the glue record is only
used as a means to find an authoritative A record defining the name
server.

>For all three cases I would like to know how to use dig to get to this info,
>rather than using dnsreport.com all the time.

Take a look at 'man dig' - it's very informative.

Chris Buxton
Men & Mice - Making DNS Easy
Customer Service and Sales Engineer

Sales:
888/4-DPOINT

Support:
858/452-3696