Re: [DNSOP] Hybird Resolver/ DNS invariants

Ralf Weber <dns@fl1ger.de> Tue, 16 June 2020 06:56 UTC

Return-Path: <dns@fl1ger.de>
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 1A1AD3A10E1 for <dnsop@ietfa.amsl.com>; Mon, 15 Jun 2020 23:56:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 8HQH3HbbMlR9 for <dnsop@ietfa.amsl.com>; Mon, 15 Jun 2020 23:56:53 -0700 (PDT)
Received: from smtp.guxx.net (smtp.guxx.net [IPv6:2a01:4f8:a0:322c::25:42]) by ietfa.amsl.com (Postfix) with ESMTP id EDD0B3A10DF for <dnsop@ietf.org>; Mon, 15 Jun 2020 23:56:52 -0700 (PDT)
Received: by nyx.guxx.net (Postfix, from userid 107) id 2424D5F402E5; Tue, 16 Jun 2020 06:56:50 +0000 (UTC)
Received: from [172.19.185.104] (p54b8acc8.dip0.t-ipconnect.de [84.184.172.200]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by nyx.guxx.net (Postfix) with ESMTPSA id 8C31A5F402E5; Tue, 16 Jun 2020 06:56:50 +0000 (UTC)
From: Ralf Weber <dns@fl1ger.de>
To: Davey Song <songlinjian@gmail.com>
Cc: dnsop <dnsop@ietf.org>
Date: Tue, 16 Jun 2020 08:56:49 +0200
X-Mailer: MailMate (1.13.1r5671)
Message-ID: <CD96B024-5B82-4CA7-AE1E-52597741E642@fl1ger.de>
In-Reply-To: <CAAObRXJF5S59jt9ipBtOLw3TK9x64+MJ3XaecWzURKBnhLtF7A@mail.gmail.com>
References: <CAAObRXJF5S59jt9ipBtOLw3TK9x64+MJ3XaecWzURKBnhLtF7A@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6WYvTU_8ocYIijQqQMbPEUqRBlY>
Subject: Re: [DNSOP] Hybird Resolver/ DNS invariants
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, 16 Jun 2020 06:56:56 -0000

Moin!

On 16 Jun 2020, at 4:23, Davey Song wrote:
> I happened to run into a discussion of behaviors of  Hybrid Resolver/ DNS
> invariants where some of the non-typical uses of DNS are listed, especially
> on the resolver. I'm encouraged to put them down as a requirement draft of
> these uses of DNS and ask the mailing list whether it is a good idea. I
> hope it is helpful to provide information including risk for people who are
> doing or going to the same thing.
>
> There are some existing cases in the discussion:
> 1. A resolver syncs (pull or receive server push) with an authoritative
> server. It reduces the recursion and resolves the very-short TTL
> requirement. RFC7706 provides an approach. Other resolveless approaches are
> used as well..
> 2. A resolver can forward queries to another resolver if the load is high
> to reduce the recursion.
> 3. A resolver/authoritative server mode serving Apps via DoH or other
> Application-level DNS.  Operators of apps can edit each response on demand
> and propagate the changes of DNS RR in seconds. It also provides a private
> zone and names for each Apps.
> 4. A Hybrid DNS which is used  as a name server but cache and pull the
> authoritative data from another authoritative server. It provides an
> approach to easily scale the system without any change of existing
> authoritative DNS.
>
> Do you think it is a useful effort for DNSOP WG? Any suggestions or
> observed related discussions on the DNS invariants?
Some of these are the same old combination of authoritative and recursive
function. Mixing these has caused a lot of problems, please don’t suggest
to do that again. How DoX (T, H, Q) changes the DNS landscape is yet to be
seen, but I don’t understand how answering via a different network protocol
makes a server different. The DNS tree still is the same.

What you describe is mix of observed behaviour and local implementations,
and IMHO not the best way to deploy DNS, but others may have different
opinions here. So if you want to describe these deployments, so that we can
discuss them go ahead. But I don’t think that we want to require DNS being
build that way.

So long
-Ralf
—--
Ralf Weber