Trying to get full domain info in nslookup

[Mark Andrews]

> 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.

	In your opinion.  Please re-read Section 6.2.2.   It clearly
	show the caching servers returning subsets of records.

	One could argue that named shouldn't even recurse in a
	attempt to get some sort of a answer but then you would not
	be able to determine if NXDOMAIN should be returned or not.

> 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.

	To turn "*" into ALL the cache the cache would have to make
	a "*" query for every query it made or remember it had made
	a "*" query and clear that state whenever it expired a RRset.

	You then also have to deal with the fact that "*" queries are 
	more likely to exceed the various DNS buffer sizes causing
	fallover to TCP initially and then truncated TCP responses
	(authoritative servers) or failures from caches as they can't
	get a non truncated response.

	In other words "*" queries are a bad idea, especially as you
	would like them to be implemented.

	Mark
 
> - Kevin
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org