Unexpected queries

[Mark Andrews]

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