Re: [DNSOP] Review of draft-livingood-dns-redirect-00

[Eric Brunner-Williams <[e-mail]>]

Antoin Verschuren wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
>   
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] 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.
>   

I would be happy with some statement that the use of unique identifiers 
created by the IANA function, and delegated to parties which in turn 
delegate these assets to network operators, in particular AS numbers and 
address space, have some policy restrictions. I don't know what they 
are, but if operator X doesn't use directly, or consume transit that 
does use those assets (back to the pre-CIX world), then the conduct of 
operator X is not inherently subject to the union of policies of 
upstream providers, and ultimately, the policy associated with the IANA 
function. Note, I'm not asserting the existence of a policy exercised 
presently by the IANA function, only the possibility. In my fantasy life 
I'd like to see BCP38 mandatory, and the BGP trusted-chain-of-delegation 
rooted.

We have rfc1918 for "private" spaces. I wouldn't first appeal to the 
"general public perception" argument, though Antoin does point out in 
the same para (below) that the issue may not be "are operator X's 
facilities a public resource", but the market power of operator X to 
restrict third parties from offering services to operator X's 
subscribers. Note, "market power" is a local matter, applicable to the 
operator used as an example.
> 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 idea has been discussed by others in the context of TLDs with 
"local scope", the largest examples of these are as you mention, 
associated with national governments which may impose, for local policy 
reasons, two or more "views" on a name space.

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

Years earlier I considered mechanisms to distinguish verifiable data 
collection practice assertions on HTTP cookies, so that jurisdictions 
(the FTC in the US, the data protection authorities in the EU member 
states, etc.) could "police" what in this conversation I'll call "lying 
cookies", where the "lie" covers not only the data collection policy 
asserted, but also the scope of the name space(s) for which the 
assertion was offered.

I'd like to see -dns-redirect- go forward, more or less for the same 
reasons Suzanne gave, and 
-dns-response-modification-considered-harmful-, as well as a 
-http(s)-intercept-and-redirect- .

However, I don't think there is sufficient public discussion of the 
underlying motivation, the details of the PPC business. In the ICANN 
policy arena the marks interests, eager to stamp out "lying resolution" 
at the lie-exists-in-published-string-space level, overlook the 
motivation of presumably rational economic actors, who manage portfolios 
of domain names, in aggregate, running well into the millions, mostly in 
the pre-ICANN name spaces. In the DNSOP policy arena (here) we're 
discussing "lying resolvers" at the lie-exists-in-resolvers level, and 
we can't be much smarter about why, not just how, what is asserted to be 
a problem exists, we may end up just as limited in our utility as the 
those lawyers.

So, if anyone wants to share PPC facts, I propose a -mumble-ppc-mumble-, 
to inform us, drop me a note or catch me at Stockholm.

> 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: [phone]  F: [phone]  M: [phone]
> mailto:[e-mail]  xmpp:[e-mail]  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop
>
>
>