tested on Safari/Firefox and this issue is not present over there

Unable to reproduce the issue on mac 10.13.3 using chrome reported version #67.0.3396.99 and latest canary #69.0.3489.0.

Attached a screen cast for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to randomblabla.fr/randomblabla.us
2. Observed that it returned page not found "This site can’t be reached" error.

rvattakkandy@ - Could you please check the issue on latest canary #69.0.3489.0 by creating a new profile without any apps and extensions and please let us know if the issue still persist or not.

Thanks...!!

Deleted: 863030.mp4 293 KB

	863030.mp4 293 KB View Download

Tried latest canary #69.0.3489.0 and still the issue exist

I have re-installed my Mac OS, and then installed chrome freshly again, but still the issue exist!

This is one of the strangest issue that I ever faced.

- Tried from multiple ISPs (with Wifi connectivity to the router) and the issue exist everywhere

- Issue doesn't exist when connecting through my mobile hotspot

- wiped complete hard disk and installed Mac OS freshly, still issue exist

In any case, this issue is not present in firefox/safari. Wondering why it is affected to chrome only!

Attached the screen recording at: https://drive.google.com/file/d/17IFCz-e-cPt4xuES11TVYq-sK742HsTj/view?usp=sharing

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

I have reinstalled the mac by following: https://support.apple.com/en-in/HT204904

This could be two things:

1) An extension you have installed.
2) A DNS setting. Some routers will return a A record for any site and then do a redirect on that. Have you tried forcing to either OpenDNS or GoogleDNS?

Answers:

1. As you see in my recorded video, its a freshly installed macOS and chrome. No extensions installed
2. Yes, I tried google dns 8.8.8.8 and the problem persist

As I mentioned, I tried with different ISPs and the problem persist.

Is there a way we could collect more debug data to identify the root cause?

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

From the dns cache "chrome://net-internals/#dns" found following:


Not sure how chrome alone is getting this dns records, while firefox/safari/manual commands fails to retrieve these entries.

Deleted: Screen Shot 2018-07-16 at 7.53.21 PM.png 16.9 KB

	Screen Shot 2018-07-16 at 7.53.21 PM.png 16.9 KB View Download

# nslookup blablabladfd.fr
Server:         8.8.8.8
Address:        8.8.8.8#53

** server can't find blablabladfd.fr: NXDOMAIN

I just captured the tcpdump for the dns lookup while trying from google chrome:

20:03:34.884321 IP 192.168.1.2.48838 > google-public-dns-a.google.com.domain: 3829+ A? dsfsafdasf.us. (31)
20:03:34.934247 IP google-public-dns-a.google.com.domain > 192.168.1.2.48838: 3829 NXDomain 0/1/0 (97)
20:03:34.934659 IP 192.168.1.2.4392 > google-public-dns-a.google.com.domain: 18828+ A? dsfsafdasf.us.domain.name. (43)
20:03:35.331731 IP google-public-dns-a.google.com.domain > 192.168.1.2.4392: 18828 4/0/0 CNAME us.domain.name., A 87.98.219.110, A 91.121.91.180, A 198.245.51.138 (105)

Hope this will be helpful

I see that default domain configured on the router is set to "domain.name" and that is causing this problem I think.

Still, this could possibly be a chrome bug. We need to answer following questions.

1. why does chrome append the default search domain when a domain suffix is already given, for eg "domain.us"
2. This behaviour is not seen in any other browsers
3. This is not seen in windows version of google chrome

[+mef]:  Are we using the stub resolver on OSX?

I'm positive that we use proc (system) resolver on iOS as we can't get the DNS Config. 

IIRC we've had experimented with Async DNS on Mac OS X, but I'm not positive. 

rvattakkandy@: Could you collect a net internals log after restarting the browser and following these instructions: https://dev.chromium.org/for-testers/providing-network-details

Attached net log

tried accessing the URL: blablatestbla.fr and got redirected to: https://nxd-media.com

Deleted: chrome-net-export-log.json 449 KB

chrome-net-export-log.json 449 KB View Download

As the net log has been provided in comment#18 by reporter, requesting someone from Network team to have a look into it for further investigation of the log provided, hence adding label "TE-NeedsTriageHelp".

Thanks!

355: HOST_RESOLVER_IMPL_JOB
blablatestbla.fr
Start Time: 2018-07-18 20:52:10.274

t= 907 [st=  0] +HOST_RESOLVER_IMPL_JOB  [dt=472]
                 --> host = "blablatestbla.fr"
                 --> source_dependency = 354 (TRANSPORT_CONNECT_JOB)
