Re: [DNSOP] Minimum viable ANAME

Ben Schwartz <bemasc@google.com> Tue, 06 November 2018 22:26 UTC

Return-Path: <bemasc@google.com>
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 1CE38130DC1 for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 14:26:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.5
X-Spam-Level:
X-Spam-Status: No, score=-17.5 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, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
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 SQEBWlOZkX87 for <dnsop@ietfa.amsl.com>; Tue, 6 Nov 2018 14:26:00 -0800 (PST)
Received: from mail-it1-x130.google.com (mail-it1-x130.google.com [IPv6:2607:f8b0:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BB651288BD for <dnsop@ietf.org>; Tue, 6 Nov 2018 14:26:00 -0800 (PST)
Received: by mail-it1-x130.google.com with SMTP id d6so20252715itl.4 for <dnsop@ietf.org>; Tue, 06 Nov 2018 14:26:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OtWjNNRjcfgMplOWGxEQiSFDxP7JeF+HkiNgSpo37E4=; b=cGgmHznbz+ARC5ivli1qDU+IlbFLu7TE8i+OO1vqw0uw9NsFK5calpZd/PpJMSUcn5 FOVlfOU0yBBUaJCfDyaZ/XeA4k/B37fFEIlg7bLJvdvA9nwUj/eh59Ja2XzP2LcDpjQh MJSP/XgpELNLjapASlNH/bnJPNrPeWkYLjszxVSBz1TC1xXFA9ODSxhxgCeiXOo0bQ8N yxvkp4/TKhKFay6B0ZYFWNiU8vvYMC/fMB11u0bN+RWnx0z31qpxRZLkcA2IwKA0yUnz AN45GhVS+JhyW8x6JIC5RAc6cNmuT8KgYb2x02M1kYRvDcVhI230lvsqXuUeWRivTXsG Uqog==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OtWjNNRjcfgMplOWGxEQiSFDxP7JeF+HkiNgSpo37E4=; b=K760kN307jNUkwoKpodbfeXnll2hPUMx8hEsW+ltadTZAPUjtE2SnE+HJU+kRZeeuI C5KJlgJhQS+3NhUsqOytfY2sGHhie0OmZApZPqQK9nWnBP3dQ2mvgps1A0p8yOvZgwMD gNH4sK+wXy/ODosnSx9i+HIAo+0w3minHSPGo33pQD2Fv6KRbcRzBhvVOmQo7qVRzJSi GQu0D4XSD4JeWzBZ6rF0KwTe+F5SMCr4liGLJXtmsBgEL2ENJgCkAT0UARDF9+kysSM6 k9I/Xv9bOVe2pa9UFK4bh5yf1W9LWDxPg00n9/f9n26nMjxySjZhgSnKkhyWPBhIpXOm y40Q==
X-Gm-Message-State: AGRZ1gJFdDpwuUIlDAojUWUmYX9p6u+Rf27GfJKPomi8bHbH4j/jZ/Uu 5s8D9fKpBMBPgQr5TVjt0X/e1MWghI/G7k4PcLV7QyZaZd4=
X-Google-Smtp-Source: AJdET5elFh/iMU+ryVOF4WYIZ2T7fonL+J9OVoMswYrE5PkCR2WI3B4AqBjLDjYwoqpUAS0bGWB8xxIqAdI5P7+g8Ow=
X-Received: by 2002:a05:660c:284:: with SMTP id s4mr3435672itl.162.1541543158921; Tue, 06 Nov 2018 14:25:58 -0800 (PST)
MIME-Version: 1.0
References: <201809211811.w8LIBdLA021837@atl4mhob20.registeredsite.com> <fdee6f3f-dd86-b482-5263-eb8e2a21bcb7@bellis.me.uk> <CAKC-DJi=Afer4uKprMf-uaNB07MVY-XJ+etocntY0BbU1bXYrg@mail.gmail.com> <CAHbrMsATrpdgP6PN2DSAjf+Nj7ZMywPu=FiGMzxjvoOm5ab2OA@mail.gmail.com> <F508AFA8-6611-4553-97AA-2A38A7F28691@isc.org>
In-Reply-To: <F508AFA8-6611-4553-97AA-2A38A7F28691@isc.org>
From: Ben Schwartz <bemasc@google.com>
Date: Tue, 6 Nov 2018 17:25:46 -0500
Message-ID: <CAHbrMsDXBJF1ieOx4H-zgCQp7SursR7q_25i99njp6m0McLg3Q@mail.gmail.com>
To: marka@isc.org
Cc: Erik Nygren <erik+ietf@nygren.org>, dnsop@ietf.org, Ray Bellis <ray@bellis.me.uk>, "Bishop, Mike" <mbishop@akamai.com>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="0000000000006f2d7d057a067cab"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/-2ZovyxeWmFccZ9d7YAiK-tHtn0>
Subject: Re: [DNSOP] Minimum viable ANAME
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: Tue, 06 Nov 2018 22:26:03 -0000

On Tue, Nov 6, 2018 at 5:06 PM Mark Andrews <marka@isc.org>; wrote:

>
>
> > On 6 Nov 2018, at 5:27 am, Ben Schwartz <bemasc=
> 40google.com@dmarc.ietf.org>; wrote:
> >
> > On Sat, Nov 3, 2018 at 4:12 PM Erik Nygren <erik+ietf@nygren.org>; 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.
>
> The publishing or the lookup?
>

Both.  Most web servers don't make use of Alt-Svc, and browsers are under
no obligation to respect it (and indeed many don't).  It's strictly an
optimization, and everything still has to work correctly without it.

> 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):
> >
> > https://tools.ietf.org/html/draft-schwartz-httpbis-dns-alt-svc-02
>
>
> What are the rules for populating the additional section of a response?
>

The DNS Alt-Svc draft currently doesn't cover this, but I would definitely
be interested to hear suggestions.  Since support is optional, the draft
focuses on the RFC 3597 opaque record process, but we can certainly
consider further optimizations that would be possible in ALTSVC-aware DNS
servers.


> It looks like nameservers will have to split the rdata up on commas the
> look for protocol-id=value pair at the start of comma separated field.
> Then look for the :port and remove it from value.
> then look to see if there was a host specified and if so lookup up that
> name.
>
> Wouldn’t be better to pre-parse the fields in the record?
>
> [<len><id-len><id><host><port>[<name-len><name><value-len><value]*]{1+}
>
> where host is in DNS wire format and . (00) is used for a empty host field
> in the alt-srv record?
>
> Libraries can reconvert this to textual format if that makes it easier for
> a browser though
> you may as well use it in structured format.
>

I'm fine with minor alterations to the syntax, but I'm not convinced that
it's important.  Parsing the contents is optional (per RFC 3597), and
writing a parser is trivial (as you've described).  Open-source parsers are
widely available (e.g. from open-source browsers).  To avoid ossification,
we'd need to have confidence that any deviations from the HTTP Alt-Svc
syntax are losslessly interconvertible and future-proof, which is a high
bar.


> > - Erik
> >
> >
> >
> > On Sun, Sep 23, 2018, 10:41 AM Ray Bellis <ray@bellis.me.uk 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
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> > _______________________________________________
> > 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
>
>