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

["Antoin Verschuren" <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> Stephane Bortzmeyer
> Subject: Re: [DNSOP] Review of draft-livingood-dns-redirect-00
> 
> Disclaimer: I find the whole idea a very bad one, a violation of
> network neutrality and certainly a service I would never accept from
> my ISP.

While I strongly agree with Stephane's sentiment here, I do see some merits in describing why it is a bad idea instead of describing how it should be done with as little problems as possible (but still with problems).

First thing that comes up is the lawyers and marketing concept that http is the Internet.
The document is trying to avoid that discussion by saying that deep packet inspection should occur to determine that an http request was made, but then we're not talking DNS anymore. I get the strong feeling this is fundamentally against what RFC4367 is arguing about.
Not only is it not true that the majority is only doing simple web browsing, but there are more and more applications and use of http, that would not allow a landing page to work.
I can think of alternative ports of web pages that do http, but also application that use http on port 80 without it being a web browser. Think of embedded http video streaming, or other applications that use the http protocol without being a browser. More and more apps work like that.

Another use case that I see a lot in small and medium size companies and even in the consumer market, and that I don't see described in the document is where a company runs 1 resolver on its own network and uses the resolver of its ISP as a backup or other redundancy reasons. If the ISP's resolver has a different truth than the own resolver, things will go very bad on the user experience side. The DNS is the DNS. There should not be multiple versions of the truth on the network.

And finally, I also don't see a description on how things might go wrong if resolvers are behind a load balancer, and the 2 or more resolvers behind it 
don't have the same filtering policy in place.

All in all I see more use cases where it degrades the user experience instead of improving it, and therefore it's a bad idea to do this in the network.
It will force end-users to deploy their own resolvers and validators to get a better user experience, and while that might seem infeasible today for ordinary users, I can't wait for the first app to arrive that has a resolver built in instead of using the default OS resolver to bypass that trouble.
Perhaps that built in resolver will even do DNS over http ! :-).
Because that will downscale the use of cached responses, I wouldn't want to go that path as it would increase the load on authoritative servers.

The only feasible use I see for a landing page is where it is invoked by an end-point in terms of a web browser that has it explicitly configured to go there when an NXDOMAIN is received by the application.



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)

wsBVAwUBSlsgUzqHrM883AgnAQgkFAgAjM/RguYXdKVL+/CeBK2OP2JsqsK1bVD6
nBmho2lpWNOh1pTllJYX5eaJzF24wDZ0P062u52P8qDMOuXOoKWP+pNRSvDKIzj6
XEyt5HazpnlY5+0mohuwDvNjRR9im2VN0vpt5LZhs3Z0EJR5ShHJJuU/xY6B5UoP
QlEMyBfZZ3PPZSoR2AR4jJO9wTraDS5Q+zkwWSYUoIQskjBMGNjqhPfFF1m6IAoC
UA4HWEDDQVfmY/mXtmCDigw4NorIJk2oakjSdYuF7MSaS3N3r1a0jnMNdHaV5LEg
ddR2ieOc+VkXtLa7f+LNb2gJrtwaqlKoUKDWzFjVeAHzxzeLj9EydA==
=eKJQ
-----END PGP SIGNATURE-----