On 1/5/2020 2:00 PM, John Levine wrote:
In article <[email protected]> you write:
1) A recommendation for the maximum size of the zone (and for that
matter the maximum churn rate). This is hinted at in the abstract, but
missing from the body of the document.
I don't get it. The draft makes it clear that ZONEMD in this
implementation is intended for statically signed zones. If Verisign
wants to put a ZONEMD in the daily download of the three hundred
million record .com zone file, I think that would be dandy. If your
zone of whatever size is updated too often to deal with recomputing
ZONEMD, then don't.
To quote one of my favorite movies: " I don't think that means what you
think it means"
The abstract text which is usually not considered normative says:
As specified at this time, ZONEMD is not designed for use in large,
dynamic zones due to the time and resources required for digest
calculation. The ZONEMD record described in this document includes a
field intended to enable future work to support large, dynamic zones.
Define: "Large" and define "Dynamic" and define "large AND dynamic".
A large fairly static zone (e.g. 100K records with changes once a month)
might be a candidate. A small dynamic zone (e.g 20 records changing
hourly) might also be a candidate.
Also, advice about what's too big or too slow doesn't age well. I
expect most of use remember a time when the idea of a million record
zone file seemed absurd.
Tim represented that "the authors feel they've performed their
experiments" and I would assume that the experiments have given them
some ideas on which zone size and churn don't cause problems. E.g. how
long does it take to canonicalize and hash various sizes of zones given
a particular (or several different) hardware implementation(s)?
2) For each of the use cases, an explanation of how this RRSet actually
mitigates or solves the identified problem.
I don't get this either. ZONEMD lets you verify that you got the
entire zone correctly. If anything, I'd take most of this section out
since the list of places where people get zone files isn't likely to
age well either.
Let's take one example:
As the
root zone spreads beyond its traditional deployment boundaries, the
need for verification of the completeness of the zone contents
becomes increasingly important.
I read this (and the motivation section), and I still don't know why
this is a problem. Nor what the receiver of the zone should do if it
detects "missing" data for some definition of missing.
(Note that the "parent tells you whether the child has a zonemd record"
thing won't work here, so it's going to have to be some sort of
configuration option for the receiver to tell it what to do - e.g. pull
it again, yell at the root signers???).
1.3.4 comes the closest to specifying a real use. The rest - not so
much. 1.3.3 basically seems to be saying - RPZ didn't do it right and
rather than fixing it by checking DNSSEC, do this instead.
This specification utilizes ZONEMD RRs located at the zone apex.
Non-apex ZONEMD RRs are not forbidden, but have no meaning in this
specification.
Instead - "non-apex ZONEMD RRs MUST be ignored by the receiving client".
Does ignore mean they aren't included in the computation of an apex ZONEMD?
Ugh.
ZONEMD RRs MUST NOT appear anywhere other than the apex of a zone.
What does a client do if it sees a non-apex ZONEMD RR because someone
will put it there? E.g. it "ignores it as a verifiable item". The rest
of the processing rules apply.
A zone MAY contain multiple ZONEMD RRs to support algorithm agility
[RFC7696] and rollovers. Each ZONEMD RR MUST specify a unique Digest
Type and Parameter tuple.
"A client that receives multiple ZONEMD RRs with the same DT and
Parameter MUST try to verify each in turn and MUST accept the zone if
any verify".
I think that's an error. If they have the same DT and parameter, either they
have the same serial and they're duplicates, or one of them is obsolete.
Yup. Or the zone issuer failed to update the serial number... know any
zones (or more to the point zone operators) like this?
It is RECOMMENDED that a zone include only
one ZONEMD RR, unless the zone publisher is in the process of
transitioning to a new Digest Type.
Lower case "recommended" here please.
I'd take it out altogether. What problem does multiple signatures cause?
Agree with most of the other editorial advice.
13) Missing a section 4.2 which says what you do when a zone doesn't
verify. Otherwise, what's the point?
That seems extremely dependent on the context. What I would do on a
secondary name server AXFR'ing a zone for which it's authoritative vs.
one of the thousand daily CZDS zip file downloads is rather different.
If a computer can't figure out what to do with a failed validation
absent human interaction then you might as well say:
"ZONEMD RRs may be safely ignored by all but the geekiest of DNS human
operators as there is no guidance on what to do if you see a zone that
appears to be incomplete due to ZONEMD RR validation as it might not
actually be incomplete"
With respect to updated zones, perhaps it should say that if zone
updates are distributed with IXFR, each update should either have an
updated ZONEMD with the new checksum for the full zone or delete the
now obsolete old ZONEMD. That seems obvious, but you never know.
Humans do stupid things, and tools don't always prevent them from doing
so. DNS is both a transport/query protocol and a data protocol, and the
data protocol is subject to some really interesting constraints that are
easily evaded by human error or intention.
The check on the data protocol is what the client/receiver does with it
in the face of errors.
Later, Mike
R's,
John
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
