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