Level(3) DNS Spoofing All Domains

Mailman List Mirror (Read Only)
1

This is mostly informational and may have already hit this group. My google-foo failed me if so.

I discovered that the CenturyLink/Level(3) public DNS (4.2.2.2, etc) are spoofing all domains. If the hostname begins with a “w” and does not exist in the authoritative zone these hosts will return two Akamai hosts.

[root@localhost ~]# dig +short w3.dummydomaindoesntexist.gov @4.2.2.2

23.202.231.167

23.217.138.108

[root@localhost ~]# dig +short w3.dummydomaindoesntexist.net @4.2.2.2

23.202.231.167

23.217.138.108

[root@localhost ~]# dig +short w3.dummydomaindoesntexist.com @4.2.2.2

23.202.231.167

23.217.138.108

[root@localhost ~]# dig +short w3.dummydomaindoesntexist.org @4.2.2.2

23.202.231.167

23.217.138.108

My apologies if this is old news.

Lawrence Q. Marshall

2

Are you a CL/L3 customer? Those resolvers have only ever been for “customers” even though they would resolve for anyone. They started injecting NXDOMAIN redirects a while ago for non-customers.

3

Wow, news to me, and it’s worse than you thought. They’re spoofing responses for ALL non-existent domains, not just those starting with a “w”:

langsam:~# whois unregistereddomaintest.com | head -1
No match for “UNREGISTEREDDOMAINTEST.COM”.

langsam:~# dig +short a unregistereddomaintest.com @4.2.2.2
23.202.231.167
23.217.138.108

langsam:~# dig +short a unregistereddomaintest.mil @4.2.2.2
23.202.231.167
23.217.138.108

I can’t get an NXDOMAIN result from 4.2.2.2 at all.

Good to know. Time to reconfigure 10,000 firewalls.

Thank you Lawrence.

  • Cary Wiedemann
4

I discovered that the CenturyLink/Level(3) public DNS (4.2.2.2, etc) are spoofing all domains. If the hostname begins with a “w” and does not exist in the authoritative zone these hosts will return two Akamai hosts.

[root@localhost ~]# dig +short w3.dummydomaindoesntexist.gov @4.2.2.2
23.202.231.167
23.217.138.108

It depends of the server you're hitting:

From AS3215 (.fr)

$ dig +short w3.dummydomaindoesntexist.org @4.2.2.2
23.217.138.108
23.202.231.167

$ dig +short caseraitvraimentconquilexiste.org @4.2.2.2
23.217.138.108
23.202.231.167

$ dig +short hostname.bind txt ch @4.2.2.2
"pubntp1.lon1.Level3.net"

From AS16276 (.ca):

$ dig w3.dummydomaindoesntexist.org @4.2.2.2
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34998
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

$ dig +short hostname.bind txt ch @4.2.2.2
"cns4.nyc1.Level3.net"

5

Just to weigh in: Here in Germany, the largest internet provider (Deutsche Telekom) did the same thing.
It's basically just a "search guide", it redirects you to a search page and assumes you just had a typo in the URL.

Telekom stopped doing that in April, after a user reported them to the district attorney for supposed data manipulation, a misdemeanor.

6

Just to weigh in: Here in Germany, the largest internet provider (Deutsche Telekom) did the same thing.
It’s basically just a “search guide”, it redirects you to a search page and assumes you just had a typo in the URL.

Telekom stopped doing that in April, after a user reported them to the district attorney for supposed data manipulation, a misdemeanor.

If your entire Internet is just the web then it’s perhaps not a big deal. But there are a lot of protocols that depend on proper functioning of NXDOMAIN. If you recall, Verisign got in a bunch of trouble for doing that back in the day at the authoritative level.

7

Yep, old news. :slight_smile: It's their "SearchGuide(TM)" nonsense.

You can opt out, but as of about 1.5? months ago it's almost impossible
to because the applet was serving a 500, and now it just refuses to work
*despite* serving a 200. And it's flaky as all else - when the applet
goes down, the resolvers take the ...aherm, "liberty" of automatically
enabling SearchGuide during the outage.

You can either attempt it via going to e.g.:
  http://searchguide.level3.com/search/?q=foo
and clicking the "Settings" link in the upper right. If you get "There
was a problem retrieving your settings from the server. Please try your
request again later.", then congrats! You won the prize of not being
able to change the redirect.

Alternatively, you can TRY running something like this:
https://pastebin.com/zktqqCxU but AGAIN, it depends on that endpoint
actually being *accessible*.

Which it increasingly is not.

I've moved on from level3 for resolvers; their reliability's been
declining but this nonsense just tanked them for me.
Lately I've been using Verisign's resolvers (64.6.64.6 and 64.6.65.6)
for upstream on my cachers, and I've been pretty pleased with it. They
seem to express a focus on privacy, which is nice, but most importantly-
records seem to get through unmolested, NXDOMAINs and all. Just as it
should be. :wink:

