Trying to get full domain info in nslookup

Mark Andrews Mark_Andrews at isc.org
Wed Sep 28 01:15:08 UTC 2005


> Mark Andrews wrote:
> 
> >>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.
> >
> In response to a *non-recursive* query, sure. All of the example queries 
> in Section 6.2.2 are RD=0 unless otherwise noted (see the intro 
> paragraph at 6.2). Nowhere in 1034/1035 is it permitted to treat an RD=1 
> query as RD=0 and yet return the response as RA=1, which is what BIND 
> does.  That's just fibbing. Of course, BIND or any DNS implementation for 
> that matter, can decline to recurse a query but a) this decision should 
> IMO be policy-driven, not hardcoded for QTYPE=* queries, and b) the 
> responding server shouldn't *lie* about whether it is honoring recursion 
> or not. Don't you think it kind of defeats the whole purpose of the RA 
> bit if responders can set it any way they want, for any arbitrary reason?

	The nameserver is not required to recurse if it can answer
	from the cache.  "*" is clearly NOT required to return all
	possible records.

3.7.1. Standard queries

*               matches all RR types.

	"*" matches NOT returns all RR types.  When you have a incomplete
	cache "*" matches all records there.

5.3.3. Algorithm

The top level algorithm has four steps:

   1. See if the answer is in local information, and if so return
      it to the client.

	....

Step 1 searches the cache for the desired data. If the data is in the
cache, it is assumed to be good enough for normal use.  Some resolvers
have an option at the user interface which will force the resolver to
ignore the cached data and consult with an authoritative server.  This
is not recommended as the default.  If the resolver has direct access to
a name server's zones, it should check to see if the desired data is
present in authoritative form, and if so, use the authoritative data in
preference to cached data.

> 
> >	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.
> >
> The former option is probably preferable rom a code-simplicity 
> standpoint, the latter from a performance/resource-consumption 
> standpoint. Note that if only *one* RRset has expired from the cache, it 
> should only be necessary to recurse for a fresh version of just that one 
> RRset, not necessarily the full nameset (of course, this is subject to 
> local and/or adaptive optimization; it might make sense to do the 
> QTYPE=* query anyway, because the additional overhead is relatively low 
> compared to the benefits of "freshening" all of the other cached RRsets 
> under the name).
> 
> >	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.
> >
> 1. We're dealing with the buffer-size/truncation/TCP-retry issue anyway 
> for DNSSEC
> 2. If the app can make do with an non-deterministic subset of the data, 
> it always has the option of issuing a non-recursive query (like the ones 
> exemplified in Section 6.2.2). If it absolutely *must* have a full set 
> of data, and can't get it because it's too big, and doesn't have a 
> fallback option of issuing multiple type-specific queries, then that's 
> the fault of the app and/or the respetive domain owner(s). We shouldn't 
> be trying to save those folks from themselves. They'll eventually learn 
> the error of their ways and either change the app and/or trim down the 
> namesets to a reasonable size.

	I've yet to see a application (other than a zone/dns maintenance
	application) that needs to see all the record types at a node.

>                                        -Kevin
> 
> P.S. I'm surprised you didn't bring up the negative-caching implications.

	What negative cache implications?  Either there node is empty,
	does not exist or has data.  It takes as much space to store that
	a node is empty as it takes to remember that a not doesn't exist
	or that is doesn't have a particuler RR type.

	Not have MX records has negative-caching implications if the
	site receives email.
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org



More information about the bind-users mailing list