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 On 2023-10-25 1:41 pm, Greg Dickinson wrote:

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."

Greg Dickinson, CCNA

Network Engineer

From: NANOG <nanog-bounces+greg.dickinson=bryantbank.com@nanog.org> On Behalf Of Mark Andrews Sent: Wednesday, October 25, 2023 1:27 PM To: Jason J. Gullickson <mr@jasongullickson.com> Cc: nanog@nanog.org Subject: Re: Charter DNS servers returning invalid IP addresses

This Message originates from outside Bryant Bank. Please use caution when opening this correspondence, attachments or hyperlinks (URLs). If you have questions, please contact IT Support. Thank you.

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

--

Mark Andrews

...

On 26 Oct 2023, at 05:07, Jason J. Gullickson via NANOG <nanog@nanog.org> wrote:

...

I've been working for a week or so to solve a problem with DNS resolution for Charter customers for our domain bonesinjars.com [1]. 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 [1] 8.8.8.8 [2]

; <<>> DiG 9.18.12-0ubuntu0.22.04.3-Ubuntu <<>> bonesinjars.com [1] 8.8.8.8 [2] ;; 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 [1]. IN A

;; ANSWER SECTION: bonesinjars.com [1]. 60 IN A 198.49.23.145 [3] bonesinjars.com [1]. 60 IN A 198.185.159.145 [4] bonesinjars.com [1]. 60 IN A 198.49.23.144 [5] bonesinjars.com [1]. 60 IN A 198.185.159.144 [6]

;; Query time: 1039 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) [7] (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 [2]. IN A

;; Query time: 35 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) [7] (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 [8]) returns only 127.0.0.54 [9]

dig bonesinjars.com [1] 24.196.64.53 [8]

; <<>> DiG 9.16.1-Ubuntu <<>> bonesinjars.com [1] 24.196.64.53 [8] ;; 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 [1]. IN A

;; ANSWER SECTION: bonesinjars.com [1]. 60 IN A 127.0.0.54 [9]

;; Query time: 55 msec ;; SERVER: 127.0.0.53#53(127.0.0.53) [7] ;; 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 [8]. IN A

;; ANSWER SECTION: 24.196.64.53 [8]. 86400 IN A 24.196.64.53 [8]

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

Any help understanding and addressing this is greatly appreciated!

Jason

NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, print, save, copy, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete copies. Thank you.

Links: ------ [1] https://secure-web.cisco.com/1QYzTVngb5oZ1KLAZyMPvb_h9plEnlxSg987WNlsBgaLug2... [2] https://secure-web.cisco.com/1imxdVmCYKyqq5wulvqemEVFHic8KD5Xk1Q4EqDP-l4FLBV... [3] https://secure-web.cisco.com/1QeSRq_up-pqhHIDl6xF_GqRzLweZJXtuPVjonTJoPahw1Q... [4] https://secure-web.cisco.com/1O5fWfiQWb4UoojSFAKsG6sZg-r7ZoEBLPCb-nUjBFPD_px... [5] https://secure-web.cisco.com/1Gksy1SWwjLAq6x2FUfJ0MAAMBhgV-1-7Zc08k_Cg-Z8MCV... [6] https://secure-web.cisco.com/1Vr7XwiMhFeLf9cMeTNX15HD8WHYJL270KD2MioSlgRG1OZ... [7] https://secure-web.cisco.com/1oHf3Mm9qxwW_PH8S4pY1BmQR998AjECHdJ2k33Ke6Rw8Oc... [8] https://secure-web.cisco.com/1MWCKSLA6JNuYXb1c5Hf_dGEOanOe-z4Ba3wu58c8y7ovol... [9] https://secure-web.cisco.com/1fh0FafrN8nhI9wEWZaByw3sg2sf9Kz5Vk5p1BkCmxRU0aH...

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. https://www.virustotal.com/gui/domain/bonesinjars.com 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 On 10/25/23, 1:54 PM, "NANOG on behalf of Bryan Fields" <nanog-bounces+rich.compton=charter.com@nanog.org <mailto:charter.com@nanog.org> on behalf of Bryan@bryanfields.net <mailto:Bryan@bryanfields.net>> wrote: CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. On 10/25/23 2:41 PM, Greg Dickinson wrote:

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.”

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. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net <http://bryanfields.net> E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

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

