Re: [DNSOP] Working Group Last Call for: Message Digest for DNS Zones

["John R Levine" <[e-mail]>]

> 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, [e-mail], Taughannock Networks, Trumansburg NY
>> "I dropped the toothpaste", said Tom, crestfallenly.
>
>
>

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