Re: [DNSOP] Hybird Resolver/ DNS invariants

[Paul Vixie <[e-mail]>]

On Tuesday, 16 June 2020 06:56:49 UTC Ralf Weber wrote:
> Moin!
> 
> On 16 Jun 2020, at 4:23, Davey Song wrote:
> > ...
> > 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..

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. i still think it's a good idea but as 
before i'm in no position, schedule-wise, to drive it. if you start an effort 
on it, i'll contribute. 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.

> > 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. 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. 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.

> > 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.

> > 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.

> > Do you think it is a useful effort for DNSOP WG? Any suggestions or
> > observed related discussions on the DNS invariants?

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.

> ...
> 
> 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.

ralf's comments are evidence that DNSOP is the wrong working group for this. i 
think that good solutions to #1 and #2 from davey's list will require protocol 
changes, and that if those existed they would be popular. however, DNS vendors 
and operators who dominate discussions in DNSOP, have more important things to 
work on. (to ralf's point, each of these extensions would be opportunistic, 
and the risk of having them become required is at least 20 years in the 
future.)

-- 
Paul