On 10/25/23 4:58 PM, Compton, Rich A wrote:

...

Charter uses threat intel from Akamai to block certain "malicious" domains.

Does charter do this on signed domains too?

Of course. If you want to run your own DNSSEC resolver and bypass their malware protection, you are welcome to do so. But for obvious good reasons, the vast majority of their customers don't. R's, John

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

-=-=-=-=-=- -=-=-=-=-=- On 10/27/23 7:49 AM, John Levine wrote:

...

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

* 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.

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

...

I’ve seen plenty of situations where the filters were just plain wrong and if the end user didn’t actively choose that filtration, the target site may be victimized without anyone knowing where to go to complain.

Not much different from IP Geolocation. Probably not the right solution to many things, but people do it anyways., often causing problems that people don't know where to go to complain. On Fri, Oct 27, 2023 at 10:14 PM Owen DeLong via NANOG <nanog@nanog.org> wrote:

...

...

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.

Takedowns of the hostile target sites.

You dismiss the purity argument, but IMHO, there’s merit to the purity argument.

Any such DNS filtration, if provided, should be provided on an opt-in basis, not as a default.

I’ve seen plenty of situations where the filters were just plain wrong and if the end user didn’t actively choose that filtration, the target site may be victimized without anyone knowing where to go to complain.

Owen

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?

Oh my, you walked right into that one. https://www.quad9.net/service/threat-blocking/ https://blog.cloudflare.com/introducing-1-1-1-1-for-families/ I'm also surprised nobody seems familiar with Vixie's Response Policy Zones, a widely supported way to put DNS filtering rules into your own DNS cache. https://www.first.org/resources/papers/aa-dec2021/Protective-DNS-a-Boris-Sli... Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

On Oct 28, 2023, at 10:28, Jay R. Ashworth <jra@baylink.com> wrote:

----- Original Message -----

...

From: "Owen DeLong via NANOG" <nanog@nanog.org>

...

...

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

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 a reasonable default behavior *for default resolver servers for consumer eyeball networks*.

I knew that was what John meant, and I can't see any reason why you wouldn't know it too, Owen; this isn't your first rodeo, either.

I knew that’s what he meant and I know what you mean. I still don’t agree. Owen

On Mon, 30 Oct 2023, Livingood, Jason wrote:

On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote:

...

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.

Are we sure that the filtering is done in the default view - I would suggest the user check to ensure they don't have a filtering service (e.g. parental controls/malware protection) turned on. In my **personal** opinion, the default view should have DNSSEC validation & no filtering; users can always optionally select additional protection services that might include DNS-based filtering as well as other mechanisms.

At Quad9 they are clear that 9.9.9.9 is filtered. Cloudflare 1.1.1.1 is unfiltered, 1.1.1.2 filters malware, 1.1.1.3 malware and stuff unsuitable for children. I have no idea whether Charter uses one of these, some other third party, or their own. We must know someone there who could tell us. Regards, John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly

No, Charter doesn't use those. Charter runs its own anycasted recursive nameservers. On 10/30/23, 2:46 PM, "NANOG on behalf of Livingood, Jason via NANOG" <nanog-bounces+rich.compton=charter.com@nanog.org <mailto:charter.com@nanog.org> on behalf of nanog@nanog.org <mailto:nanog@nanog.org>> wrote: CAUTION: The e-mail below is from an external source. Please exercise caution before opening attachments, clicking links, or following guidance. On 10/30/23, 16:02, "John R. Levine" <johnl@iecc.com <mailto:johnl@iecc.com> <mailto:johnl@iecc.com <mailto:johnl@iecc.com>>> wrote:

I have no idea whether Charter uses one of these, some other third party, or their own.

They don't use those providers as far as I am aware. I've alerted someone from CHTR of this thread. JL E-MAIL CONFIDENTIALITY NOTICE: The contents of this e-mail message and any attachments are intended solely for the addressee(s) and may contain confidential and/or legally privileged information. If you are not the intended recipient of this message or if this message has been addressed to you in error, please immediately alert the sender by reply e-mail and then delete this message and any attachments. If you are not the intended recipient, you are notified that any use, dissemination, distribution, copying, or storage of this message or any attachment is strictly prohibited.

