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

Brian Dickson <> Thu, 08 November 2018 03:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 30949130E1A for <>; Wed, 7 Nov 2018 19:31:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VgXONARt1zGh for <>; Wed, 7 Nov 2018 19:31:11 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B5FAB12958B for <>; Wed, 7 Nov 2018 19:31:11 -0800 (PST)
Received: by with SMTP id x1so4440171vsc.10 for <>; Wed, 07 Nov 2018 19:31:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=fTExUJFymtwra9kJxaeMUIn99nroV8LMd2I31vUuj74=; b=fiJzGRK/8eG4ZIDHBdRrFkXdSk7+IFHsR/q89+aZL+DqEsGL2c8qNk3a8FRO/FY6FJ gFjhi6jSthzwmptYOQGy2mWsgYe38GPT+UdFXhKBp59eqnBsotWEtSpd3s2DOOzFmqln lSZbMv0LvIWHoCESFXQAwvkKs+gDaGiErPtOkUXSiLRn/17wTYKq0I3oaTc2iUVPYQ8N 8L5LdnbniGh2xRHkLsa8my/ezGBBJRua/g5PQRSih1AEdGnDNSCma12NxIXspAo6NL6j T8YRYmabRhqMyuJSVh+QVQj0i9v8lp+wTFNk5otMK0uAsQd3QLvPjXwSYXBeANjxaR8p 8H6Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=fTExUJFymtwra9kJxaeMUIn99nroV8LMd2I31vUuj74=; b=snMBjeTu62GR6zuO/fqVo+93LbQ+mQ7Q+LyWZKCuEeD74ZP0Mhj0qgub+PrmsfgB6Q LCJ7uXag5Jn4Z/9IFDzkrbjWOLJ3wQWi6hZe1pBCef2cJbx2vlhmzwhxtWHJxSEnCkO0 QGNhAjwITiYzmMVZjcApxR0CpwIZUSKaYCgyTjuua5XsLdEUd2c/7o0M+efEUhQkr5zd KtxfhcCWk3eymt0qOf4XE+haYpZWJrv/nb6yJHXcYt1aj7qiGCSgwp3758YhA6+sNkTg NJ+bETt9jBVVIGRzd6Re9qceEVOBipFus7QsSnMcgZL3dbpo3OHIn8mO0PlFs8ycX0xJ 7lBQ==
X-Gm-Message-State: AGRZ1gL+WIINWX0c0PRk54vKkaPpEEjbDQf2d40BjGdUCntDVtrxLCju X3AcC16SxzCDsQlJSPVXJAVC1FanziHDFfXKmlV/g4Vn
X-Google-Smtp-Source: AJdET5dHUfpGxorzEdJIkRqexy3lVAzZosmLEaCyCAu44QMKqaGZvcNlUbnwDWV0j7oICLtnBnatTHI6SdXC9E0pkPE=
X-Received: by 2002:a67:3edc:: with SMTP id a89mr1245591vsi.136.1541647870685; Wed, 07 Nov 2018 19:31:10 -0800 (PST)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 08 Nov 2018 10:30:58 +0700
Message-ID: <>
Cc: " WG" <>
Content-Type: multipart/alternative; boundary="000000000000b3783c057a1eddc3"
Archived-At: <>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Nov 2018 03:31:14 -0000

On Thu, Nov 8, 2018 at 10:06 AM Dan York <> 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.)

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.