Trying to get full domain info in nslookup

[Kevin Darcy]

Koehler, Charles wrote:

>I have an interesting situation and am unclear if my DNS servers are at
>issue (128.218.254.10 and 128.218.254.40).
>
>I get the following results when trying to get complete info for the
>domain below though after querying the separate components, I get that
>piece of info.
>
>Is this normal and what should I do to remedy it if it is not.
>
>Running QIP's BIND8.2.4 on Solaris9
>
>
>==============================================
>1st query w/ set q=any:
>Answer Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>Authority Records Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>Additional Records Section:
>    UDNS2.ULTRADNS.NET, A, 204.74.101.1
>    UDNS1.ULTRADNS.NET, A, 204.69.234.1
>---
>
>2nd query w/ set q=any after set q=soa:
>Answer Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>    immunetolerance.org, SOA, UDNS1.ULTRADNS.NET,
>gkuyat.immunetolerance.org
>Authority Records Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>Additional Records Section:
>    UDNS2.ULTRADNS.NET, A, 204.74.101.1
>    UDNS1.ULTRADNS.NET, A, 204.69.234.1
>---
>
>3rd query w/ set q=any after set q=a:
>Answer Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>    immunetolerance.org, SOA, UDNS1.ULTRADNS.NET,
>gkuyat.immunetolerance.org
>    immunetolerance.org, A, 128.121.49.2
>Authority Records Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>Additional Records Section:
>    UDNS2.ULTRADNS.NET, A, 204.74.101.1
>    UDNS1.ULTRADNS.NET, A, 204.69.234.1
>---
>
>4th query w/ set q=any after set q=mx:
>Answer Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>    immunetolerance.org, SOA, UDNS1.ULTRADNS.NET,
>gkuyat.immunetolerance.org
>    immunetolerance.org, A, 128.121.49.2
>    immunetolerance.org, MX, 0, mail.immunetolerance.org
>Authority Records Section:
>    immunetolerance.org, NS, UDNS2.ULTRADNS.NET
>    immunetolerance.org, NS, UDNS1.ULTRADNS.NET
>Additional Records Section:
>    UDNS2.ULTRADNS.NET, A, 204.74.101.1
>    UDNS1.ULTRADNS.NET, A, 204.69.234.1
>    mail.immunetolerance.org, A, 38.118.73.195
>
QTYPE=* (otherwise known as "any") queries are treated by BIND as 
non-recursive-when-something-is-cached-for-the-name-recursive-otherwise 
because of a misreading of RFC 1034 that has never been corrected. So if 
something happens to be cached for the name you're querying in the 
nameserver which is responding to the query, you get the cached data, 
otherwise it goes out and fetches a new set of Resource Records. To run 
a proper test, you'd need to clear the cache (i.e. restart the 
nameserver process) between each set of queries. Then you'd see that 
each response to a QTYPE=* query consists of only those RRs with the 
name immunetolerance.org that were cached from the responses to the 
previous immunetolerance.org queries (assuming that the cache wasn't 
being populated with immunetolerance.org Resource Records by anything else).

Bottom line, BIND has made QTYPE=* a lot less useful than it could be or 
was originally intended to be. I think there isn't a lot of incentive to 
fix this, though, because to fix it raises the possibility that apps 
could start using QTYPE=* inappropriately, thus causing wasted 
resources. That's a FUD argument, though, and should not IMO stand in 
the way of a proper implementation.

- Kevin