Outgoing Connection Attempts to kgnmwyga, jtqnveir, etc. -- resolving to Akamai IPs if OpenDNS is used

Description Hi, convinced a friend to give Brave a try and he recently pointed out he had some outgoing connection attempts from the browser to invalid DNS names that we are unable to resolve but the browser seems to have resolved it and attempted to initiate a connection.

Steps to Reproduce

1. Have some outgoing firewall set up
2. Launch Brave
3. Wait for outgoing connection attempts

Actual result:

Expected result:

For at least no-thanks.invalid to not resolve to a host and a connection to not be initiated. I thought the whole incentive for replacing GAIA hostnames with no-thanks.invalid was to blackhole the attempt.

And how are kgnmwyga, jtqnveir etc. even resolved IP addresses owned by Akamai?

Reproduces how often:

Easily reproduced.

Brave version (brave://version info)

Brave    1.1.23 Chromium: 79.0.3945.88 (Official Build) (64-bit)
Revision    c2a58a36b9411c80829b4b154bfcab97e581f1f3-refs/branch-heads/3945@{#954}
OS    macOS Version 10.14.6 (Build 18G1012)
JavaScript    V8 7.9.317.32

Version/Channel Information:

Haven’t tried on any other versions/channels. I could ask him if you think it will help provide more data points.

Other Additional Information:

• Does the issue resolve itself when disabling Brave Shields? Not tested.
• Does the issue resolve itself when disabling Brave Rewards? Not tested.
• Is the issue reproducible on the latest version of Chrome? No

Miscellaneous Information:

I asked him if he is using OpenDNS or any other DNS provider that returns “placeholder” A records in an NXDOMAIN scenario. He then said yes, he uses OpenDNS.

I asked him to resolve a bogus domain.

; <<>> DiG 9.10.6 <<>> somethingasdaskldjasldkj
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48398
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;somethingasdaskldjasldkj.    IN    A

;; ANSWER SECTION:
somethingasdaskldjasldkj. 10    IN    A    23.202.231.166
somethingasdaskldjasldkj. 10    IN    A    23.195.69.106

;; Query time: 27 msec
;; SERVER: 192.168.1.1#53(192.168.1.1)
;; WHEN: Fri Dec 27 11:35:29 PST 2019
;; MSG SIZE  rcvd: 74

It resolved to an Akamai IP in a similar IP block to the earlier resolutions.

So I guess the fact that these resolved is now explained however doesn’t that cast some doubt on replacing GAIA domains with domains that’ll result in NXDOMAIN? Perhaps that code should be removed at a more fundamental level?

[canselcik]

Thanks everyone for all the answers. Definitely has been helpful.

Basically when OpenDNS is used, any NXDOMAIN will get an A record to an IP running an HTTP server controlled by OpenDNS serving the search/suggestion page. And as far as I know that is indeed the expected behavior unless you use their customization features but then you need a static IP so that they know not to serve you that fake A record.

Definitely removing the call to GAIA would be better all together however I understand the reason why this approach was taken instead.

Thanks again. 👍

[bsclifton]

@jonathansampson that is correct; the nothanks.invalid is the call to GAIA, which we change the URL for. A better approach might be to remove the call altogether

@canselcik hopefully this helps answer the question 😄 Would you be able to have your friend try on Chrome to see if the same behavior happens? (with the various lookups). Is this expected behavior for OpenDNS?