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

Brian Dickson <brian.peter.dickson@gmail.com> Fri, 09 November 2018 05:55 UTC

Return-Path: <brian.peter.dickson@gmail.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 75B581292AD for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 21:55:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 nGA6WKcJMvSf for <dnsop@ietfa.amsl.com>; Thu, 8 Nov 2018 21:55:21 -0800 (PST)
Received: from mail-vs1-xe33.google.com (mail-vs1-xe33.google.com [IPv6:2607:f8b0:4864:20::e33]) (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 E52B71276D0 for <dnsop@ietf.org>; Thu, 8 Nov 2018 21:55:20 -0800 (PST)
Received: by mail-vs1-xe33.google.com with SMTP id y27so413512vsi.1 for <dnsop@ietf.org>; Thu, 08 Nov 2018 21:55:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=50yvsbs5TIsdi3aaHub0saTxoH+LdYXyLCiEWmIz7+U=; b=G8srQrGY0ubYgxGuq8TOtcPsJItwpnsn8srL3MIa9dTEqQ+/DOmu1541vxQ68wdtmm YmQqkDjy/b9mskJjOrVZwxAH11Sn5YsQUfClO8a9/Oc/V+cLt7ORbHoi8lDEqgJZRiFi 56l4TVOVEG9U8OWPeHe6xGaJthQJC0yz0LgTzvwfIKIyyxe1RJ4UCVIN5bOWwMXHZ+cW ypAoYLSlMwaY9KeYOIWEfBLkvogGHAFBWSx0MbZc8NoZZY96bYlgLGZsFUBFTPi7Kfdc ONtqvhBKsis0tSonK9tFkEpAU6cV+ND+Utv8VhzjicYDbibjtpyF/F4SkGytdf6u6WxG NDmw==
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=50yvsbs5TIsdi3aaHub0saTxoH+LdYXyLCiEWmIz7+U=; b=JnTkUj2kupxWO6A/PIsgkob/i4u1GD7SfJx0gvX+WOwYk9FeaNWLqvE770CJ5EmMuJ txLVYt6+zEyo3ZgJhrHbWDOtSnQMfnXqz3C9NuE84bvlPbv9mJbtdEE7n096dINZ+Pi9 5S5AnZZH/n/JuOFkjy6/gDsEApnGgq/DaLRbdOSqONLnUiI81OlUxlJvYmz4ab56JmU5 XtSXNlrVfuF7aLlQSUryhZBFMKwICn3yx8l+CaE8L6i1hAKs//VPucJYDKwe0oCPVV17 YS/wzjKfiV2jDv2HHfUyKHy3WFV0Y69asz4bHOWylqkaTf1N4yw33d2/7HVcGo5xRfRx pjsQ==
X-Gm-Message-State: AGRZ1gK1t/DuSVsmaCW3S4EUDvNqsXs/fvmSTZdVjh+/V7tbqdsWmrvu jjJQDfZVuHJEbyx1mD/gQz1P+/vo8A9LDWZXzcC8veGx
X-Google-Smtp-Source: AJdET5fWPrC34hcYnuwKzoNdvCDk+VYCxcYxZ8yduAJTVWKmktOANltCBLNO9UtYu0h6ATA8W8WjrM2d2LqRrim4kgc=
X-Received: by 2002:a67:7b0a:: with SMTP id w10mr3242680vsc.5.1541742919886; Thu, 08 Nov 2018 21:55:19 -0800 (PST)
MIME-Version: 1.0
References: <CAH1iCiqnzV6NE2FaRapFK_SQ4bhbraLs5GAbBuU+DYe15E54XA@mail.gmail.com> <5BE51691.1050006@redbarn.org>
In-Reply-To: <5BE51691.1050006@redbarn.org>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Fri, 9 Nov 2018 12:55:07 +0700
Message-ID: <CAH1iCipaDdOMC9450wSapFkieeUcMf6L6MqfbxrP21o8ZsGNNw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000132f15057a34ff09"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/4wZVbTvGNYqj7BRXbvSn97Kc0C8>
Subject: Re: [DNSOP] Root reasons (aka "why") - HTTP vs SRV vs ANAME vs CNAME
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: Fri, 09 Nov 2018 05:55:23 -0000

On Fri, Nov 9, 2018 at 12:09 PM Paul Vixie <paul@redbarn.org> wrote:

> Brian Dickson wrote:
> > Paul Vixie wrote:
>
i don't love the dnssec implications of this, including proof of
> nonwildcard.
>

I'm not 100% sure, but I think the generic DNSSEC response handling already
covers this.
If the response does not include the QTYPE, the NSEC/NSEC3 record proving
non-existent is required (already).
That the types are "type-specific thing" vs "wildcard-type thing", doesn't
even require special handling.


> it's pretty not-practical at this point to add a feature whose first
> real utility will come after the last resolver understands and
> implements it.
>

I think that overstates the deployment issue; in 1990, there weren't any
public resolvers that could be used (at least not that I'm aware of, or
maybe they were but got closed down later.)

Currently, the feature becomes usable when some fraction of the
{standard,open} resolvers have deployed support, and/or enough of the
clients (browsers) provide support, or both, plus some significant
support/deployment in authorities.

The efficiencies/optimizations on queries are something that might be
signaled via EDNS (either an OPT or a flag), regarding support for the new
slew of types.

Clients could have multiple resolvers configured, and prefer ones that
support the new types (as signaled by EDNS).

Those resolvers that provide support, and resolve the RDATA names to A/AAAA
and return those (from cache or proactively), minimize the need for
parallel queries and the corresponding query load.
Clients can learn (or be configured, or whatever) about resolver support
and tune their query logic based on that support.

That would put some degree of competitive pressure on resolver operators,
as well as providing a signal on client-side support. Client queries with
EDNS signal, to resolvers that do not support, still provide meaningful
uptake signal level to resolver operators.

The remaining two elements are authority server (software/operator)
support, and end-user (registrant) use. Competitive pressure in the market
place is beneficial once the first entrant deploys. EDNS signaling can help
there too, even when no response would have been provided (due to lack of
actual RRtype(s) at owner name).

I'm optimistic that there's a clean, scalable, flag-day-less, incremental
way forward.

Brian