Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Brown, William]

Sorry for going dark on this issue.  I appreciate the efforts everyone has put 
into this issue for me and the students in Western
New York.


  1.  172.64.80.1 was blocked by our firewall (I believed based on Fortinet 
malware intelligence).  It was also triggering in Google Chrome as a 
potentially malicious site as well.



Regardless, From Warren’s emails, it looks like this was still not a valid 
address to reach deltamath.com’s web page.



  1.  I am still getting the inconsistent result when querying one of the 
authoritative name servers:
[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
172.64.80.1
[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short

104.26.3.229
104.26.2.229
172.67.75.10

  1.  We have reached out to deltamath in conjunction with the school districts 
and deltamath has reached out to CF on this issue.


At this point, I will let deltamath and CF work this all out.

Again, thank you everyone that assisted with this issue.
--
William Brown
WNYRIC/Erie 1 BOCES
716-821-7285

SharePoint, Eforms, Email, Spam Filtering Please reach out to 
messag...@e1b.org<mailto:messag...@e1b.org>
Immediate Needs Call our Service Desk at 716-821-7171

From: Adam David 
Sent: Wednesday, September 22, 2021 7:17 PM
To: Brown, William 
Cc: Erik Stian Tefre ; dns-operations@lists.dns-oarc.net
Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers


 This email originated from outside of the organization. Use caution 
when replying, opening attachment(s), and/or clicking on URL's. 

This does not seem to be a DNS resolution/misconfiguration issue on 
Cloudflare's end.

https://172.64.80.1/ provides an error message (as it should) indicating it is 
a CloudFlare IP. If you can't see that in a web browser, then the issue is 
local to your network.

The main causes that I gather would be:

1. There was a temporary cache propagation issue on CF's network. (Still not a 
DNS issue.)
2. Your IT department is using 172.0.0.0/9<http://172.0.0.0/9> or possibly even 
172.0.0.0/8<http://172.0.0.0/8> where they intended to use 
172.16.0.0/12<http://172.16.0.0/12> (RFC1918 IP space). This would block access 
to the netblock belonging to Cloudflare and you would have difficulty accessing 
thousands of websites.
 Side Note: 172.64.0.0/13<http://172.64.0.0/13> 
belongs to AS13335.

You should always start with your IT department.
If you are a Cloudflare customer, contact them directly.
If you are a DeltaMath customer, then you need to contact them directly.

Sincerely,

Adam Vallee



On Wed, Sep 22, 2021 at 4:03 PM Brown, William 
mailto:wbr...@e1b.org>> wrote:
From: dns-operations 
mailto:dns-operations-boun...@dns-oarc.net>>
 On Behalf Of Erik Stian Tefre
Sent: Wednesday, September 22, 2021 3:38 PM
To: dns-operations@lists.dns-oarc.net<mailto:dns-operations@lists.dns-oarc.net>
Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers

> Possibly not a DNS issue at all, but something like this:

> https://community.cloudflare.com/t/revil-ransomware/301435

> (Executive summary: One Cloudflare IP being blocked by a firewall because of 
> a different and misbehaving Cloudflare customer who happened to serve 
> malicious content from that same IP.)

> Regards,
> Erik

Interesting.  The real issue I am experiencing is that I am getting 
inconsistent responses from nominally the same authoritative server.  It just 
so happens that when we get 172.64.80.1 as the answer it fails.  I would prefer 
to get the correct answer so students can use the online educational resource 
the district is paying for.
Confidentiality Notice: This electronic message and any attachments may contain 
confidential or privileged information, and is intended only for the individual 
or entity identified above as the addressee. If you are not the addressee (or 
the employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that you 
may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or telephone 
and delete this message from your system.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net<mailto:dns-operations@lists.dns-oarc.net>
https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Confidentiality Notice: This electronic message and any attachments may contain 
confidential or privileged information, and is intended only for the individual 
or entity identified above as the addressee. If you are not the addressee (or 
the employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that you 
may not copy, forward, disclose or use any part of this me

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Peter van Dijk]

On Thu, 2021-09-23 at 14:35 -0400, Warren Kumari wrote:
> Whatever the case, the fact that William was experiencing issues when this 
> particular address was returned, and it seems to be the only one that 
> responds in this way when no SNI is provided is, um, interesting.

As far as I have seen, in the past and recently and today, all
Cloudflare properties respond like this when no SNI is provided.

>  Perhaps whatever his customer was using isn't a web browser, or is really 
> old, or (being part of a school system) passes through some sort of 
> interception proxy which doesn't interact well, or...

To me William's problem is still entirely unexplained, unless the 172/8
theory fits!

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Thu, Sep 23, 2021 at 9:34 AM Peter van Dijk 
wrote:

> On Wed, 2021-09-22 at 20:13 -0400, Warren Kumari wrote:
> > Oh, testing now gives a different / working result:
> >
> > $ curl -v https://www.deltamath.com --connect-to 
> > deltamath.com:443:172.64.80.1
> 2>&1 | grep "HTTP/2 200"
> >
>
> This one sends a Server Name Indication of www.deltamath.com (like with
> 'openssl s_client -connect 172.64.80.1:443 -servername deltapath.com').
>
> >
> > > Yes, 172.64.80.1 is a CF address, but it was being returned for
> deltamath.com.
> > > Doing a GET / over TLS with the host set to deltamath.com  was giving
> a 403 Forbidden:
> > > HTTP/1.1 403 Forbidden
>
> This one is reproducible by not sending an SNI (like with 'openssl
> s_client -connect 172.64.80.1:443').
>
> As far as I can tell -right now-, the IP is entirely valid for the
> site, as long as the client sends the correct SNI and Host header
> (which web browsers do!).
>

Hah! That explains at least some of my testing issues.
When I was testing this issue it was from a machine without curl -- and so
I used openssl and manually typed the HTTP, I didn't include -servername:
$ echo -e "GET / HTTP/1.1\r\nHost:deltamath.com\r\n\r\n" | openssl 2>&1
s_client -quiet -connect 172.64.80.1:443
depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust
Root
verify return:1
depth=1 C = US, O = "Cloudflare, Inc.", CN = Cloudflare Inc ECC CA-3
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.",
CN = sni.cloudflaressl.com
verify return:1
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Wed, 22 Sep 2021 18:36:57 GMT
Content-Type: text/html
Content-Length: 151
Connection: keep-alive
CF-RAY: 692da44bb84eeb39-LAX


403 Forbidden

403 Forbidden
cloudflare


^C

This gave a different result to testing against the other addresses, which
just error out:
$ echo -e "GET / HTTP/1.1\r\nHost:deltamath.com\r\n\r\n" | openssl 2>&1
s_client -quiet -connect 104.26.2.229:443
140607395013952:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert
handshake failure:../ssl/record/rec_layer_s3.c:1544:SSL alert number 40

I didn't really bother wondering *why* the "working" ones were giving me an
SSL failure though.

Adding '-servername deltamath.com' does at least fix that, but now I've
made CF sufficiently grumpy by sending odd requests that it's popping up a
CAPTCHA :-)

Whatever the case, the fact that William was experiencing issues when this
particular address was returned, and it seems to be the only one that
responds in this way when no SNI is provided is, um, interesting. Perhaps
whatever his customer was using isn't a web browser, or is really old, or
(being part of a school system) passes through some sort of interception
proxy which doesn't interact well, or...

W






>
> Kind regards,
> --
> Peter van Dijk
> PowerDNS.COM BV - https://www.powerdns.com/
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Ethan Katz-Bassett]

Cloudflare in particular is experimenting with returning different IP
addresses to different queries for all kinds of reasons:
https://mislove.org/publications/IP-Unbound-SIGCOMM.pdf



On Wed, Sep 22, 2021 at 1:29 PM Warren Kumari  wrote:

>
>
> On Wed, Sep 22, 2021 at 1:01 PM Brown, William  wrote:
>
>> We have a school district that is trying to resolve the domain
>> deltamath.com.  This issue is impacting the classroom use of this
>> service.
>>
>>
>>
>> The authoritative servers are tani.ns.cloudflare.com and
>> jarred.ns.cloudfare.com.  Tani seems to work correctly.  Jarred however,
>> will return two different results:
>>
>>
>>
>> Here are the results of four tries within a few seconds:
>>
>>
>>
>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>
>> 172.67.75.10
>>
>> 104.26.2.229
>>
>> 104.26.3.229
>>
>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>
>> 104.26.2.229
>>
>> 104.26.3.229
>>
>> 172.67.75.10
>>
>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>
>> 172.67.75.10
>>
>> 104.26.3.229
>>
>> 104.26.2.229
>>
>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>
>> 172.64.80.1
>>
>>
>>
>> Is anyone from Cloudflare of the list that can assist with resolving
>> this?  Anyone have a contact at Cloudflare they can share to get this
>> resolved for the school district?
>>
>
> I don't really see the problem here -- all of the addresses returned seem
> to be valid CloudFlare addresses, and (I think) that all of them are
> answering correctly for deltamath.com.
> Nameservers routinely answer with different answers to split the load
> between different VIPS, provide answers which they think are "better" for
> specific queriers, etc. As long as the servers returned are behaving
> correctly, CF can return basically whatever they like.
>
> Of course, it's entirely possible/likely that I completely misunderstood
> the issue/question.
> W
>
>
>
>
>
>>
>>
>> --
>>
>> William Brown
>>
>> WNYRIC/Erie 1 BOCES
>>
>> 716-821-7285
>>
>>
>>
>> SharePoint, Eforms, Email, Spam Filtering Please reach out to
>> messag...@e1b.org
>>
>> Immediate Needs Call our Service Desk at 716-821-7171
>>
>>
>> Confidentiality Notice: This electronic message and any attachments may
>> contain confidential or privileged information, and is intended only for
>> the individual or entity identified above as the addressee. If you are not
>> the addressee (or the employee or agent responsible to deliver it to the
>> addressee), or if this message has been addressed to you in error, you are
>> hereby notified that you may not copy, forward, disclose or use any part of
>> this message or any attachments. Please notify the sender immediately by
>> return e-mail or telephone and delete this message from your system.
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
>
>
> --
> The computing scientist’s main challenge is not to get confused by the
> complexities of his own making.
>   -- E. W. Dijkstra
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
http://www.columbia.edu/~ebk2141/
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Peter van Dijk]

