[dns-operations] Looking for someone in charge for gtm-ext.dla.mil, DNSSEC validates as Bogus

Thu Mar 11 09:33:17 UTC 2021

On Thu, 2021-03-11 at 03:38 -0500, Viktor Dukhovni wrote:
> 
> > Also visible on DNSViz 
> > https://dnsviz.net/d/quicksearch.gtm-ext.dla.mil/dnssec/
> 
> Somehow the subdomain as served by the parent's nameservers ended up
> with its own separate DNSKEYs and a DS RRset owned by the subdomain,
> rather than the parent:
> 
>     gtm-ext.dla.mil. IN DNSKEY 257 3 8 AwEAAakiB93xx2GkyKCjqE9tsGE8Xb/cbS9oW+AIjD23bvsRxRVczDUchMbw6RvbJq/qH9rdspXCStgpdEvLWXWC0cCTkx/cJ8hf3UJMgMj3jd3lTxSo1KJaS5DXRdJR2+OuYEUZ3NMVJZhuJsVlYDJRFWOrnLOxuWYU65aY/eRE7rp9Z9aPN21bIDzokmVI9L3v8hd3ApQJhe2B4hnuKvvU5R+0lDkK9t2cHjvrh3ggAhR9fqZIUkVWzZA01mgJR3D8gt1MiwX9sPGwSAmCHCGdljrhvPy675CBt3cSdhCced1Ys4eIzblyp/fWsdRGaldYWWZYQUw21NGzCVTd0faNSpc=
>     gtm-ext.dla.mil. IN DNSKEY 256 3 8 AwEAAcldZpiH0g67gZS8K0T7VxRXumVxDinai8hrK17PzRZlAn63Zx5eNOFMql4TZ1e2eT3lwwH1zMx8mWbQqvQafbhlkm9onfnJkAa7oaRpi/YHK/lStrBadmYx6aE/DOz+7o5EM/mYlvfoS0kQm0RR21aMxNZ4za1mbV5N13OY5Nhj
> 
>     gtm-ext.dla.mil. IN DS 33646 8 2 cf58476a6e7145302866a112677862f08bb29611b6acdbed0fc44997bb75d8ba
>     gtm-ext.dla.mil. IN DS 33646 8 1 6f6faf621c1dbd3966b1b2fac3f41f773a297388
>     gtm-ext.dla.mil. IN RRSIG DS 8 3 86400 20210320013600 20210310012713 58143 dla.mil. mOpFYLQH8NkyFO3d7FCzCeZACD8puDeu2QW/dTRt4HaiCtWpD0zzwrjmt4yg4RY8cf35BSsMqt95Cgz6Rxvgea588ZYyJoi+he6N/2gHZgBUbYlJPR38vGuYYka/oKhhccGy3VBFc2JrvYZ/y+yProfjWii8hTVglZE9hb0ch70=
> 

That actually looks fine to me - DS is signed by parent (dla.mil),
DNSKEY is signed by child (gtm-ext.dla.mil).

> So sure looks like some delegation data is populated in error into the
> subdomain rather than the parent, but on the other hand there is neither
> an SOA RRSet nor an NS RRSet for the subdomain...

Even an A query for the subdomain apex (gtm-ext.dla.mil) returns a
completely empty NOERROR, not even a SOA.

If I completely avoid 'extra' queries (like an A query to gtm-ext as
part of qname minimization), PowerDNS Recursor (with 
https://github.com/PowerDNS/pdns/pull/10057 which also reduces 'extra'
queries) can validate it, but this domain certainly is walking a very
thin line.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/