Unexpected queries

[Kevin Darcy]

Mark Andrews wrote:

>>Mark Andrews wrote:
>>
>>    
>>
>>>>Mark Andrews wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>>-----BEGIN PGP SIGNED MESSAGE-----
>>>>>>Hash: SHA1
>>>>>>
>>>>>>Currently running bind-9.3.1
>>>>>>
>>>>>>When examining logs of DNS queries, I notice
>>>>>>
>>>>>>Dec  4 07:30:43 mp named[212]: client 99.99.99.99#33040: query: huskiesde
>>>>>>            
>>>>>>
>>n.
>>    
>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>ni
>>>>   
>>>>
>>>>        
>>>>
>>>>>>u.edu IN A -E
>>>>>>Dec  4 07:30:43 mp named[212]: client 99.99.99.99#33040: query (cache) 'h
>>>>>>            
>>>>>>
>>us
>>    
>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>ki
>>>>   
>>>>
>>>>        
>>>>
>>>>>>es-den.com/A/IN' denied
>>>>>>
>>>>>>The above query IP address was munged to protect the innocent.
>>>>>>
>>>>>>For the record, the server where this was logged is authoritative for
>>>>>>"niu.edu", but not for "com".
>>>>>>
>>>>>>Off campus queries are restricted to the zones for which we are
>>>>>>authoritative, and hence the "denied" for the second of those
>>>>>>lookups.
>>>>>>
>>>>>>The result of looking up huskiesden.niu.edu from off-campus is
>>>>>>
>>>>>>huskiesden.niu.edu.     86400   IN      CNAME   huskies-den.com.
>>>>>>
>>>>>>when made from on-campus, the result is
>>>>>>
>>>>>>huskiesden.niu.edu.     86400   IN      CNAME   huskies-den.com.
>>>>>>huskies-den.com.        1800    IN      A       207.227.157.52
>>>>>>
>>>>>>Checking for this in yesterday's logs, every lookup of
>>>>>>huskiesden.niu.edu was followed by a lookup for huskies-den.com.
>>>>>>
>>>>>>The total number of lookups is modest, but enough that it is likely
>>>>>>that at least some of the lookups were from other bind servers.  Most
>>>>>>did not respond to a version.bind lookup.  Among those that
>>>>>>responded, I saw 8.4.6-REL, 9.3.1, 9.2.1, 9.2.3
>>>>>>
>>>>>>It seems to me that something is awry here.  If my server is supposed
>>>>>>to provide the info on huskies-den.com along with the CNAME response,
>>>>>>then it should do so based on the acl for huskiesden.niu.edu.  As
>>>>>>long as it fails to provide that record in its initial response, the
>>>>>>off-campus DNS servers should not be looking up a "COM." record at
>>>>>>our DNS server.
>>>>>>
>>>>>>-----BEGIN PGP SIGNATURE-----
>>>>>>Version: GnuPG v1.4.2 (SunOS)
>>>>>>
>>>>>>iD8DBQFDlI0svmGe70vHPUMRAnwAAKCoaW6wYpphA92IRC8jrzAwyKktawCePMk7
>>>>>>+ot9MSlZOaA7ZN6f7VcUDrc=
>>>>>>=PUyd
>>>>>>-----END PGP SIGNATURE-----
>>>>>>  
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>	When you ask a query that refers to a CNAME you follow that
>>>>>	CNAME if you can.  All the log message was saying is that
>>>>>	after following the CNAME the new query was refused.
>>>>>
>>>>>	Note this is the sort of answer where the client needs to
>>>>>	requery after following the CNAME.  It looks like a NODATA
>>>>>	response by isn't.
>>>>>
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>Mark,
>>>>          I think the point is: why is the client restarting the query 
>>>>at the CNAME's authoritative nameserver, instead of looking for the 
>>>>nameservers of the closest-enclosing zone of the canonical name, as per 
>>>>the usual iterative-resolution algorithm? I've noticed this behavior 
>>>>too, and wondered whether it was some sort of "optimization" (e.g. the 
>>>>CNAME owner seems more likely to get back answer in less steps than 
>>>>restarting the query ab initio), or just sloppy coding (forgot to reset 
>>>>who we're querying), or something else. Neil's forensics imply that at 
>>>>least some of these iterative resolvers are BIND.
>>>>   
>>>>
>>>>        
>>>>
>>>	Well when +70% of the worlds iterative resolvers are BIND there
>>>	is a high probability that some of the queries are from BIND.
>>> 
>>>
>>>      
>>>
>>>>                                                                        
>>>>                                                                 - Kevin
>>>>   
>>>>
>>>>        
>>>>
>>>	The query is non-recursive.  Named follows the CNAME.  Attempts
>>>	to look in the cache which is denied by ACL,  logs the fact that
>>>	it was denied, then returns the answer.
>>>
>>>      
>>>
>>Right. No-one is questioning what the authoritative nameserver is 
>>returning. But why is the client coming right back to the same 
>>nameserver to query the canonical name, even though it's not in the 
>>delegation chain for it?
>>    
>>
>
>	It isn't.  You are not reading the logs correctly.  The client
>	is querying for huskiesden.niu.edu.
>
>  
>
>>Is it an optimization, a coding mistake, or something else?
>>    
>>
>
>	It's a noisy log message, nothing more.
>	
>  
>
>>This is a question about iterative-resolver behavior, not
>>authoritative-nameserver behavior.
>>    
>>
>
>	No, it is a question about authoritative-nameserver behavior.
>
>  
>
>>Maybe someone who is familiar with the nuances of BIND 8's and/or
>>BIND 9's resolver code can answer the question. I'm just curious.
>>
I'm sniffing the packets now, and preliminary indications are that there 
are no separate queries for the canonical name. So perhaps it's just a 
case of me misinterpreting the logs. I thought I had nailed down this 
behavior in the past, but maybe it's just my faulty memory, or possibly 
just an isolated instance of resolver misbehavior, probably from a 
non-BIND implementation.

Sorry for the confusion.

                                                                         
                                       - Kevin