On Fri, Jun 05, 2020 at 12:44:03PM +0200, Steinar Haug via Pdns-users wrote:
> We recently upgraded from Recursor 4.2.1 to 4.3.1, due to the recent > security alert. Unfortunately, after this upgrade some queries have > stopped working. > > The examples below are from a test installation where the only config > are the following two lines: > > query-local-address=193.75.4.60 > trace=on > > Example of query which works with 4.2.1: > > % dig microsoft-my.sharepoint-df.com @127.0.0.1 > > ; <<>> DiG 9.16.3 <<>> microsoft-my.sharepoint-df.com @127.0.0.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19220 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;microsoft-my.sharepoint-df.com. IN A > > ;; ANSWER SECTION: > microsoft-my.sharepoint-df.com. 3600 IN CNAME www.sharepoint-df.com. > www.sharepoint-df.com. 3600 IN CNAME microsoftcan.sharepoint.com. > microsoftcan.sharepoint.com. 3600 IN CNAME > 2-ipv4mte.clump.msit.aa-rt.sharepoint.com. > 2-ipv4mte.clump.msit.aa-rt.sharepoint.com. 30 IN CNAME > 82022-ipv4mte.farm.msit.aa-rt.sharepoint.com. > 82022-ipv4mte.farm.msit.aa-rt.sharepoint.com. 30 IN CNAME > 82022-ipv4mte.farm.msit.sharepointonline.com.akadns.net. > 82022-ipv4mte.farm.msit.sharepointonline.com.akadns.net. 300 IN CNAME > 82022-ipv4.farm.msit.aa-rt.sharepoint.com.spov-0006.spov-msedge.net. > 82022-ipv4.farm.msit.aa-rt.sharepoint.com.spov-0006.spov-msedge.net. 240 IN > CNAME spov-0006.spov-msedge.net. > spov-0006.spov-msedge.net. 240 IN A 13.107.137.11 > > ;; Query time: 2276 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Jun 05 12:22:29 CEST 2020 > ;; MSG SIZE rcvd: 366 > > But with 4.3.1 the query returns SERVFAIL and the last resolution to A > is missing: > > % dig microsoft-my.sharepoint-df.com @127.0.0.1 > > ; <<>> DiG 9.16.3 <<>> microsoft-my.sharepoint-df.com @127.0.0.1 > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 45924 > ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 0, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;microsoft-my.sharepoint-df.com. IN A > > ;; ANSWER SECTION: > microsoft-my.sharepoint-df.com. 3600 IN CNAME www.sharepoint-df.com. > www.sharepoint-df.com. 3600 IN CNAME microsoftcan.sharepoint.com. > microsoftcan.sharepoint.com. 3600 IN CNAME > 2-ipv4mte.clump.msit.aa-rt.sharepoint.com. > 2-ipv4mte.clump.msit.aa-rt.sharepoint.com. 30 IN CNAME > 82022-ipv4mte.farm.msit.aa-rt.sharepoint.com. > 82022-ipv4mte.farm.msit.aa-rt.sharepoint.com. 30 IN CNAME > 82022-ipv4mte.farm.msit.sharepointonline.com.akadns.net. > 82022-ipv4mte.farm.msit.sharepointonline.com.akadns.net. 300 IN CNAME > 82022-ipv4.farm.msit.aa-rt.sharepoint.com.spov-0006.spov-msedge.net. > 82022-ipv4.farm.msit.aa-rt.sharepoint.com.spov-0006.spov-msedge.net. 240 IN > CNAME spov-0006.spov-msedge.net. > > ;; Query time: 3276 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Fri Jun 05 12:24:20 CEST 2020 > ;; MSG SIZE rcvd: 350 > > In the trace log for 4.3.1 we see the following which ends with the > message about SERVFAIL: > > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-04.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-04.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-03.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-03.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-01.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-01.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-02.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > ns3-02.azure-dns.org: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > a0.org.afilias-nst.info: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > afilias-nst.info: recursing (CNAME or other indirection) too deep, depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > a0.org.afilias-nst.info: recursing (CNAME or other indirection) too deep, > depth=17 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > a2.org.afilias-nst.info: recursing (CNAME or other indirection) too deep, > depth=16 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > d0.org.afilias-nst.org: recursing (CNAME or other indirection) too deep, > depth=16 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > b2.org.afilias-nst.org: recursing (CNAME or other indirection) too deep, > depth=16 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > c0.org.afilias-nst.info: recursing (CNAME or other indirection) too deep, > depth=16 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > b0.org.afilias-nst.org: recursing (CNAME or other indirection) too deep, > depth=16 > Jun 5 12:24:20 lab4 pdns_recursor[13424]: [1] > 82022-ipv4.farm.msit.aa-rt.sharepoint.com.spov-0006.spov-msedge.net: > status=got a CNAME referral, but recursing too deep, returning SERVFAIL > > I have tried: > > max-ns-address-qperq=50 (default 10) > max-qperq=120 (default 60) > max-recursion-depth=0 (default 40) > > but the end result is still the same - SERVFAIL and the last A record > missing. > > Any suggestions? Bug report to Github? > > This is unfortunately serious enough for our users that I may have > downgrade to 4.2.1. > > Steinar Haug, AS2116 > _______________________________________________ > Pdns-users mailing list > Pdns-users@mailman.powerdns.com > https://mailman.powerdns.com/mailman/listinfo/pdns-users This is a known issue: https://github.com/PowerDNS/pdns/pull/9192 As a temporary workaround, you try disabling qname-minimization: qname-minimization=off -Otto _______________________________________________ Pdns-users mailing list Pdns-users@mailman.powerdns.com https://mailman.powerdns.com/mailman/listinfo/pdns-users
