From: "Patrik =?utf-8?b?RsOkbHRzdHLDtm0=?=" <paf@frobbit.se>
To: dnsop@ietf.org
Date: Fri, 09 Nov 2018 11:31:07 +0100
Message-ID: <4F024E15-AA7B-4260-85D7-AB9B07D1C7F1@frobbit.se>
In-Reply-To: <57fff590-9e0f-0510-9c8a-bc0abab471b6@bellis.me.uk>
References: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com>
 <2BDA0411-202D-4199-A43B-3FDC50DC47F5@isoc.org>
 <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com>
 <D378E8F5-A667-4649-90ED-7C3612F0A013@isoc.org>
 <a4087032-acb2-0f2e-f84b-31d2885d8390@bellis.me.uk>
 <alpine.DEB.2.20.1811081801580.3596@grey.csi.cam.ac.uk>
 <7702EE25-1B10-4880-804C-C7CF5FE609C8@isc.org>
 <A7834682-C078-4E7F-985E-8FBBF387AC66@dotat.at>
 <57fff590-9e0f-0510-9c8a-bc0abab471b6@bellis.me.uk>
MIME-Version: 1.0
Content-Type: multipart/signed;
 boundary="=_MailMate_B59825F8-8317-4A73-8F49-C2304E8D760C_=";
 micalg=pgp-sha1; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/payq-17upyyQPZavIc0ZuAI5PW8>
Subject: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs
 URI vs NAPTR
Precedence: list

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_B59825F8-8317-4A73-8F49-C2304E8D760C_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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 descripti=
on, 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 imp=
lementors 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. T=
he selection of the subset of potential records one want should be in the=
 initial query (QNAME, CLASS, TYPE) and not on the client side. Originall=
y 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 alrea=
dy 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 deleg=
ate the _tcp.example.com domain name to a separate DNS server and that wa=
y delegate across administrative boundaries. Like we already today handle=
 quite often Active Directory and service discovery based on the AD mecha=
nisms Microsoft have deployed. That way the AD server do not have to be t=
he one that faces the internet etc. XFR ends up being simpler and what no=
t.

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 foll=
ow 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=3D1

4.2. Look up _http._tcp.www.example.se -> https://example.se/site3/

4.3. Fetch with HOST=3Dwww.example.se https://example.se/site3/path&kalle=
=3D1

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

--=_MailMate_B59825F8-8317-4A73-8F49-C2304E8D760C_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iG0EARECAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCW+Vh6w8ccGFmQGZyb2Ji
aXQuc2UACgkQrMabGguI181yZACgj3sI3jPUC0uahQ8PaMWCw6wCkDIAnjE4wg88
WoXX0ETuMJjLKsFp+jaD
=b1qq
-----END PGP SIGNATURE-----

--=_MailMate_B59825F8-8317-4A73-8F49-C2304E8D760C_=--