Re: Additional filtering of responses

["Roy Arends" <[e-mail]>]

Paul Vixie wrote on 08/07/2008 05:22:32 PM:

> Re: Additional filtering of responses
> 
> > 1) Stuff in the additional section. RFC2181. Understand why Masataka 
and
> > Paul think it is very important, and worth bickering over. Just 
mentioning.
> 
> first, we should not send, or if we receive, we should not cache or 
forward,
> anything in the additional section that could be found using a new 
query.
> this rules out all records except those referred to by NS RRs in an 
authority
> or answer section, whose target names are at-or-below the NS RR owner 
name.


What does the scripture say about the following, very small (see * below) 
response:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37612
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;010a.example.          IN      A

;; ANSWER SECTION:
010a.example.           86400   IN      A       192.0.2.9

;; AUTHORITY SECTION:
example.                86400   IN      NS      010a.example.

;; Query time: 3 msec
;; SERVER: 192.0.2.10#53(192.0.2.10)

No glue. No additional section. 

Is the address record in the answer section cached? 
When cached, is 192.0.2.9 considered authoritative now for future lookups 
under example? 
Will that NS record ever expire if a query is send once a day ?

With all scrubbing and additional filtering of responses, will this 
response cause a successful cache-(over)write of example NS records?

No criticism about scrubbers and filters, just curious of what 
implementations do and what the protocol dictates.

Roy Arends
Nominet.

(*) The wireformat of this DNS message is just 60 octets due to the use of 
compression pointers.

--
to unsubscribe send a message to [e-mail] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>