On Sun, Apr 15, 2012 at 09:24:35PM -0700, David Conrad wrote: > On Apr 15, 2012, at 6:28 PM, Scott Schmit wrote: > > It's manual for now...until the utter lack of consequences for screwing > > up (everybody can still get to the broken zones just fine) junks up the > > NTA lists. > > Given the implicit assertions associated with NTA (specifically, that > the validator operator is asserting that the zone in question is not > being spoofed despite the fact that validation is failing), I have > some skepticism that folks will let stuff like this 'junk up NTA > lists'.
Please explain how operators will prevent this, and why they can afford to remove a zone from the NTA list (while it is still failing) but couldn't afford to leave it off the list in the first place. > > If the resolver is unable to validate the domain, it MAY return a false > > result leading the user to a host that will explain the error and how to > > notify the domain owner of the problem. > > Not sure I follow -- are you proposing additional error codes in stub > resolver responses? No, I'm talking about a targeted use of the controversial practice of returning spoofed results redirecting the user to another host. Since the usual protocol in use is HTTP or HTTPS, that host presents a web page with the desired content (usually a search page with embedded ads, or a portal page requesting payment and/or providing terms of use that must be accepted before continuing). It may be possible to provide application-level error messages for other protocols to be served by that host in support of non-HTTP/HTTPS traffic (email bounces, etc). In this case, the page would educate the user that there's something wrong with the site, and offer a way to let the user let the site know about the problem. This shifts the perception of brokenness back toward the site causing the problem (or at least attempts to). If desired, one could also go the captive portal route and let the user through after they've seen/acknowledged the error page (for some amount of time). References: https://en.wikipedia.org/wiki/DNS_hijacking https://en.wikipedia.org/wiki/Captive_portal -- Scott Schmit
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
