Because I want to use my own DNS server and block ads at the DNS level rather than the browser level. With this move, Google has effectively white listed adsense / adwords to not be blocked regardless of the network settings of the device.

this is confusing.

https://www.xda-developers.com/fix-dns-ad-blocker-chrome/

seems that the problem is not async itself, but that chrome ignores the system DNS settings and uses googles own DNS servers instead.

That is a good point, I might have been pointing at the wrong issue in Chrome. I have only seen this behavior happen since 2-3 days ago and all my research pointed me to async dns being the culprit. I am really eager to find out if this can be disabled in any way, but my Chrome time has come to an end with recent developments.

Seems like a bug. Some environments cannot reach external DNS servers, so it would break resolution in general. This happened before and was fixed: https://bugs.chromium.org/p/chromium/issues/detail?id=265970 I couldn't find any report for the current issue though - maybe you should start one.

Chrome doesn't respect DNS settings anyway. I have in my resolv.conf:

    search my.home

And entering hostname of my server would just googles the hostname of my server, instead of trying a lookup and googling only afterwards (or never, I don't see why the browser should contact the owner just because I mistyped the url).

This point merits an explanation. The file /etc/resolv.conf is a configuration file for the `dns` NSS module used by the glibc resolver.

Google's async DNS feature uses Chrome's own internal DNS resolver which doesn't call gethostname(). It would be incorrect for Chrome to parse this file and attempt to "respect" your settings because NSS is a series of black-box system-specific modules. If you removed the dns module from /etc/nsswitch.conf then resolv.conf wouldn't even enter the mix on your system and then Chrome would do the wrong thing. If the dns module behaved differently on your system and /etc/resolv.conf was actually /etc/resolv.json or /etc/resolver.conf then Chrome would again do the wrong thing.

When resolving a name applications have two choices, either look up the name with glibc, send the request through the NSS gauntlet of black-box modules and take whatever it returns of perform the DNS request itself and ignore everything on the system. Any sort of hybrid approach would be more confusing.

Hmm, so does this mean /etc/hosts will no longer work either, etc.? That's handled by the same glibc function too.