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

[Paul Vixie]

please, no. the longer the innocent work around it, the larger the pool of unintended guilty will get. re:

⁣Get BlueMail for Android ​

On 12 Dec 2019, 08:19, at 08:19, Viktor Dukhovni <ietf-dane at dukhovni.org> wrote:
>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.
>_______________________________________________
>dns-operations mailing list
>dns-operations at lists.dns-oarc.net
>https://lists.dns-oarc.net/mailman/listinfo/dns-operations
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20191212/78d6d9a5/attachment.html>