-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 > -----Original Message----- > From: dnsop-boun...@ietf.org [mailto:dnsop-boun...@ietf.org] On Behalf Of > David Conrad > Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00 > > As far as I can tell, Comcast's network and their recursive servers > are not a "public resource". As folks on Comcast's network are not > forced to be Comcast's customer nor (as far as I know) are they > required to use Comcast's name servers, I don't see where you, this > working group, or the IETF has a right to determine what Comcast does.
I tend to disagree with you here. If Comcast is selling it's service as "Internet service" the general public might think that that's the way it should work, and we would all suffer from that general public's perception. If it would break some applications, a general user would think that the application is broken, not "The Internet" as offered by Comcast. So application builders will design their products to work on the "broken" Comcast network, or go bankrupt. I'm actually thinking that we are fighting this war on a wrong battleground. Just because DNS is wrongly considered to be the easiest hammer doesn't mean it fits every nail. I very much see the benefits of protecting innocent users from the bad of the Internet. But if it's web pages that are the bad thing, fight that. I'm very much in favor of writing a draft-arends-dns-response-modification-considered-harmful-00 I'll explain further on. At the same time, if I had enough knowledge of http(s), I would even want to contribute to a draft draft-verschuren-http(s)-intercept-and-redirect-00 Because I think that is the right battleground for this. I don't know where such a discussion should take place though, but certainly not here. So for harmful content of web pages, intercept and redirect http(s) traffic. For unclear errors in browsers when typos are made, fix the browsers. I'll explain where I see the conflicts. The "Internet" has gone above a technical definition. It's considered a brand name or at least a steady concept. (forgive my searching for the correct term as non-native speaker) The same is true, or even more, for domain names. TLD's and domain owners consider their domains as brand names, and might fight if somebody is affecting their autonomy. Since the game that's being played here is not about technology but about dollars, image, politics and policy, consider where this fight might end. The suggestion I'm making is not one I favor, but just as an indication of where the DNS redirection path might end: If ISP's start to mess up the authoritative answers for my TLD, I might consider protecting my brand name with a split view on my TLD. One view for "proper" resolvers, with real answers and NXdomains. The other view would be for "lying" resolvers where I would enter a wildcard so that my "brand name" TLD would show a proper error message without adds, preferred search engines or harmful content instead of the one from the lying resolver. I would do this to protect the image of the TLD as being a "safe" TLD to register your name in. It would protect my TLD against redirects that are not considered "appropriate" for the image or local policy under my TLD. I would make a blacklist of resolvers I know are lying, and redirect them to the wildcard view of the DNS infrastructure. This might even be imposed by ignorant local governments. This would be a war without an end, so again, I don't want to go this path. It will be a war between the ones with power and the ones with money, and in the end, it does not help the "Internet" user. So please, if harmful web content is the problem, fix that. Perhaps we need a screwdriver instead of a hammer. If unclear error messages in browsers are the problem, fix that. Perhaps we need a saw instead of a hammer. The dollars against politics war is one we're not going to win on instable technical solutions. Antoin Verschuren Technical Policy Advisor SIDN Utrechtseweg 310, PO Box 5022, 6802 EA Arnhem, The Netherlands P: +31 26 3525500 F: +31 26 3525505 M: +31 6 23368970 mailto:antoin.verschu...@sidn.nl xmpp:ant...@jabber.sidn.nl http://www.sidn.nl/ -----BEGIN PGP SIGNATURE----- Version: 9.6.3 (Build 3017) wsBVAwUBSmA6dzqHrM883AgnAQhTqggAsrRaGi/ZPuJ7ZnKUYtaKdxz7iaeyi2nU nCT/YXI4w/OudjyRapMmTvKGgb2tmGnN1nEPUXnwraDGV628HkqU/GJG6AwTq8X+ k3S7YGC5MUjgUVG/O1fux7oSMY4YmHhMngJWpBzhsAosA1yRtAGW/9iKZTs01t1S hYWssFkjLh+MGNn2t+FD93p8HsY4fiYcO2QZh8KZOTHPMCeezyni+ODxEMftbD+L aQLk8Hw/xJEf3TIfR8NE1csL+jV32yWKBFAebjq3+cNtGgH7eHRHuetHjxl2L5nW X3NK+zHswu9vvckmg5mTAoJ5u188Hgv2njS0DKFe8YdUKNK0DgNoVg== =ib4t -----END PGP SIGNATURE----- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
