On Mon, 13 Jul 2009, Paul Hoffman wrote:

I think you need to widen that caveat: anything that isn't a web browser
should not use a DNS server that misbehaves as described in this draft.

I think you need to widen that caveat: anything should not use a DNS server
that misbehaves as described in this draft.

Paul: that's over the top. Some of the services defined in the draft are highly desired 
by some Internet users. You may not like them, and that's fine. Your statement is akin 
to, and as useful as, the "NATs are bad so we shouldn't talk about them" debate 
that flares in the IETF approximately biannually.

There is a huge difference here. With NAT, one is putting some
inconvenience to the end user and the server administrator that requires
some clarifications in protocols and some support with detecting it
and working with it. With manipulating my laptop's DNS asking for MY
OWN cryptographically signed data, you are asking me to throw out the
crypto protection and make me accept a downgrade attack.

The IETF allowing or endorsing any kind of DNS forging in the age of
DNSSEC is simply wrong. There can be other methods, such as DHCP related
options, that can be used to notify or redirect a user without resorting
to crippling DNSSEC security.

I have serious problems with:

   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.

Validating stub resolvers will become the norm, with more and more
devices connecting to whatever they can get (and not trust). Modifying
DNS answers was a hack because there is no "Please go here first with
a browser" DHCP option. We need to phase outsuch practises, and not
endorse them in any way.

In fact, most hotspots now grab port 80 for their redirects and allow
DNS requests to go out unmodified, which is a much better way of handling
the hot spot scenario.

As for the various commercial races on who gets to sell ads on typoed
domains, non-existing domains et. all, I think the IETF should not
participate either. These fall in the same domain as the MIME type wars,
the search engine setting wars, the home page changing wars, the file
extension changing wars. Whatever the IETF would recommend, some vendor
will override it because they are losing revenue because of it.

Paul
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to