date:20240423

Re: [EXTERNAL] Re: Help with removing DNS shinkhole FP from Charter/Spectrum

2024-04-23 Thread Validin Axon

Thank you, Jim. Who is the vendor responsible?

Kenneth

On Tue, Apr 23, 2024 at 4:24 PM Rampley, Jim F 
wrote:

>
>
> Hi Kenneth,
>
>
>
> We have been working internally and with our third-party domain reputation
> source to get your domain removed from their malware list.
>
>
>
> Jim
>
>
>
> *From: *NANOG  on behalf
> of Validin Axon 
> *Date: *Tuesday, April 23, 2024 at 2:15 PM
> *To: *Tom Beecher 
> *Cc: *NANOG 
> *Subject: *[EXTERNAL] Re: Help with removing DNS shinkhole FP from
> Charter/Spectrum
>
>
>
> CAUTION: The e-mail below is from an external source. Please exercise
> caution before opening attachments, clicking links, or following guidance.
>
>
>
> Tom,
>
>
>
> Thank you for this! It is very interesting that the behavior is
> intermittent. A friend of mine who tested it this weekend saw correct
> answers on IPv6 and incorrect answers on IPv4.
>
>
>
> Kenneth
>
>
>
> On Tue, Apr 23, 2024 at 2:56 PM Tom Beecher  wrote:
>
> Validin, made an interesting observation on this. I am also a Spectrum
> residential customer,  none of their equipment, run my own DNS server
> (pihole).
>
>
>
> My DHCP Assigned DNS servers are
>
> 2001:1998:f00:1::1
> 2001:1998:f00:2::1
>
> bash-3.2$ dig -x 2001:1998:f00:1::1 +short
> dns-cac-lb-01.rr.com.
> bash-3.2$ dig -x 2001:1998:f00:2::1 +short
> dns-cac-lb-02.rr.com.
> bash-3.2$
>
>
> bash-3.2$ dig dns-cac-lb-01.rr.com +short
> 209.18.47.61
> bash-3.2$ dig dns-cac-lb-02.rr.com +short
> 209.18.47.62
> bash-3.2$
>
> bash-3.2$ dig @209.18.47.61 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$ dig @209.18.47.62 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$
>
> bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
> 127.0.0.54
> bash-3.2$
>
> bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
> 127.0.0.54
> bash-3.2$
>
> Same servers on V4 were returning correct info, but on V6 were not.
>
> However, a few minutes later :
>
> bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$
>
> Deltas :
>
> bash-3.2$ dig @2001:1998:f00:1::1  validin.com
>
> ; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42329
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;validin.com.   IN  A
>
> ;; ANSWER SECTION:
> validin.com.60  IN  A   127.0.0.54
>
> ;; Query time: 37 msec
> ;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
> ;; WHEN: Tue Apr 23 13:50:03 EDT 2024
> ;; MSG SIZE  rcvd: 45
>
> bash-3.2$
>
> bash-3.2$ dig @2001:1998:f00:1::1 validin.com
>
> ; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9667
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;validin.com.   IN  A
>
> ;; ANSWER SECTION:
> validin.com.600 IN  A   157.245.112.183
> validin.com.600 IN  A   137.184.54.107
>
> ;; Query time: 157 msec
> ;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
> ;; WHEN: Tue Apr 23 14:19:20 EDT 2024
> ;; MSG SIZE  rcvd: 72
>
> bash-3.2$
>
>
>
> Seems like quite possibly they are intermittently caching bunk data from
> something.
>
>
>
>
>
> On Tue, Apr 23, 2024 at 1:39 PM Validin Axon  wrote:
>
> Hi Jason,
>
>
>
> > I suspect what’s happened is an incorrect assumption that DNS is even
> the issue here. Because you mentioned Spectrum Shield, I suspect it is not.
>
>
>
> I appreciate the response and links. However, I've been told repeatedly by
> Spectrum that they're not blocking with Spectrum Shield. Despite these
> assurances, I've filled out a removal request through their published
> removal process several times, and the response I received stated that
> we're not being blocked. This check agrees with that:
>
> https://www.spectrum.net/support/forms/verify_url_security
>
>
>
> "Security Shield Is Not Blocking This Site
>
> The URL provided is not being blocked by Spectrum Security Shield
> The URL you entered should be accessible."
>
> Further, checking Spectrum DNS servers on the Spectrum network show that
> my company's main domain and all subdomains resolve to 127.0.0.54. So, if
> CujoAI/Spectrum Shield are not using DNS query responses to control access,
> then it's not CujoAI/Spectrum Shield that is responsible for the incorrect
> DNS response. Using a different recursive resolve, I can resolve our
> domains just fine. I can also resolve other domains that point to the same
> IPs as the sinkholed domain just fine. However, many people use the
> Spectrum default DNS servers and cannot access my

