[DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME vs URI vs NAPTR

"Patrik Fältström " <paf@frobbit.se> Fri, 09 November 2018 10:31 UTC

Return-Path: <paf@frobbit.se>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EEC130DCC for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 02:31:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.722
X-Spam-Level:
X-Spam-Status: No, score=-1.722 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=frobbit.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YDdm8q0TYFk for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 02:31:17 -0800 (PST)
Received: from mail.frobbit.se (mail.frobbit.se [85.30.129.185]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E640612777C for <dnsop@ietf.org>; Fri, 9 Nov 2018 02:31:16 -0800 (PST)
Received: from [192.71.80.208] (vpn-client-208.netnod.se [192.71.80.208]) by mail.frobbit.se (Postfix) with ESMTPSA id 1842126C19 for <dnsop@ietf.org>; Fri, 9 Nov 2018 11:31:13 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=frobbit.se; s=mail; t=1541759473; bh=uWLLnofGNMJkhLKAFQFQsU2iZJNv6+zWS2o4nzi62xU=; h=From:To:Subject:Date:In-Reply-To:References:From; b=MhbGXlfEfpxZeH80AHhPS6sA1N+enrPNlQ8puqxBhXJJmRvZD9CsUihoZedq7tRYg 4fH0558UoLUFPP+ALEp9seW0LbG4ZMhrhbjoL49cWOw7Dulofei5IHjVprX3HRtiha eSiO6bLLJjRTYn/cqf4BC4779GhjDS12FasRpL1U=
From: Patrik Fältström <paf@frobbit.se>
To: dnsop@ietf.org
Date: Fri, 09 Nov 2018 11:31:07 +0100
X-Mailer: MailMate (1.12.1r5552)
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
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Nov 2018 10:31:19 -0000

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