Re: [DNSOP] status of the aname and svcb/httpsvc drafts

Joe Abley <jabley@hopcount.ca> Thu, 27 February 2020 01:28 UTC

Return-Path: <jabley@hopcount.ca>
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 4BECE3A0DA4 for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2020 17:28:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.087
X-Spam-Level:
X-Spam-Status: No, score=-2.087 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_NONE=0.001, T_SPF_HELO_TEMPERROR=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 4f2tydFtmqPk for <dnsop@ietfa.amsl.com>; Wed, 26 Feb 2020 17:28:04 -0800 (PST)
Received: from mail-ot1-x331.google.com (mail-ot1-x331.google.com [IPv6:2607:f8b0:4864:20::331]) (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 2F0073A0DC5 for <dnsop@ietf.org>; Wed, 26 Feb 2020 17:28:04 -0800 (PST)
Received: by mail-ot1-x331.google.com with SMTP id j16so1431367otl.1 for <dnsop@ietf.org>; Wed, 26 Feb 2020 17:28:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:references:in-reply-to:date:message-id:subject:to :cc:content-transfer-encoding; bh=O1aUJN5mQ7FYcua/ul6cvG+rBufPtTuE32C8XgY2Nj0=; b=nl/iVZkYi2+T24Aheccp2BTy7Qvv8z1xOn2SirWK3rKQ0vrIuu2tCOkC/Hj5fFDa6H b8hF3/S9wramOvIPwVVG5xXIBtkW4Or0cQ6kR2s/eM8KOoiDjH4w+b+QcjzX1xyTs5g9 R09Q/zAmfqL9bOxajHfpo2d8CS4Fdo9rWiXVQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:references:in-reply-to:date :message-id:subject:to:cc:content-transfer-encoding; bh=O1aUJN5mQ7FYcua/ul6cvG+rBufPtTuE32C8XgY2Nj0=; b=rFINgvYMrB5y0DbZgNkQi5DUJ9y6E2zKeNJhV9HpUjS5V0/eRNQ/gz+OtkQ8g291Nr Zq97f7cwTeijBclw1uOlU7Sb5BSypkcCIoSEM96Xrkrl2+sPaDIRyTP6TV+pexX8uYMT mAarWqREr11se8mbft90mlkIOg1VRVLxfHysvG5+ku1KrDMPWeVYOPGGo4gl8+Q8dl7G aHDV53xLEMonGjmOUDzAYb90as+QrVjdcArtE0p1JybBSK5EXdUG0u/nZ5FfCV3R79DR l6dnx0XaHrbhqI+bGZrnVqHATpe4zQsU4bHexedqL72DLig0G7TgKZxvgeaLX9jCG/WH SrCQ==
X-Gm-Message-State: APjAAAWacOb0rPTOS64hR04uF4qUzPSUAw8oek25NErBWS5pU5C1hUWl FQChWAy0CCddbWXnj6y9yjONUwmFLEmDscYpO7kHNA==
X-Google-Smtp-Source: APXvYqyME8+D7F/dbl4vI15UIPYPwd//pqaXNVgsryYZe1YT4GkoAZaaHjEf3CtvKDMdj3lgR0hgHAd7l7zi8hV8FEg=
X-Received: by 2002:a9d:de9:: with SMTP id 96mr1415959ots.222.1582766881277; Wed, 26 Feb 2020 17:28:01 -0800 (PST)
Received: from unknown named unknown by gmailapi.google.com with HTTPREST; Wed, 26 Feb 2020 17:28:00 -0800
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
References: <4461B348-6C35-421E-B039-ABBA5B578051@isoc.org>
In-Reply-To: <4461B348-6C35-421E-B039-ABBA5B578051@isoc.org>
Date: Wed, 26 Feb 2020 17:28:00 -0800
Message-ID: <CAJhMdTNS6NxSC5QRzKvcE4bFA6MA4TU__BM-nrCCgWbKuLQC-g@mail.gmail.com>
To: Dan York <york@isoc.org>
Cc: Evan Hunt <each@isc.org>, "Andrew M. Hettinger" <AHettinger@prominic.net>, "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/HcSyUEqRCgmwBkh9_46M8bcyrrQ>
Subject: Re: [DNSOP] status of the aname and svcb/httpsvc drafts
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, 27 Feb 2020 01:28:16 -0000

On Feb 26, 2020, at 14:35, Dan York <york@isoc.org> wrote:

> While a new RR type is obviously different from a crypto algorithm, the “system upgrade” is similar:
>
> - resolvers have to be upgraded to support the new behavior of the ANAME record

For what it's worth, there are numerous examples of ANAME-like ALIAS
functionality that were implemented on authority servers and have not
needed any changes on recursive servers.

(Recursive servers also don't generally need upgrades to support new RRTypes.)

> - authoritative servers need to upgraded to process the ANAME record

Yes. In the ALIAS cases that I know of that happened in the form of
product offerings from commercial operators who had a commercial
reason to make them.

> - DNS hosting providers (which can often also be registrars) need to have updated software to allow customers to enter ANAME records

In the enterprise case where its non-trivial to use multiple providers
because of all the Stupid DNS Tricks you need as a customer, this is
the same as the previous point.

> - DNSSEC signing software may need to be updated to sign the ANAME record (section 4.2 in the ANAME draft notes the sibling resolution that must occur before signing)

DNSSEC wasn't implemented in the cases I'm aware of (at least while I
was paying attention) but if you can generate signatures at response
time I don't think ANAME makes anything more complicated.


Joe