Re: [DNSOP] Hybird Resolver/ DNS invariants
Davey Song <songlinjian@gmail.com> Fri, 19 June 2020 01:50 UTC
Return-Path: <songlinjian@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 270273A0FAE for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 18:50:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 3Dr2OH--7gwo for <dnsop@ietfa.amsl.com>; Thu, 18 Jun 2020 18:50:26 -0700 (PDT)
Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 DB01C3A0FAC for <dnsop@ietf.org>; Thu, 18 Jun 2020 18:50:25 -0700 (PDT)
Received: by mail-qk1-x736.google.com with SMTP id r22so6119063qke.13 for <dnsop@ietf.org>; Thu, 18 Jun 2020 18:50:25 -0700 (PDT)
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=Bil0JfbP3NgUlg/6zt+vRWuoN97AHuNhV/qWHu6xNxk=; b=Uaf5yJvImy8d188moCU1nN7RI1bp/cAXm2kX4/rTXqi4RdAXy2l2ep55egXcVvZtFv NwjkJtcfTA5gW4oVgUiIPxDIouvMpo0tL3Yi5MRCZAn+3hf+Fc2z0OyG4vM77Y9DWQhN Ugx01LrJ/lqZyQhS33E7qn2WPaj4lqrAvPlmMOzIH4T7f2PNPnr+HaGR+YlsyaBhUy+d fitIQh9Qdvt0YHBog+7LP7e1M/AFpvmHva8/QbeRkN+BggFqvI8C6nxqJLzMR5mxHz7k hWpqntzCv2ETS5cwZbrvOKE1uj3yoCPQuMvYZn9Jwcgck9LemgaoPx+qdnFlDlXrfh61 91oA==
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=Bil0JfbP3NgUlg/6zt+vRWuoN97AHuNhV/qWHu6xNxk=; b=SH4gydoG7mirZiDrFWr2YEi5Ed/5f/R5Fi/ejXXA4Mkceos+FdLEMM5Iigg5+Jyp7T DEFJUwwbKMVNDXIZEasCh8vnCqmLeL4otzGrIsJrEmAAin+12o6f+5fj1ehDW+pwn0h/ extKVTT6bas0ya3A0Ek6GqwJ7OUNcnkwSaUpcnBW3V8ipp1tx0zypvUWaq2Hq12xJ364 U95okwD3eHWZdfiuJnyQfZGXdzAgvl5dU4tEEpcjo3GaZnjrDEuKeMz/7FHrKAEUPzr7 vrlZNLZAoMdYIhCPIDL7r6qkLDk3xlinly8UUXiKZz6Zx+UOHBKq/MVh7X+Jy7Ygll1Z WTnQ==
X-Gm-Message-State: AOAM533TnekRbmR43wLObZ/C7kmendBWK0Mb8tXEC2Yf/Jf7pekAg79f Fl9svxJz5gBP5H8h6KZvlIdeTQiRzJvXxNB8c74Kebdv
X-Google-Smtp-Source: ABdhPJx2ppAAodnuG3CyjKqMfpAPaE/tjkjNiFXyKvI9hW9p3zORTcEtSzWTc4Y579RRFNw1FYg/ehHDRrV1zwj5YiY=
X-Received: by 2002:a05:620a:22f5:: with SMTP id p21mr1243473qki.241.1592531424939; Thu, 18 Jun 2020 18:50:24 -0700 (PDT)
MIME-Version: 1.0
References: <CAAObRXJF5S59jt9ipBtOLw3TK9x64+MJ3XaecWzURKBnhLtF7A@mail.gmail.com> <CD96B024-5B82-4CA7-AE1E-52597741E642@fl1ger.de> <5589359.aibOfOBbj8@linux-9daj>
In-Reply-To: <5589359.aibOfOBbj8@linux-9daj>
From: Davey Song <songlinjian@gmail.com>
Date: Fri, 19 Jun 2020 09:50:13 +0800
Message-ID: <CAAObRXL1RwbkRr+Xjo2NB2vHtz581Bh_niDrhJ7DreN3R4TVuw@mail.gmail.com>
To: Paul Vixie <paul@redbarn.org>
Cc: dnsop <dnsop@ietf.org>, Ralf Weber <dns@fl1ger.de>
Content-Type: multipart/alternative; boundary="000000000000e0957105a8661d50"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/6g4YQMPHTo9tU1TFP1MdSc3X14E>
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: Fri, 19 Jun 2020 01:50:28 -0000
Dear Paul, On Wed, 17 Jun 2020 at 00:03, Paul Vixie <paul@redbarn.org> wrote: > > i've described this to you (when you were at BII) several times as a kind > of > microtransfer or lease, where cooperating initiators (RDNS in this case) > and > responders (ADNS in this case) can agree on a NOTIFY TSIG key to be used > later, so that an RRset if changed or removed in the authority, a few > million > leaseholder RDNS can be told about this. Yes. I remember we discussed the distribution of shared TSIG key instead of address-based ACL when we talked about the zone distribution. > if you start an effort on it, i'll contribute. OK. Thank you for your support. > as you know, synchronizing the root zone (RFC 7706) > solves almost none of the problem of occasional connectivity, since so > many > other NS, DS, glue, key, and signature data are needed in-cache to > continue > retrieving other answers during times of disconnectivity. we (you) should > do > this. > I guess you mean providing an alternative resolution path for occasional disconnectivity on the path between the authority server and the resolver , #2 is one approach, right? > > > 2. A resolver can forward queries to another resolver if the load is > high > > > to reduce the recursion. > > if by this you mean the potential for a DNS Ring, where a cooperating set > of > RDNS servers agrees to randomly forward queries through other RDNS servers > in > order to obscure the real source of a query, then i'm in favour of it. The original idea is to reduce the load of resolver for recursion. The privacy feature you proposed is a good point we can include in the requirement draft. > it's long been known that ECS is a privacy nightmare; we must obsolete it > and also > erase set-associativity currently available by non-anycasted RDNS servers. What do you mean by set-associativity of non-anycasted RDNS servers? > i'd like to see a world where every house, every VM cluster (including > laptops > like mine) can run their own recursive validating iterating caching DNS > server > and have almost none of those queries reach an ADNS server with any sort > of > topology or other identifying characteristics. we (you) should do this > also. i > think it would be _very_ popular in these anti- pervasive monitoring times. > The concentration of Resolver seems like a tread nowadays. Privacy is one concern, the other concern is the HA of resolver even if all resolvers are run by one operator. > > > 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. > > i think a correct and complete microtransfer / lease method as described > for > #1 above would answer this App level requirement, and that working on this > requirement discretely would qualify as unnecessary systemic complexity. > > It's fine > > > 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. > > i think ralf's observation (below) applies here. existing RDNS > implementations > already do this. i think it's justified for NS/DS, glue, key and signature > chains needed to re-fetch and re-validate high-usage cache content, and > that > it may also be justified for high-usage content itself. but if it's to > become > a standard, it should be part of #1 above ("if the ADNS doesn't agree to > share > a NOTIFY TSIG key") rather than pursued independently. > > OK i think DNSOP is the wrong working group, and that the IRTF would be better > at > this early stage. however, if you begin the work, several of us will > contribute > OK. We can draft a document with requirements and gap analysis first. Again, thank you for your comments and support. Davey
- [DNSOP] Hybird Resolver/ DNS invariants Davey Song
- Re: [DNSOP] Hybird Resolver/ DNS invariants Ralf Weber
- Re: [DNSOP] Hybird Resolver/ DNS invariants Mats Dufberg
- Re: [DNSOP] Hybird Resolver/ DNS invariants Paul Vixie
- Re: [DNSOP] Hybird Resolver/ DNS invariants Davey Song
- Re: [DNSOP] Hybird Resolver/ DNS invariants Paul Vixie