Thought I'd forgotten about this? :-)
No such luck, but I'm done. I don't see any benefit in further argument.
On 1/8/2020 3:13 PM, John R Levine wrote:
On Wed, 8 Jan 2020, Michael StJohns wrote:
I'm running a private copy of the root zone for my organization. I
(automated) check the SOA every so often, and arrange for a download of
the zone when it changes. I (automated) get a copy of the zone data,
including an ZONEMD RR, everything validates DNSSEC wise, but the ZONEMD
RR is invalid (hashes don't match). I do:
[ various things ]
I know this isn't the answer you want, but it still depends. One size fits
all error recovery is rarely possible. I also realize you're trying to
tease out a single answer to the question of whether a ZONEMD failure is
more likely to be a bogus zone or a broken signer, and it still depends.
No - I'm trying to tease out what the receiver does without being able to
determine why the zone didn't validate. AFAICT you're sticking with "there
must be a human in the loop because we haven't a clue why it didn't validate
and we mustn't do anything until we do". This sounds remarkably like the
arguments related to DNSSEC and non-DNS dependence on validity.
In the rather peculiar case of the root zone, ZONEMD for the first time
covers the otherwise completely unauthenticated A/AAAA records for the root
servers since root-servers.net remains unsigned, so it can detect tampering
that we couldn't detect before.
Given that I said I'm using this for local publication of the root, those
glue records are unlikely to be of any interest to me.
In any event, the *right* way to verify those records is to actually try and
make a connection with them. That gets you away from "the operation was
successful (e.g. ZONEMD said these were fine), but the patient died (e.g. the
addresses didn't actually point to a root instance because someone fat
fingered the data entry)" problem.
Since we happen to know that significant changes to the root are fairly
rare, I'd keep using the old version of the root and flag the failure for
someone to look at.
Would you or would you not add the additional records - e.g. new DS's or new
names? Or if the serial was N+1 would you only use the records that were
there at N? Keep in mind that DNSSEC says that all of the new records
validate. It's just this damn ZONEMD RR that doesn't seem to have its act
together.
In other applications, the risks and consequences are different, so I'd
probably do something different.
Given that - why do you think this is useful for more than a small set of DNS
geeks? Yes, info is useful, but either you depend upon it or it's just a
play thing. If the former, you have to then start assuming other people will
depend upon it, which means you need to be serious about getting the
provisioning right, and at the receiver, discarding "bad data". Something
that does not require a human to spend costly man hours resolving over and
over and over again.
Never mind - I'm not convinced of the general utility of this scheme. It
feels like DNS bloat and more a solution in search of a problem. That said,
I appreciate Duane's willingness to make changes to fix some of the more
egregious problems.
Later, Mike
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
"I dropped the toothpaste", said Tom, crestfallenly.
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
