Trying to get full domain info in nslookup
Kevin Darcy
kcd at daimlerchrysler.com
Tue Sep 27 21:13:36 UTC 2005
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
More information about the bind-users
mailing list