t= 907 [st=  0]    HOST_RESOLVER_IMPL_JOB_STARTED
t= 907 [st=  0]   +HOST_RESOLVER_IMPL_DNS_TASK  [dt=472]
t= 907 [st=  0]     +DNS_TRANSACTION  [dt=472]
                     --> hostname = "blablatestbla.fr"
                     --> query_type = 1
t= 907 [st=  0]       +DNS_TRANSACTION_QUERY  [dt=57]
                       --> qname = "blablatestbla.fr"
t= 907 [st=  0]          DNS_TRANSACTION_ATTEMPT
                         --> source_dependency = 356 (UDP_SOCKET)
t= 907 [st=  0]          HOST_RESOLVER_IMPL_JOB_REQUEST_ATTACH
                         --> priority = "IDLE"
                         --> source_dependency = 354 (TRANSPORT_CONNECT_JOB)
t= 908 [st=  1]          HOST_RESOLVER_IMPL_JOB_REQUEST_ATTACH
                         --> priority = "IDLE"
                         --> source_dependency = 357 (TRANSPORT_CONNECT_JOB)
t= 964 [st= 57]          DNS_TRANSACTION_RESPONSE
                         --> answer_count = 0
                         --> rcode = 3
                         --> source_dependency = 356 (UDP_SOCKET)
t= 964 [st= 57]       -DNS_TRANSACTION_QUERY
                       --> net_error = -105 (ERR_NAME_NOT_RESOLVED)
t= 964 [st= 57]       +DNS_TRANSACTION_QUERY  [dt=415]
                       --> qname = "blablatestbla.fr.domain.name"
t= 964 [st= 57]          DNS_TRANSACTION_ATTEMPT
                         --> source_dependency = 361 (UDP_SOCKET)
t=1379 [st=472]          DNS_TRANSACTION_RESPONSE
                         --> answer_count = 4
                         --> rcode = 0
                         --> source_dependency = 361 (UDP_SOCKET)
t=1379 [st=472]       -DNS_TRANSACTION_QUERY
t=1379 [st=472]     -DNS_TRANSACTION
t=1379 [st=472]   -HOST_RESOLVER_IMPL_DNS_TASK
                   --> address_list = ["87.98.219.110:0","91.121.91.180:0","198.245.51.138:0"]
t=1379 [st=472] -HOST_RESOLVER_IMPL_JOB

mmenke@: The HOST_RESOLVER_IMPL_DNS_TASK is coming from Async resolver. 
It is enabled on Mac OS by default.

Retrying failed DNS resolutions appending each entry from res_init()'s dnsrch list (the list of domains to be searched) seems to be correct default behavior (see how RES_DNSRCH is default enabled).  Using wireshark we verified both Mac and Linux do this when you for example try and ping an unknown host (i.e. if you try and ping "a" and your dnsrch list is "b" and "c", getaddrinfo() will issue resolution requests for "a", "a.b", and "a.c").

The issue here seems to be the incorrect dnsrch list your router is installing.  Could you comment about what router brand and model you're using?  If this is a common misconfiguration, perhaps a mitigation in Chrome is a possible solution.

It is not just dnsrch list in my router configuration.

default dnsrch domain in router is configured to: domain.name

You can easily reproduce this if you set dnsrch domain to "domain.name"

Key points here:

- this issue is not happening with any other browsers, but just chrome
- "blablatestbla.fr" is an FQDN with ".fr" as the TLD. So it should not go and append dnsrch domain, but should return 404 error
- Same behaviour is not seen with windows version of google chrome.
- This incorrect behaviour is now misused by phishing websites, as given in this example.

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Hmm I'm not sure where it's documented that hostnames with TLD suffixes should bypass dnsrch.  Things like ping don't seem to conform to this.

Still seems like a dnsrch of domain.name is a misconfiguration.  My ISP, one of the most popular in the US, gives out legit dnsrch's which my Linksys router happily passes along via DHCP.

see the ping output:

# ping blablabladfd1.fr
ping: cannot resolve blablabladfd1.fr: Unknown host



tcpdump:

05:56:19.169875 IP 192.168.1.3.57453 > google-public-dns-a.google.com.domain: 45770+ A? blablabladfd1.fr. (34)
05:56:19.171365 IP 192.168.1.3.64010 > google-public-dns-a.google.com.domain: 20039+ PTR? 3.1.168.192.in-addr.arpa. (42)
05:56:19.218735 IP google-public-dns-a.google.com.domain > 192.168.1.3.57453: 45770 NXDomain 0/1/0 (94)
05:56:19.221157 IP google-public-dns-a.google.com.domain > 192.168.1.3.64010: 20039 NXDomain 0/0/0 (42)