Re: Additional filtering of responses

[Paul Vixie <[e-mail]>]

From: "Roy Arends" <[e-mail]>
> Paul Vixie wrote on 08/07/2008 05:22:32 PM:
> > ...
> 
> What does the scripture say about the following, very small (see * below) 
> response:

what am i, your prophet?  to hell with the scriptures, here's my take on it.

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

yes, since it matches the qname and it's in the zone you were querying.

> When cached, is 192.0.2.9 considered authoritative now for future lookups 
> under example? 

yes, since it was received as an answer, it's presumed to be the same as
the answer one would get by discarding it and re-asking for it.  (that's
what's different about this case vs. the additional data case.)

> Will that NS record ever expire if a query is send once a day ?

your example shows an authoritative response.  your question here is about
expiry and therefore caching.  the TTL would tick down, and on the seventh
day it would expire, and a subsequent query would cause us to go back to
the root zone for a new delegation response.

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

yes.

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

the protocol is horribly weak in terms of datapath protection.  the whole
thing is laboratory-grade.  the only true fix for any of this is dnssec.

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

i think DW (DNS-OARC) has a wiki where stuff like this can be shared, fwiw.

note that RTT banding, to make more random the RDNS' selection of an ADNS,
is another terrible idea (similar to dns-0x20 in its terribleness but also
in the ability to deploy it without a forklift of the whole infrastructure),
which would make it little bit harder to spoof .COM delegation responses.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


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