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

[Scott Morizot]

On Wed, Oct 19, 2022 at 5:11 AM Petr Špaček <pspacek at isc.org> 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= )
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20221019/1077afc6/attachment.html>