[dns-operations] summary of recent vulnerabilities in DNS security.
keith at dns-oarc.net
Tue Oct 22 16:53:21 UTC 2013
On 10/22/2013 10:52 AM, Haya Shulman wrote:
>> Disclosing such potential vulnerabilities remains valuable work,
>> but I think careful consideration needs to be applied to the
>> engineering economics of the best operational-world mitigation
> @/Keith Mitchell/
(My head is *really* hurting from this quotation formatting..)-:
(re-wrapping and indenting to list conventions...)
> I do not advocate to deploy these or other countermeasures. Above
> any doubt you are in the best position to decide which
> countermeasures to deploy.
Not really, OARC does not operate production service-providing
infrastructure except to support a membership organization, most of our
infrastructure is dedicated to data-gathering/testbed/research purposes.
So I defer to *real* DNS infrastructure operators and implementors on
any such judgments.
> The situation with DNS checkers is different from deployment of port
> randomisation. DNS checkers is a very important service to the
> community and the efforts that their operators took to make them
> available is very valuable. However, an illusion of security is more
> dangerous than not being protected at all (in the later case one is
> aware that he is not protected and may be attacked).
> I admit that I do not know what economic effort is required to patch
> DNS checkers which report per-destination ports, recommended in
> [RFC6056], as secure
Well, more than we've been able to dedicate in the past month or so. I'm
trying to get an estimate of this from those best placed to do the
> but I suggested a fix to this vulnerability some time ago, that
> should be fairly simple to implement;
Yes, but as I explained privately previously, there is no record of this
correspondence through official OARC channels - I did request you
re-send, but I don't have a copy of it.
> the problem with the porttest checker is that each IP address of the
> checker system receives a single query from the tested resolver, and
> so to each such IP address a random port is selected. But, if more
> than a single query were sent to each checker IP during the test,
> then the predictable sequence would be easily identified.
Thank you for this clarification - any further points you have about the
best way to implement the fix to this would be welcome, but are likely
best taken off-list.
More information about the dns-operations