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

[Viktor Dukhovni]

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.

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.