On Wed, 2021-09-22 at 20:13 -0400, Warren Kumari wrote:
> Oh, testing now gives a different / working result:
> 
> $ curl -v https://www.deltamath.com --connect-to 
> deltamath.com:443:172.64.80.1 2>&1 | grep "HTTP/2 200"
> 

This one sends a Server Name Indication of www.deltamath.com (like with
'openssl s_client -connect 172.64.80.1:443 -servername deltapath.com').

> 
> > Yes, 172.64.80.1 is a CF address, but it was being returned for 
> > deltamath.com.
> > Doing a GET / over TLS with the host set to deltamath.com  was giving a 403 
> > Forbidden:
> > HTTP/1.1 403 Forbidden

This one is reproducible by not sending an SNI (like with 'openssl
s_client -connect 172.64.80.1:443').

As far as I can tell -right now-, the IP is entirely valid for the
site, as long as the client sends the correct SNI and Host header
(which web browsers do!).

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

Oh, testing now gives a different / working result:

$ curl -v https://www.deltamath.com --connect-to deltamath.com:443:172.64.80.1
2>&1 | grep "HTTP/2 200"

So, looks like the issue is likely resolved.
W

On Wed, Sep 22, 2021 at 7:49 PM Warren Kumari  wrote:

>
>
> On Wed, Sep 22, 2021 at 7:26 PM Adam David  wrote:
>
>> This does not seem to be a DNS resolution/misconfiguration issue on
>> Cloudflare's end.
>>
>> https://172.64.80.1/ provides an error message (as it should) indicating
>> it is a CloudFlare IP. If you can't see that in a web browser, then the
>> issue is local to your network.
>>
>
> Yes, 172.64.80.1 is a CF address, but it was being returned for
> deltamath.com.
> Doing a GET / over TLS with the host set to deltamath.com  was giving a
> 403 Forbidden:
> HTTP/1.1 403 Forbidden
> Server: cloudflare
> Date: Wed, 22 Sep 2021 18:44:15 GMT
> Content-Type: text/html
> Content-Length: 151
> Connection: keep-alive
> CF-RAY: 692daefc1ffd542b-YYZ
>
> 
> 403 Forbidden
> 
> 403 Forbidden
> cloudflare
> 
> 
>
> The other address handed out all worked fine.
> So:
> 1: it is a DNS issue and they shouldn’t have handed out that address for
> that name or
> 2: that machine was borked.
>
> W
>
>
>
>
>
>
>> The main causes that I gather would be:
>>
>> 1. There was a temporary cache propagation issue on CF's network. (Still
>> not a DNS issue.)
>> 2. Your IT department is using 172.0.0.0/9 or possibly even 172.0.0.0/8
>> where they intended to use 172.16.0.0/12 (RFC1918 IP space). This would
>> block access to the netblock belonging to Cloudflare and you would have
>> difficulty accessing thousands of websites.
>>  Side Note: 172.64.0.0/13 belongs
>> to AS13335.
>>
>> You should always start with your IT department.
>> If you are a Cloudflare customer, contact them directly.
>> If you are a DeltaMath customer, then you need to contact them directly.
>>
>> Sincerely,
>>
>> Adam Vallee
>>
>>
>>
>> On Wed, Sep 22, 2021 at 4:03 PM Brown, William  wrote:
>>
>>> From: dns-operations  On Behalf Of
>>> Erik Stian Tefre
>>> Sent: Wednesday, September 22, 2021 3:38 PM
>>> To: dns-operations@lists.dns-oarc.net
>>> Subject: Re: [dns-operations] Oddness with Cloudfare authoritative
>>> servers
>>>
>>> > Possibly not a DNS issue at all, but something like this:
>>>
>>> > https://community.cloudflare.com/t/revil-ransomware/301435
>>>
>>> > (Executive summary: One Cloudflare IP being blocked by a firewall
>>> because of a different and misbehaving Cloudflare customer who happened to
>>> serve malicious content from that same IP.)
>>>
>>> > Regards,
>>> > Erik
>>>
>>> Interesting.  The real issue I am experiencing is that I am getting
>>> inconsistent responses from nominally the same authoritative server.  It
>>> just so happens that when we get 172.64.80.1 as the answer it fails.  I
>>> would prefer to get the correct answer so students can use the online
>>> educational resource the district is paying for.
>>> Confidentiality Notice: This electronic message and any attachments may
>>> contain confidential or privileged information, and is intended only for
>>> the individual or entity identified above as the addressee. If you are not
>>> the addressee (or the employee or agent responsible to deliver it to the
>>> addressee), or if this message has been addressed to you in error, you are
>>> hereby notified that you may not copy, forward, disclose or use any part of
>>> this message or any attachments. Please notify the sender immediately by
>>> return e-mail or telephone and delete this message from your system.
>>>
>>> ___
>>> dns-operations mailing list
>>> dns-operations@lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>>
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
> --
> Perhaps they really do strive for incomprehensibility in their specs.
> After all, when the liturgy was in Latin, the laity knew their place.
> -- Michael Padlipsky
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Wed, Sep 22, 2021 at 7:26 PM Adam David  wrote:

