[dns-operations] Anyone with contacts at Paypal and/or Ultradns?
ietf-dane at dukhovni.org
Thu Dec 12 07:04:22 UTC 2019
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: 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:
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.
More information about the dns-operations