Re: [EXTERNAL] Re: Help with removing DNS shinkhole FP from Charter/Spectrum

2024-04-23 Thread Rampley, Jim F

Hi Kenneth,

We have been working internally and with our third-party domain reputation 
source to get your domain removed from their malware list.

Jim

From: NANOG  on behalf of 
Validin Axon 
Date: Tuesday, April 23, 2024 at 2:15 PM
To: Tom Beecher 
Cc: NANOG 
Subject: [EXTERNAL] Re: Help with removing DNS shinkhole FP from 
Charter/Spectrum

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

Tom,

Thank you for this! It is very interesting that the behavior is intermittent. A 
friend of mine who tested it this weekend saw correct answers on IPv6 and 
incorrect answers on IPv4.

Kenneth

On Tue, Apr 23, 2024 at 2:56 PM Tom Beecher 
mailto:beec...@beecher.cc>> wrote:
Validin, made an interesting observation on this. I am also a Spectrum 
residential customer,  none of their equipment, run my own DNS server (pihole).

My DHCP Assigned DNS servers are

2001:1998:f00:1::1
2001:1998:f00:2::1

bash-3.2$ dig -x 2001:1998:f00:1::1 +short
dns-cac-lb-01.rr.com.
bash-3.2$ dig -x 2001:1998:f00:2::1 +short
dns-cac-lb-02.rr.com.
bash-3.2$

bash-3.2$ dig dns-cac-lb-01.rr.com +short
209.18.47.61
bash-3.2$ dig dns-cac-lb-02.rr.com +short
209.18.47.62
bash-3.2$

bash-3.2$ dig @209.18.47.61 
validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$ dig @209.18.47.62 
validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$

bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
127.0.0.54
bash-3.2$

bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
127.0.0.54
bash-3.2$

Same servers on V4 were returning correct info, but on V6 were not.

However, a few minutes later :

bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$

Deltas :

bash-3.2$ dig @2001:1998:f00:1::1  validin.com

; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;validin.com.   IN  A

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

;; Query time: 37 msec
;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
;; WHEN: Tue Apr 23 13:50:03 EDT 2024
;; MSG SIZE  rcvd: 45

bash-3.2$

bash-3.2$ dig @2001:1998:f00:1::1 validin.com

; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9667
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
validin.com.600 IN  A   
157.245.112.183
validin.com.600 IN  A   
137.184.54.107

;; Query time: 157 msec
;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
;; WHEN: Tue Apr 23 14:19:20 EDT 2024
;; MSG SIZE  rcvd: 72

bash-3.2$

Seems like quite possibly they are intermittently caching bunk data from 
something.

On Tue, Apr 23, 2024 at 1:39 PM Validin Axon 
mailto:a...@validin.com>> wrote:
Hi Jason,

> I suspect what’s happened is an incorrect assumption that DNS is even the 
> issue here. Because you mentioned Spectrum Shield, I suspect it is not.

I appreciate the response and links. However, I've been told repeatedly by 
Spectrum that they're not blocking with Spectrum Shield. Despite these 
assurances, I've filled out a removal request through their published removal 
process several times, and the response I received stated that we're not being 
blocked. This check agrees with that:
https://www.spectrum.net/support/forms/verify_url_security