8

On Tuesday, November 19, 2019 10:42 AM Ryan, Spencer…

“Are you a CL/L3 customer?”

I am a legacy L(3) customer.

The availability of their AnyCast NS is public from my nets. I was on a my home TWC circuit when I ran the provided lookups.

I have used the L(3) NS, in a pinch, because of their reliability, privacy, and ease. I would assume that others did similar. It would seem that the reliability and privacy are not so, anymore.

FWIW – They have not provided a coherent reply to my ticket. Should I get a relevant update, I’ll forward to the list.

9

Frontier and Verizon have been doing it for years. They have simply thumbed their noses at NXDOMAIN. All in the name of capturing data and eyeballs By Any Means Necessary.

-mel

10

As far as I know, this has been going on for quite some time at least for folks not on Level3. I know I've seen it as far back as 5-7 years ago from various vantage points.

I guess it's also possible somebody was intercepting those well known anycast addresses between me and Level3, but the "search guide" it redirected to didn't implicate any obvious suspects.

It fails DNSSEC checking, of course, so if you have DNSSEC validation turned on at your recursive resolver, you should get something else (probably SERVFAIL).

11

Frontier and Verizon have been doing it for years. They have simply thumbed their noses at NXDOMAIN. All in the name of capturing data and eyeballs By Any Means Necessary.

Verizon USED to do this on the former UUnet customer cache resolvers
(notably: 198.6.1.1 and it's ilk) ... but:

$ dig @198.6.1.1 dad.ads123j.com
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 2315
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;dad.ads123j.com. IN A

;; AUTHORITY SECTION:
com. 899 IN SOA a.gtld-servers.net. nstld.verisign-grs.com. 1574180221
1800 900 604800 86400

my understanding was that this was discontinued eventually when the 'product':
  1) made no appreciable money for the cost of operation
  2) paxfire died in a fiew
  3) the ProjectManager responsible inside VZB got canned...

I didn't think they brought this back to life... I hope they did not :frowning:
Maybe you meant the VZ dsl/fios customer cache devices were/are doing this?
oh :frowning:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43555
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;dad.ads123j.com. IN A

;; ANSWER SECTION:
dad.ads123j.com. 0 IN A 92.242.140.21

;; Query time: 22 msec
;; SERVER: 71.250.0.12#53(71.250.0.12)

that's unfortunate for all of VZ's landline/dsl/fios folks :frowning: bummer.

12

This is was my thought as well. People always get up in arms about how it’s “Public DNS!” but it’s really not. It’s just well known and used because it’s easy to remember.

13

I ask the users of 4.2.2.x where it is stated by the owners of 4.2.2.x that the public may use it, and what expectations they state the public should have of its availability, integrity, and security.

Not having a contract with Level3, I would assume no such expectations, and discourage anyone from using 4.2.2.x, Even L3 customers unless they were specifically given it to use by L3.

The other ‘public DNS providers’ outwardly encourage their use by the public. 4.2.2.x does not.

14

On Tuesday, November 19, 2019 12:49 PM, Mike Bolitho mikebolitho@gmail.com said…

“This is was my thought as well. People always get up in arms about how it’s “Public DNS!” but it’s really not. It’s just well known and used because it’s easy to remember”

I am not against their “securing” their hosts. It costs them money to provide the service. I disagree with what they did - Disable the service or only allow local or on-net resolution. How many of (my) clients have miss-typed something and sent their data, unknowingly, to a 3rd party host? (Who’s fault would that be?)

That said I AM a L(3) customer. These IPs were provided when the circuit was provisioned for NS resolution. Admittedly, they has indicated, this morning, that we are using the “wrong” Anycast NS and provided a different set; which functioned the same as the “Public” ones.

15

How many of (my) clients have miss-typed something and sent their data, unknowingly, to a 3rd party host? (Who’s fault would that be?)

Yours? They paid you to set up their network properly and you set it up to resolve to Level 3. So if they “unknowingly sent their data” to a third party then it would be your fault.

16

On Tuesday, November 19, 2019 1:35 PM, Mike Bolitho mikebolitho@gmail.com said…

“How many of (my) clients have miss-typed something and sent their data, unknowingly, to a 3rd party host? (Who’s fault would that be?)

Yours? They paid you to set up their network properly and you set it up to resolve to Level 3. So if they “unknowingly sent their data” to a third party then it would be your fault.”

If I was retained by my clients to setup, design, configure, and/or maintain, our client’s networks. I would completely agree with you.
(FWIW, my internal network would not connect to these host even if one of my user’s fat-fingered the URL.)

However, I’m referring to a completely autonomous 3rd party network (Say they type wwww.omb.gov) Can I be expected to anticipate their user’s/APP DEV’s typos?

Lawrence Q. Marshall