Subject: [DNSOP] Hybird Resolver/ DNS invariants

From: Davey Song <[email-masked]>
Date: Tue, 16 Jun 2020 10:23:50 +0800

Hi folks,

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?

Best regards,
Davey

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 16 Jun 2020 08:56:49 +0200

Moin!

> 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

---

From: Mats Dufberg <[email-masked]>
Date: Tue, 16 Jun 2020 07:50:37 +0000

In general, the resolver function and the authoritative function are best separated on different servers. When serving local data on a local network it is usually necessary to integrate serving authoritative data into the resolver function.

If the proposal if for public DNS servers I no not see a value of such recommendations. Keep those apart.

---
Mats Dufberg
[email-masked]
Technical Expert
Internetstiftelsen (The Swedish Internet Foundation)
Mobile: +46 73 065 3899
https://internetstiftelsen.se/

-----Original Message-----
From: DNSOP <[email-masked]> on behalf of Ralf Weber <[email-masked]>
Date: Tuesday, 16 June 2020 at 08:57
To: Davey Song <[email-masked]>
Cc: dnsop <[email-masked]>
Subject: Re: [DNSOP] Hybird Resolver/ DNS invariants

    Moin!

    So long
    -Ralf
    —--
    Ralf Weber

    _______________________________________________
    DNSOP mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Vixie <[email-masked]>
Date: Tue, 16 Jun 2020 16:03:34 +0000

On Tuesday, 16 June 2020 06:56:49 UTC Ralf Weber wrote:
> > ...
> > I hope it is helpful to provide information including risk for people who
> > are doing or going to the same thing.
> > 
> > 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

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.

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

> > approach to easily scale the system without any change of existing

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.

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

> ...

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

---

From: Davey Song <[email-masked]>
Date: Fri, 19 Jun 2020 09:50:13 +0800

Dear Paul,

On Wed, 17 Jun 2020 at 00:03, Paul Vixie <[email-masked]> wrote:

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

  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?

> 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

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.

> requirement discretely would qualify as unnecessary systemic complexity.
It's fine

>  OK

i think DNSOP is the wrong working group, and that the IRTF would be better
> at
> contribute

OK. We can draft a document with requirements and gap analysis first.

Again, thank you for your comments and support.

Davey

---

From: Paul Vixie <[email-masked]>
Date: Fri, 19 Jun 2020 08:23:07 +0000

On Friday, 19 June 2020 01:50:13 UTC Davey Song wrote:
> > 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.
> 
> disconnectivity on the path between the authority server and the resolver,
> #2 is one approach, right?

i don't think so. what i'm interested in is the situation where a host 
desiring to discover and reach some service, and that service, and the DNS 
content needed to discover that service, are all on the same side of a 
discontinuity. discoverability and reachability should be continuous.

this would naturally fall into two units of protocol development. first, the 
DNS metadata (NS, DS, DNSKEY, A/AAAA glue for NS) discovered during times when 
the whole DNS infrastructure (roots, TLD servers, SLD servers if any, and so 
on) are reachable, should be retained in a form very similar to IXFR/NOTIFY. 
think of this as a "hidden secondary" at the RRset level rather than at the 
zone level. this method relies on normal operations to help discover normally 
needed DNS metadata, and then keep it in cache.

i should be able to reach the servers in my house even when the fiber has been 
cut, and i should not have to use LLMNR or similar protocols to make that 
possible. similarly, an island nation should be able to reach its entire 
electronic economy even if a shark has eaten the last undersea cable. this 
should not require that copies of all relevant DNS infrastructure be served 
inside that economy -- for example some new zealand web services are in .COM 
or .NET or elsewhere, and while it's possible to have a hidden secondary for 
NZ and CO.NZ, it's not possible to have hidden secondaries for all possible 
zones. the system must be able to opportunistically discover the "necessary" 
DNS infrastructure, and keep this data in-cache at an RRset granularity, and 
to make sure that this "leased RRset" can be invalidated by a secure 
transaction from the containing authority zone. so, that's a lot of data, and 
a lot of traffic. it wasn't practical until recently but it _is_ practical.

second, we should employ IP multicast or similar announcement technology so 
that zone authorities whether primary or secondary, and whether published or 
hidden, can become known by local validating recursive iterative DNS servers. 
this is a harder problem than the early opportunistic discovery approach, 
because we don't know how to define "local" properly. however, i'd like to be 
able to reboot my entire network during times of upstream discontinuity, and 
still be able to discover and reach all services on my side of the fiber cut. 
also, i'd like to be able to operate a fully disconnected network without 
having to create my own fake "root zone" to delegate my own names to my own 
servers inside my disconnected network. this wasn't practical without DNSSEC, 
but it _is_ practical.

> What do you mean by  set-associativity of   non-anycasted RDNS servers?

set-associativity means the authority server's opportunity to guess the 
topologic location of the stub resolver by examining the recursive server's 
uplink address. that's the original sin that led to ECS when RDNS anycast 
first became popular. authority servers should answer the questions they're 
asked, without topological favoritism. the 1.1.1.1 service does not speak ECS, 
yet the CDN world has not melted down. we can now move beyond not just ECS, 
but the privacy-violating original presumptions that ECS was based on.

see also: https://queue.acm.org/detail.cfm?id=1647302

> Again, thank you for your comments and support.

i hope this work continues. i'd like to see these problems solved, correctly 
and scalably, within my lifetime.

-- 
Paul