"Security Shield Is Not Blocking This Site
The URL provided is not being blocked by Spectrum Security Shield
The URL you entered should be accessible."
Further, checking Spectrum DNS servers on the Spectrum network show that my 
company's main domain and all subdomains resolve to 127.0.0.54. So, if 
CujoAI/Spectrum Shield are not using DNS query responses to control access, 
then it's not CujoAI/Spectrum Shield that is responsible for the incorrect DNS 
response. Using a different recursive resolve, I can resolve our domains just 
fine. I can also resolve other domains that point to the same IPs as the 
sinkholed domain just fine.

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

2024-04-23 Thread Validin Axon

Tom,

Thank you for this! It is very interesting that the behavior is
intermittent. A friend of mine who tested it this weekend saw correct
answers on IPv6 and incorrect answers on IPv4.

Kenneth

On Tue, Apr 23, 2024 at 2:56 PM Tom Beecher  wrote:

> Validin, made an interesting observation on this. I am also a Spectrum
> residential customer,  none of their equipment, run my own DNS server
> (pihole).
>
> My DHCP Assigned DNS servers are
>
> 2001:1998:f00:1::1
> 2001:1998:f00:2::1
>
> bash-3.2$ dig -x 2001:1998:f00:1::1 +short
> dns-cac-lb-01.rr.com.
> bash-3.2$ dig -x 2001:1998:f00:2::1 +short
> dns-cac-lb-02.rr.com.
> bash-3.2$
>
>
> bash-3.2$ dig dns-cac-lb-01.rr.com +short
> 209.18.47.61
> bash-3.2$ dig dns-cac-lb-02.rr.com +short
> 209.18.47.62
> bash-3.2$
>
> bash-3.2$ dig @209.18.47.61 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$ dig @209.18.47.62 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$
>
> bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
> 127.0.0.54
> bash-3.2$
>
> bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
> 127.0.0.54
> bash-3.2$
>
> Same servers on V4 were returning correct info, but on V6 were not.
>
> However, a few minutes later :
>
> bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
> 157.245.112.183
> 137.184.54.107
> bash-3.2$
>
> Deltas :
>
> bash-3.2$ dig @2001:1998:f00:1::1  validin.com
>
> ; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42329
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;validin.com.   IN  A
>
> ;; ANSWER SECTION:
> validin.com.60  IN  A   127.0.0.54
>
> ;; Query time: 37 msec
> ;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
> ;; WHEN: Tue Apr 23 13:50:03 EDT 2024
> ;; MSG SIZE  rcvd: 45
>
> bash-3.2$
>
> bash-3.2$ dig @2001:1998:f00:1::1 validin.com
>
> ; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9667
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;validin.com.   IN  A
>
> ;; ANSWER SECTION:
> validin.com.600 IN  A   157.245.112.183
> validin.com.600 IN  A   137.184.54.107
>
> ;; Query time: 157 msec
> ;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
> ;; WHEN: Tue Apr 23 14:19:20 EDT 2024
> ;; MSG SIZE  rcvd: 72
>
> bash-3.2$
>
> Seems like quite possibly they are intermittently caching bunk data from
> something.
>
>
> On Tue, Apr 23, 2024 at 1:39 PM Validin Axon  wrote:
>
>> Hi Jason,
>>
>> > I suspect what’s happened is an incorrect assumption that DNS is even
>> the issue here. Because you mentioned Spectrum Shield, I suspect it is not.
>>
>> I appreciate the response and links. However, I've been told repeatedly
>> by Spectrum that they're not blocking with Spectrum Shield. Despite these
>> assurances, I've filled out a removal request through their published
>> removal process several times, and the response I received stated that
>> we're not being blocked. This check agrees with that:
>> https://www.spectrum.net/support/forms/verify_url_security
>>
>> "Security Shield Is Not Blocking This Site
>> The URL provided is not being blocked by Spectrum Security Shield
>> The URL you entered should be accessible."
>>
>> Further, checking Spectrum DNS servers on the Spectrum network show that
>> my company's main domain and all subdomains resolve to 127.0.0.54. So, if
>> CujoAI/Spectrum Shield are not using DNS query responses to control access,
>> then it's not CujoAI/Spectrum Shield that is responsible for the incorrect
>> DNS response. Using a different recursive resolve, I can resolve our
>> domains just fine. I can also resolve other domains that point to the same
>> IPs as the sinkholed domain just fine. However, many people use the
>> Spectrum default DNS servers and cannot access my website because of this.
>>
>> > You should contact Charter/Spectrum to have them investigate what their
>> system might be blocking this content.
>>
>> I have tried, for months, including spending many hours on chat and phone
>> support, to reach someone within Spectrum support who is capable of both
>> understanding and directing me to someone who can fix the problem, but it
>> hasn't happened yet. I've asked to talk to someone on the DNS team and was
>> given a flat "No." I've posted here hoping that someone in the
>> ISP-connected world knows SOMEONE at Spectrum, Akamai, or whichever company
>> is actually responsible for the Spectrum DNS servers who can provide a
>> remediation path.
>>
>>

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

