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

[Mark Andrews]

> On 18 Oct 2022, at 17:02, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> 
> On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-oarc at pumpky.net wrote:
> 
>> Having some problems resolving qa.ws.igt.fiscal.treasury.gov. There is 
>> pretty clearly a problem,
>> 
>> https://dnsviz.net/d/qa.ws.igt.fiscal.treasury.gov/dnssec/
> 
> DNSViz struggles to display this properly, because the same underlying
> nameservers serve both the parent and child zone, and instead of
> referrals serves authoritative data from the child.  However, the
> parent zone is signed, and the child zone is not.  A resolver
> expecting signed answers from the parent sees unsigned answers
> instead and is liable to get confused.
> 
>> What it looks like to me is that everything [below] fiscal.treasury.gov is 
>> supposed to be insecure (unsigned). There is a zone cut at 
>> fiscal.treasury.gov, but it is not properly delegated in DNSSEC. The 
>> servers are signing above the cut with the treasury.gov ZSK, but there 
>> are no DS records in the parent or the DNSKEY records in the 
>> fiscal.treasury.gov apex. Thus, the responses are seen as BOGUS.
> 
> Close, but not quite.  Explicit DS queries to the parent in fact
> elicit a valid denial of existence:
> 
>    $ dig +dnssec -t ds fiscal.treasury.gov @ns1.treasury.gov +norecur +nocl +nottl +noall +nocrypto +question +ans +auth
>    ;fiscal.treasury.gov.   IN DS
>    treasury.gov.           SOA     ns1.treasury.gov. ecb-hosting.fiscal.treasury.gov. 2001180551 3600 900 1209600 900
>    treasury.gov.           RRSIG   SOA 7 2 900 20221022031023 20221015021023 3908 treasury.gov. [omitted]
>    4u954er66u6qum644o2088ircof2kt1g.treasury.gov. NSEC3 1 0 1 DADE5BC724805E45 4U954ER66U6QUM644O2088IRCOF2KT1H NS RRSIG
>    4u954er66u6qum644o2088ircof2kt1g.treasury.gov. RRSIG NSEC3 7 3 900 20221025022736 20221018012736 3908 treasury.gov. [omitted]
> 
>    $ ldns-nsec3-hash -s DADE5BC724805E45 -t 1 fiscal.treasury.gov
>    4u954er66u6qum644o2088ircof2kt1g.
> 
> However, resolvers generally don't send explicit DS queries.  Instead,
> when the parent zone is signed, they set the DO bit and expect any
> referrals to either include the signed DS records, or authenticated
> denial of existence thereof.

What resolver doesn’t make DS queries?  BIND makes DS queries.  If you
have reasonable testing insecure delegations (signed -> unsigned as well
as signed -> signed (no DS)) from the same server should be part of your
test suite.

> Here however, the auth nameserver has no way to know that you're
> expecting signed parent-side delegation answers, and answers
> authoritatively from the child perspective.  Such answers lack the
> requisite signatures.
> 
>> Now if our servers saw it as completely broken, I'd understand. But 
>> names above fiscal.treasury.gov sometimes work. Sometimes they don't. 
>> That's what's really confusing me.
> 
> Rather depends whether the denial of existence of DS records manages to
> make it into the resolver cache (via an explicit DS query perhaps).
> 
> This looks like a poorly understood corner case, serving a DNSSEC-signed
> zone and its child from the same server can work poorly, becase either
> no or the wrong signatures may accompany query replies.
> 
> The delegation NS records are not visible, and the DS records can only
> be discovered via explicit DS queries.  And when queries for an interior
> node or for other zone apex RRtypes are received, answers from the child
> perspective are all the more natural.
> 
> -- 
>    Viktor.
> _______________________________________________
> dns-operations mailing list
> dns-operations at lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: marka at isc.org