> This does not seem to be a DNS resolution/misconfiguration issue on
> Cloudflare's end.
>
> https://172.64.80.1/ provides an error message (as it should) indicating
> it is a CloudFlare IP. If you can't see that in a web browser, then the
> issue is local to your network.
>

Yes, 172.64.80.1 is a CF address, but it was being returned for
deltamath.com.
Doing a GET / over TLS with the host set to deltamath.com  was giving a 403
Forbidden:
HTTP/1.1 403 Forbidden
Server: cloudflare
Date: Wed, 22 Sep 2021 18:44:15 GMT
Content-Type: text/html
Content-Length: 151
Connection: keep-alive
CF-RAY: 692daefc1ffd542b-YYZ


403 Forbidden

403 Forbidden
cloudflare



The other address handed out all worked fine.
So:
1: it is a DNS issue and they shouldn’t have handed out that address for
that name or
2: that machine was borked.

W






> The main causes that I gather would be:
>
> 1. There was a temporary cache propagation issue on CF's network. (Still
> not a DNS issue.)
> 2. Your IT department is using 172.0.0.0/9 or possibly even 172.0.0.0/8
> where they intended to use 172.16.0.0/12 (RFC1918 IP space). This would
> block access to the netblock belonging to Cloudflare and you would have
> difficulty accessing thousands of websites.
>  Side Note: 172.64.0.0/13 belongs
> to AS13335.
>
> You should always start with your IT department.
> If you are a Cloudflare customer, contact them directly.
> If you are a DeltaMath customer, then you need to contact them directly.
>
> Sincerely,
>
> Adam Vallee
>
>
>
> On Wed, Sep 22, 2021 at 4:03 PM Brown, William  wrote:
>
>> From: dns-operations  On Behalf Of
>> Erik Stian Tefre
>> Sent: Wednesday, September 22, 2021 3:38 PM
>> To: dns-operations@lists.dns-oarc.net
>> Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers
>>
>> > Possibly not a DNS issue at all, but something like this:
>>
>> > https://community.cloudflare.com/t/revil-ransomware/301435
>>
>> > (Executive summary: One Cloudflare IP being blocked by a firewall
>> because of a different and misbehaving Cloudflare customer who happened to
>> serve malicious content from that same IP.)
>>
>> > Regards,
>> > Erik
>>
>> Interesting.  The real issue I am experiencing is that I am getting
>> inconsistent responses from nominally the same authoritative server.  It
>> just so happens that when we get 172.64.80.1 as the answer it fails.  I
>> would prefer to get the correct answer so students can use the online
>> educational resource the district is paying for.
>> Confidentiality Notice: This electronic message and any attachments may
>> contain confidential or privileged information, and is intended only for
>> the individual or entity identified above as the addressee. If you are not
>> the addressee (or the employee or agent responsible to deliver it to the
>> addressee), or if this message has been addressed to you in error, you are
>> hereby notified that you may not copy, forward, disclose or use any part of
>> this message or any attachments. Please notify the sender immediately by
>> return e-mail or telephone and delete this message from your system.
>>
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Wed, Sep 22, 2021 at 7:38 PM Ethan Katz-Bassett 
wrote:

