Subject: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

From: Tim Wicinski <[email-masked]>
Date: Sat, 28 Jul 2018 05:30:05 -0400

(these are just my comments alone. So take it as such)

The draft states in the Motivation section:

 "The motivation and design of this protocol enhancement is tied to the DNS
root zone [InterNIC]."

Your Design Overview states that this will work for zones that are
"relatively stable and have infrequent updates".  I think some descriptive
text about the type of zone this RR type attempts to address should be more
clearly spelled out in your Abstract.

For the ZONEMD RR Type, where in the registry do the authors think it
should go?  While some of that falls on the Expert Review process,  I think
the document authors should capture their rationale in the document.  If
the proposed RR Type is greater than 256 (which I think it does), it does
not appear to require a Standards Track document, just Expert Review.

I ask this since the document is listed as "Standards Track" and the
document is narrowly scoped to focus on the Root  Zone. Additionally the
document states: "This specification is OPTIONAL to implement by both
publishers and consumers of zone file data."   This appears to be
contradictory to me, but hopefully someone can illuminate me.

I ask all of this because we have seen the working group start to push back
on similarly scoped Proposed Standards (kskroll-sentinel).

Though I do find it amusing that you use "The Camel" as the excuse for such
a limited scope use case, even while requesting a Proposed Standard!

Now I will find that you've already answered all these questions and I
failed to find them in the mail archive.

tim

---

From: Florian Weimer <[email-masked]>
Date: Sun, 29 Jul 2018 23:13:56 +0200

> not appear to require a Standards Track document, just Expert Review.

There is some talk in the draft about blocking ZONEMD queries through
recursive resolvers, which wiuld put it into the meta RR space, I
think.

(But I disagree that there wouldn't be a loss of functionality—if the
ZONEMD record contained the size of the zone, clients might want to
query it, verify its signature, and only download the specified number
of bytes.)

---

From: Joe Abley <[email-masked]>
Date: Sun, 29 Jul 2018 17:42:04 -0400

> query it, verify its signature, and only download the specified number

I agree with that use-case. 

I also don't see a compelling reason to complicate the DNS protocol by specifying that QTYPE=ZONEMD needs special handling. That's camel territory as I think Jinmei expresed concern over the other day; better just to document the RRType and let the DNS be the DNS.

I also agree with Tim's observation the other day that if this is just a new RRType, then expert review is all that is procedurally required and it'd be a generous extension of what is required to document the implementation and use of the new RRType in the RFC series.

Such a document would only need to be an informational and could plausibly be independent stream or AD-sponsored if it doesn't fit the charter or is otherwise unpalatable to the working group.

Joe

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Jul 2018 00:23:48 +0000

On Sun, Jul 29, 2018 at 05:42:04PM -0400, Joe Abley wrote:
> I also agree with Tim's observation the other day that if this is just a
> new RRType, then expert review is all that is procedurally required and
> it'd be a generous extension of what is required to document the
> implementation and use of the new RRType in the RFC series.

A good point. Technically, I don't think there's anything in ZONEMD that
couldn't be implemented with TXT; using a dedicated rrtype for the purpose
is mere convenience.

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

---

From: Mark Andrews <[email-masked]>
Date: Mon, 30 Jul 2018 11:03:25 +1000

> On 30 Jul 2018, at 10:23 am, Evan Hunt <[email-masked]> wrote:
> 

Actually it needs to be a type code.  How do you hash the TXT RRset and
RRSIG(TXT) RRset when you need to modify both of them after computing the
hash?  You need to be able to cleanly exclude the records from the ZONEMD /
XHASH calculations but have a indication that it is present in the zone
(NSEC/NSEC3 bit map).

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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: "John Levine" <[email-masked]>
Date: 29 Jul 2018 21:26:19 -0400

>couldn't be implemented with TXT; using a dedicated rrtype for the purpose

Well, heck, we could do the whole DNS with TXT records.  But if it
were a TXT record, it'd either need a reserved prefix name or a
reserved string in the record to say what it is.  As Mark noted, that
makes calculating the hash a lot more fiddly.

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 29 Jul 2018 22:11:14 -0400

Joe

My email wasn't a statement that I don't think the work is relevant. It
seems that interesting enough for the WG that there are
two use cases: 1) the root zone; and 2) everything else.

I had spent some time looking the draft over and realizing it was marked
standards track, and I think it would be easier to adopt for the the
 specific use case if
it wasn't standards track.

And, why not combine zone-digest with 7706bis?

Tim

---

From: "John R Levine" <[email-masked]>
Date: 29 Jul 2018 22:30:16 -0400

