This is a discussion on Re: increasing DNS message entropy, a solution for NATs - DNS ; Roy Arends wrote: > The proposed solution to solve the problem highlighted by Dan Kaminsky is > randomizing source ports. As some have mentioned, NAT/PAT scenarios do not > benefit from this solution. I'm not as up on firewall/NAT stuff ...
Roy Arends wrote:
> The proposed solution to solve the problem highlighted by Dan Kaminsky is
> randomizing source ports. As some have mentioned, NAT/PAT scenarios do not
> benefit from this solution.
I'm not as up on firewall/NAT stuff as I used to be, but don't most of
them nowadays try to assign the same port on the outside as the client
starts with on the inside? I do know that most firewalls nowadays have
knobs to enable "randomization" of the outgoing UDP ports, so while it
may not have the same level of effectiveness as what BIND is doing
directly, it is "better than nothing."
> A while back, Alessandro Linari (Oxford Brookes, working in our advanced
> projects team), mentioned this alternative solution:
> A simple, straightforward method to increase entropy in DNS message
> transaction, is to query for the same name twice (or N times for even more
> increased entropy) and require that the answers be the same. This does
> require a change to the resolver, but not to the authoritative server.
That actually depends on how the authoritative server is configured.
For example, I've written in the past about a hack we added when I was
DNS Admin at Yahoo! to limit the number of A records in a rotor to
those that would fit into a 512 byte UDP packet. So, if this proposal
was in effect at that time, you would be virtually certain to get a
different response _every_ time you query, which would trigger the
"we're being attacked" alarm.
I don't want to go down the "but that's a protocol violation" road
again on this topic, I know it is. My point in this context is that
this is being done "out in the wild," and it's probably being done a
lot more often than people realize.
Plenty of other folks have chimed in on why this multiple query idea
is probably not a good path to pursue, but I thought I'd throw one
more log on the fire.
to unsubscribe send a message to firstname.lastname@example.org with
the word 'unsubscribe' in a single line as the message text body.