On Jul 9, 2009, at 5:23 PM, Livingood, Jason wrote:
I submitted this draft, which you can find at http://tools.ietf.org/html/draft-livingood-dns-redirect-00
, before the –00 cutoff on Monday, and it will be discussed in the
DNSOP WG meeting at IETF 75 (it is listed on the agenda).
If anyone is interested and has time before IETF 75, I’m happy to
take feedback before then obviously. Please note that there is a
list of open items at the end, which we plan to address in
subsequent versions.
This part of section 10 is troublesome:
So the only case where DNS security extensions cause problems for
DNS Redirect is with a validating stub resolver. This case doesn't
have widespread deployment now and could be mitigated by using trust
anchor, configured by the applicable ISP or DNS ASP, that could be
used to sign the redirected answers.
This mitigation strategy just doesn't work, and for a very good
reason, as it allows a downgrade attack.
As for the rest of the document, I think it overloads the term
"redirection" by incorporating lawfully mandated filtering (whatever
that means), and therefor wrongly justifying this practice altogether.
In general, this kind of muddling with the DNS protocol assumes that
the sole purpose of the DNS is to allow a web-browser find the address
of a web-server. Clearly it is not.
There are alternatives. I run unbound from my laptop. Windows users
can do too: http://unbound.net/downloads/unbound_setup_1.3.1.exe
Other alternatives are OARC's ODVR: https://www.dns-oarc.net/oarc/services/odvr
Kind regards,
Roy Arends
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
