New issue
Advanced search Search tips

Issue 674581 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2018
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux
Pri: 2
Type: Bug



Sign in to add a comment

Extra resolvers are sometimes used

Reported by paulddra...@gmail.com, Dec 15 2016

Issue description

UserAgent: 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
 
To be clear, chrome://net-internals/#dns always shows the correct list when I check; there appear to be resolvers not present in that list.

Comment 2 by mmenke@chromium.org, Dec 15 2016

Components: -Internals>Network Internals>Network>DNS
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).
Labels: Needs-Milestone
Adding 'Needs-Milestone' label, TE will check the issue and update the bug with comments & tag with respective Mstone
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.
(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.)
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
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).
Labels: TE-NeedsTriageHelp
Owner: mge...@chromium.org
Owner: ----
Status: WontFix (was: Unconfirmed)

Sign in to add a comment