Agreed, it should be 100% opt-in… and I don’t even like the idea of providing filtered DNS at all. But sadly, judging by the number of neighborhood Facebook group posts I see from people complaining about “their wifi being down” during yet another fiber cut, there are an increasingly large number of end users that expect their ISPs to provide a 100% idiot-proof solution. Security filtering is part of that solution, along with all of the ’set and forget’ mesh wifi systems that clog up spectrum worse than an overdriven CB radio. Certainly not bulletproof, but as the movie “Idiocracy” turns more and more into a documentary, I think solutions like this will become more commonplace. As long as clueful users can disable it without trouble, I’m perfectly fine with it.

On Oct 30, 2023, at 6:00 PM, Owen DeLong via NANOG <nanog@nanog.org> wrote:

...

On Oct 30, 2023, at 07:58, Livingood, Jason <jason_livingood@comcast.com> wrote:

On 10/27/23, 19:01, "NANOG on behalf of Owen DeLong wrote:

...

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.

Are we sure that the filtering is done in the default view - I would suggest the user check to ensure they don't have a filtering service (e.g. parental controls/malware protection) turned on. In my **personal** opinion, the default view should have DNSSEC validation & no filtering; users can always optionally select additional protection services that might include DNS-based filtering as well as other mechanisms.

JL

Looks like 9.9.9.9 is filtered but ONLY for actual verified security threats, not spam, etc. If you want unfiltered, they offer 9.9.9.10.

Cloudflare offers two different filtered services, but 1.1.1.1 remains unfiltered.

1.1.1.2 is “No Malware” 1.1.1.3 is “No Malware or Adult Content”

So yes, apparently one (and only one) public resolver now filters by default.

I stand by my statement… It should be an opt-in choice, not a default.

Owen

It appears that Michael Thomas <mike@mtcc.com> said:

...

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.

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

Generally, no. I believe that Chrome probes whatever resolver is configured into the system and uses that if it does DoH or DoT. At one point Firefox was going to send everything to their favorite DoH resolver but they got a great deal of pushback from people who pointed out that they had policies on their networks and they'd have to ban Firefox. Firefox responded with a lame hack where you can tell your cache to respond to some name and if so Firefox will use your resolver. R's, John

On Nov 1, 2023, at 13:28, Michael Thomas <mike@mtcc.com> wrote:

On 10/28/23 3:13 AM, John Levine wrote:

...

It appears that Michael Thomas <mike@mtcc.com> said:

...

...

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. How does this line up with DoH? Aren't they using hardwired resolver addresses? I would hope they are not doing anything heroic. Generally, no. I believe that Chrome probes whatever resolver is configured into the system and uses that if it does DoH or DoT.

At one point Firefox was going to send everything to their favorite DoH resolver but they got a great deal of pushback from people who pointed out that they had policies on their networks and they'd have to ban Firefox. Firefox responded with a lame hack where you can tell your cache to respond to some name and if so Firefox will use your resolver.

That's probably what I'm remembering with Firefox. But doesn't probing the local resolver sort of defeat the point of DoH? That is, I really don't want my ISP to be able to snoop on my DNS history. Sending it off to one of the well known resolvers at least gives me a chance to know whether they are evil or not because there aren't very many of them vs every random ISP out there. Since nobody but people like us know about those resolvers it seems to me that without preconfiguration meaningful DoH is pretty limited?

