Re: [DNSOP] Minimum viable ANAME

Brian Dickson <> Mon, 05 November 2018 05:51 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B9381298C5 for <>; Sun, 4 Nov 2018 21:51:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 xWSrZFVcQbKM for <>; Sun, 4 Nov 2018 21:51:25 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 61BC3129C6B for <>; Sun, 4 Nov 2018 21:51:24 -0800 (PST)
Received: by with SMTP id d62so4407219vsd.2 for <>; Sun, 04 Nov 2018 21:51:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=kyx2tgIE4SjZfLuVjR4MNFgUmvQzYoxpvl3Ol/BDpjE=; b=CmMXjnPMNoy2IEPl/X4UBDFRQU1paXJvMmMBWeJ90gc0wtcduMhLweSr3smGykuzl9 p2ga4mxOKivFb7gIE8RXdC1JFVP1OL+R/XBicyJ0khXg8xGYc52ivnoySvKRK+4EXjuy no9vohrWqAlfG68fkAJwDGmrmrtSnlearzFsc5I4bEmrTjj8LI10SZpxT1691WRQwQsy ZRtrRDoXqROA8Sd82qeY66/6JQn9VXfM9bTJZdXGHTWAi/Rs3rIMGorhHzib/QCwtwtv 9bu9einU5Ll67pOTg8gV4MlqfRaoCF3f8QWls7KT1KZ4+TTbqskbwxBLXjVo4O9PlNiN Pmiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=kyx2tgIE4SjZfLuVjR4MNFgUmvQzYoxpvl3Ol/BDpjE=; b=byKvrfh/DMLeLVLi+tfWpW0RvqL8rVjrI+qeBkYgBlcmeW1UCkJLu9kX08BMR1f9FX GqmhiMmE8KJmTam9qmYBPx7+OcTpv7eRnP/BWO0ds6MDrK0K/j9wHhpfQwsDB1ZUZZEI xqhwt/9XstdIBkypOv0Km2x+d5mv2RMafVcDAAEsBrLl/KQAC7UIqodtGa+ctd2mSRf2 orj4JdV8y5vP8fWYz71qJrl9vsZyTFQYK4prt5Qua/EznH9jYu2IzwAuw/x+qA6nNupE DrEg3DYn9IMsULxQxI6Ml0D7GvhlHy7HfHngxqRuqhY1pjCno9W+WktFkXO7ABHMnSwW D21Q==
X-Gm-Message-State: AGRZ1gIW5cMau6FB+YfUcvXIt1dLIzG/8t/ryPkZ9l9mJf2UK0OHyel/ /5V66S49La49ZOEqB0Ugvu03DwP3+u1i7p9hgrQ2rTaIEYU=
X-Google-Smtp-Source: AJdET5cVRVYx/GZNPuvOFoKKvT4gR7iaAlVf0qDEKXhaYeYwevty/otxoiVITID8VkwyDD5rSlTJ4wE5GRyVqYC6F9E=
X-Received: by 2002:a67:3edc:: with SMTP id a89mr4549453vsi.136.1541397083166; Sun, 04 Nov 2018 21:51:23 -0800 (PST)
MIME-Version: 1.0
From: Brian Dickson <>
Date: Mon, 05 Nov 2018 12:51:11 +0700
Message-ID: <>
To: " WG" <>
Content-Type: multipart/alternative; boundary="000000000000999c930579e479c2"
Archived-At: <>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Mon, 05 Nov 2018 05:51:28 -0000

Paul Vixie wrote:

> Ray Bellis wrote:
> On 21/09/2018 20:12, Dan York wrote:
> I do think this is a path we need to go.  We need *something* like
> CNAME at the apex.  Either CNAME itself or something that works in the
> same way but might have a different name.
> [...]
> i think that makes HTTP as fast in terms of round trips as SRV is.
>    Also, the presence of the Port field in an SRV record is incompatible
>    with the "Same Origin" security policy enforced by web browsers and
>    in practise the load-balancing / fallback capabilities of the SRV
>    record are not widely used either, ...
> so use "0" for the port number, and don't include more than one SRV RR.
> there's no benefit to accompany the cost of this proposal compared to re-use
> of existing code points which are already broadly implemented.
So, the counter-arguments (or better, facts) are:

   - The existing code points (SRV etc), for whatever reason, are not being
   used (fact)
   - Providing Ray's "http" solution, enforces the equivalent of "use '0'
   for the port number", implicitly (fact)
   - The cost is extremely low, i.e. adding the new code point to authority
   servers with no new logic or RDATA format required (argument or fact)

IMHO, opposing http on the basis of extremely marginal development cost and
no operational cost (as a differential comparison to SRV), and otherwise on
the vague assertion that the browser folks won't use it, isn't helpful.

At worst, it gets adopted and fails to make significant deployment.

At best, it gets adopted and deployed and used with significant uptake,
especially in the CDN vendor space, and everybody wins.

It's a lot better than ANAME, and I think we do a disservice to ourselves
as a DNS community, if we do anything other than put our collective support
into it, preferably unanimously.

I see getting http adopted and deployed, and fixing the single major
web-specific deficiency in DNS, as critical to attempting to head off DoH,
which is the biggest bugbear at the moment.