Trying to get full domain info in nslookup

[Kevin Darcy]

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?

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

                                                                         
                                       -Kevin

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