[dns-operations] Validation anomalies under gpo.gov

[Viktor Dukhovni]

On Fri, Apr 03, 2020 at 12:18:57PM -0700, Brian Somers wrote:

> The gpo.gov domain came up recently as being something that likes to
> compress the RRSIG signer field, but something even more disturbing
> has now come up and, of course, customers like to compare the
> behaviour of different recursive resolvers!
> 
> In summary, looking at permanent.access.gpo.gov, it’s a complete mess:
> * gpo.gov/RRSIG/DNSKEY has a compressed signer
> * access.gpo.gov is a delegation point
> * access.gpo.gov/DS is denied without an SOA and with a fabricated, irrelevant NSEC3 RR
> * permanent.access.gpo.gov/A comes with an RRSIG with a signer field of gpo.gov
> 
> However, it seems that both 8.8.8.8 and 9.9.9.9 are happy to respond
> with an answer, and worse still, 8.8.8.8 also sets the AD bit in the
> response.
> Cloudflare gets it right and returns SERVFAIL.

The problems even seem to be getting worse in near-real-time:

    https://dnsviz.net/d/permanent.access.gpo.gov/XoeUqQ/dnssec/
    https://dnsviz.net/d/permanent.access.gpo.gov/XoebRg/dnssec/

though are not new:

    https://dnsviz.net/d/permanent.access.gpo.gov/XmugWA/dnssec/

I don't recall whether Scott Rose et. al. are on this list, but perhaps
someone from .gov will follow up without an off-list ping...

Looking across all the major public resolvers I see:

    1.0.0.1        permanent.access.gpo.gov. IN A ? ; ServFail AD=0
    1.1.1.1        permanent.access.gpo.gov. IN A ? ; ServFail AD=0
    ;
    8.8.4.4        permanent.access.gpo.gov. IN A 162.140.254.81 ; NoError AD=1
    8.8.8.8        permanent.access.gpo.gov. IN A 162.140.254.81 ; NoError AD=1
    ;
    64.6.64.6      permanent.access.gpo.gov. IN A 162.140.254.81 ; NoError AD=1
    64.6.65.6      permanent.access.gpo.gov. IN A 162.140.254.81 ; NoError AD=1
    ;
    9.9.9.10       permanent.access.gpo.gov. IN A 162.140.254.81 ; NoError AD=0
    149.112.112.10 permanent.access.gpo.gov. IN A 162.140.254.81 ; NoError AD=0

My take is that:

    - Cloudflare at some point discovered that the domain should be
      delegated, and is treating the answer as bogus (or has received
      more recent, even more broken answers).

    - Google and Verisign obtained a correctly signed response from the parent
      zone with no evidence of delegation, and did not qname-minimize to
      discover the breakage.

    - Quad9 also discovered the breakage, but they return AD=0, rather
      than ServFail, and let the downstream resolver decide what to do.

When I specifically ask for the NS RRs of the intermediate domain, I
get (consistent with the above hypotheses):

    1.0.0.1             access.gpo.gov. IN NS ? ; ServFail AD=0
    1.1.1.1             access.gpo.gov. IN NS ? ; ServFail AD=0
    ;
    8.8.4.4             access.gpo.gov. IN NS ? ; ServFail AD=0
    8.8.8.8             access.gpo.gov. IN NS ? ; ServFail AD=0
    ;
    64.6.64.6           access.gpo.gov. IN NS ? ; ServFail AD=0
    64.6.65.6           access.gpo.gov. IN NS ? ; ServFail AD=0
    ;
    9.9.9.10            access.gpo.gov. IN NS ns2.gpo.gov. ; NoError AD=0
    9.9.9.10            access.gpo.gov. IN NS ns1.gpo.gov. ; NoError AD=0
    149.112.112.10      access.gpo.gov. IN NS ns2.gpo.gov. ; NoError AD=0
    149.112.112.10      access.gpo.gov. IN NS ns1.gpo.gov. ; NoError AD=0

The AD=1 replies from Google and Verisign are not "wrong".  They just
reflect the fact that any ancestor zone is in principle free to bypass
delegation and return "unexpected" signed answers for a child domain,
legitimately or otherwise.  Of course if a TLD were found doing that
for nefarious reasons, there'd be a major "covfefe".

--
    Viktor.