Re: draft-ietf-dnsext-forgery-resilience-01.txt

[Florian Weimer <fw@deneb.enyo.de>]

* Shane Kerr:

>> Why are ID clashes a problem?  Do real-world authoritative servers
>> misbehave when confronted with them?
>
> Well, it's a resolver that picks the query ID, but this is a good
> question.

Yes, and it has to choose them in a way that doesn't trigger bugs in
authoritative servers (or upstream resolvers, if there's a hierarchy).

> The only time you have an actual clash is when you have a duplicate ID+source
> IP+source port+destination IP+destination port for a UDP query, because then the
> resolver has no way to disambiguate the replies it gets.

In a typical setup, this will just look like a duplicate packet.  And
thanks to certain load balancers, you already need to deal with this
situation on the resolver side.

Parallel UDP and TCP queries with the same ID could be a different
matter.

> Certainly some implementations may have problems with duplicate query IDs, but
> that's out of scope for an RFC, IMHO.

Does that mean ID collision avoidance is just based on a hunch?  I don't
want to sound disparaging--I just hope that we can get rid of the
additional complexity such a requirement implies.

I agree that if collision avoidance isn't a must, the RFC can be silent
on this issue.

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