2024-04-23 Thread Tom Beecher

Validin, made an interesting observation on this. I am also a Spectrum
residential customer,  none of their equipment, run my own DNS server
(pihole).

My DHCP Assigned DNS servers are

2001:1998:f00:1::1
2001:1998:f00:2::1

bash-3.2$ dig -x 2001:1998:f00:1::1 +short
dns-cac-lb-01.rr.com.
bash-3.2$ dig -x 2001:1998:f00:2::1 +short
dns-cac-lb-02.rr.com.
bash-3.2$


bash-3.2$ dig dns-cac-lb-01.rr.com +short
209.18.47.61
bash-3.2$ dig dns-cac-lb-02.rr.com +short
209.18.47.62
bash-3.2$

bash-3.2$ dig @209.18.47.61 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$ dig @209.18.47.62 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$

bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
127.0.0.54
bash-3.2$

bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
127.0.0.54
bash-3.2$

Same servers on V4 were returning correct info, but on V6 were not.

However, a few minutes later :

bash-3.2$ dig @2001:1998:f00:1::1 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$ dig @2001:1998:f00:2::1 validin.com +short
157.245.112.183
137.184.54.107
bash-3.2$

Deltas :

bash-3.2$ dig @2001:1998:f00:1::1  validin.com

; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42329
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;validin.com.   IN  A

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

;; Query time: 37 msec
;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
;; WHEN: Tue Apr 23 13:50:03 EDT 2024
;; MSG SIZE  rcvd: 45

bash-3.2$

bash-3.2$ dig @2001:1998:f00:1::1 validin.com

; <<>> DiG 9.10.6 <<>> @2001:1998:f00:1::1 validin.com
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 9667
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

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

;; ANSWER SECTION:
validin.com.600 IN  A   157.245.112.183
validin.com.600 IN  A   137.184.54.107

;; Query time: 157 msec
;; SERVER: 2001:1998:f00:1::1#53(2001:1998:f00:1::1)
;; WHEN: Tue Apr 23 14:19:20 EDT 2024
;; MSG SIZE  rcvd: 72

bash-3.2$

Seems like quite possibly they are intermittently caching bunk data from
something.


On Tue, Apr 23, 2024 at 1:39 PM Validin Axon  wrote:

> Hi Jason,
>
> > I suspect what’s happened is an incorrect assumption that DNS is even
> the issue here. Because you mentioned Spectrum Shield, I suspect it is not.
>
> I appreciate the response and links. However, I've been told repeatedly by
> Spectrum that they're not blocking with Spectrum Shield. Despite these
> assurances, I've filled out a removal request through their published
> removal process several times, and the response I received stated that
> we're not being blocked. This check agrees with that:
> https://www.spectrum.net/support/forms/verify_url_security
>
> "Security Shield Is Not Blocking This Site
> The URL provided is not being blocked by Spectrum Security Shield
> The URL you entered should be accessible."
>
> Further, checking Spectrum DNS servers on the Spectrum network show that
> my company's main domain and all subdomains resolve to 127.0.0.54. So, if
> CujoAI/Spectrum Shield are not using DNS query responses to control access,
> then it's not CujoAI/Spectrum Shield that is responsible for the incorrect
> DNS response. Using a different recursive resolve, I can resolve our
> domains just fine. I can also resolve other domains that point to the same
> IPs as the sinkholed domain just fine. However, many people use the
> Spectrum default DNS servers and cannot access my website because of this.
>
> > You should contact Charter/Spectrum to have them investigate what their
> system might be blocking this content.
>
> I have tried, for months, including spending many hours on chat and phone
> support, to reach someone within Spectrum support who is capable of both
> understanding and directing me to someone who can fix the problem, but it
> hasn't happened yet. I've asked to talk to someone on the DNS team and was
> given a flat "No." I've posted here hoping that someone in the
> ISP-connected world knows SOMEONE at Spectrum, Akamai, or whichever company
> is actually responsible for the Spectrum DNS servers who can provide a
> remediation path.
>
> Regards,
>
> Kenneth
>
> On Tue, Apr 23, 2024 at 12:59 PM 'Livingood, Jason' via axon <
> a...@validin.com> wrote:
>
>> > However, there's no correction process for Spectrum's DNS sinkhole
>>
>> > But back to the topic: someone mentioned to me that Spectrum may not be
>> the direct providers for the DNS services they provide to their customers.
>> If anyone knows anything about how I might discover and reach out to the
>> people responsible, please let me know.
>>

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

2024-04-23 Thread Validin Axon

Hi Jason,

> I suspect what’s happened is an incorrect assumption that DNS is even the
issue here. Because you mentioned Spectrum Shield, I suspect it is not.

I appreciate the response and links. However, I've been told repeatedly by
Spectrum that they're not blocking with Spectrum Shield. Despite these
assurances, I've filled out a removal request through their published
removal process several times, and the response I received stated that
we're not being blocked. This check agrees with that:
https://www.spectrum.net/support/forms/verify_url_security

"Security Shield Is Not Blocking This Site
The URL provided is not being blocked by Spectrum Security Shield
The URL you entered should be accessible."

Further, checking Spectrum DNS servers on the Spectrum network show that my
company's main domain and all subdomains resolve to 127.0.0.54. So, if
CujoAI/Spectrum Shield are not using DNS query responses to control access,
then it's not CujoAI/Spectrum Shield that is responsible for the incorrect
DNS response. Using a different recursive resolve, I can resolve our
domains just fine. I can also resolve other domains that point to the same
IPs as the sinkholed domain just fine. However, many people use the
Spectrum default DNS servers and cannot access my website because of this.

> You should contact Charter/Spectrum to have them investigate what their
system might be blocking this content.

I have tried, for months, including spending many hours on chat and phone
support, to reach someone within Spectrum support who is capable of both
understanding and directing me to someone who can fix the problem, but it
hasn't happened yet. I've asked to talk to someone on the DNS team and was
given a flat "No." I've posted here hoping that someone in the
ISP-connected world knows SOMEONE at Spectrum, Akamai, or whichever company
is actually responsible for the Spectrum DNS servers who can provide a
remediation path.

Regards,

Kenneth

On Tue, Apr 23, 2024 at 12:59 PM 'Livingood, Jason' via axon <
a...@validin.com> wrote:

