[dns-operations] Validation anomalies under gpo.gov

[Viktor Dukhovni]

On Fri, Apr 03, 2020 at 07:47:09PM -0700, Brian Somers wrote:

> > On Apr 3, 2020, at 1:49 PM, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
> > 
> > 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”.
> 
> That didn’t occur to me, but yes, I agree.  If the access.gpo.gov/NS RRset is
> considered BOGUS (it should be signed) and because of that the delegation
> (to self) is considered “not present" then google & verisign are correct!

It is even simpler than that.

When, hypothetically, the example.com zone returns a signed answer for
the A RRset of "foo.bar.example.com" to a resolver that is not doing
qname minimisation, the resolver is not expected to go back and check
for potential delegation at "bar.example.com" (or its "foo" subdomain),
bogus or otherwise.

When  "example.com" is authoritative for "foo.bar.example.com" and
returns a valid signed answer, that answer is taken at face value.

> I wonder if this is some sort of canary domain?!

I very much doubt it.  This is Government Publishing Office, likely not
a high-tech DNS-savvy organisation.  Mere lack of operational discipline
is sufficient to explain the observed symptoms.

> In our case, we deduce that there IS a delegation point.

Perhaps you're doing qname minimisation.  Given the bogus response,
failure for child domains is not an unreasonable outcome, though as
you say below:

> I wonder if it’s better behaviour to ignore BOGUS NS RRsets (given that
> they can only be declared BOGUS if they came from the authority as
> opposed to being supplied as glue)?

it could be reasonable to ignore the bogus NS RRset (other than forward
it to clients that set CD=1) and then accept any answers that happen to
have valid signatures from the parent zone.

Since the bogus answers here are consistently observed from multiple
vantage points, and over a long time, they are with high probability
misconfiguration at gpo.gov, and the solution is for them to fix
their zone and/or nameservers.

I think a case can be made for either failing, and not failing lookups
when your cache gets bogus glue, but it is certainly possible to be
simply oblivious to the problem by not doing qname-minimisation.

-- 
    Viktor.