[dns-operations] Anyone with contacts at Paypal and/or Ultradns?

[Viktor Dukhovni]

On Thu, Dec 12, 2019 at 07:48:15AM +0100, Tom Ivar Helbekkmo wrote:

> Viktor Dukhovni <ietf-dane at dukhovni.org> writes:
> 
> > If you disable qname minimization and flush your cache, it would be
> > interesting to learn what issues you still see after that, assuming
> > you're willing to re-enable the ultradns servers long enough to
> > perform a test.
> 
> I did that before blocking out the ultradns servers.  It still failed,
> and the reason is that the PowerDNS recursor, when validating DNSSEC,
> inspects each node in the tree, searching for DS records.  The error in
> those particular ENTs will render them, and anything below them, bogus.

Ah, so it seems that PowerDNS recursor pays most of the cost of qname
minimization even with qname-minization turned off?

I use unbound, and I think the corresponding setting is:

   harden-referral-path: <yes or no>
      Harden  the  referral  path by performing additional queries for
      infrastructure data.  Validates the replies if trust anchors are
      configured and the zones are signed.  This enforces DNSSEC vali-
      dation on nameserver NS sets and the nameserver  addresses  that
      are encountered on the referral path to the answer.  Default no,
      because it burdens the authority servers,  and  it  is  not  RFC
      standard,  and could lead to performance problems because of the
      extra query load that is generated.   Experimental  option.   If
      you  enable  it  consider  adding  more  numbers  after the tar-
      get-fetch-policy to increase the max depth that is checked to.

which is off by default.  Repeated flushing of the entire cache,
followed by queries for the qname you're testing always return results
with no noticeable delay and never result in ServFail.

> Did it again, now - here's what happens with qname minimization turned
> off, but DNSSEC validation left on, and the recursor restarted:
> 
> : barsoom# ;dig -t txt 1sfdc._domainkey.paypal.com
> 
> ; <<>> DiG 9.14.8 <<>> -t txt 1sfdc._domainkey.paypal.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45727
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
> ;1sfdc._domainkey.paypal.com.   IN      TXT
> 
> Dec 12 07:34:12 barsoom pdns_recursor[846]: Answer to 1sfdc._domainkey.paypal.com|TXT for 127.0.0.1:52836 validates as Bogus

So it looks like PowerDNS recursor is more sensitive to this type of
nameserver breakage.  Now I'm no apologist for the nameserver bugs, I've
been fighting various denial of existence bugs myself over the years.  I
have a list of just over 1k domains with TLSA-related denial of
existence problems, the top 20 guilty parties by domain count are:

 329 mijnhostingpartner.nl
  89 egensajt.se
  54 movenext.nl
  41 metaregistrar.nl
  32 tiscomhosting.nl
  31 eurodns.com
  27 nrdns.nl
  26 hostnet.nl
  19 sylconia.net
  14 is.nl
  11 openprovider.nl
  10 dnscluster.nl
   9 cloudflare.com
   9 cdmon.net
   9 army.mil
   8 host-redirect.com
   8 flinks.se
   8 enterweb.nl
   7 mobi-net.ch
   7 forpsi.net

So I'm not blame-shifting to either your configuration, or PowerDNS,
just reporting that at the present moment, there is still a small
minority of domains hosted by nameservers that mishandle authenticated
denial of existence, and it is perhaps sadly prudent (for now) to
use resolver strategies that avoid running some of the breakage.

-- 
    Viktor.