The point of DoH is to move the ability to monetize your DNS history away from the public resolver world and into the hands of the content providers and other DoH providers. I’m not sure I see that as an improvement, but I guess it depends on who you want to donate to. Personally, I run my own resolvers and that doesn’t leak any data that wouldn’t have to be leaked anyway (after all, the DoH resolvers have to query the upstream authoritative servers on my behalf anyway, and with EDNS0, they’re likely passing along enough to deanonymize those queries, at least in my case. YMMV Owen

I'd agree and disagree, filtering the default isp provided dns server for consumer and possibly small business, reasonable, not without some issues, but reasonable. Comcast style filter servers and intercept all dns headed to other dns servers and redirect them to your own servers and make it difficult to disable, unreasonable, if people deliberately choose to use different dns do NOT override that choice at an isp level (corporate/business firewalls are a bit of a different story), offering security filtered dns as a default isp provided server is a value add for many non technical users, filtering beyond security or making it difficult to use other dns servers is a detriment to users. my view on small business's with static addresses are a little more complex, they are more likely to be doing things the filtering might break, but many of those things also are best done while running your own recursive resolver, so it may not actually matter that much, but definitely don't do a forced dns server via redirection of all dns queries for such users, honestly don't ever do that as an ISP without specific direct opt in, not opt in by not fighting with sales to remove a line from an order, or other "opt-in" that isn't actually customer initiated informed opt-in, I'm looking at you Comcast. On 10/27/2023 5:20 PM, John Levine wrote:

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

...

-=-=-=-=-=- -=-=-=-=-=- On 10/27/23 7:49 AM, John Levine wrote:

...

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

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. Greg Dickinson, CCNA Network Engineer [mid:ac0798f5d04aec2c4c40f9c44056646c8ba72bfb332f7f64d451d99665886e29@getboxer.com/image001.png@01D2DDE3.06E76B70] From: NANOG <nanog-bounces+greg.dickinson=bryantbank.com@nanog.org> On Behalf Of Bryan Fields Sent: Wednesday, October 25, 2023 2:51 PM To: nanog@nanog.org Subject: Re: Charter DNS servers returning invalid IP addresses This Message originates from outside Bryant Bank. Please use caution when opening this correspondence, attachments or hyperlinks (URLs). If you have questions, please contact IT Support. Thank you. On 10/25/23 2:41 PM, Greg Dickinson wrote:

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.”

I saw nothing referencing Mimecast in the original email. Where did you see this? bonesinjars.com<https://secure-web.cisco.com/1QQZVslnfiRjBtYsKz_oXFZ_6WtTz9sVZ_f0uvfIVeQ2J1pIidIRXn6_jdq-yZOHUogW_K6VK7D0Z1XlMCU582_TcZAVhTdpiq9JxixxYbkJfGT49HwTOslxUlMJyF7N2kN6HGX2LhEGO9n3mr5OwxMrdseSfDjdEqt8CduYaiS4G2LDlbe8Dg2l0amB-7s_zlqczuasnjL0pQdK7KvyQKqUHW_aEjlr6tbm-Ot4IBuFYyVgFvyCt4ELqnUS74BeHrFwprUthd9Gs2KHJTNoJubcCC3u5rmijvsEmteQDOe-1FIdONODBxWbubyjpRccL/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2FFF75CB1GO7fVEN2TNemvK%3Fdomain%3Dbonesinjars.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. -- Bryan Fields 727-409-1194 - Voice http://bryanfields.net<https://secure-web.cisco.com/1IMgbVJ8gycWN6tw-46nbbWjKIELzO75mx5XvOPS1W9lFcp-t5iPb6Z6pom_P03J9roVyNep9lT5w4tQ38iAYBobJI4sey3-XZisw2KcRArZXNJsOQZ0GEd0TR2wOdJLQqdU170lylzPwbJ6UWgjTvMlPaCE_u7WdxOX9gCG7M20OzhYTA0TRtif-nRWHyCQKT7sBiFlPcItRDX_CLbnsg4NIjnn-NlUpGkbnCUe2x_MG5y8ed6IODpcaiWvjb4-1NPVharBH-SfJW3KRxmxaOtf-uxLSK2fZH91teBZ6v6HkeoLdoyWaprqZAWMuY_dd/https%3A%2F%2Fprotect-usb.mimecast.com%2Fs%2F76FZCDwK67fBgZGHZQHy_%3Fdomain%3Dbryanfields.net> NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, print, save, copy, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete copies. Thank you.

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

On Oct 26, 2023, at 02:10, Bjørn Mork <bjorn@mork.no> wrote:

"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

-- J. Hellenthal "You think it's the living who will have ultimate judgement over you because the dead will have no claim over your soul. But you may be mistaken.*"

This is very interesting. I did some poking-around and found other Squarespace customers with similar issues (in their case it was Google complaining that their sites were suspicious and therefore couldn't serve Google ads). The leading theory is that the "canned" Squarespace sites are using an old version of some library or other piece of code that some software identifies as malware or otherwise dubious. If I can figure out exactly what these services are upset about maybe I can take that to Squarespace and get them to fix it, but I'm not sure how far I'll get with what I know so far. - Jason On 2023-10-27 6:44 am, John Levine wrote:

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