[dns-operations] [DNSOP] bind fails to continue recursing on one specific query

Viktor Dukhovni ietf-dane at dukhovni.org
Wed Mar 29 21:46:08 UTC 2023


On Wed, Mar 29, 2023 at 08:57:51AM -0400, jmurray at pdknox.org wrote:

> * Viktor Dukhovni <ietf-dane at dukhovni.org> [230328 00:05]:
> > The queries for "_.extglb.tn.gov. IN A ?" in your PCAP are a novelty to
> > me.  Are these some form of query minimisation, or some sort of sanity
> > check of the delegation?  Sadly, the "tn.gov" nameserver just drops
> > these without responding, so their failure could well contribute to the
> > problems you observe.
> 
> A little more info here. My informant was cagey, but I think I
> understand that they are providing a whitelist of extant domains and
> their upstream is using that to filter queries as a mitigation
> measure. "Scrubbing terabytes of malicious traffic" was mentioned. 
> 
> Having found this,
> 
> https://gitlab.isc.org/isc-projects/bind9/-/issues/3331
> 
> though I can't access the ticket mentioned, I was inspired to try
> finding the zone cuts on tn.gov using NS queries; none my queries were
> dropped as those with underscore labels were.

Dropping all queries for which the response would be NXDOMAIN is a
terrible idea.  They may have outsourced their DNS to a plausibly
well-meaning, but not obviously skilled operator.

> Take it with a grain of salt as I really have no idea what I'm doing,
> but if this is a common anti-ddos technique then maybe this goes on
> the NS side of the qname minimization balance.

If always dropping instead of NXDOMAIN were particularly common, we'd be
hearing about a lot more breakage, both from BIND users and from senders
doing DANE SMTP where dropping of queries for TLSA records that aren't
there leads to deferring and ultimately bouncing email.

This doesn't mean that one wants to deliberately "poke the bear", and
perhaps "NS" for the apex is more prudent than "A" for "_.<apex>", but
both are reasonably expected to work (as are _25._tcp.<mxhost>, when
the <mxhost> zone is DNSSEC signed, whether or not the TLSA RRs exist).

Out of 21.6 million DNSSEC-signed zones, only ~3k have TLSA denial of
existence issues, and the vast majority are NSEC chain issues, with
roughly six or so TLSA non-responders).

-- 
    Viktor.



More information about the dns-operations mailing list