> Cloudflare in particular is experimenting with returning different IP
> addresses to different queries for all kinds of reasons:
> https://mislove.org/publications/IP-Unbound-SIGCOMM.pdf
>

Yup — but in this case, at least one of the addresses that they returned
gave a 403 Error when connecting and trying to fetch /.

Giving out different addresses is fine, but they should all work :-)

W



>
>
> On Wed, Sep 22, 2021 at 1:29 PM Warren Kumari  wrote:
>
>>
>>
>> On Wed, Sep 22, 2021 at 1:01 PM Brown, William  wrote:
>>
>>> We have a school district that is trying to resolve the domain
>>> deltamath.com.  This issue is impacting the classroom use of this
>>> service.
>>>
>>>
>>>
>>> The authoritative servers are tani.ns.cloudflare.com and
>>> jarred.ns.cloudfare.com.  Tani seems to work correctly.  Jarred
>>> however, will return two different results:
>>>
>>>
>>>
>>> Here are the results of four tries within a few seconds:
>>>
>>>
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 172.67.75.10
>>>
>>> 104.26.2.229
>>>
>>> 104.26.3.229
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 104.26.2.229
>>>
>>> 104.26.3.229
>>>
>>> 172.67.75.10
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 172.67.75.10
>>>
>>> 104.26.3.229
>>>
>>> 104.26.2.229
>>>
>>> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>>>
>>> 172.64.80.1
>>>
>>>
>>>
>>> Is anyone from Cloudflare of the list that can assist with resolving
>>> this?  Anyone have a contact at Cloudflare they can share to get this
>>> resolved for the school district?
>>>
>>
>> I don't really see the problem here -- all of the addresses returned seem
>> to be valid CloudFlare addresses, and (I think) that all of them are
>> answering correctly for deltamath.com.
>> Nameservers routinely answer with different answers to split the load
>> between different VIPS, provide answers which they think are "better" for
>> specific queriers, etc. As long as the servers returned are behaving
>> correctly, CF can return basically whatever they like.
>>
>> Of course, it's entirely possible/likely that I completely misunderstood
>> the issue/question.
>> W
>>
>>
>>
>>
>>
>>>
>>>
>>> --
>>>
>>> William Brown
>>>
>>> WNYRIC/Erie 1 BOCES
>>>
>>> 716-821-7285
>>>
>>>
>>>
>>> SharePoint, Eforms, Email, Spam Filtering Please reach out to
>>> messag...@e1b.org
>>>
>>> Immediate Needs Call our Service Desk at 716-821-7171
>>>
>>>
>>> Confidentiality Notice: This electronic message and any attachments may
>>> contain confidential or privileged information, and is intended only for
>>> the individual or entity identified above as the addressee. If you are not
>>> the addressee (or the employee or agent responsible to deliver it to the
>>> addressee), or if this message has been addressed to you in error, you are
>>> hereby notified that you may not copy, forward, disclose or use any part of
>>> this message or any attachments. Please notify the sender immediately by
>>> return e-mail or telephone and delete this message from your system.
>>> ___
>>> dns-operations mailing list
>>> dns-operations@lists.dns-oarc.net
>>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>>
>>
>>
>> --
>> The computing scientist’s main challenge is not to get confused by the
>> complexities of his own making.
>>   -- E. W. Dijkstra
>> ___
>> dns-operations mailing list
>> dns-operations@lists.dns-oarc.net
>> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>>
>
>
> --
> http://www.columbia.edu/~ebk2141/
>
-- 
Perhaps they really do strive for incomprehensibility in their specs.
After all, when the liturgy was in Latin, the laity knew their place.
-- Michael Padlipsky
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Adam David]

