Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
Mark Andrews <marka@isc.org> Thu, 08 November 2018 05:12 UTC
Return-Path: <marka@isc.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 218351292AD for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 21:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 O4beY4hE6cRf for <dnsop@ietfa.amsl.com>; Wed, 7 Nov 2018 21:12:17 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 50A47127332 for <dnsop@ietf.org>; Wed, 7 Nov 2018 21:12:17 -0800 (PST)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 19F8E3AB526; Thu, 8 Nov 2018 05:12:17 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id C138F16007B; Thu, 8 Nov 2018 05:12:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 9FCE216006F; Thu, 8 Nov 2018 05:12:15 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id snsnXTjloZ2v; Thu, 8 Nov 2018 05:12:15 +0000 (UTC)
Received: from [172.30.42.67] (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 9E37C16007A; Thu, 8 Nov 2018 05:12:14 +0000 (UTC)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Mark Andrews <marka@isc.org>
In-Reply-To: <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com>
Date: Thu, 08 Nov 2018 16:12:11 +1100
Cc: york@isoc.org, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <0B18608D-3343-4DD5-A176-47719F94D46E@isc.org>
References: <CAH1iCirLfSEUcTf=p5bHuFJSFie_BoPh4X=89w2mpxgNpR9HkA@mail.gmail.com> <2BDA0411-202D-4199-A43B-3FDC50DC47F5@isoc.org> <CAH1iCirdkU-jYLRGeOm3DcdsReShyOez3oU5hw5sJYEtQyyqGw@mail.gmail.com>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cIBOD6iZNtArJNxwSbOSKL1qh_8>
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: Thu, 08 Nov 2018 05:12:21 -0000
> On 8 Nov 2018, at 2:30 pm, Brian Dickson <brian.peter.dickson@gmail.com> wrote: > > > > On Thu, Nov 8, 2018 at 10:06 AM Dan York <york@isoc.org> wrote: > Brian, > > DY> Upgrading our DNS infrastructure is VERY difficult. Because it is still massively distributed and decentralized (even though we do have ongoing centralization/consolidation), getting a new RRTYPE deployed means: > > - upgrading all the authoritative servers to support the new RRTYPE > - upgrading all the *provisioning software* at the thousands of DNS registries, DNS registrars, DNS hosting operators to support the new RRTYPE > - upgrading the *millions* of recursive resolvers to know what to do they receive the new RRTYPE in a query response > > > Actually, for this specific case, the only places that require support (at least initially) are: > • Authority servers (because, duh), unless they already support it, via hard-coded types and RDATA generically (maybe not overly relevant, but covering all cases) > • Authority provisioning systems for DNS hosting services (at least one hosting service has to do so before the type is "live") (also possibly supported by the hard-coded mechanism?) > • Clients (because someone has to request the new type) > For new RRtypes, registries, registrars, and their provisioning services do NOT need to support them; the new types are in the zones only. > New RRtypes which do not require any "additional" processing, do NOT strictly speaking require resolver support, since resolvers handle unknown RRtypes. (Mark A can quote you the RFC, and I think has recently.) It's RFC 1034 and RFC 1035. AKA STD 13. The only components that have *ever* needed upgrading for a new type from the very beginning for a where the authoritative servers for the zone as they needed to be able to load the record. Recursive servers and stub resolvers where all supposed to treat unknown record types and blobs of data. DNS records are named TVLs, name compression was only every valid on well known types and the only possible well known types are those listed in STD13. Anything that dropped or blocked unknown types was not STD 13 compliant. RFC 3597 reduced the list of components that needed to be updated to NONE though it was still desirable to update the primary server and provisioning systems. RFC 1034 3. General lookup function This function retrieves arbitrary information from the DNS, and has no counterpart in previous systems. The caller supplies a QNAME, QTYPE, and QCLASS, and wants all of the matching RRs. This function will often use the DNS format for all RR data instead of the local host's, and returns all RR content (e.g., TTL) instead of a processed form with local quoting conventions. When the resolver performs the indicated function, it usually has one of the following results to pass back to the client: - One or more RRs giving the requested data. In this case the resolver returns the answer in the appropriate format. - A name error (NE). This happens when the referenced name does not exist. For example, a user may have mistyped a host name. - A data not found error. This happens when the referenced name exists, but data of the appropriate type does not. For example, a host address function applied to a mailbox name would return this error since the name exists, but no address RR is present. It is important to note that the functions for translating between host names and addresses may combine the "name error" and "data not found" error conditions into a single type of error return, but the general function should not. One reason for this is that applications may ask first for one type of information about a name followed by a second request to the same name for some other type of information; if the two errors are combined, then useless queries may slow the application. > On the plus side, I can confirm at least one hosting/authority service will do this as soon as a stable spec is available (i.e. HTTP and a code point early allocation). > > That should take what, a couple of weeks or so? > > It'd be nice to ask the browser folks to start using something that is already deployed (however small the initial user base is, with the expectation of viral uptake.) > > > DY> Which does means we do need to get started NOW [...] > > Thanks for bringing this all together, > Dan > > You're welcome, and thanks for participating in the discussion. > > Brian > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
- [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs… Brian Dickson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… p vixie
- Re: [DNSOP] [Ext] Root reasons (aka "why") - HTTP… Paul Hoffman
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Dan York
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Brian Dickson
- Re: [DNSOP] [Ext] Root reasons (aka "why") - HTTP… Paul Vixie
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Dan York
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Ray Bellis
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Brian Dickson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Mark Andrews
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Måns Nilsson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Tony Finch
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Mark Andrews
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Tony Finch
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Ray Bellis
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Paul Vixie
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Ray Bellis
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Brian Dickson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Brian Dickson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Paul Vixie
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Brian Dickson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Matthijs Mekking
- [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs… Patrik Fältström
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Måns Nilsson
- Re: [DNSOP] Root reasons (aka "why") - HTTP vs SR… Tony Finch