This is a discussion on Re: More 0x20 craziness - DNS ; --On 29 August 2008 16:54:51 +0000 Paul Vixie wrote: > i love the sound of that, except, there isn't "an" additional query in the > sense of "the one at the end that turns out to be one too many, ...
--On 29 August 2008 16:54:51 +0000 Paul Vixie
> i love the sound of that, except, there isn't "an" additional query in the
> sense of "the one at the end that turns out to be one too many, that we'd
> like to avoid". you literally don't know which one is going to be the one
> you'd be trying to avoid, until after you've received an answer to it.
I need to think a bit more about that. I think a query by query illustration
of how the "section by section" approach works would help illustrate it
to people in general (not just me).
> issue the first is, the goal of this part of the proposal is to make it
> possible to be very draconian in the NS RRset replacement strategy, and
> i'm pretty sure that the number of bits i'd want to be protected by is
> in the 64-or-so range when i'm about to make a predictable refill query.
> issue the second is, one never knows if there's a UDP port derandomizer
> somewhere in the path between an RDNS and an ADNS, so the number of 0x20
> bits needed for full confidence is really 48 or so, and that's a very
> long qname indeed.
Is it a reasonable assumption that if "the internet" (perhaps signaled
by a couple of test probes) is not behind a port derandomiser, then
no nameserver is? IE is discovery that an RDNS is "behind" a derandomiser
(NAT / ALG etc.) sufficient to use as a heuristic for needing more
entropy in the qname (under 0x20 or some other proposal), or do we
also need to consider the case where any arbitrary ADNS might have
a derandomiser in front of it? I am thinking that if we could put
in the category of "if you run an ADNS like this you deserve to get
your domains spoofed more easily", then an RDNS which could detect
whether it is behind a NAT through queries to a couple of servers
that happened to support a suitable extension could by extension apply
(or not apply) that to all servers, and hence require more bits of
A possible nit with approaches that rely on prepending data to
the qname is that they risk shortening the maximum 'true' qname
length. I think in the real world the heaviest user here is NSEC3
(no comments about DNSSEC and 'real world' in the same sentence
please) and one presumes that this isn't a problem.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.