This does not seem to be a DNS resolution/misconfiguration issue on
Cloudflare's end.

https://172.64.80.1/ provides an error message (as it should) indicating it
is a CloudFlare IP. If you can't see that in a web browser, then the issue
is local to your network.

The main causes that I gather would be:

1. There was a temporary cache propagation issue on CF's network. (Still
not a DNS issue.)
2. Your IT department is using 172.0.0.0/9 or possibly even 172.0.0.0/8
where they intended to use 172.16.0.0/12 (RFC1918 IP space). This would
block access to the netblock belonging to Cloudflare and you would have
difficulty accessing thousands of websites.
 Side Note: 172.64.0.0/13 belongs
to AS13335.

You should always start with your IT department.
If you are a Cloudflare customer, contact them directly.
If you are a DeltaMath customer, then you need to contact them directly.

Sincerely,

Adam Vallee



On Wed, Sep 22, 2021 at 4:03 PM Brown, William  wrote:

> From: dns-operations  On Behalf Of
> Erik Stian Tefre
> Sent: Wednesday, September 22, 2021 3:38 PM
> To: dns-operations@lists.dns-oarc.net
> Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers
>
> > Possibly not a DNS issue at all, but something like this:
>
> > https://community.cloudflare.com/t/revil-ransomware/301435
>
> > (Executive summary: One Cloudflare IP being blocked by a firewall
> because of a different and misbehaving Cloudflare customer who happened to
> serve malicious content from that same IP.)
>
> > Regards,
> > Erik
>
> Interesting.  The real issue I am experiencing is that I am getting
> inconsistent responses from nominally the same authoritative server.  It
> just so happens that when we get 172.64.80.1 as the answer it fails.  I
> would prefer to get the correct answer so students can use the online
> educational resource the district is paying for.
> Confidentiality Notice: This electronic message and any attachments may
> contain confidential or privileged information, and is intended only for
> the individual or entity identified above as the addressee. If you are not
> the addressee (or the employee or agent responsible to deliver it to the
> addressee), or if this message has been addressed to you in error, you are
> hereby notified that you may not copy, forward, disclose or use any part of
> this message or any attachments. Please notify the sender immediately by
> return e-mail or telephone and delete this message from your system.
>
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Mark Andrews]