Sorry, if that's what it sounded like.  I also think it's worth 
considering.  My point is that if it's worth trying, we should give it an 
rrtype and not screw around with overloaded TXT records.  It's not like 
we're in any immediate danger of running out of rrtypes.

R's,
John

---

From: Tim Wicinski <[email-masked]>
Date: Sun, 29 Jul 2018 22:41:52 -0400

I agreee John.We have plenty of RR Types to hand out. especially at the
upper end

---

From: "Jiankang Yao" <[email-masked]>
Date: Mon, 30 Jul 2018 10:47:13 +0800

From: Tim Wicinski
Date: 2018-07-30 10:11
To: John Levine
CC: Evan Hunt; dnsop
Subject: Re: [DNSOP] One Chair's comments on draft-wessels-dns-zone-digest

> 
> I had spent some time looking the draft over and realizing it was marked standards track, and I think it would be easier to adopt for the the  specific use case if 

> And, why not combine zone-digest with 7706bis? 

 It seems to be a good try. 

Jiankang Yao

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Jul 2018 17:21:04 +0000

On Sun, Jul 29, 2018 at 09:26:19PM -0400, John Levine wrote:
> Well, heck, we could do the whole DNS with TXT records. 

No, not really - you couldn't do NSEC3 with TXT, for example. Or DNAME,
or ANY, or lots of things.

I'm just using "could I implement this with TXT?" as a proxy for whether
it's a major change to the way the DNS works, or just a thing we can move
forward on with expert review.

---

From: Evan Hunt <[email-masked]>
Date: Mon, 30 Jul 2018 17:26:07 +0000

> XHASH calculations but have a indication that it is present in the zone

You omit the relevant TXT rrset (_zonehash./TXT, or whatever) when
computing the hash for the remainder of the zone.

Using a type code is obviously more convenient, but I could implement a
zone verification hash without it and so could you.  SO, ZONEMD only needs
expert review.

---

From: "John R Levine" <[email-masked]>
Date: 30 Jul 2018 14:05:19 -0400

> forward on with expert review.

Ah.  I gather the question is whether the record has semantics beyond just 
serving it, like DNAME or the proposed BULK, or it's just another record 
with no special handling.  I think we agree this is clearly the latter, 
since any specialness is outside the DNS query/response protocol.

Regards,
John Levine, [email-masked], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

---

From: "Wessels, Duane" <[email-masked]>
Date: Mon, 30 Jul 2018 21:36:40 +0000

> On Jul 28, 2018, at 2:30 AM, Tim Wicinski <[email-masked]> wrote:
> 

Thanks Tim,

I don't think these questions are already answered, so thank you for bringing them up.

>  "The motivation and design of this protocol enhancement is tied to the DNS root zone [InterNIC]."
> 
> Your Design Overview states that this will work for zones that are "relatively stable and have infrequent updates".  I think some descriptive text about the type of zone this RR type attempts to address should be more clearly spelled out in your Abstract. 

Noted.

> 
> For the ZONEMD RR Type, where in the registry do the authors think it should go?  While some of that falls on the Expert Review process,  I think the document authors should capture their rationale in the document.  If the proposed RR Type is greater than 256 (which I think it does), it does not appear to require a Standards Track document, just Expert Review. 

Thanks. Is there a proper way to word such a request?  Looking at RFC6895 I'm not seeing a real difference in the way that ranges "<=127" and ">=256" are described.

> 
> I ask this since the document is listed as "Standards Track" and the document is narrowly scoped to focus on the Root  Zone. Additionally the document states: "This specification is OPTIONAL to implement by both publishers and consumers of zone file data."   This appears to be contradictory to me, but hopefully someone can illuminate me. 
> 
> I ask all of this because we have seen the working group start to push back on similarly scoped Proposed Standards (kskroll-sentinel).  
> 
> Though I do find it amusing that you use "The Camel" as the excuse for such a limited scope use case, even while requesting a Proposed Standard! 

I can accept that Standards Track is the wrong choice here.  Chalk it up to my naïveté.  I suppose Experimental would be more appropriate?

DW

---

From: Wes Hardaker <[email-masked]>
Date: Mon, 30 Jul 2018 16:58:29 -0700

>      "The motivation and design of this protocol enhancement is tied to the DNS root zone [InterNIC]."

That may be a motivation, but as a prospective user I want to use it for
much more.  My LocalRoot server is already going to be serving 3 zones,
and I have plans for many more.  It would be helpful to know that on the
distribution side of things that I had indeed grabbed an authentic
source before sending it off to all the resolvers that want to pre-cache
a random zone X.

