It is a terminology issue, I think.

> 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? 

(c)

Or, all of them!

The implementation does not matter to me.  An app could just run "dig
+short" for all I care.  My point is that this is an entirely internal
matter to the host.  Unlike the case of a shared resolver there is no
requirement that it accept any lookup request from outside the box.

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

I should---as I hope we do in the paper---be careful and use the term
'shared resolver' for something outside the host itself.

> My point was that to definitively fix resolver-to-authoritative,
> you're going to need something like DNSSEC.

Yes- absolutely.  E.g., just because a client does the name lookup
instead of handing to a shared resolver isn't going to make the great
firewall any less likely to forge a response.  So, I don't mean to in
any way say DNSSEC isn't useful.

allman



Attachment: pgp4JunCe_ilo.pgp
Description: PGP signature

_______________________________________________
dns-operations mailing list
[email protected]
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Reply via email to