Unexpected queries

[Kevin Darcy]

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) 'huski
>>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.

                                                                         
                                                                  - Kevin