Charter DNS servers returning invalid IP addresses

Mailman List Mirror (Read Only)
1

I’ve been working for a week or so to solve a problem with DNS resolution for Charter customers for our domain bonesinjars.com. I’ve reached-out to Charter directly but since I’m not a customer I couldn’t get any help from them. I was directed by a friend to this list in hopes that there may be able to reach a Charter/Spectrum engineer who might be able to explain and/or resolve this one.

A dig against Google’s DNS servers correctly returns 4 A records:

dig bonesinjars.com 8.8.8.8

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com 8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31383
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com. IN A

;; ANSWER SECTION:
bonesinjars.com. 60 IN A 198.49.23.145
bonesinjars.com. 60 IN A 198.185.159.145
bonesinjars.com. 60 IN A 198.49.23.144
bonesinjars.com. 60 IN A 198.185.159.144

;; Query time: 1039 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE rcvd: 108

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 26879
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;8.8.8.8. IN A

;; Query time: 35 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Oct 23 10:26:32 CDT 2023
;; MSG SIZE rcvd: 36

Verizon, AT&T, Comcast and all other DNS servers we tested return the same 4 A records. However the same dig against a Charter DNS (24.196.64.53) returns only 127.0.0.54:

dig bonesinjars.com 24.196.64.53

; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com 24.196.64.53
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;bonesinjars.com. IN A

;; ANSWER SECTION:
bonesinjars.com. 60 IN A 127.0.0.54

;; Query time: 55 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE rcvd: 60

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

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;24.196.64.53. IN A

;; ANSWER SECTION:
24.196.64.53. 86400 IN A 24.196.64.53

;; Query time: 27 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Tue Oct 24 13:28:36 CDT 2023
;; MSG SIZE rcvd: 57

Any help understanding and addressing this is greatly appreciated!

Jason

2

It’s being filtered. Only Charter can tell you why.

3

If it helps troubleshooting, when I click the domain in the email Mimecast tells me:

“We checked the website you are trying to access for malicious and spear-phishing content and found it likely to be unsafe.”

4

That does help Greg.

I’ve heard from a few other folks on the list that the domain is considered suspicious by a few different providers like this. It’s a turnkey Squarespace gallery/ecommerce site so I’m not sure why it would be classified as a threat, but perhaps a previous domain holder was doing something that could have been and these reports are just outdated?

  • Jason
5

I saw nothing referencing Mimecast in the original email. Where did you see this?

bonesinjars.com is not signed with DNSSEC. This is trivial to setup and might prevent some of this.

Probably not a good idea for your customers to rely on $BIGCABLE DNS servers.

6

VirusTotal and other domain reputation sites say the domain is malicious. Specifically there have been multiple malware samples that were scanned (latest was 10-09-2023) that had this domain hard coded in it.

You may want to get a new domain. Other option is to contact Akamai and see if they can whitelist this domain. Charter uses threat intel from Akamai to block certain "malicious" domains.

-Rich

CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance.

7

Dear NANOG-er,

Hope this email finds you in good health!

Please see my comments below, inline…

Thanks,

…this is unexpected! given what you said. …it’s not what you wanted to test! dig understood it otherwise. …associating the @ sign with the above IPv4 address would have corrected the behavior of dig: @24.196.64.53

8

He didn’t, I was just referencing Mimecast to indicate it was probably larger than Charter’s DNS. Given the reports that someone else gave from Virustotal, it seems it’s more widespread than first reported.

9

Does charter do this on signed domains too?

10

Is there a link where this can be looked up? I've not seen anything on
their website <https://www.mimecast.com>.

If you're going to quote me, please don't alter what I wrote, and please
trim the relevant parts of it.

Thanks,
- --
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

11

"Jason J. Gullickson via NANOG" <nanog@nanog.org> writes:

I've been working for a week or so to solve a problem with DNS
resolution for Charter customers for our domain bonesinjars.com. I've
reached-out to Charter directly but since I'm not a customer I
couldn't get any help from them. I was directed by a friend to this
list in hopes that there may be able to reach a Charter/Spectrum
engineer who might be able to explain and/or resolve this one.

A dig against Google's DNS servers correctly returns 4 A records:

dig bonesinjars.com 8.8.8.8

Guess you wanted

  dig bonesinjars.com @8.8.8.8

?

;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)

This is not 8.8.8.8

dig bonesinjars.com 24.196.64.53

still missing @

;; SERVER: 127.0.0.53#53(127.0.0.53)

This is not 24.196.64.53

Bjørn

12

Maybe the site “has/had” a shopping cart infection at one point that has been found and eradicated at one point ?

13

It appears that J. Hellenthal via NANOG <jhellenthal@dataix.net> said:

-=-=-=-=-=-

Maybe the site "has/had" a shopping cart infection at one point that has been found and eradicated at one point ?

Virustotal reported it four days ago, which suggests that whatever was
wrong with it is still wrong with it,

The usual (correct) response to "whitelist us because your malware
report is wrong" is "no, because it's not."

R's,
John

14

According to Bryan Fields <Bryan@bryanfields.net>:

15

I'd argue that as a service provider deliberately messing with DNS is an obvious bad thing. They're there to deliver packets.

16

It appears that Bryan Fields <Bryan@bryanfields.net> said:

-=-=-=-=-=-
-=-=-=-=-=-

But for obvious good reasons,
the vast majority of their customers don't

I'd argue that as a service provider deliberately messing with DNS is an
obvious bad thing. They're there to deliver packets.

For a network feeding a data center, sure. For a network like
Charter's which is feeding unsophisticated nontechnical users, they
need all the messing they can get.

If you're one of the small minority of retail users that knows enough
about the technology to pick your own resolver, go ahead. But it's
a reasonable default to keep malware out of Grandma's iPad.

R's,
John

17

If it’s such a reasonable default, why don’t any of the public resolvers (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?

DNS isn’t the right place to attack this, IMHO.

Owen

18

How does this line up with DoH? Aren't they using hardwired resolver addresses? I would hope they are not doing anything heroic.

Mike

19

When you have a sufficiently large mass of non-technical end users, inevitably some percentage of them will end up doing something like enabling WAN-interface-facing remote admin access,which then gets pwned and turned into a botnet. It’s a real problem at scale. Compromised CPE routers in addition to people visiting virus/trojan laden webservers and infecting their endpoint devices.

good example:

https://www.fortinet.com/blog/threat-research/condi-ddos-botnet-spreads-via-tp-links-cve-2023-1389

20

* Owen DeLong [Sat 28 Oct 2023, 01:00 CEST]:

If it’s such a reasonable default, why don’t any of the public resolvers (e.g. 1.1.1.1, 8.8.8.8, 9.9.9.9, etc.) do so?

It's generally a service that's offered for money. Quad9 definitely offer it: https://www.quad9.net/service/threat-blocking

DNS isn’t the right place to attack this, IMHO.

Why not (apart from a purity argument), and where should it happen instead? As others pointed out, network operators have a vested interest in protecting their customers from becoming victims to malware.

  -- Niels.