We seem to have a fairly basic disagreement here about whether we can
expect people who implement ZONEMD to be familiar with the way that DNS
servers work. In pretty much all of the cases below, it seems to me that
if the answer to the question isn't obvious, you're not the audience for
this document.
On Sun, 5 Jan 2020, Michael StJohns wrote:
On 1/5/2020 2:00 PM, John Levine wrote:
In article <84650844-1d13-9377-c913-23dcbc76d...@nthpermutation.com> 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.
MUST NOT means it doesn't matter. A zone with a non-apex ZONEMD does not
implement this spec, so it's not useful to try and guess what the person
who created the zone got wrong. It's more or less the same as what do you
do with a record that has a compressed name that points past the end pf
the message -- it's just wrong.
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?
See above -- it's broken. I don't think at this late stage that it is a
good idea try and guess how people will screw things up and to propose
kludges to guess what they meant.
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"
It's exactly the same thing you'd say about any other zone that has
techincal errors. I don't see anything new here.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
