New issue
Advanced search Search tips

Issue 640596 link

Starred by 1 user

Issue metadata

Status: Available
Owner: ----
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment

Order of DNS RR (CNAME/A) prevents domain resolution

Reported by m...@rcel.cz, Aug 24 2016

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2838.0 Safari/537.36

Example URL:
www.paypalobjects.com

Steps to reproduce the problem:
1. Open Chrome on Linux (tested on Fedora/OpenSUSE)
2. Clear all Chrome browsing data
3. Try going to "www.paypalobjects.com"

What is the expected behavior?

What went wrong?
Chrome fails with "DNS_PROBE_FINISHED_NXDOMAIN".

Seems like Chrome on linux (Fedora/OpenSUSE) can't properly handle DNS answer containing multiple CNAMEs "without the right order".

This is the RR order for www.paypalobjects.com received from our internal DNS (running PowerDNS 4.0.1 on CentOS 6).

;; QUESTION SECTION:
;www.paypalobjects.com.         IN      A

;; ANSWER SECTION:
www.paypalobjects.com.  341     IN      CNAME   www.paypalobjects.com.akadns.net.
e3691.g.akamaiedge.net. 20      IN      A       104.103.76.134
www.paypalobjects.com.edgekey.net. 120 IN CNAME e3691.g.akamaiedge.net.
www.paypalobjects.com.akadns.net. 300 IN CNAME  www.paypalobjects.com.edgekey.net.

RFC 1034 mentions that RR order is not significant so I believe it shouldn't matter. (I see http://unix.stackexchange.com/questions/164872/dig-command-is-the-output-guaranteed-to-be-sorted mentioning CNAME order is guaranteed but I can't find that in RFC.)

I'm convinced that it's caused by the CNAME/A RR order because Chrome loads the page once answer with acceptable order is received (checked in Wireshark).

chrome://net-internals/#dns reports following:
www.paypalobjects.com	IPV4	error: -105 (ERR_NAME_NOT_RESOLVED)	2016-08-24 14:34:14.542 [Expired]

I didn't try replicating the problem outside the internal PowerDNS server. Both Google Public DNS and BIND return DNS answer with acceptable RR order (that works with Chrome).

Did this work before? N/A 

Chrome version: 52.0.2743.116  Channel: n/a
OS Version: Fedora 24
Flash Version:
 
Components: -Internals>Network Internals>Network>DNS
Labels: -OS-Linux OS-All
Owner: juliatut...@chromium.org
Status: Assigned (was: Unconfirmed)
Yup, we expect the CNAME chain to be in order. Lemme see how hard it would be to handle out-of-order ones.
Do you have a sense for how often this happens when behind a PowerDNS server? IS it an occasional flake, or does it make Chrome fairly unusable?

Comment 4 by m...@rcel.cz, Aug 24 2016

Out of tens request to that domain I tried today i saw that out of order in 80-90% of cases (when viewing dig output in Cygwin on Windows or monitoring traffic of linux in Wireshark). 

But that out of order was only with our PowerDNS instance. I tried some other public PowerDNS servers and I never encountered any CNAME out of order. However the servers I tried were probably not running 4.x (based on info from http://public-dns.info ).

I can try duplicating the issue with another PowerDNS instance (and the exact configuration from our admins). Alternatively we can try flushing whatever it's possible to flush in PowerDNS but so far I'm not aware that the out of order CNAMEs are something non RFC compliant in PowerDNS.

Comment 5 by m...@rcel.cz, Aug 25 2016

I installed PowerDNS Recursor 4.0.1 in Fedora 24 (with the default settings), started it and responses were fine (in order). However once the record with shortest TTL expired (20), it got out of order and stayed like that.

$ dig @127.0.0.1 a www.paypalobjects.com

; <<>> DiG 9.10.4-P2-RedHat-9.10.4-1.P2.fc24 <<>> @127.0.0.1 a www.paypalobjects.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58339
;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.paypalobjects.com.		IN	A

;; ANSWER SECTION:
www.paypalobjects.com.	3579	IN	CNAME	www.paypalobjects.com.akadns.net.
e3691.g.akamaiedge.net.	20	IN	A	104.103.76.134
www.paypalobjects.com.	3579	IN	RRSIG	CNAME 5 3 3600 20160904000120 20160804231339 65355 paypalobjects.com. 3YOD5bDq7DE9cRW/DhQ1hQbLpTYr3/mhv62ZguY39HOLXf7nn5ZhstPz /KZqcdMTboKHOBw8jESv9fqPCfHqvDTqXLW2HcfbGmWyT9PrJz4nZKO0 HD7eK/qN6z+QVzTZ016fbwtyG8ySvtmQE12CYaMszIMFqhMP9GOc5J1P ma0=
www.paypalobjects.com.edgekey.net. 99 IN CNAME	e3691.g.akamaiedge.net.
www.paypalobjects.com.akadns.net. 279 IN CNAME	www.paypalobjects.com.edgekey.net.

;; Query time: 9 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Aug 25 07:46:44 CEST 2016
;; MSG SIZE  rcvd: 366

Comment 6 by m...@rcel.cz, Aug 25 2016

Related PowerDNS 4.0.1 issue: https://github.com/PowerDNS/pdns/issues/4339
Owner: ----
Status: Available (was: Assigned)
Owner: mge...@chromium.org
Owner: ----

Sign in to add a comment