Be careful that we don't collectively interpret the sentence you quote
as meaning 'this is only useful for the root zone' just because that was
the original motivation.

In fact, I'd even argue to remove that sentence if it's causing such confusion.
-- 
Wes Hardaker
USC/ISI

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Jul 2018 11:44:24 +0200

> That may be a motivation, but as a prospective user I want to use
> it for much more.  My LocalRoot server is already going to be
> serving 3 zones, and I have plans for many more.  It would be
> helpful to know that on the distribution side of things that I had
> indeed grabbed an authentic source before sending it off to all
> the resolvers that want to pre-cache a random zone X.
> 
> Be careful that we don't collectively interpret the sentence you
> quote as meaning 'this is only useful for the root zone' just
> because that was the original motivation.

I think there is a big difference between distributing the root zone and
distributing a few 'local' zones.

In the first case you need something that is massively scalable.

In the second case, just create a tar file with a zone file and a hash, put
it up on a web server and the problem is solved. Verifying the contents of a
file is not exactly a new problem. 

I wonder if there still is a use case for distributing the root zone. With
QNAME minimization and NXDOMAIN based on NSEC records, the major use cases
seem to be gone. Compared to other zones, the root is massively over
provisioned. So if (from an availability point of view) there is need to have
a local copy of the root, then you would need a local copy of .com as well.

Though I'm sure that are people who want to reinvent DNSSEC.

One final remark, maybe it is worth investigating a 'NSDEL' record type,
and possibly 'ADEL' and 'AAAADEL'. Which are the equivalents of NS, A, AAAA
for delegations/glue. With separate record types, we can define that they are
covered by a RRSIG. Solving issues with data not being signed.

---

From: Joe Abley <[email-masked]>
Date: Tue, 31 Jul 2018 09:38:11 -0400

Hi Philip,

Are you suggesting that web servers can't be massively scaleable? I'm not sure I understand your examples.

You cite overprovisionoing in the root server system as a reason not to try and supplement it, but I think it makes sense to look at it the other way round -- if there were ways to distribute the root zone reliably and accurately without presenting the attack targets that the root server system does, the need for continued investment in the infrastructure could be reduced (or the effective benefit to end-users from that investment could be increased).

The bandwidth available at the consumer edge, where a lot of the attack sources now live, continues to grow far faster than the bandwidth that can be provisioned at the root server edge. The observation that "there's enough bandwidth that we're safe" doesn't seem future-proof (it doesn't even seem present-proof, really).

For "root server system" also read "publishing system for any zone that people care about" -- the root server system is just a handy example.

Joe

---

From: Wes Hardaker <[email-masked]>
Date: Tue, 31 Jul 2018 06:49:04 -0700

> In the first case you need something that is massively scalable.

I'm afraid I don't see those as different problems like you do.  I'd
like a massively scalable way of distributing any zone, not just the
root.  If for no other reason, .arpa and root-servers.net should be
included too, for example.

Yes, huge zones like .com and similar are not possible.  But there are
many other TLDs that likely are possible to pre-cache and serve locally.

> file is not exactly a new problem.

No, very true.  But a standardized and agreed upon way of doing it for
DNS zone data currently doesn't exist.  That's what we're trying to accomplish.

-- 
Wes Hardaker
USC/ISI

---

From: Matt Larson <[email-masked]>
Date: Tue, 31 Jul 2018 09:53:04 -0400

> On Jul 31, 2018, at 5:44 AM, Philip Homburg <[email-masked]> wrote:
> 

A local copy of the root zone improves availability in and of itself because of its importance as the starting point of all resolution. While the root zone is indeed massively over provisioned, the bad guys will always be able to send more traffic: that's an un-winnable arms race. And over provisioning doesn't help me if reachability is poor from my particular vantage point. Availability will therefore always be a concern.

Sure, a local copy of .com would (further) improve availability, but that's entirely impractical given the zone's size and rate of change. We're fortunate that the critically important root zone is small enough and changes infrequently enough that having a local copy is a realistic option.

I don't think we should assume only (or even primarily) AXFR for root zone distribution on a massive scale. Building a scalable infrastructure for that is a significant expense that I don't think is necessary (for the root operators or anyone else) when distributing 2MB files is a problem that's been solved other ways many times over. Why not distribute the root zone via, for example, multiple CDNs?

To verify the integrity of the downloaded zone one could validate all the RRSIGs, but that opens up the DOS and privacy attacks that have been described elsewhere in this discussion. And even if we issue admonitions to not have a local copy of the root zone without also enabling DNSSEC validation, we know that realistically there will be those who do the former without the latter.

