Subject: [DNSOP] Two Resurrected WG I-Ds: Don't Switch Resolvers & Auth DNS Mistakes

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 20 Feb 2019 14:54:14 +0000

A few years ago I had somehow succeeded in getting WG adoption of 2 documents that addressed some pet peeves I had as a recursive DNS operator. Things got busy and my attention wandered elsewhere and I did not advance them. Since these issues continue to haunt RDNS operators, I have decided to update these documents. The first says that DNSSEC errors (and other auth RR issues) are the operational responsibility of and must be solved by auth DNS admins. The second says that people should not change to non-validating resolvers when a DNSSEC failure occurs. Both are likely obvious to us in the WG, but no so much to anyone else. ;-)

Just a week or so ago, Windows Update started to fail seemingly due to a bad delegation to a CDN from Microsoft and the TTL on the bad RR was long-ish (details are scant). So reporters and even Microsoft support started suggesting that people change their DNS resolvers. Only later did people figure out the problem was on Microsoft’s auth DNS end (see https://www.zdnet.com/article/windows-update-problems-fixed-now-but-heres-what-went-wrong-says-microsoft/ and 1st story at https://www.zdnet.com/article/windows-10-updates-are-broken-again-but-this-time-its-not-microsofts-fault/). And we also see the issue of “DNSSEC validation failed, so switch to a non-validator” on a regular basis.

So I just submitted these again / updated them. I have asked the WG chairs to let me know how they’d like me to proceed with them, but haven’t yet heard back. In the meantime, I’m happy to continue to once again take input and comment from the WG.

https://datatracker.ietf.org/doc/draft-livingood-dnsop-dont-switch-resolvers/
https://datatracker.ietf.org/doc/draft-livingood-dnsop-auth-dnssec-mistakes/

Thanks!
Jason

---

From: Tim Wicinski <[email-masked]>
Date: Thu, 21 Feb 2019 12:42:49 -0500

Followup to DNSOP on a conversation the Chairs had.

I remembered Jason's earlier drafts, and him presenting, but not the
approvals, but senility is always a concern.   Luckily I'm a seem to
be a hoarder or sorts.   Here is Jason's original presentation from IETF91
(Honolulu for those keeping score at home), but no
official adoption.

Tim

On Wed, Feb 20, 2019 at 9:54 AM Livingood, Jason <
[email-masked]> wrote:

> A few years ago I had somehow succeeded in getting WG adoption of 2
> documents that addressed some pet peeves I had as a recursive DNS operator.
> Things got busy and my attention wandered elsewhere and I did not advance
> them. Since these issues continue to haunt RDNS operators, I have decided
> to update these documents. The first says that DNSSEC errors (and other
> auth RR issues) are the operational responsibility of and must be solved by
> auth DNS admins. The second says that people should not change to
> non-validating resolvers when a DNSSEC failure occurs. Both are likely
> obvious to us in the WG, but no so much to anyone else. ;-)
>
>
>
> Just a week or so ago, Windows Update started to fail seemingly due to a
> bad delegation to a CDN from Microsoft and the TTL on the bad RR was
> long-ish (details are scant). So reporters and even Microsoft support
> started suggesting that people change their DNS resolvers. Only later did
> people figure out the problem was on Microsoft’s auth DNS end (see
> https://www.zdnet.com/article/windows-update-problems-fixed-now-but-heres-what-went-wrong-says-microsoft/
> and 1st story at
> https://www.zdnet.com/article/windows-10-updates-are-broken-again-but-this-time-its-not-microsofts-fault/).
> And we also see the issue of “DNSSEC validation failed, so switch to a
> non-validator” on a regular basis.
>
>
>
> So I just submitted these again / updated them. I have asked the WG chairs
> to let me know how they’d like me to proceed with them, but haven’t yet
> heard back. In the meantime, I’m happy to continue to once again take input
> and comment from the WG.
>
>
>
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>