The correct thing to do is to contact the service provider and say that you are 
getting inconsistent
DNS results.  That when you only get back 172.64.80.1 it doesn’t work.

Mark

> On 23 Sep 2021, at 05:58, Brown, William  wrote:
> 
> From: dns-operations  On Behalf Of Erik 
> Stian Tefre
> Sent: Wednesday, September 22, 2021 3:38 PM
> To: dns-operations@lists.dns-oarc.net
> Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers
> 
>> Possibly not a DNS issue at all, but something like this:
> 
>> https://community.cloudflare.com/t/revil-ransomware/301435
> 
>> (Executive summary: One Cloudflare IP being blocked by a firewall because of 
>> a different and misbehaving Cloudflare customer who happened to serve 
>> malicious content from that same IP.)
> 
>> Regards,
>> Erik
> 
> Interesting.  The real issue I am experiencing is that I am getting 
> inconsistent responses from nominally the same authoritative server.  It just 
> so happens that when we get 172.64.80.1 as the answer it fails.  I would 
> prefer to get the correct answer so students can use the online educational 
> resource the district is paying for.
> Confidentiality Notice: This electronic message and any attachments may 
> contain confidential or privileged information, and is intended only for the 
> individual or entity identified above as the addressee. If you are not the 
> addressee (or the employee or agent responsible to deliver it to the 
> addressee), or if this message has been addressed to you in error, you are 
> hereby notified that you may not copy, forward, disclose or use any part of 
> this message or any attachments. Please notify the sender immediately by 
> return e-mail or telephone and delete this message from your system.
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Brown, William]

