[dns-operations] resolvers considered harmful

David Conrad drc at virtualized.org
Thu Oct 23 02:27:13 UTC 2014


Mark,

On Oct 22, 2014, at 6:07 PM, Mark Allman <mallman at icir.org> wrote:
> David Conrad <drc at virtualized.org>:
>> As I understand it, you're proposing pushing the resolvers out to the edges 
> That is not what we are proposing.  We are not suggesting resolvers be
> *moved*, but rather *removed*.  That is, clients simply do name lookup
> on their own.

Perhaps I'm being unclear and/or we're having a terminology mismatch. To be concrete: are you suggesting that (a) every application on an 'endpoint' provide its own iterative resolution, (b) the 'end point' effectively runs an iterative caching resolver at 127.0.0.1/::1, or (c) something else?

> All I am saying is that the resolver
> cannot do its job without accepting requests from other hosts.

As a person who frequently runs unbound listening only to 127.0.0.1 on my laptop, we may have differing opinions of the scope of the job of a resolver.

> David Conrad <drc at virtualized.org>:
>> if you're not doing DNSSEC at the edges,
> Let me be clear.... I am not arguing against DNSSEC.  A crypto signed
> record is always better than a clear text record.  But, DNSSEC is still
> not here

It's getting there (cue Geoff Huston :)). BTW, while it may be true that 1% of resolvers validate as you mention in your paper, a more interesting number is the percentage of clients that are getting validated answers.  IIRC, I believe Geoff's numbers are suggesting that percentage is upwards of 20% (too lazy to look it up).

> and it seems to me that factoring out some of the
> intermediaries that we know sometimes both play games and have games
> played on them may well be a useful path.

I don't disagree (and have argued the same thing numerous times). By moving resolution "to the endpoint" (whichever way you mean it), you are presumably reducing the attack surface, specifically erasing the stub-to-resolver vector of attack, at a cost (as Andrew notes) of increased network/authoritative load and latency (whether that cost is negligible is an interesting question).  Of course, this doesn't remove the resolver-to-authoritative vector of attack, it lessens the impact (specifically, a successful attack only impacts the endpoint, not the multiple system that are using the resolver).  My point was that to definitively fix resolver-to-authoritative, you're going to need something like DNSSEC.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20141022/d10e2bc4/attachment.sig>


More information about the dns-operations mailing list