Unexpected queries

[Mark Andrews]

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


--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org