Re: Additional filtering of responses

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

[e-mail] wrote on 08/07/2008 06:46:44 PM:

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

I was trying to address the group in general, you happened to be on the 
recipient list. Forgot to scrub that ;-)

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

Thanks for the pointer. I'll ping DW.

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

Agree

Roy


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