Extra resolvers are sometimes used
Reported by
paulddra...@gmail.com,
Dec 15 2016
|
||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36 Example URL: Steps to reproduce the problem: Sometimes Chrome ignores the resolvers set in /etc/resolv.conf and uses extra resolvers. What is the expected behavior? It should always use only the specified system resolvers. What went wrong? This inconsistently causes incorrect DNS lookups.chrome://net-internals/#dns nameservers are the correct list, as taken from /etc/resolv.conf When there are issues, UDP dumps show chrome trying to access resolver1.level3.net and maybe others. Did this work before? No Chrome version: 53.0.2785.116 Channel: stable OS Version: Ubuntu 14.04 Flash Version: Shockwave Flash 24.0 r0 Chrome seems to use DNS resolvers correct most of the time; only sometimes does it get into a funk where it doesn't. Restarting Chrome causes it to use the correct resolvers again. Async DNS Configuration Internal DNS client enabled: true nameservers 10.12.0.42:53 10.12.64.42:53 209.244.0.3:53 append_to_multi_label_name true attempts 2 edns0 false ndots 1 num_hosts 73 rotate false search office.lucidchart.com timeout 1 unhandled_options false
,
Dec 15 2016
resolver1.level3.net? Any idea where we'd get that from? We will talk to Google DNS when we see a DNS error, to check if your DNS seems to be working and you have an internet connection, I assume that's not what you're seeing? (We won't send the DNS address you were looking up to GDNS - we just look up google.com or somesuch).
,
Dec 16 2016
Adding 'Needs-Milestone' label, TE will check the issue and update the bug with comments & tag with respective Mstone
,
Dec 16 2016
This is the tcpdump of me accessing https://jenkins.lucidchart.com in this state after clearing the host cache. (Resources are loaded from aarjithn.github.io and fonts.googleapis.com; must be doing some prefetch for those.) $ sudo tcpdump -i any udp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on any, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 10:49:50.753165 IP6 ip6-localhost.49882 > ip6-localhost.50047: UDP, length 0 10:49:52.131408 IP 192.168.0.1.50743 > 255.255.255.255.7437: UDP, length 173 10:49:52.261267 IP paul.office.lucidchart.com.58018 > resolver1.level3.net.domain: 29369+ A? jenkins.lucidchart.com. (40) 10:49:52.261564 IP paul.office.lucidchart.com.44644 > resolver1.level3.net.domain: 6304+ A? aarjithn.github.io. (36) 10:49:52.261870 IP paul.office.lucidchart.com.17899 > resolver1.level3.net.domain: 52157+ A? fonts.googleapis.com. (38) 10:49:52.286286 IP resolver1.level3.net.domain > paul.office.lucidchart.com.17899: 52157 2/0/0 CNAME googleadapis.l.google.com., A 216.58.203.42 (90) 10:49:52.463002 IP resolver1.level3.net.domain > paul.office.lucidchart.com.44644: 6304 2/0/0 CNAME github.map.fastly.net., A 151.101.24.133 (87) 10:49:52.478081 IP resolver1.level3.net.domain > paul.office.lucidchart.com.58018: 29369 NXDomain 0/1/0 (118) 10:49:52.478358 IP paul.office.lucidchart.com.54168 > resolver1.level3.net.domain: 34931+ A? jenkins.lucidchart.com.office.lucidchart.com. (62) 10:49:52.501567 IP resolver1.level3.net.domain > paul.office.lucidchart.com.54168: 34931 2/0/0 CNAME office.lucidchart.com., A 65.181.56.178 (92) Maybe unrelated, but if anyone knows how I can prevent the DNS suffix search, that would also help me.
,
Dec 16 2016
(DNS suffix search being the part where it goes from trying jenkins.lucidchart.com to jenkins.lucidchart.com.office.lucidchart.com because my local hostname is paul.office.lucidchart.com.)
,
Dec 20 2016
Err....sorry 209.244.0.3 is resolver1.level3.net (didn't have a reverse DNS entry). It does seem that Chrome is pretty aggressive about marking DNS servers as down and keeping them as down...but the issue can be resolved. I filed a separate bug with the suffix search problems I'm having https://bugs.chromium.org/p/chromium/issues/detail?id=676085
,
Jan 3 2017
Once a server fails for a particular number of attempts in a row (I think we get the number of attempts from the local DNS configuration), I don't believe we'll ever try it again as long as we have another (Another two?) servers that have not failed that number of times in a row, unless we reload the DNS configuration (And perhaps only if the DNS configuration has changed from when we last read it).
,
Jan 11 2017
,
May 9 2017
,
Mar 2 2018
|
||||||
►
Sign in to add a comment |
||||||
Comment 1 by paulddra...@gmail.com
, Dec 15 2016