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

Måns Nilsson <mansaxel@besserwisser.org> Fri, 09 November 2018 12:28 UTC

Return-Path: <mansaxel@besserwisser.org>
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 06FBC130E5A for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 04:28:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.22
X-Spam-Level:
X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 qBW12m1KzwNB for <dnsop@ietfa.amsl.com>; Fri, 9 Nov 2018 04:28:27 -0800 (PST)
Received: from jaja.besserwisser.org (jaja.besserwisser.org [192.36.115.55]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6EF130E16 for <dnsop@ietf.org>; Fri, 9 Nov 2018 04:28:27 -0800 (PST)
Received: by jaja.besserwisser.org (Postfix, from userid 1004) id 19C939E64; Fri, 9 Nov 2018 13:28:25 +0100 (CET)
Date: Fri, 09 Nov 2018 13:28:25 +0100
From: Måns Nilsson <mansaxel@besserwisser.org>
To: Paul Vixie <paul@redbarn.org>
Cc: Ray Bellis <ray@bellis.me.uk>, dnsop@ietf.org
Message-ID: <20181109122824.GB2115@besserwisser.org>
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> <5BE4F151.8000802@redbarn.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="H+4ONPRPur6+Ovig"
Content-Disposition: inline
In-Reply-To: <5BE4F151.8000802@redbarn.org>
X-URL: http://vvv.besserwisser.org
X-Clacks-Overhead: "GNU Sir Terry Pratchett"
X-Purpose: More of everything NOW!
X-happyness: Life is good.
User-Agent: Mutt/1.7.2 (2016-11-26)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KOwu0M9zl0I5QyQctbkrpy-a-sw>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
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 12:28:32 -0000

Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME Date: Thu, Nov 08, 2018 at 06:30:41PM -0800 Quoting Paul Vixie (paul@redbarn.org):

> i am loath to create per-service record types. that's why SRV. if you really
> want every client of a service to query for something other than AAAA/A, can
> you try to fix what's wrong with SRV regarding wildcards, but avoid a new

In my sometimes half-working brain a SRV or URI record can be a wildcard. 

If we look at it this way: The user is going to (unless they are
led by a search engine) type a domain name of the form "trademark.TLD"
into their client. Today, the client does matching to actual domain
names by asking for trademark.tld A/AAAA and www.trademark.tld
A/AAAA. (2 queries, not counting the CDN CNAME chain) 

We, or more specifically, people asking for data, can elect to treat the
URI record for 'trademark.tld' node as the default (wildcard) record for
any node that does not exist within the same domain. The semantics "change"
would be "if we ask for _http._tcp.asdf.trademark.tld and get NXDOMAIN
we'll check if _http._tcp.trademark.tld URI exists and return that."

As mentioned above, browsers today do this, but for "www" and "".
And it is done entirely in the client. 

No DNS changes required. 

We can be more specific upwards in the tree by asking  that such cache
hits can't be reused beyond a delegation point (by looking for SOA) if
we so desire. This, as well, is done as a behavioural change in the
client. It can be accelerated by anticipating the next shorter query
in the resolver and send that answer in the additional data section
(as we do with SOA on NXdomain) but it is not strictly necessary.

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE           SA0XLR            +46 705 989668
Pardon me, but do you know what it means to be TRULY ONE with your BOOTH!