For all those reasons, I think a checksum in the zone file itself that can be verified with DNSSEC is the best option for this use case, and I like the ZONEMD solution.

Matt

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Jul 2018 16:38:34 +0200

> Are you suggesting that web servers can't be massively scaleable
> ?
> I'm not sure I understand your examples.

Yes, you can build massively scaleable web servers, but at what price?

What if some popular IoT device starts to fetch the root zone. And at a
high rate?

> You cite overprovisionoing in the root server system as a reason
> not to try and supplement it, but I think it makes sense to look
> at it the other way round -- if there were ways to distribute th
> e
> root zone reliably and accurately without presenting the attack
> targets that the root server system does, the need for continued
> investment in the infrastructure could be reduced (or the effect
> ive
> benefit to end-users from that investment could be increased).

What if your web servers are not massively overprovisioned? Can we handle
failures there. If you do massively overprovision those web servers, will it
actually be cheaper or better than the current system?

> The bandwidth available at the consumer edge, where a lot of the
> attack sources now live, continues to grow far faster than the
> bandwidth that can be provisioned at the root server edge. The
> observation that "there's enough bandwidth that we're safe" does
> n't
> seem future-proof (it doesn't even seem present-proof, really).

>From a ddos point of view there doesn't seem to be big difference between
how the current DNS root absorbs traffic and what a highly available web
service would have to do.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 31 Jul 2018 16:49:31 +0200

>many other TLDs that likely are possible to pre-cache and serve locally.

I'm curious how that is going to be provisioned at a large scale.

We don't really know how to roll the KSK of the root zone. I wonder how
we are going to manage thousands, maybe millions, and if you are unlucky
billions of devices that want to fetch some zone files.

Would we paint ourselves into a corner with repect to TTLs? Currently, if
the root would need to have lower TTLs then that would require coordination
with the root server operators, but that's it. If many devices are hardwired
to fetch the root at a fixed rate, you can't do that. If you make the rate
a parameter then the first time you try to lower it, you find that some
large subset accidentally wired the parameter.

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2018 11:37:02 -0400

>In the first case you need something that is massively scalable.

Fortunately, Cloudflare, Edgecast, Limelight, Azure, and Akamai are
only a phone call away.  That problem is pretty thoroughly solved.  Whether
you'd want to use them to distribute copies of root or TLD files is more of
a political than a technical question.

>file is not exactly a new problem. 

It's not a new problem but it's not one we've addressed very well for
the DNS.  My DNS setup signs the zones and then uses rsync to
distribute the zone files, which I don't think is unusual.  I assume
that rsync doesn't scramble the zones, but it'd be enough of a pain to
create and distribute detached signatures that I don't.  If the signer
added ZONEMD at signing time which the servers could check before
using the zones, I think that would be useful.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 31 Jul 2018 12:04:19 -0400

>many other TLDs that likely are possible to pre-cache and serve locally.

I have most of the TLD zone files that it is possible to get.  They're
all gzipped so if you wanted to estimate the uncompressed master file
sizes, multiply these sizes by about 3.

The smallest from CZDS is 1.4K, the largest are .top (599M), .net
(262M), and .org (260M).  The median is under 4K.  All but 11 are
under 20M.

For the ones you get other ways, .com is huge at 2.7G, then .info (110M), .biz (37M),
.us (30M), and a handful of forgettable ones under 5M.

So, yeah, there are plenty of TLDs you could pre-cache if you wanted
to.  CZDAP downloads come from a web server that ICANN currently hosts
directly but could move to a CDN if the demand got large enough.

R's,
John

---

From: "Paul Hoffman" <[email-masked]>
Date: Tue, 31 Jul 2018 09:22:45 -0700

On 31 Jul 2018, at 9:04, John Levine wrote:

> to.

This would only be useful for zones whose children don't change often 
and whose TTLs are long. Many TLDs don't have those properties. Let's 
focus on the ones that do.

--Paul Hoffman

---

From: Paul Wouters <[email-masked]>
Date: Tue, 31 Jul 2018 12:50:10 -0400 (EDT)

On Tue, 31 Jul 2018, Paul Hoffman wrote:

> This would only be useful for zones whose children don't change often and 
> whose TTLs are long. Many TLDs don't have those properties. Let's focus on 
> the ones that do.

And are small enough, so it is mostly the new gTLD vanity domains. I'd
rather not preload those 500 domains every couple of hours/days.

Paul