Thought I'd forgotten about this? :-)
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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
