Subject: [DNSOP] draft-hardaker-dnsop-intentionally-temporary-insec-01.txt

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Oct 2021 09:55:28 -0700

FYI, I've published

  draft-hardaker-dnsop-intentionally-temporary-insec-01.txt

It adds a new section using multiple authoritative servers  with
different data to get around algorithm roll difficulties.

It remains to be debated whether these ideas that you shouldn't use
unless you have to should eventually be published as an RFC.

-- 
Wes Hardaker
USC/ISI

---

From: Peter van Dijk <[email-masked]>
Date: Fri, 22 Oct 2021 11:16:29 +0200

Hi Wes,

> different data to get around algorithm roll difficulties.

That section only works for some validator implementations. Others will
simpy go bogus, the only question is how many times they will hit each
authoritative name server before deciding so.

I strongly suggest removing section 2.2, or perhaps changing it to say
"whatever you do, don't do this" - but I'm not sure we really want a
repository of bad ideas.

> unless you have to should eventually be published as an RFC.

I'm torn on this one. Sometimes going insecure is what has to happen, and for those cases, operational guidance is good to have.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 22 Oct 2021 12:12:28 +0200

> different data to get around algorithm roll difficulties.

I'm also not convinced that it's a good recommendation, meaning I can't 
predict if it will behave relatively reliably.  Perhaps if you have just 
two IP addresses in the whole NS set, it seems reasonable that on 
validation error the next one tried will be the other one (though I 
haven't surveyed these strategies).  In general, 50% failure rate 
doesn't sound very nice, e.g. with three attempts you still have failure 
rate over 10%, which doesn't make me happy.  (Real numbers get 
complicated by caching, selection by round-trip time, etc.)

--Vladimir

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 22 Oct 2021 09:13:27 -0700

Peter van Dijk <[email-masked]> writes:

> I'm torn on this one. Sometimes going insecure is what has to happen,
> and for those cases, operational guidance is good to have.

Thanks Peter.  I agree completely on the "I'm torn" feeling.
-- 
Wes Hardaker
USC/ISI

---

From: "Rose, Scott W." <[email-masked]>
Date: Fri, 22 Oct 2021 12:44:55 -0400

> Thanks Peter.  I agree completely on the "I'm torn" feeling.

We can’t ignore the fact that going insecure in order to do a DNSSEC 
algorithm rollover happens and sometimes happens in ways that results in 
errors.  Having a documented way that will cause the least amount of 
headaches seems wise. Domain operators may do it regardless of the 
caveats in place, but hopefully do it without causing resolution 
failures.

Scott

> -- 
> Wes Hardaker
> USC/ISI
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://gcc02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdnsop&amp;data=04%7C01%7Cscott.rose%40nist.gov%7Cf91f977e3829401ef3e508d995772211%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C0%7C637705161201400214%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&amp;sdata=Nf%2F3%2BZBS3%2BLUjRXXkC7ROPbRowvA0u079Fz%2Fgr9FdIk%3D&amp;reserved=0

=================
Scott Rose, NIST/CTL
[email-masked]
ph: +1-301-975-8439
GVoice: +1-571-249-3671

---

From: Peter van Dijk <[email-masked]>
Date: Sat, 23 Oct 2021 00:25:08 +0200

> caveats in place, but hopefully do it without causing resolution 

"Anything worth doing is worth doing well."

I've been pondering whether this document would work, fully fleshed
out, but never hitting RFC status - a web search would still find it.
But then again, at least once a week I tell people "no, that's an
expired draft, the WG did not want that"

So, I'm starting to lean strongly towards publication.

Kind regards,