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

[Warren Kumari]

On Wed, Oct 19, 2022 at 4:38 AM, Scott Morizot <tmorizot at gmail.com> wrote:

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


Weeeeeell… I think that the way it *should* work is: When you need to
understand how something works you read the fine RFCs… and when it doesn't
work like that, you read the code and say "See, over here in line 42 of
foozlewargh.c you are checking if bar <= 17, and you *should* be checking
if bar == 17."

Yes, I know, I know… but I did say "the way it *should* work"...

W



>
>> 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 at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20221022/8a824dd4/attachment.html>