[dns-operations] Why non-repeating transaction IDs?

Paul Vixie paul at vix.com
Fri Aug 3 21:02:04 UTC 2007

> > i first heard this idea from dan bernstein, and it's a good one.  ...
> It is indeed very good. It additionally alows a resolver to connect() its
> sockets, which means ICMP messages get delivered to the nameserver, allowing
> it act more quickly on filtered or non-running remotes.

in my implementation, there's an ICMP socket open, and i just parse the
messages.  yes, this means throwing away a lot of crap that's not for me,
but it means i don't have to connect() my sockets, and i can use a small
number (16 of them, as i said) to handle an effectively unlimited number
of upstream transactions.  i would worry about one-descriptor-one-transaction
since i might have more than FD_SETSIZE (or ever UDP_PORTMAX) transactions
in flight at a moment.  again, this is not in BIND, but it could be if it
turns out to be a good idea.

> If I understand you correctly, having 16 random ports as you describe is a
> subset of the proposals in
> http://ds9a.nl/tmp/draft-ietf-dnsext-forgery-resilience.html#anchor17


> I'd very much advise BIND to do something like this.

we'll see if marka agrees with you.

More information about the dns-operations mailing list