Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

[Scott Morizot]

On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček  wrote:

> Code is your guide :-)
>

Agreed. Any time I have a need to drill down and understand exactly what is
happening and source code is available, that is always where I look first.


> Now seriously: I don't think documenting it neither
> a) necessary
> b) good idea
>

Comments in the code are always helpful. ;-) But yes, beyond that trying to
capture specific mechanisms rather than what is being accomplished in the
documentation is often counter-productive.


> It can change between versions, and we certainly do not want people to
> depend on particular behavior. We want people to follow protocol!
>

Yep. And in this instance, I haven't found the protocol standard ambiguous.
Once the chain of trust is broken through a valid insecure delegation, it
can only be reestablished by a trust anchor for a zone farther down the
hierarchy. In earlier days, before the root zone was signed or when there
were gaps in the chain, such lower level trust anchors were more common for
early adopters. These days, people mostly just use the root trust anchor so
once there's a point where the chain of trust shifts to insecure it remains
insecure for everyone for subsequent delegations. A DS record can only
establish a secure delegation when placed in a secure zone. Putting one in
an insecure zone does nothing for the security status of the delegated
zone. A resolver would require a trust anchor for it to establish security.

So the controlling point from a DNSSEC perspective is the insecure status
of fiscal.treasury.gov.

DNSVIZ captures it. The red lines note that the RRSIGs for the entries in
fiscal.treasury.gov are no good. (I have no insight into why they are being
generated, but it's likely a misconfiguration somewhere.) But the records
themselves, like the delegation, are clearly marked insecure. At that
juncture, everything below fiscal.treasury.gov becomes insecure unless a
resolver has a trust anchor for a lower level zone.

https://dnsviz.net/d/fiscal.treasury.gov/dnssec/

The DS query correctly validates the non-existence of a DS record in the
secure parent zone, treasury.gov. They should clean up the
fiscal.treasury.gov zone and fix whatever is generating the spurious and
invalid DNSSEC records in it. But the presence of those records should have
no impact on validation since the zone itself is insecure. They also really
should migrate at least to algorithm 8 and remove the SHA-1 DS record for
treasury.gov from .gov. But none of those items actually break anything.

dig @ns1.treasury.gov fiscal.treasury.gov ds +multiline +dnssec +norecurse

; <<>> DiG 9.16.28 <<>> @ns1.treasury.gov fiscal.treasury.gov ds +multiline
+dnssec +norecurse
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10792
;; flags: qr aa; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;fiscal.treasury.gov.   IN DS

;; AUTHORITY SECTION:
treasury.gov.   900 IN SOA ns1.treasury.gov.
ecb-hosting.fiscal.treasury.gov. (
2001180551 ; serial
3600   ; refresh (1 hour)
900; retry (15 minutes)
1209600; expire (2 weeks)
900; minimum (15 minutes)
)
treasury.gov.   900 IN RRSIG SOA 7 2 900 (
20221023094202 20221016084202 3908
treasury.gov.
J0M3CKVGn+KAUhQ086q4tuAlA9HpoUQRVjfwP67wC/RO
HTvSldVFCnKEV0QfTBnb8Z+bCU421PtMTjeI66efgPrc
agp2BcggozZyMkonypTRJ4CW63JabXxy5RtSFq1jnTdf
zNz2TK+yhfelkV1e3FN4uJmT2rcwcaQToOEYCzM= )
mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN NSEC3 1 0 1
16EBC108F10FE696 (
MTA7ICVE5V8C9RQJ08UR3QEO9TPP6L6T
NS RRSIG )
mta7icve5v8c9rqj08ur3qeo9tpp6l6s.treasury.gov. 900 IN RRSIG NSEC3 7 3 900 (
20221026090448 20221019080448 3908
treasury.gov.
ng8mTUN469dzduIYeUWNcVJJlnRLnH8C7OA5J3ysjk+8
X1yX0/CONnMmlztKL1zwCstgv6L9xr8aUJW9Z/Bn/CtI
whh9ymeJ0lXQzXzg6Fi7RmeSHl9Ecu1789FrbuPQF+tA
bwTcddJ29fDG9lgx4F8JvnzVxeHk4TqOh171Fhs= )
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Trouble with qa.ws.igt.fiscal.treasury.gov

[Scott Morizot]

There's a validated insecure delegation from treasury.gov to
fiscal.treasury.gov.

I can't say why any RRSIGs or other DNSSEC records are being returned for
queries for records in fiscal.treasury.gov, however those records are
spurious. As DNSVIZ does show, the delegation from the last secure zone,
treasury.gov, to fiscal.treasury.gov is insecure. And thus the subsequent
delegation from fiscal.treasury.gov to igt.fiscal.treasury.gov is also
insecure. Once the chain of trust is properly broken and the status moves
to insecure, everything below that point is also insecure.

DNSVIZ is attempting to make some sense of the spurious DNSSEC records and
show what the state would be if there weren't an insecure delegation at
treasury.gov. Or at least that's my guess at what it's doing.

I haven't found any public resolver or other implemented validator that
doesn't properly validate qa.ws.igt.fiscal.treasury.gov as insecure.

Scott


On Tue, Oct 18, 2022, 15:35 Casey Deccio  wrote:

> > On Oct 18, 2022, at 1:58 PM, Mark Andrews  wrote:
> >
> > Not for DS  as it is part of the parent zone.
> >
>
> Right.  What I meant (but didn't say) was this:
>
> The following is a query for testing for the presence of a DS record in
> the igt.fiscal.treasury.gov zone.  The signer for the records in the
> response should be the parent zone of igt.fiscal.treasury.gov, which is
> fiscal.treasury.gov.  However, the the signer for the records in the
> observed response is treasury.gov.
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Surprising ds.fedex.com NS RRset.

[Scott Morizot]

On Fri, Mar 5, 2021 at 1:23 AM Viktor Dukhovni 
wrote:

> The below was just brought to my attention, a domain with 81(!) records
> in its NS RRSet (3201 bytes over TCP):
>

I can tell from the naming convention that's a DNS zone supporting an
Active Directory domain and those are the domain controllers. For a large
organization, that's not a particularly unusual number of
domain controllers. We have an AD domain in one of our forests with
probably a similar number. It's not as common for the DNS supporting an
active directory forest to be resolvable from the Internet, but in today's
network world that doesn't strike me as terribly odd. I can think of a
number of reasons an organization might make that decision.

I believe if you run Microsoft DNS Server in integrated active directory
mode every domain controller has to be an authoritative nameserver for the
zone. We haven't used Microsoft DNS Server in any significant capacity
supporting the DNS zones for our large forests in so many years, though, I
can't say with certainty.

Scott
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

That would seem to be a stretch, especially since the domain they actually
appear to use is:

https://www.uscp.gov/

That's also the one that comes up on searches.

Scott

On Mon, Mar 1, 2021 at 4:48 PM Brian Dickson 
wrote:

>
>
> On Mon, Mar 1, 2021 at 2:16 PM Viktor Dukhovni 
> wrote:
>
>> On Mon, Mar 01, 2021 at 09:12:38AM +0100, Petr Špaček wrote:
>>
>> > In my experience negative trust anchors for big parts of MIL and/or GOV
>> > are way more common, let's not pick specifically on Quad9. For periods
>> > of time I have seen with other big resolver operators as well.
>>
>> On the .gov side, just 10 of 1239 domains fail to return validated
>> DNSKEY RRsets (with rounded number of weeks duration):
>>
>> weeks |   domain
>>---+
>>
>
>
>>   148 | uscapitolpolice.gov
>
>
> Just an observation, in terms of real world implications of DNSSEC
> validation failures:
>
> I hope this wasn't in any way a contributing factor in the 2021-01-06
> events/response.
>
> Brian
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

On Mon, Mar 1, 2021 at 9:40 AM John Todd  wrote:

>
> TL;DR:
> - 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.
> - NTAs are terrible, and we wish they didn't have to exist, but... they
> do, at the moment, and not just for Quad9
> - Is anyone interested in being a central NTA manager so this can be less
> arbitrary and fractured?
> - If not, can we develop a best practice on publishing NTAs and NTA
> policies for everyone to follow?
> - Better yet: Can we (recursive DNS operators) agree to just get rid of
> NTAs entirely?
>
> 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.

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.


> 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.
>

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.


> 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 (
> https://learn-umbrella.cisco.com/i/1202769-support-for-dnssec-in-umbrella/0?)
> 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 

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

gt;
> Well, kind of. But only incidentally for different users. Really, behavior
> is different based on which resolver the user is pointed at.
>
> As long as each recursive resolver implements NTAs silently and
> independently, there’s not 100% overlap between them, and users just shop
> resolvers until they find one with the NTA that allows them to still reach
> af.mil or the CDC or mail.mil, or whatever. The user blames the resolver
> that doesn’t have an NTA and praises the one that does have an NTA (or
> which doesn't do DNSSEC at all!) No pressure is exerted on the actual
> offending party, and resolver operators wind up having to juggle the
> subjective risks and benefits of NTAs versus user
> departure/complaints/confusion.
>
> Again to your point: Consistent failures are explainable; inconsistent
> failures are not. "Well, it works on a.b.c.d but not on 9.9.9.9" is a
> difficult problem to solve when the white-hot anger of tens or hundreds of
> thousands of end users is applied to the support structures of a platform
> which can no longer resolve an important address that has just broken
> either DNSSEC or some other authoritative-side issue which can be worked
> around by resolver operators jumping through hoops. Even if the problem is
> explainable ("The domain operator broke their own DNSSEC,") a result that
> leads to end users moving to a non-DNSSEC platform or NTA-excepted platform
> is a less than ideal result, but that's what we face. Other providers have
> NTAs, so we have NTAs.
>
> On Feb 28, 2021, at 9:14 PM, Vladimír Čunát 
> wrote:
> My (naive?) hope is that large validating services could form some
> agreement to start
> acting stricter in this respect. Of course it's often hard to argue that a
> breakage is the
> domain's fault as long as it works almost everywhere else, but
> dnsflagday.net has shown that similar arrangements are possible to pull
> off.
>
> Yes, exactly. This is a prisoner's dilemma problem, and everyone is
> defecting on their own terms - not a good situation.
>
> There have been several hallway discussions at DNS-OARC and other forums,
> back when hallway discussions were a thing (or did it make it into a list
> discussion?) about creating shared NTA lists or at least everyone publicly
> publishing or stating their NTAs in some standardized way that the "greater
> DNS community" could see what might need temporary workarounds. We’d very
> much like to be using a list that was publicly available and was formed and
> managed through public discussion. That would solve two goals: first, it
> would name-and-shame the folks who are so broken that they have to be put
> on the list; second, it would take care of all the resolver-shopping by
> users. If something caused a DNSSEC failure on one, it would DNSSEC fail on
> the others as well. Then there would no longer be competitive pressure to
> add NTAs. It seems unlikely however that there could be a centralized NTA
> list - there were fears voiced of responsibility (aka: lawsuit,) mis-use or
> fault, and security. Though if some neutral party could create it, we would
> closely evaluate using such a list if it was responsive to our specific
> customer requests, and was secure. It would be surprising but welcome to
> see someone step up to this task, though DNS-OARC would be on the short
> list of candidates. As noted above, we would really just prefer a world
> where NTAs were entirely abandoned by enough of the significant operational
> community that it became impossible for a domain operator to continue with
> faults. Are we there yet?
>
> On Feb 28, 2021, at 7:09 PM, Scott Morizot  wrote:
> It is supposed to be temporary and domain name specific. In fact, the
> informational
> RFC states that technical personnel should ensure it is due to a
> misconfiguration
> and not the sort of attack DNSSEC is intended to prevent and that they
> should make every reasonable attempt to contact the domain owner.
>
> Yep, all those are the case. Quad9 implements NTAs specifically,
> temporarily, after determining that it’s a misconfiguration, and then also
> making a reasonable attempt to contact the domain name owner (SOA email
> addresses or RFC2142 addresses are typically used, but that is another
> thread of woe, so we end up scraping websites and often in languages that
> are not typically used by our support desk - we do make the effort.) We are
> quite often successful in reaching domain operators and informing them that
> their DNSSEC is not functioning as expected, and that typically precludes
> any NTA addition - I think the summary here is that NTAs are quite rare,
> and we do try to help authoritative operators identify their problems. Most
> NTAs can be removed after

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

On Mon, Mar 1, 2021 at 7:26 AM Jim Popovitch via dns-operations <
dns-operati...@dns-oarc.net> wrote:

> Over on the email side, I know of several instances in the past 5+ years
> where email providers have had to disable TLS and/or DANE/DNSSEC checks
> (i.e. postfix's smtp_tls_policy_maps) for .mil and .gov domains due
> mostly in part for poor key rollover management practives/monitoring.
>

Disabling SMTP opportunistic TLS is a bit different since the standard
fallback should be plain text SMTP anyway. I know our email people have a
number of domains (mostly in the .gov space) where TLS is not opportunistic
but enforced. The agencies that do that likely manage their SMTP
certificates, however they are provided, more stringently.

It's unclear from your phrasing, though, if they disabled SMTP TLS for
specific domains under .gov or .mil or for both entire gTLDs. The latter
would seem like an overreaction and downgrading security where there was no
identified operational need.

In either instance, it's not the same as a public service advertising a
particular set of features to those who decide to consume it and then
silently excluding large swaths of the Internet from one of those
advertised security features. That's what I pointed out. If Quad9 updated
the description of their service to accurately state the service they in
fact provide, I wouldn't have an issue. I wouldn't have even asked about it
publicly. Those who then chose to consume that service would have made an
informed choice about the service they are consuming.

Scott
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

On Mon, Mar 1, 2021 at 2:21 AM Petr Špaček  wrote:

> In my experience negative trust anchors for big parts of MIL and/or GOV
> are way more common, let's not pick specifically on Quad9. For periods
> of time I have seen with other big resolver operators as well.
>
>
That's an interesting assertion. Do you have any data to support it? I
checked validation of our zone through all major providers whose
nameservers I could access that advertise DNSSEC validation including my
own personal, residential ISP. They all responded with the AD flag in
queries for irs.gov. And they all returned SERVFAIL for queries for the
test subzone I have had in place for a decade but did return a response for
that test zone with the CD flag enabled. Quad9 is the only one I could find
that advertises they perform DNSSEC validation in their public
documentation for a service provided to the general public but who have
silently and without notice disabled all such validation for the entire
.gov and .mil gTLDs.

If you know of another such public recursive DNS service doing the same,
please share that.

And it is the failure to provide any notice to the consumers of their
service that I see as a problem. I did read the description of their
service before I ever asked any questions about it. Had it included a
notice that they disable DNSSEC validation for all of .gov and .mil I
wouldn't have asked. I would have had my answer. It's the lack of
transparency that's a problem.

Scott
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

I have gone back and read Quad9's description of their service offering.

https://www.quad9.net/service/service-addresses-and-features

Their own public description of their service to people who might decide to
employ it clearly indicates that their secure services perform and enforce
DNSSEC validation.

That is, at best, a misleading description if not outright false.
The service does not properly implement DNSSEC validation according to the
DNSSEC protocol standards. Moreover, they have not even properly complied
with the informational RFC on negative trust anchors, RFC7646.

https://tools.ietf.org/html/rfc7646

First, it is supposed to be temporary and domain name specific. In fact,
the informational RFC states that technical personnel should ensure it is
due to a misconfiguration and not the sort of attack DNSSEC is intended to
prevent and that they should make every reasonable attempt to contact the
domain owner.

Instead, Quad9 has silently disabled DNSSEC validation for effectively the
entire United States Federal Government, civilian and military, without
prominently publishing a notice to that effect in its service description.
If citizens of the US are selecting a "secure" DNS service, they should be
so informed. It is frankly, not just a lack of transparency. It is
dishonest and misleading.

It's their service and they can do whatever they like. But they need to
tell the people using it the truth about the service they are, in fact,
providing.

Scott






On Sun, Feb 28, 2021 at 6:52 AM Scott Morizot  wrote:

> On Sun, Feb 28, 2021 at 3:17 AM Bill Woodcock  wrote:
>
>> Your experiment is not distributing malware through .GOV or .MIL,
>> therefore you have no reasonable expectation that we, our donors, and our
>> users should absorb the externalized costs of your experiment.
>>
>>
> I beg your pardon. I am the DNS Architect for the Internal Revenue Service
> in the Department of Treasury in the US Federal Government. I was not
> running an experiment. We have had DNSSEC signing for public zones in place
> since 2011, DNSSEC validation at the perimeter of our recursive
> infrastructure for all Internet queries, including those for our own public
> zones, in place since 2012. We have had DNSSEC validation enabled
> throughout our internal enterprise recursive infrastructure since 2015 and
> at this juncture have most of our enterprise authoritative DNS DNSSEC
> signed as well.
>
> I asked about Quad9 because your publicly posted information asserts you
> enforce DNSSEC validation. No exceptions are publicly documented yet it
> appeared that validation was disabled for our primary production second
> level domain. I was asking if anyone knew why since it appeared Quad9 did
> enforce DNSSEC validation on other zones like comcast.net.
>
> It did not occur to me that the Quad9 service had disabled DNSSEC
> validation for the entire .gov and .mil gTLDs. That definitely needs to be
> part of your public documentation. Your service DNSSEC validates the parts
> of Internet DNS you feel like validating.
>
> Scott
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

On Sun, Feb 28, 2021 at 3:17 AM Bill Woodcock  wrote:

> Your experiment is not distributing malware through .GOV or .MIL,
> therefore you have no reasonable expectation that we, our donors, and our
> users should absorb the externalized costs of your experiment.
>
>
I beg your pardon. I am the DNS Architect for the Internal Revenue Service
in the Department of Treasury in the US Federal Government. I was not
running an experiment. We have had DNSSEC signing for public zones in place
since 2011, DNSSEC validation at the perimeter of our recursive
infrastructure for all Internet queries, including those for our own public
zones, in place since 2012. We have had DNSSEC validation enabled
throughout our internal enterprise recursive infrastructure since 2015 and
at this juncture have most of our enterprise authoritative DNS DNSSEC
signed as well.

I asked about Quad9 because your publicly posted information asserts you
enforce DNSSEC validation. No exceptions are publicly documented yet it
appeared that validation was disabled for our primary production second
level domain. I was asking if anyone knew why since it appeared Quad9 did
enforce DNSSEC validation on other zones like comcast.net.

It did not occur to me that the Quad9 service had disabled DNSSEC
validation for the entire .gov and .mil gTLDs. That definitely needs to be
part of your public documentation. Your service DNSSEC validates the parts
of Internet DNS you feel like validating.

Scott
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

On Sun, Feb 28, 2021 at 2:44 AM Florian Weimer  wrote:

> * Winfried Angele:
>
> > I guess they've turned off validation for irs.gov because of a
> > former failure.
>
> I think it goes beyond that.  It extends to GOV and MIL as a whole, it
> seems.
>
>
Interesting. It didn't occur to me to check that. It appears you are
correct.

Their website should certainly document that they have such a huge
exception in place for two major US gTLDs in their DNSSEC validation
implementation.

If it is documented somewhere, I couldn't find it.

C:\>dig @9.9.9.9 gov. ns +dnssec +adflag

; <<>> DiG 9.12.1-P2 <<>> @9.9.9.9 gov. ns +dnssec +adflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 49356
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;gov.   IN  NS

;; ANSWER SECTION:
gov.43200   IN  NS  a.gov-servers.net.
gov.43200   IN  NS  c.gov-servers.net.
gov.43200   IN  NS  b.gov-servers.net.
gov.43200   IN  NS  d.gov-servers.net.
gov.43200   IN  RRSIG   NS 8 1 172800
20210307111009 20210228111009 27306 gov.
Hsn0bfePCVgL89MzbJLO+qWeVS8UyBhTsI8ZkiM0L3Bd4Ts94b5Lr+b6
1mmRBggNq60YNmNNr0T6pWYgiXvkHNFiMAkOWsWnBhF78bFhvZZzWUWU
ajD3Jcwj9iYK2OiL+ee3Qk1U0iBIAcoAkB7xD8Ffk0wzzak3Ly/Q6M3s
Y/cjCmsI5ts6KtCxZoE3vrqZVyRaqAVQdsyJDZx7HCsjig==

;; Query time: 57 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sun Feb 28 06:39:33 Central Standard Time 2021
;; MSG SIZE  rcvd: 306


C:\>dig @9.9.9.9 mil. ns +dnssec +adflag

; <<>> DiG 9.12.1-P2 <<>> @9.9.9.9 mil. ns +dnssec +adflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7742
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;mil.   IN  NS

;; ANSWER SECTION:
mil.19475   IN  NS  CON2.NIPR.mil.
mil.19475   IN  NS  EUR1.NIPR.mil.
mil.19475   IN  NS  PAC1.NIPR.mil.
mil.19475   IN  NS  CON1.NIPR.mil.
mil.19475   IN  NS  PAC2.NIPR.mil.
mil.19475   IN  NS  EUR2.NIPR.mil.
mil.19475   IN  RRSIG   NS 8 1 21600 20210305172406
20210226172406 19128 mil.
xgAGFEuR9fgkV3LFYwkVgES3PzZOJan/Rnxz3eK9UJIf87Hvr3b8/6G4
Wk8Bc+3amLOZYEt483hU3ONJKa+gY4Mb4i7jCc1otvyOxF0eCWMTLN6V
9ZBKK5sLJm5GSYblD+MWS5Ko6DiwbGhR6u4PatEzrXhUrLITiSjQjLJH 1rQ=

;; Query time: 59 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sun Feb 28 06:39:43 Central Standard Time 2021
;; MSG SIZE  rcvd: 314
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

On Sun, Feb 28, 2021 at 1:59 AM Winfried Angele  wrote:

> >Resolution fails as expected on our recursive infrastructure.
> >Resolution
> >fails through my personal Internet ISP's recursive nameservers
> >(Suddenlink)
> >which are also validating. And 8.8.8.8 and 1.1.1.1 return the expected
> >SERVFAIL. But 9.9.9.9 does not.
>
> I guess they've turned off validation for irs.gov because of a former
> failure. Maybe this one?
> https://dnsviz.net/d/irs.gov/XqOruQ/dnssec/?no_js=1
>
>
Yes, that failure was a big deal to us when it happened last spring. There
were a number of factors that led to it, some of them pandemic related, and
it created a major disruption across our enterprise network, not just for
Internet users. It was also a relatively pretty brief interruption in the
night in the US. The history of it in DNSViz is mostly from me working on
the problem. And it was resolved in a few hours.

https://dnsviz.net/d/irs.gov/XqPUOQ/dnssec/?no_js=1

At the IRS, we have DNSSEC validation enabled throughout our recursive
infrastructure and most of our internal DNS is also signed. If anything
fails in our infrastructure and signing, it impacts 100% of our employees
as well as the roughly one third of client queries in the US that originate
exclusively from behind DNSSEC validating recursive nameservers.

https://stats.labs.apnic.net/dnssec/US

Nobody contacted us. There is no reason to rush to put in a negative trust
anchor that quickly absent some sort of public outcry, which did not occur.
And there is certainly no reason for it to still be in place almost a year
later.

Scott
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Quad9 DNSSEC Validation?

[Scott Morizot]

I submitted a report through their interface, but I was curious if anyone
had noticed other oddities about Quad9's operational implementation of
DNSSEC validation. I happened to notice today that their service resolved
the test subzone I've had set up for the past decade to test DNSSEC
validation. (The failure is straightforward. The DS record in irs.gov does
not match any of the DNSKEY records in the dnssec-failed.irs.gov RRSet and
thus fails to match the DNSKEY RRSIG.)

Resolution fails as expected on our recursive infrastructure. Resolution
fails through my personal Internet ISP's recursive nameservers (Suddenlink)
which are also validating. And 8.8.8.8 and 1.1.1.1 return the expected
SERVFAIL. But 9.9.9.9 does not.

C:\>dig @9.9.9.9 dnssec-failed.irs.gov ns

; <<>> DiG 9.12.1-P2 <<>> @9.9.9.9 dnssec-failed.irs.gov ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7807
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;dnssec-failed.irs.gov. IN  NS

;; ANSWER SECTION:
dnssec-failed.irs.gov.  14400   IN  NS  ns5.irs.gov.
dnssec-failed.irs.gov.  14400   IN  NS  ns6.irs.gov.
dnssec-failed.irs.gov.  14400   IN  NS  ns1.irs.gov.
dnssec-failed.irs.gov.  14400   IN  NS  ns2.irs.gov.
dnssec-failed.irs.gov.  14400   IN  NS  ns3.irs.gov.
dnssec-failed.irs.gov.  14400   IN  NS  ns4.irs.gov.

;; Query time: 111 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Feb 27 14:47:52 Central Standard Time 2021
;; MSG SIZE  rcvd: 158

When I set the adflag in the query for our second level domain, it's not
set in the reply. It is set in replies for other zones like comcast.net.

C:\>dig @9.9.9.9 irs.gov ns +dnssec +adflag

; <<>> DiG 9.12.1-P2 <<>> @9.9.9.9 irs.gov ns +dnssec +adflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9737
;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;irs.gov.   IN  NS

;; ANSWER SECTION:
irs.gov.7200IN  NS  ns5.irs.gov.
irs.gov.7200IN  NS  ns3.irs.gov.
irs.gov.7200IN  NS  ns4.irs.gov.
irs.gov.7200IN  NS  ns1.irs.gov.
irs.gov.7200IN  NS  ns6.irs.gov.
irs.gov.7200IN  NS  ns2.irs.gov.
irs.gov.7200IN  RRSIG   NS 8 2 7200 20210306030006
20210227020006 14079 irs.gov.
UiKOASs3k/KJ7dom32117wBIyyQkXU7kk8cGqGyYw144+wczgIlPmx4V
uCk6CeXjlVJqDUPokeecsYDGjIy97CLH2ov88HTscEwjBepQR/c/QqU0
BB3onjVmcFCBdwc0zJhTG3MM0dR5JvLcgxw6Jj3IjP1w8C0A6Lmstesg
ojb6NOc97m50mzbUuNIHEnt1x2DZ7fTYMakQYFZLgHDCZmj8xFIlL5S3
mindmqVa8sRvaDEl5No2tQpACDnqOgIhUDie3dscMnVSM8f0avYisjkw
S6GBynWLhHZGkkTcDlPKYuNqf2VRcZRdQTezLZyk4jG8DBhQSRNaTZj/ iqyeGw==

;; Query time: 111 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Feb 27 14:47:45 Central Standard Time 2021
;; MSG SIZE  rcvd: 439

C:\>dig @9.9.9.9 comcast.net ns +dnssec +adflag

; <<>> DiG 9.12.1-P2 <<>> @9.9.9.9 comcast.net ns +dnssec +adflag
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40387
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;comcast.net.   IN  NS

;; ANSWER SECTION:
comcast.net.7200IN  NS  dns101.comcast.net.
comcast.net.7200IN  NS  dns102.comcast.net.
comcast.net.7200IN  NS  dns105.comcast.net.
comcast.net.7200IN  NS  dns104.comcast.net.
comcast.net.7200IN  NS  dns103.comcast.net.
comcast.net.7200IN  RRSIG   NS 5 2 7200 20210314144427
20210225143927 26550 comcast.net.
Iot8H7kR1FmShx00Z6FkuqoVTQbcvyILTIeehw8GBqYCF8bBn/yklka+
AOtj7S0qQwINc4BTYdbGPKYZyA0n7OmXWddsZfmVhsf7/6g3mx5x9Vfd
BNhFk0fmudCERsvA3nmk8vyH7ngS46oHvT/zzLYgko2LxPZRBtq84Kxe peA=

;; Query time: 65 msec
;; SERVER: 9.9.9.9#53(9.9.9.9)
;; WHEN: Sat Feb 27 14:47:38 Central Standard Time 2021
;; MSG SIZE  rcvd: 316

Are there other inconsistencies about which I should be aware? The above
seems to indicate they have DNSSEC validation intentionally disabled for
our zone. That concerns me since we advertise DNSSEC secured authoritative
zones and anyone using a DNSSEC validating recursive service would
reasonably expect validated responses and failures enforced.

Thanks,

Scott Morizot
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] DNSViz Service Restoration

[Scott Morizot]

Fantastic news! Thanks. Already checked and confirmed. Access to the
responses is especially appreciated.

On Wed, Mar 11, 2020 at 2:40 PM Matthew Pounsett  wrote:

> Hi all!
>
> OARC is happy… no, ecstatic… to announce that the DNSViz historical
> functions have been restored!  Users will now be seeing full functionality
> from the site at .
>
> A few weeks ago we made the decision to temporarily put aside the attempt
> to completely restore the old historical data and instead stand up a new,
> empty database so that we could get the full featureset online.  So, for
> now there is no access to old tests run prior to the service’s move to
> OARC, however new tests will be available for review.
>
> We’re continuing to work to restore the full historical database; we hope
> that with the pressure off, and the temptation to cut corners in order to
> speed up the process removed, we can restart the import from scratch with a
> slower—but more reliable—approach to recovering those data.
>
> I’d like to thank everyone again for your patience with this whole saga.
>
> Matt Pounsett
> DNS-OARC Systems Engineering
>
>
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Implementation of negative trust anchors?

[Scott Morizot]

On 22 Aug 2013 at 15:59, wbr...@e1b.org wrote:
 Running the DNS for 100+ school districts and 400,000+ devices, I really, 
 REALLY don't want to be the one saying Sorry, you can't use the site 
 called for in your lesson plan today because they messed up the DNSSEC 
 records.  Management's response would be Just make it work!
 
 Without a per domain NTA, the only option would be to turn off DNSSEC, 
 returning to square one.

I'm the engineer responsible for DNS in an organization with something on 
the order of a thousand sites, over 100K employees, and I'm not even 
going to estimate the number of devices. We've been DNSSEC validating all 
query responses from the Internet for two years now and we routinely tell 
employees that if a domain is DNSSEC signed and has messed up its zone, 
they won't be able to resolve it (no web access and no email to it) until 
the problem is fixed on the authoritative end.

The only time I've sought and received emergency approval to disable 
DNSSEC validation was during the recent snafu Verisign made with .gov. 
Fortunately I saw it and was able to react before things started failing 
on our own network.

I understand why it's necessary for early adopter ISPs. Their customers 
won't understand why they can't resolve something, but other ISPs can. We 
saw with Comcast and the nasa.gov failure a while back. Once a number of 
major ISPs have enabled validation, though, it should no longer be 
necessary.

It should never be necessary for an enterprise or government network. If 
you've made the organizational decision to implement DNSSEC validation, 
then it's rightly an all or nothing approach. A validate some things and 
not others approach is largely useless.

 Our browsers give us the option to trust invalid TLS certificates, some 
 even storing it indefinitely.  Is an NTA much different?

Yes, and we all see how well that's worked out from a security 
perspective...

Scott

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Implementation of negative trust anchors?

[Scott Morizot]

On 22 Aug 2013 at 14:37, Joe Abley wrote:
 If we accept that logic, then the pertinent questions is whether or
 not NTAs should be standardised (in a protocol or operational
 sense). I think the answer is yes. So do others. Some don't see
 value in it, but that's fine; nobody is *requiring* anybody to
 implement anything. 

If they are made a part of the standard, then the various DNS 
implementations will be expected (reasonably) to implement them. And they 
then become a standard operational tool, making DNSSEC little better than 
the current certificate process.

If recursive, caching nameserver operators have to roll their own 
implementation to achieve the goal, it keeps NTAs contained. Sure, some 
people will go to that trouble, but unless they have a well-defined 
reason to do so, most won't.

Scott

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] Implementation of negative trust anchors?

[Scott Morizot]

On 23 Aug 2013 at 19:54, UFJORw== wrote:
 NTA is a way to turn off DNSSEC for a single domain instead of
 having to go completely insecure, like some did a few days ago
 during the gov algorihm rollover screw up (BTW shutting DNSSEC
 validation down to have at least their own domain working was not
 the best thing to do: temporarily adding their own KSK to the list
 of trust anchors was the way to go (as the most specific key is
 prefered by all implementations i know of (despite the stupidity
 that is written here : http://tools.ietf.org/html/rfc6840#appendix-C
 ))) 

Ummm. No. Not all of our domains are necessarily signed or in a signed 
tree. The .gov screw-up broke secure and insecure delegations from .gov. 
I considered all this as I watched the .gov DNSKEY RRSet TTL count down 
in those caches which still had it before recommending we disable 
validation until it could be corrected.

Having your TLD screw up DNSSEC validation is particularly bad...

Scott
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs

Re: [dns-operations] dotless domains

[Scott Morizot]

On 21 Sep 2012 at 10:28, Stephane Bortzmeyer wrote:

 On Fri, Sep 21, 2012 at 10:12:42AM +0200,
  Phil Regnauld regna...@nsrc.org wrote 
  a message of 23 lines which said:
 
  Surprised no one's brought up http://dk/ as an already existing scenario
  that doesn't work (try it in various browsers).
 
 Worked fine with Chromium and lynx, despite the ICANN FUD.

Even if a particular browser supports it and even if it does not exist in 
a search list, let's not forget all the enterprise networks that restrict 
access to the web to proxy servers and utilize proxy.pac 
autoconfiguration scripts. How many of those will include the following 
line?

if (isPlainHostName(host)) return DIRECT;

Just another illustration in the long list of reasons it's a really bad 
idea. It will be a long, long time before a dotless domain would return 
any sort of vaguely consistent behavior.

Scott


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
dns-jobs mailing list
https://lists.dns-oarc.net/mailman/listinfo/dns-jobs