Long response for a non-authoritative answers

[Mark_Andrews at isc.org]

> > > Right.  That means that the answer is not in your local cache, so
> > >your local nameserver has to go find the answer before it can display
> > >it to you.
> >
> > But if the answer came from the authoritative server, it should be an
> > authoritative answer.  If the answer is non-authoritative, it means it
> came
> > from the cache, so the response time shouldn't have been long.
> 
> Actually, BIND 9's different from BIND 8 in that regard.  Watch me
> query my BIND 9.2.0rc3 name server for a domain name it doesn't
> have cached:
> 
> $ dig cnn.com.
> 
> ; <<>> DiG 8.3 <<>> cnn.com.
> ;; res options: init recurs defnam dnsrch
> ;; got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 10, AUTHORITY: 4, ADDITIONAL: 0
> ;; QUERY SECTION:
> ;;      cnn.com, type = A, class = IN
> 
> ;; ANSWER SECTION:
> cnn.com.                15M IN A        64.12.50.249
> cnn.com.                15M IN A        207.25.71.5
> cnn.com.                15M IN A        207.25.71.25
> cnn.com.                15M IN A        207.25.71.27
> cnn.com.                15M IN A        207.25.71.29
> cnn.com.                15M IN A        64.12.48.217
> cnn.com.                15M IN A        64.12.48.249
> cnn.com.                15M IN A        64.12.50.121
> cnn.com.                15M IN A        64.12.50.153
> cnn.com.                15M IN A        64.12.50.217
> 
> Note how suspiciously round the TTLs are, and yet no "aa" bit.
> 
> Personally, I thought the old behavior, of returning the first answer
> with "aa" set, made a certain amount of sense.
> 
> cricket
> 
> Men & Mice
> DNS Software & Services
> www.menandmice.com

	The answers with AA set were received packets being forwarded.
	These sometimes let records through which they really
	shouldn't have.  Some of the fixes in 8.2.5 address this
	sort of leakage.

	The fact that there is no AA should make you more comfortable
	because then you know ever record in the answer has been
	through the cache (and hence the cache protection algorithms).

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