Subject: [DNSOP] zonemd/xhash versus nothing new

From: Paul Wouters <[email-masked]>
Date: Fri, 27 Jul 2018 18:17:37 -0400 (EDT)

On Fri, 27 Jul 2018, Warren Kumari wrote:

> This can, but does not have, to be built into the nameserver itself.

Those are just more arguments to not have a DNS checksum/sig option.

What I see is that:

We are looking at a way to distribute the root zone, presumably to
make the root servers less mission critical and for enhanced
privacy and reduced NXDOMAIN queries.

We are depening on DNSSEC for integrity of the data, which just misses
glue/NS verification.

we can do AXFR but that would keep the root servers mission critical.

glue/NS verification isn't needed normally, because we would just
need a single working entry to pull the new root zone from one of
the root servers - but then we depend again on the root servers
as critical infrastructure which is something we seem to want to
try and avoid.

maybe this is also useful for non-root zones, so the method was sort
of made to apply generically.

I think the use for non-root zones is quite a different use case, so if
I ignore that, we are looking at specifically the root zone only.

What is the pain of getting a root zone file from an unknown/untrusted
source ?

- transport seurity isn't enough (so no (D)TLS)
- detached sigs like pgp too annoying/hard? (two files instead of one,
   or the one file needs preprocessing before giving it to DNS tools)
- we have to validate it with the known key (so some tooling needed)
- glue/ns could be filtered (either a ddos, or a privacy concern?)
- we cannot depend on finding 1 working root server and then AXFR it
   to confirm, assuming that would be too much load on the existing
   root servers (although load of junk queries would decrease if this
   is deployed)

It seems the way to fix this would be to have well known recursive servers
(8.8.8.8, 1.1.1.1, 4.4.4.4, level3, opendns, etc) also offer the root
zone for AXFR. If you get something that does not work, fall back to
standard recursive root zone queries based on the buildin hints file.

We could also do some /.well-known/root.zone URI to allow for other
https/tls servers for serving the zone without being a public resolver,
eg for enterprise or isp network use only? Maybe a dhcp option to point
to the location?

Additionally, these servers could allow downloads of the root zone via
HTTPS/TLS/etc for those tools that want to write a root zone file to
disk for re-use or for preloading a resolver cache on startup ?

In all of this, I don't see much use in protecting the root zone with
either ZONEMD or XHASH. If the NS/glue is mangled to the point of being
unusable to refresh the root zone, drop the garbage and do traditional
DNS querying from the preloaded hints or previous copy of the root zone.

If ZONEMD or XHASH was a regular record with no special handling, maybe
it could be worth it, but it is a very a-typical RRTYPE and I think
there isn't a very strong case for adding it to the DNS system.

Paul

---

From: Evan Hunt <[email-masked]>
Date: Sat, 28 Jul 2018 02:57:14 +0000

> we can do AXFR but that would keep the root servers mission critical.

Also, the only currently practical channel security for AXFR is TSIG and
it can't scale to hundreds of thousands of clients.

Speaking as an implementer, I like AXFR from the traditional root servers
as a method of distribution (despite the regrettable fact that half of them
don't support AXFR; I wish they would). Reducing the root servers' central
role isn't a major concern for me, and I don't think daily zone transfers
from resolvers will overly tax them.  The code's long-since implemented and
mature and using it doesn't introduce a lot of new moving parts.

However, the inability to verify a the correctness and completeness of a
zone transfer (including the gluey bits) with an in-band signature *is* a
problem. ZONEMD/XHASH solves it.

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Tony Finch <[email-masked]>
Date: Mon, 30 Jul 2018 14:32:34 +0100

> privacy and reduced NXDOMAIN queries.

RFC 8198 with qname minimization give you the latter two.

> We are depening on DNSSEC for integrity of the data, which just misses

I keep thinking it might make sense to sign non-authoritative delegation
records, though it's really hard to see how we could get there from here.
For instance, there isn't a flags field in RRSIG so you can't explicitly
mark an RRset as being non-authoritative.

> zone for AXFR.

This just makes the surveillance capitalists part of your mission critical
problem area, which isn't obviously an improvement.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fisher, German Bight: Southerly or southeasterly 4 or 5, occasionally 6 in
west Fisher. Slight or moderate. Showers. Good.

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Jul 2018 17:03:03 -0700

Paul Wouters <[email-masked]> writes:

> What I see is that:
> 
> We are looking at a way to distribute the root zone
...
> of made to apply generically.
...
> I ignore that, we are looking at specifically the root zone only.

Please don't ignore that.  We really do ourselves a disservice when we
design a solution that only works for singular or minimal instances.
This is beneficial to more than just the root zone.

-- 
Wes Hardaker
USC/ISI

---

From: David Conrad <[email-masked]>
Date: Mon, 30 Jul 2018 17:14:46 -0700

On Jul 30, 2018, at 5:03 PM, Wes Hardaker <[email-masked]> wrote:
>> I think the use for non-root zones is quite a different use case,

I don’t.

>> so if

+1

I don’t think the benefits of mirroring a zone into a resolver is limited to the root.

Regards,
-drc

---

From: Petr Špaček <[email-masked]>
Date: Tue, 31 Jul 2018 08:52:06 +0200

> mark an RRset as being non-authoritative.

It is! RRSIG has signer name field which points to node with particular
DNSKEY. If signer name is shorter than zone apex name the signature was
created by someone up the tree.

I think this is an interesting idea worth exploring.

Petr Špaček  @  CZ.NIC

---

From: Tony Finch <[email-masked]>
Date: Tue, 31 Jul 2018 15:58:56 +0100

> created by someone up the tree.

It would be nice if that is enough :-) For NS records the RRSIG signer
will either be the same as the owner (apex RRset) or shorter (delegation
RRset). For glue it's not so clear-cut if you don't have any
apex/delegation records to hand. But maybe the other context is enough -
the section that the records appear in, the RFC 2181 priority order.

The other question I can't answer is whether existing validators will be
discombobulated by an RRSIG of unknown algorithm on a delegation NS
RRset...

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
an equitable and peaceful international order