Re: [Add] Zone ownership in DNS server discovery

Joe Abley <jabley@hopcount.ca> Fri, 11 September 2020 10:34 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A3C33A0E0E for <add@ietfa.amsl.com>; Fri, 11 Sep 2020 03:34:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.095
X-Spam-Level:
X-Spam-Status: No, score=-2.095 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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable 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 dJdoUrQOol18 for <add@ietfa.amsl.com>; Fri, 11 Sep 2020 03:34:02 -0700 (PDT)
Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) (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 37CB73A0E16 for <add@ietf.org>; Fri, 11 Sep 2020 03:34:02 -0700 (PDT)
Received: by mail-ed1-x52c.google.com with SMTP id g4so9455934edk.0 for <add@ietf.org>; Fri, 11 Sep 2020 03:34:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=content-transfer-encoding:from:mime-version:subject:date:message-id :references:cc:in-reply-to:to; bh=4idTLNt+1lwacvilDrIVlQ16wLa36Kcixe1aUTpMx9c=; b=WUATpff9d+sthbvq0u9hXRzykgL9TQIVglZDqd+k9qsU7QaBgr0dEm1fvwJXX1ZzpM i9xczcrB2w6QpRP1uOu461vOvnCxYMbaCJQEpZV7PfrXVkQwu2IoQ0k8xcNr+X3HvNEz tkjfoLOSLk0egSljSFpgRuQ4l43C+hzFXNjg0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:content-transfer-encoding:from:mime-version :subject:date:message-id:references:cc:in-reply-to:to; bh=4idTLNt+1lwacvilDrIVlQ16wLa36Kcixe1aUTpMx9c=; b=BNgAMBXIV86ByOZSzYkN1AceNv04N/90s/PLTtJQq+dwkTnT+1wQAQ/acIWSXvwd4B P5yAlJGT7O9YgQeN3yDUHvDjhJFsREmEb3WPIiFaiKjEHVgg1gSxwDpwGe4MlIyNfdIz WqPfOUpuoGVy3prtbeTMr5FtIr1xjsw8ZIUljAc2Nu1dENtwfcfOoo7a+8xKi0MD5hRD SYSK7MYi5KH/x1A/HpxQFpJWlRrVPqBnTOruIyHZJnsAwunN2s5MpFz7KQgfl/hXbajA N79lO1a4TX9DgvQ+6G5Js335GsJyRaKx/hHxHCjCtdwvazL9WRfzpmPQlAEnraoaaGuo W/Fw==
X-Gm-Message-State: AOAM5304OKO1Wg+u/TFSo1mZJyAt4tow5RCUQDAPJKR1DY5jr1wuIsSO vVqZoWmCJPXBlTKULTCCSVzA4MaQp7o5eA==
X-Google-Smtp-Source: ABdhPJwiIyUASYBoZIFz+sUC2HPQlc/LcR40xzNmGD974JNpvfl/a+e3npKVJvwKAq/RQlSAjcpOhg==
X-Received: by 2002:a50:99d6:: with SMTP id n22mr1263534edb.265.1599820439887; Fri, 11 Sep 2020 03:33:59 -0700 (PDT)
Received: from localhost.localdomain ([2001:980:6aad:1:35dc:ae5f:673e:2933]) by smtp.gmail.com with ESMTPSA id p25sm1280037edm.60.2020.09.11.03.33.58 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Sep 2020 03:33:58 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-11D03FE8-C8A8-49E1-A44B-03F6199D49D4"
Content-Transfer-Encoding: 7bit
From: Joe Abley <jabley@hopcount.ca>
Mime-Version: 1.0 (1.0)
Date: Fri, 11 Sep 2020 12:33:57 +0200
Message-Id: <534F994B-65FC-466B-AFBC-F9D65BCF2B27@hopcount.ca>
References: <DM6PR00MB07815FC428CDA3F393EF7F95FA271@DM6PR00MB0781.namprd00.prod.outlook.com>
Cc: Jim Reid <jim@rfc1035.com>, ADD Mailing list <add@ietf.org>
In-Reply-To: <DM6PR00MB07815FC428CDA3F393EF7F95FA271@DM6PR00MB0781.namprd00.prod.outlook.com>
To: Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org>
X-Mailer: iPad Mail (18A5373a)
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/NS6mp2ViDbDHKP3zpNrqtpxWYmw>
Subject: Re: [Add] Zone ownership in DNS server discovery
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 11 Sep 2020 10:34:04 -0000

Hi Tommy,

On Sep 10, 2020, at 18:32, Tommy Jensen <Jensen.Thomas=40microsoft.com@dmarc.ietf.org> wrote:

> Changing subject line to avoid the noise on Martin's single use case. This is a separate topic.
> 
> >From the WG charter:
> 
> > Define a mechanism that allows communication of DNS resolver
> > information to clients for use in selection decisions. This could be
> > part of the mechanism used for discovery, above
> 
> If I know "doh.example.com" is authoritative for "foo.example.com", I may prefer to take *.foo.example.com queries directly to it instead of using an intermediary recursive.

In the taxonomy described in RFC 8499, "clients" in the ADD charter refers to "stub resolver" -- "a resolver that cannot perform all resolution itself". The phrase "resolver information" in the charter refers to information about "recursive resolvers" -- resolvers that operate in "recursive mode".

What you are describing above is a hybrid entity that behaves like a stub resolver in some cases but like a recursive resolver in others. The opportunistic choice of transport between this new entity and a particular authoritative server is by definition not communication between stub resolver and recursive resolver (as defined in RFC 8499) or between client and resolver (as described in the ADD charter).

This might be an interesting discussion to start in DNSOP, perhaps as part of a larger discussion about capabilities negotiation between authoritative servers and their clients, but I think it's out of scope for ADD.


Joe