Antoin Verschuren wrote:
-----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.
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: +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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
