Unexpected queries

[Mark Andrews]

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

dig huskiesden.niu.edu +norec @mp.cs.niu.edu.

; <<>> DiG 8.3 <<>> huskiesden.niu.edu +norec @mp.cs.niu.edu. 
; (2 servers found)
;; res options: init defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 732
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUERY SECTION:
;;      huskiesden.niu.edu, type = A, class = IN

;; ANSWER SECTION:
huskiesden.niu.edu.     1D IN CNAME     huskies-den.com.

;; Total query time: 226 msec
;; FROM: drugs.dv.isc.org to SERVER: 131.156.68.41
;; WHEN: Tue Dec  6 08:29:30 2005
;; MSG SIZE  sent: 36  rcvd: 65

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