Re: [DNSOP] Minimum viable ANAME

Ben Schwartz <> Mon, 05 November 2018 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id BE5E21277D2 for <>; Mon, 5 Nov 2018 10:27:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -17.501
X-Spam-Status: No, score=-17.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] 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 rmXgMAI7KHsy for <>; Mon, 5 Nov 2018 10:27:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::133]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4AD57127133 for <>; Mon, 5 Nov 2018 10:27:27 -0800 (PST)
Received: by with SMTP id w7-v6so14066059itd.1 for <>; Mon, 05 Nov 2018 10:27:27 -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=CL0UZ+JRxO7GEgaDiQ2gtZ5tquV0kfKbPK3TcTdBPL0=; b=r7rGBJ9kUdhAI2X/bBqyvHsh8UIg/wV7mRKkHrGh2SIaZot09J02KsMQ3iIkz25tXz 6X11TuHRbUeJd0obKtiR6DAJWukybFVjxpBO1g8ze/igpkameb3sLSLNw8IBrGgaHF/K OuLG3OhkcJzBs7DRfDq9PGG6VmO/MHJ12dBiGE9FbYu1+ANuo3uy29pS++SNpvVbR3Jg sTvXXGGC0apSvFewlpsf48M8ilrTNlAGThWWabf0PztDjpreYORtXh5vUoNv6VsggL2K k1x0J26HvjrDiE0tRTXfy6knlcWpY79yKiUDtq9BC6pr0A9i2HjFZdwQhNztX7cEZApL L+0w==
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=CL0UZ+JRxO7GEgaDiQ2gtZ5tquV0kfKbPK3TcTdBPL0=; b=QFmfR0wmn1dVwTHDB3FtY+XvohtvNhTbvjRb/QyP6hlqp6ZVBaavj/5KX3Zg3mCX6r E3/RKC+b4rnAuVjejAAoLfQ/xCux4Ak8PI5d6/QTaej/mJCJaw8uxHT92TsLRU/XvTjk osCysCRmxS1ei+MMhCXtF5jNA45c7mb2LPBT1pqh39KV/K2ib6brSNDdnWYghTOSa8qL ywXWc0ibjaT7lK8U+uswKkZ2qhW1rddTZgVgbq0OXTSLuw+YJ/mhexvpO0ia1dwskLGl l5PSpXdjwLf4f9TLGTInvqBGsMf/x1Msq78A7ogLkN3ZCjgP+onQqpISrG8EsO5/+p/L H+YQ==
X-Gm-Message-State: AGRZ1gJl+2vuNyqHSJNxWZojLTV0trTDmaWrxazKkvLgstM8VEnn9p2u TlpExdnNc9i8BgJmR59FojJP2x11QpGDVuNs8ocLsRcrFTY=
X-Google-Smtp-Source: AJdET5d1DO39LjN3uxSrdKXFDY8QPRBSqOOnM42E0WQtE2qz/TFKq0Y3xMbX0M+/QktuYebI+z9Z8JUGIvGvPTbo3r0=
X-Received: by 2002:a02:7e56:: with SMTP id h83-v6mr22967944jac.8.1541442446118; Mon, 05 Nov 2018 10:27:26 -0800 (PST)
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
From: Ben Schwartz <>
Date: Mon, 5 Nov 2018 13:27:14 -0500
Message-ID: <>
To: Erik Nygren <>
Cc: Ray Bellis <>,, "Bishop, Mike" <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000007abffe0579ef0967"
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 18:27:30 -0000

On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren <> wrote:

> How does draft-schwartz-httpbis-dns-alt-svc-02 with some changes to make
> it more DNS-aligned (e.g. the name as a separate field in the record) not
> help here?

Thanks for mentioning DNS-Alt-Svc, Erik.

Compared to URI or the proposed HTTP record, one thing that's different
about DNS-Alt-Svc is that Alt-Svc is always optional, as currently defined,
and DNS-Alt-Svc inherits those semantics.  That means servers have to be
prepared for some users to ignore the ALTSVC record, so the apex would
still need AAAA records.

Being optional may seem like a deficiency for this application, but I now
think it's actually the best we can do as a first step.  If we start with
an optional record type that offers added value (e.g. performance, privacy,
or security), then both client vendors and server operators have a reason
to invest in deployment.  Once it's widely deployed, then we can imagine
simplified architectures that rely on the new record type, starting with
servers that don't need to support legacy clients.

I think it's reasonable to have a roadmap to a full transformation of the
DNS architecture for HTTP, but every step along the roadmap ought to have
clear net benefit to each participating party.  This seems to require a
design more or less like DNS Alt-Svc, where the additional indirection is
coupled to other improvements for HTTP.

>   It comes from the HTTP world and is aligned with the existing AltSvc
> feature and thus is useful in other ways (such as perhaps solving the DNS
> deployabilty issues for encrypted SNI):
> - Erik
> On Sun, Sep 23, 2018, 10:41 AM Ray Bellis < wrote:
>> On 21/09/2018 19:11, JW wrote:
>> > I also feel from this discussion, we are all roughly on the same page.
>> > We want SRV as the long term solution ...
>> except that we heard at the side meeting in Montreal (albeit from
>> browser people rather than content people) that they *don't* want SRV,
>> because it has fields that are not compatible with the web security model.
>> I still want to define a new RR that does have mutually agreed semantics
>> that's specifically for use by HTTP(s), but so far no takers.
>> Ray
>> _______________________________________________
>> DNSOP mailing list