From: dns-operations  On Behalf Of Erik 
Stian Tefre
Sent: Wednesday, September 22, 2021 3:38 PM
To: dns-operations@lists.dns-oarc.net
Subject: Re: [dns-operations] Oddness with Cloudfare authoritative servers

> Possibly not a DNS issue at all, but something like this:

> https://community.cloudflare.com/t/revil-ransomware/301435

> (Executive summary: One Cloudflare IP being blocked by a firewall because of 
> a different and misbehaving Cloudflare customer who happened to serve 
> malicious content from that same IP.)

> Regards,
> Erik

Interesting.  The real issue I am experiencing is that I am getting 
inconsistent responses from nominally the same authoritative server.  It just 
so happens that when we get 172.64.80.1 as the answer it fails.  I would prefer 
to get the correct answer so students can use the online educational resource 
the district is paying for.
Confidentiality Notice: This electronic message and any attachments may contain 
confidential or privileged information, and is intended only for the individual 
or entity identified above as the addressee. If you are not the addressee (or 
the employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that you 
may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or telephone 
and delete this message from your system.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Erik Stian Tefre]

On 2021-09-22 19:28, Warren Kumari wrote:

On Wed, Sep 22, 2021 at 1:01 PM Brown, William  wrote:

We have a school district that is trying to resolve the domain
deltamath.com [1].  This issue is impacting the classroom use of
this service.

The authoritative servers are tani.ns.cloudflare.com [2] and
jarred.ns.cloudfare.com [3].  Tani seems to work correctly.  Jarred
however, will return two different results:

Here are the results of four tries within a few seconds:

[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com [4] deltamath.com [1]
+short
172.67.75.10
104.26.2.229
104.26.3.229

[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com [4] deltamath.com [1]
+short
104.26.2.229
104.26.3.229
172.67.75.10

[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com [4] deltamath.com [1]
+short
172.67.75.10
104.26.3.229
104.26.2.229

[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com [4] deltamath.com [1]
+short
172.64.80.1

Is anyone from Cloudflare of the list that can assist with resolving
this?  Anyone have a contact at Cloudflare they can share to get
this resolved for the school district?


I don't really see the problem here -- all of the addresses returned
seem to be valid CloudFlare addresses, and (I think) that all of them
are answering correctly for deltamath.com [1].
Nameservers routinely answer with different answers to split the load
between different VIPS, provide answers which they think are "better"
for specific queriers, etc. As long as the servers returned are
behaving correctly, CF can return basically whatever they like.

Of course, it's entirely possible/likely that I completely
misunderstood the issue/question.
W


Possibly not a DNS issue at all, but something like this:

https://community.cloudflare.com/t/revil-ransomware/301435

(Executive summary: One Cloudflare IP being blocked by a firewall 
because of a different and misbehaving Cloudflare customer who happened 
to serve malicious content from that same IP.)


Regards,
Erik
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] Oddness with Cloudfare authoritative servers

[Warren Kumari]

On Wed, Sep 22, 2021 at 1:01 PM Brown, William  wrote:

> We have a school district that is trying to resolve the domain
> deltamath.com.  This issue is impacting the classroom use of this service.
>
>
>
> The authoritative servers are tani.ns.cloudflare.com and
> jarred.ns.cloudfare.com.  Tani seems to work correctly.  Jarred however,
> will return two different results:
>
>
>
> Here are the results of four tries within a few seconds:
>
>
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 172.67.75.10
>
> 104.26.2.229
>
> 104.26.3.229
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 104.26.2.229
>
> 104.26.3.229
>
> 172.67.75.10
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 172.67.75.10
>
> 104.26.3.229
>
> 104.26.2.229
>
> [wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
>
> 172.64.80.1
>
>
>
> Is anyone from Cloudflare of the list that can assist with resolving
> this?  Anyone have a contact at Cloudflare they can share to get this
> resolved for the school district?
>

I don't really see the problem here -- all of the addresses returned seem
to be valid CloudFlare addresses, and (I think) that all of them are
answering correctly for deltamath.com.
Nameservers routinely answer with different answers to split the load
between different VIPS, provide answers which they think are "better" for
specific queriers, etc. As long as the servers returned are behaving
correctly, CF can return basically whatever they like.

Of course, it's entirely possible/likely that I completely misunderstood
the issue/question.
W





>
>
> --
>
> William Brown
>
> WNYRIC/Erie 1 BOCES
>
> 716-821-7285
>
>
>
> SharePoint, Eforms, Email, Spam Filtering Please reach out to
> messag...@e1b.org
>
> Immediate Needs Call our Service Desk at 716-821-7171
>
>
> Confidentiality Notice: This electronic message and any attachments may
> contain confidential or privileged information, and is intended only for
> the individual or entity identified above as the addressee. If you are not
> the addressee (or the employee or agent responsible to deliver it to the
> addressee), or if this message has been addressed to you in error, you are
> hereby notified that you may not copy, forward, disclose or use any part of
> this message or any attachments. Please notify the sender immediately by
> return e-mail or telephone and delete this message from your system.
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>


-- 
The computing scientist’s main challenge is not to get confused by the
complexities of his own making.
  -- E. W. Dijkstra
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

[dns-operations] Oddness with Cloudfare authoritative servers

[Brown, William]

We have a school district that is trying to resolve the domain deltamath.com.  
This issue is impacting the classroom use of this service.

The authoritative servers are tani.ns.cloudflare.com and 
jarred.ns.cloudfare.com.  Tani seems to work correctly.  Jarred however, will 
return two different results:

Here are the results of four tries within a few seconds:

[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
172.67.75.10
104.26.2.229
104.26.3.229
[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
104.26.2.229
104.26.3.229
172.67.75.10
[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
172.67.75.10
104.26.3.229
104.26.2.229
[wbrown@ns3 ~]$ dig @jarred.ns.cloudflare.com deltamath.com +short
172.64.80.1

Is anyone from Cloudflare of the list that can assist with resolving this?  
Anyone have a contact at Cloudflare they can share to get this resolved for the 
school district?

--
William Brown
WNYRIC/Erie 1 BOCES
716-821-7285

SharePoint, Eforms, Email, Spam Filtering Please reach out to 
messag...@e1b.org
Immediate Needs Call our Service Desk at 716-821-7171

Confidentiality Notice: This electronic message and any attachments may contain 
confidential or privileged information, and is intended only for the individual 
or entity identified above as the addressee. If you are not the addressee (or 
the employee or agent responsible to deliver it to the addressee), or if this 
message has been addressed to you in error, you are hereby notified that you 
may not copy, forward, disclose or use any part of this message or any 
attachments. Please notify the sender immediately by return e-mail or telephone 
and delete this message from your system.
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations