<div dir="ltr"><div dir="ltr">On Mon, Mar 1, 2021 at 9:40 AM John Todd <<a href="mailto:jtodd@quad9.net">jtodd@quad9.net</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u>




<div>
<div style="font-family:sans-serif"><div style="white-space:normal"><br><p dir="auto">TL;DR:<br>
  - We agree: Quad9 should be more transparent about it's NTA list and policy; that will be forthcoming, and we hope others will do the same. It’s time to do that.<br>
  - NTAs are terrible, and we wish they didn't have to exist, but... they do, at the moment, and not just for Quad9<br>
  - Is anyone interested in being a central NTA manager so this can be less arbitrary and fractured?<br>
  - If not, can we develop a best practice on publishing NTAs and NTA policies for everyone to follow?<br>
  - Better yet: Can we (recursive DNS operators) agree to just get rid of NTAs entirely?</p>
<p dir="auto"></p></div></div></div></blockquote><div>For my personal use, I have pretty much always run my own nameservers. However, as a typical Internet user, my choices for recursive nameservers other than one I run are pretty limited. I can use my ISP's nameservers, which are typically only available to customers. And I can use one of the well-known public DNS providers. Right now, that's primarily Google, OpenDNS, Cloudflare, and Quad9. Yes, I know there are more that can be located, but at some juncture if someone is savvy enough to research that far, they can probably just run their own recursive nameserver. It's not rocket science at the small, residential personal network level. It's at scale that DNS gets much more complex. For most people, the choice boils down to their ISP's recursive nameservers or one of the well-known public DNS sources. At this juncture, those four all validate DNSSEC. I have no idea what the particular incentives are behind the free services, but it doesn't seem like a huge universe. My ISP is one of the ones other than Comcast that now performs DNSSEC validation. So if I were using a public service and resolution failed there, it would fail at my ISP's nameservers too. As a recursive DNS operator in the enterprise/government sphere who has never employed NTAs for Internet queries, I have no problem with people getting rid of them. However, we can point to FISMA security requirements (NIST SP 800-53 control SC-21) which is reflected in our Cybersecurity IRM as justification. It's a security and compliance issue and the way government functions is inherently different with different incentives than business models.<br></div><div><br></div><div>But I'm not sure there are all that many parties who would need to agree to eliminate NTAs to normalize that approach. Again, though, my perspective is a different one.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">So, first things first. The comments about a lack of publishing the NTA list are correct and we are falling short on that, and that is something we need to remedy. It's been on the "to-do" list, but has not been high enough to score for completion in our constantly large list of operational work with (relatively) small non-profit resources, but we'll change that. We’ll have our NTA list up on our website shortly after with some discussion of policy with the team here of what gets domains put on that list and how/when they should be taken off. We've recently undertaken extensive review of our privacy policies and transparency statements, and NTAs seem to be a reasonable thing to add to the list of review and publication. The addition process for NTAs to date has been subjective, and that needs to be better documented and published, and the domains listed in a way that can be discovered on our website. This needs to be done both as assurance to our users as to the exceptions to our validation claims, and also hopefully as an additional indication to domain operators who are important enough to except but also broken enough to fail validation.<br></p></div></div></div></blockquote><div><br></div><div>Thank you. That addresses my issue. I would prefer to see the DNSSEC information we publish consumed and enforced of course, and I was surprised by the breadth of the exclusion, but as long as those who use a public service know what they are getting and in this instance that domains used primarily by the US government are excluded from validation, I have no issue with whatever approach any such service uses.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto"></p>
<p dir="auto">As we will be undergoing this transparency process, we would hope that others providing similar DNS recursive services would hope to do the same. Kudos to Cisco for calling that out as an intended NTA publication concept in their policy (<a href="https://learn-umbrella.cisco.com/i/1202769-support-for-dnssec-in-umbrella/0" target="_blank" style="color:rgb(57,131,196)">https://learn-umbrella.cisco.com/i/1202769-support-for-dnssec-in-umbrella/0</a>?) but we're unable to find this dashboard (sorry if we've just not dug deeply enough, or perhaps it's only available to paying customers.)  We're not able to find even a policy statement for Cloudflare, Google, Comcast, Deutsche Telekom, KPN, Reliance Jio or others who are actively enforcing strict validation about what NTAs they have in place or when they are added/deleted, though there are certainly discussions about some of those providers having NTAs in threads similar to this one over time. Perhaps some of these providers have public NTA lists, but some quick searching did not find anything obvious - does anyone have pointers?<br></p></div></div></div></blockquote><div>Here, I have to admit that I've generally not looked for such a list because most of the time my testing of various public services is limited to ensuring our domains are being properly validated when validation is advertised. I also don't check ISPs outside the US. And my checking has been sporadic. I also subscribe to various groups so I see some of them, like Google Public DNS, responding to inquiries. This is the first time I have ever encountered a negative trust anchor for the entire .gov gTLD. Until someone pointed it out earlier in the thread, it didn't even occur to me to check for that. My initial assumption was that it was an NTA for <a href="http://irs.gov">irs.gov</a> specifically.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto"></p>
<p dir="auto">So, let’s all do this.(*) That will help people understand the scope of the problem, and we hope that it will get the discussion moving again. We would actually like to see some sort of "best practices" policy for NTA implementation, or at least NTA declaration, or perhaps our publication of our methods might move towards that as an agreeable first attempt at a best practice. Ideally, the best possible case would to be having no NTAs at all, but it's clear that most resolver operators have NTAs in place in a non-zero volume. We hope we can come up with a way to use them as levers to improve security with those domains, rather than just create hidden exceptions.</p>
<p dir="auto">Is anyone else here interested in the discussion about a standardized method of NTA publication and policy statement publication? The discussions about privacy policy went exceptionally well in that regard leading to RFC8932, though this topic of NTA transparency is a much smaller slice of policy framing. There perhaps may be some other better forum in which to move that discussion, though making it an IETF Draft discussion or BCP may be somewhat heavy for the need.</p></div></div></div></blockquote><div>Well, NTAs are not part of the protocol standard at all, so I'm not sure how receptive the IETF dnsop group would be. I remember the informational RFC discussion being somewhat controversial at the time and approved more with an attitude of "if you're going to do this bad thing, at least try to adhere to these principles". </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:sans-serif"><div style="white-space:normal"><p dir="auto">(*) Can we short-circuit this whole issue, perhaps? Have we reached a world where strict validation of DNSSEC is now viable, with no NTAs? I think it is worth evaluating, because even if that day is not today or this year then when would it be? How could we determine the viability of such a shift?  If NTA elimination was a DNS Flag Day event for strict-validating recursive operators, where some significant portion of the largest resolvers agreed on that policy, I know that would make everyone here exceptionally happy. This whole subjective-decision issue could go away and functional comparisons against other large recursive resolver arrays (open or closed) would not have any differences in DNSSEC results, at least none that would be able to be blamed on "manual exceptions." I think this deserves to be broken out into a separate thread of discussion if anyone wishes to continue the conversation, as this is not a Quad9-specific aspiration.</p></div></div></div></blockquote><div><br></div><div>Comcast had a particular storm where the media reported incorrectly that they were "blocking NASA" during a significant NASA event with a lot of eyes on it. I understand the particular pain they encountered in that event. I don't believe we are in that world or that stage of deployment anymore. As I noted, we have never employed NTAs for Internet recursive DNS resolution for our population of ~100k employees and contractors and we have been enforcing DNSSEC validation at our perimeter since 2012. (The precise number fluctuates over time and I don't usually bother to keep track of it.) Our employees, however, are a captive audience. On our network, we are the only DNS provider they are allowed to use. And we have multiple firewalls and ACLs throughout our network enforcing that level of restricted access.</div><div><br></div><div>Scott</div></div></div>