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 <[email protected]> wrote: >On Thu, Dec 12, 2019 at 07:48:15AM +0100, Tom Ivar Helbekkmo wrote: > >> Viktor Dukhovni <[email protected]> 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 >[email protected] >https://lists.dns-oarc.net/mailman/listinfo/dns-operations
_______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations
