Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs URI vs NAPTR
From: "Patrik Fältström" <[email-masked]>
To: [email-masked]
Date: Fri, 09 Nov 2018 11:31:07 +0100
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>

Note changed subject...

Sure, I think of course the URI RR is the best thing since sliced bread, but same for each one of the proponents of the other RRs.

I think we could look at the various deployment scenarios and demonstrate what design features each one of the RRs have. And with such a description, including why the life of the web hosting provider and web site owner ends up being easier it is possible to have a better discussion with implementors of various libraries that do http fetch. Like libcurl.

When comparing the RRs I agree with the features the other records have, but I want to because of this mention why URI is defined as it is.

1. NAPTR did not scale as the size of the RRSet ends up being so large. The selection of the subset of potential records one want should be in the initial query (QNAME, CLASS, TYPE) and not on the client side. Originally URI was because of that designed to replace NAPTR for the ENUM service, to make the algorithm simpler. But that was not accepted as people already had implemented the (nasty) NAPTR algorithm.

2. URI is a RR type that do use a prefix. It is correct one can not have a wildcard, but instead must explicitly have records for all hostnames in the URI that is served. This is though a conscious choice. See [3].

3. URI is a RR type that do use a prefix and thanks to this one can delegate the _tcp.example.com domain name to a separate DNS server and that way delegate across administrative boundaries. Like we already today handle quite often Active Directory and service discovery based on the AD mechanisms Microsoft have deployed. That way the AD server do not have to be the one that faces the internet etc. XFR ends up being simpler and what not.

4. URI do have as RDATA a full URI and not only a new hostname, and that way can be part of the rewrite that is to happen. One do not have to follow whatever well known URI scheme is to be used, but can instead directly refer to the new URI.

4.1. http://www.example.se/path&kalle=1

4.2. Look up _http._tcp.www.example.se -> https://example.se/site3/

4.3. Fetch with HOST=www.example.se https://example.se/site3/path&kalle=1

This is why I still push URI because I feel 1, 3 and 4 together outweighs 3.

But as other writes, what we lack is code.

   Patrik