> On 18 Oct 2022, at 17:02, Viktor Dukhovni <ietf-d...@dukhovni.org> wrote: > > On Mon, Oct 17, 2022 at 09:52:43PM -0700, cjc+dns-o...@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@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: ma...@isc.org _______________________________________________ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
