Unexpected queries

[Kevin Darcy]

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: huskiesden.
>>>>        
>>>>
>>ni
>>    
>>
>>>>u.edu IN A -E
>>>>Dec  4 07:30:43 mp named[212]: client 99.99.99.99#33040: query (cache) 'hus
>>>>        
>>>>
>>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? Is it an optimization, a coding mistake, or 
something else? This is a question about iterative-resolver behavior, 
not 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.

                                                                         
                                                                     - Kevin