[Pdns-users] Recursor 4.3.1 problems with long CNAME chains
sthaug at nethelp.no
sthaug at nethelp.no
Fri Jun 5 10:44:03 UTC 2020
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
More information about the Pdns-users
mailing list