> > However, there's no correction process for Spectrum's DNS sinkhole
>
> > But back to the topic: someone mentioned to me that Spectrum may not be
> the direct providers for the DNS services they provide to their customers.
> If anyone knows anything about how I might discover and reach out to the
> people responsible, please let me know.
>
>
>
> I suspect what’s happened is an incorrect assumption that DNS is even the
> issue here. Because you mentioned Spectrum Shield, I suspect it is not.
>
> Spectrum Shield (
> https://www.spectrum.com/resources/internet-wifi/benefits-of-spectrum-security-shield)
> is a customer-managed security protection service built into their gateways
> (I assume you can turn it off). The malware and content detection engine
> behind that is very likely run by CujoAI (https://cujo.com/) and it does
> not use DNS query/response exchanges as the control mechanism (in part to
> counter-act DNS-changing malware or malware using its own DoH channel for
> example).
>
> You should contact Charter/Spectrum to have them investigate what their
> system might be blocking this content.
>
> Comcast (where I work) runs a similar system (
> https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security)
> and maintains a site to report these sorts of issues (
> https://www.xfinity.com/support/articles/report-blocked-website).
>
> Jason
>
>
>
>
>
>
>
>
>

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

2024-04-23 Thread Livingood, Jason via NANOG

> However, there's no correction process for Spectrum's DNS sinkhole
> But back to the topic: someone mentioned to me that Spectrum may not be the 
> direct providers for the DNS services they provide to their customers. If 
> anyone knows anything about how I might discover and reach out to the people 
> responsible, please let me know.

I suspect what’s happened is an incorrect assumption that DNS is even the issue 
here. Because you mentioned Spectrum Shield, I suspect it is not.

Spectrum Shield 
(https://www.spectrum.com/resources/internet-wifi/benefits-of-spectrum-security-shield)
 is a customer-managed security protection service built into their gateways (I 
assume you can turn it off). The malware and content detection engine behind 
that is very likely run by CujoAI (https://cujo.com/) and it does not use DNS 
query/response exchanges as the control mechanism (in part to counter-act 
DNS-changing malware or malware using its own DoH channel for example).

You should contact Charter/Spectrum to have them investigate what their system 
might be blocking this content.

Comcast (where I work) runs a similar system 
(https://www.xfinity.com/support/articles/using-xfinity-xfi-advanced-security) 
and maintains a site to report these sorts of issues 
(https://www.xfinity.com/support/articles/report-blocked-website).

Jason

OARC 43 - Call for Contribution

2024-04-23 Thread John Todd



The DNS-OARC Programme Committee is seeking contributions from the community.

This workshop will be a hybrid event.

Date - likely in the week of 23-27 September 2024, details will be confirmed 
later
Location - South America, exact location will be confirmed later
Time zone - approximately 09:00-17:00 UTC -5 (TBC)
Partnered/co-located with - related industry events, will be confirmed later

Submission requirements
Topic must be related to DNS
10 or 20 minutes (there will be additional 5 min of Q following each talk)
Will be broadcast live and recorded for future reference
Presentation slides will be publicly available before, during and after meeting

Acceptance Criteria
Proposal should be at a high technical level suitable to the audience
Submissions should include draft slides or at least detailed description of the 
proposed talk content
PC might require improvements to slides before and after talk acceptance

How to submit
Submission deadline: 2024-06-23 23:59 UTC
You will need to create an account in the Indico system
A Step-by-Step guide to submitting in Indico can be found here: 


Suggested Topics
All DNS-related subjects and discussion topics are welcome!

Here’s a non-exhaustive list of ideas:

Operations: Any operational gotchas, lessons learned from an outage, 
details/reasons for a recent outage (how to improve time to recovery, tooling), 
interoperability concerns and experience.
Deployment: DNS config management and release process.
Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly detection.
Scaling: DNS performance management and metrics. Increasing DNS server 
efficiency
Security/Privacy: DNSSEC signing and validation, key storage, qname 
minimization, DoH/DoT/DoQ

Workshop Milestones
CFP submissions open in Indico: now
Deadline for Submissions: 2024-06-23 23:59 UTC
Preliminary list of contributions published: end of June 2024
Full agenda published: beginning of July 2024
Deadline for slides submission - no changes possible: 2024-09-12 23:59 UTC
Remote speaker rehearsal: will be confirmed later

Relevant Links
Registration page and details for presentation submission 

FAQ - Submitting a Proposal for the Workshop  
Contact information (who to contact for what) 

Guidelines for presentation slides 

Note: DNS-OARC provides registration fee waivers for the workshop to support 
those who are part of underrepresented groups to speak at and/or attend 
DNS-OARC. More details will be provided when registration opens.

If you have questions or concerns you can contact the Programme Committee:
https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

John Todd, for the DNS-OARC Programme Committee

For OARC 43 we are open to patronage and donations to fund the Workshop and 
associated events. Please contact spon...@dns-oarc.net if your organization is 
interested in becoming an OARC 43 patron.

(Please note that OARC is run on a non-profit basis, and is not in a position 
to reimburse expenses or time for speakers at its meetings.)

Re: [EXTERNAL] Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Re: [EXTERNAL] Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

Re: Help with removing DNS shinkhole FP from Charter/Spectrum

OARC 43 - Call for Contribution

7 matches

Site Navigation

Mail list logo

Footer information