Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Stephen Satchell]

On 04/02/2018 11:58 AM, Rhys Williams wrote:

Yep, Because you should have been setting up your networks correctly in the 
first place. There's plenty of private space assigned, use it.

Regards,

Rhys Williams

April 2, 2018 4:54 PM, "Simon Lockhart"  wrote:

and now suddenly it's our responsibility to make significant changes to live
infrastructures just so they can continue to look clever with the IP address.


(ah, the top-posting)

We go by the guidance of our vendors, and in this case the vendors are 
the one who made inappropriate use of Net 1.  Many of them.  So to put 
the onus on just Mr. Lockhart is plainly inappropriate.


"Fixing the blame" is not going to take us very far.  We as a community 
need to "fix the problem" -- that road will lead to proper functioning 
of all of our networks.


Even the little ones.

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Rhys Williams]

Yep, Because you should have been setting up your networks correctly in the 
first place. There's plenty of private space assigned, use it.

Regards,

Rhys Williams

April 2, 2018 4:54 PM, "Simon Lockhart"  wrote:
> and now suddenly it's our responsibility to make significant changes to live
> infrastructures just so they can continue to look clever with the IP address.

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[blakangel]

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Youssef Bengelloun-Zahr]

Still believe in santa ?   ;-)

Good luck with that.

Best regards.



2018-04-03 8:37 GMT+02:00 Marty Strong via NANOG :

> Orange France is known, they just didn’t tell us the exact reason.
>
> They said that if you contact them, they’ll provide you with an official
> explanation.
>
> Regards,
> Marty Strong
> --
> Cloudflare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
>
> https://www.peeringdb.com/asn/13335
>
> > On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン)  wrote:
> >
> > Hello,
> >
> > On Mon, 2 Apr 2018 16:26:13 +0100
> > Marty Strong via NANOG  wrote:
> >
> >> So far we know about a few CPEs which answer for 1.1.1.1 themselves:
> >>
> >> - Pace 5268
> >> - Calix GigaCenter
> >> - Various Cisco Wifi access points
> >>
> >> If you know of others please send them my way so we can investigate.
> >
> > It seems that in France, Orange's Livebox is also using 1.1.1.1 is some
> > way...
> >
> > 215 [6:20] rol@riri:~> traceroute 1.1.1.1
> > traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
> > 1  * * *
> > 2  * * *
> > 3  * * *
> > 4  * * *
> >
> > 216 [6:20] rol@riri:~> ping 1.1.1.1
> > PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
> > 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms
> > 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms
> > ^C
> > --- 1.1.1.1 ping statistics ---
> > 2 packets transmitted, 2 received, 0% packet loss, time 1037ms
> > rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms
> >
> > 217 [6:20] rol@riri:~> traceroute 8.8.8.8
> > traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> > 1  livebox.home (192.168.1.254)  0.268 ms  0.236 ms  0.263 ms
> > 2  * * *
> > 3  ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138)  1.724
> ms  1.733 ms  1.793 ms
> > ...
> >
> > That IP address is definitely full of magic...
> >
> > Paul
> >
> >
>
>

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Marty Strong via NANOG]

Orange France is known, they just didn’t tell us the exact reason.

They said that if you contact them, they’ll provide you with an official 
explanation.

Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

https://www.peeringdb.com/asn/13335

> On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン)  wrote:
> 
> Hello,
> 
> On Mon, 2 Apr 2018 16:26:13 +0100
> Marty Strong via NANOG  wrote:
> 
>> So far we know about a few CPEs which answer for 1.1.1.1 themselves:
>> 
>> - Pace 5268
>> - Calix GigaCenter
>> - Various Cisco Wifi access points
>> 
>> If you know of others please send them my way so we can investigate. 
> 
> It seems that in France, Orange's Livebox is also using 1.1.1.1 is some
> way...
> 
> 215 [6:20] rol@riri:~> traceroute 1.1.1.1
> traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
> 1  * * *
> 2  * * *
> 3  * * *
> 4  * * *
> 
> 216 [6:20] rol@riri:~> ping 1.1.1.1
> PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
> 64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms
> 64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms
> ^C
> --- 1.1.1.1 ping statistics ---
> 2 packets transmitted, 2 received, 0% packet loss, time 1037ms
> rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms
> 
> 217 [6:20] rol@riri:~> traceroute 8.8.8.8
> traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
> 1  livebox.home (192.168.1.254)  0.268 ms  0.236 ms  0.263 ms
> 2  * * *
> 3  ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138)  1.724 ms  
> 1.733 ms  1.793 ms
> ...
> 
> That IP address is definitely full of magic...
> 
> Paul
> 
> 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Paul Rolland (ポール・ロラン)]

Hello,

On Mon, 2 Apr 2018 16:26:13 +0100
Marty Strong via NANOG  wrote:

> So far we know about a few CPEs which answer for 1.1.1.1 themselves:
> 
> - Pace 5268
> - Calix GigaCenter
> - Various Cisco Wifi access points
> 
> If you know of others please send them my way so we can investigate. 

It seems that in France, Orange's Livebox is also using 1.1.1.1 is some
way...

215 [6:20] rol@riri:~> traceroute 1.1.1.1
traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets
 1  * * *
 2  * * *
 3  * * *
 4  * * *

216 [6:20] rol@riri:~> ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
64 bytes from 1.1.1.1: icmp_seq=1 ttl=64 time=0.371 ms
64 bytes from 1.1.1.1: icmp_seq=2 ttl=64 time=0.292 ms
^C
--- 1.1.1.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1037ms
rtt min/avg/max/mdev = 0.292/0.331/0.371/0.043 ms

217 [6:20] rol@riri:~> traceroute 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  livebox.home (192.168.1.254)  0.268 ms  0.236 ms  0.263 ms
 2  * * *
 3  ae102-0.ncidf103.Puteaux.francetelecom.net (193.253.80.138)  1.724 ms  
1.733 ms  1.793 ms
...

That IP address is definitely full of magic...

Paul




pgpeF9LT535CB.pgp
Description: OpenPGP digital signature

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Seth Mattinen]

On 4/2/18 5:10 PM, Mark Andrews wrote:

On 3 Apr 2018, at 1:39 am, Seth Mattinen  wrote:

On 4/2/18 8:35 AM, Simon Lockhart wrote:

This looks like a willy-waving exercise by Cloudflare coming up with the lowest
quad-digit IP. They must have known that this would cause routing issues, and
now suddenly it's our responsibility to make significant changes to live
infrastructures just so they can continue to look clever with the IP address.


To be fair, nobody should have been using 1/8 for anything.

Stop living in the 1900’s.  Parts to 1/8 have be allocated to people for
years now.



Copypasta:


I didn't say that.

In case this is a non-native English issue, "nobody should have been 
using" is past tense, which is to say everyone squatting on 1/8 space 
for their own purposes because it was "unassigned" shouldn't have been 
doing that.


~Seth

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Mark Andrews]

> On 3 Apr 2018, at 1:39 am, Seth Mattinen  wrote:
> 
> On 4/2/18 8:35 AM, Simon Lockhart wrote:
>> This looks like a willy-waving exercise by Cloudflare coming up with the 
>> lowest
>> quad-digit IP. They must have known that this would cause routing issues, and
>> now suddenly it's our responsibility to make significant changes to live
>> infrastructures just so they can continue to look clever with the IP address.
> 
> 
> To be fair, nobody should have been using 1/8 for anything.

Stop living in the 1900’s.  Parts to 1/8 have be allocated to people for
years now.

1.0.0/24 and 1.2.3/24 have been used for various experiments but the rest
of 1/8 is being allocated for normal use (there may be a couple of more
exceptions).

Mark

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

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Rubens Kuhl]

On Mon, Apr 2, 2018 at 4:32 PM, Marty Strong  wrote:

> Do you have one?
>

Yes, supplied by local broadband provider Vivo. FTTH GPON connection,
router with broadband and IPTV services.


> Do you know what is causing it to fail? i.e. IP on internal interface etc.
>

Interface table:

eth5.2 (WAN2) Static 10.200.a.b 255.255.128.0 10.200.0.1 Connected NONE
527220
eth5.3 (WAN4) DHCP   Unconfigured NONE 0
eth5.4 (WAN5) DHCP   Unconfigured NONE 0
ppp0.1/eth5.1 (WAN1) PPPoE 179.x.y.z 255.255.255.255 200.d.e.f Connected
NONE 527200
ppp1/wan3g (WAN3) PPPoE   Unconfigured NONE 0
LAN INTERFACE STATUS

Name
Status
IP Address
Subnet Mask
br0 Enable 192.168.1.1 255.255.255.0
br0:0 Enable 1.1.1.1 255.255.255.0

Routing table:

200.x.y.z 0.0.0.0 255.255.255.255 UH 0 ppp0.1
192.168.1.0 0.0.0.0 255.255.255.0 U 0 br0
1.1.1.0 0.0.0.0 255.255.255.0 U 0 br0
10.200.0.0 0.0.0.0 255.255.128.0 U 0 eth5.2
0.0.0.0 200.100.88.195 0.0.0.0 UG 0 ppp0.1

Rubens

Re: UBNT Security was Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Brielle Bruns]

On 4/2/2018 3:23 PM, Mike Hammett wrote:

I believe at one point UBNT did block outside management access, but then their 
customers voiced to bring it back.

That said, I think they're taking security more seriously going forward.



I'm not entirely sure what Ubnt has changed lately, because I'm not a 
user of the Air* product lines (usually used by the WISPs), but I know 
on, for example the Unifi stuff, while the default password is ubnt/ubnt 
for the devices, as soon as they are paired with a controller, the 
password is set to a random long strong (on a per site basis).


I seem to remember on new EdgeRouter devices they do have you change the 
default password during initial web setup.  CLI stuff, I think still 
have to manually change it from the default.


So yeah, big improvements.

That being said, either way, providers that fail to even basic setup 
tasks like changing the default password do deserve what happens to them.


(Note: I heavily use Ubnt's Unifi and Edge* product lines, so I'm 
probably biased in one way or another.)



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Florian Weimer]

* Hank Nussbacher:

> Perhaps they are running all  this to shake out exactly these type of
> issues?  I think that is exactly why APNIC research is called for.

And return another 2**24 addresses to the global IPv4 pool eventually?
That would indeed be a loadable goal.

UBNT Security was Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Mike Hammett]

I believe at one point UBNT did block outside management access, but then their 
customers voiced to bring it back. 

That said, I think they're taking security more seriously going forward. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 

Midwest-IX 
http://www.midwest-ix.com 

- Original Message -

From: "Brielle Bruns" <br...@2mbit.com> 
To: nanog@nanog.org 
Sent: Monday, April 2, 2018 4:20:38 PM 
Subject: Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE 

On 4/2/2018 9:35 AM, Simon Lockhart wrote: 
> Quite. 
> 
> This looks like a willy-waving exercise by Cloudflare coming up with the 
> lowest 
> quad-digit IP. They must have known that this would cause routing issues, and 
> now suddenly it's our responsibility to make significant changes to live 
> infrastructures just so they can continue to look clever with the IP address. 
> 
> Simon 


I don't see how this is Cloudflare's fault really? Its the 
responsibility of network maintainers to... well, lets be blunt here, 
maintain their network. 

If part of maintaining their network involves updating bogon 
routes/filters, then that's part of maintaining the network that can't 
be lapsed. 

This is like the WISPs blaming Ubiquiti for their failure to update 
their CPEs and PtP devices for a security flaw that Ubnt released fix 
for more then a year before (and for not properly securing the 
management interfaces of their network devices). 

Or even better, the morons who blocked all of 172.0.0.0/8 even though a 
good portion of that block is live public IP space. I actually felt 
really bad for AOL having been assigned IP blocks from that space, since 
it had to have created customer complaints at times. 

There's only one person to blame here, and it's not the RIRs or Cloudflare. 

-- 
Brielle Bruns 
The Summit Open Source Development Group 
http://www.sosdg.org / http://www.ahbl.org 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Brielle Bruns]

On 4/2/2018 9:35 AM, Simon Lockhart wrote:

Quite.

This looks like a willy-waving exercise by Cloudflare coming up with the lowest
quad-digit IP. They must have known that this would cause routing issues, and
now suddenly it's our responsibility to make significant changes to live
infrastructures just so they can continue to look clever with the IP address.

Simon



I don't see how this is Cloudflare's fault really?  Its the 
responsibility of network maintainers to... well, lets be blunt here, 
maintain their network.


If part of maintaining their network involves updating bogon 
routes/filters, then that's part of maintaining the network that can't 
be lapsed.


This is like the WISPs blaming Ubiquiti for their failure to update 
their CPEs and PtP devices for a security flaw that Ubnt released fix 
for more then a year before (and for not properly securing the 
management interfaces of their network devices).


Or even better, the morons who blocked all of 172.0.0.0/8 even though a 
good portion of that block is live public IP space.  I actually felt 
really bad for AOL having been assigned IP blocks from that space, since 
it had to have created customer complaints at times.


There's only one person to blame here, and it's not the RIRs or Cloudflare.

--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Marty Strong via NANOG]

Do you have one?

Do you know what is causing it to fail? i.e. IP on internal interface etc.

Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

https://www.peeringdb.com/asn/13335

> On 2 Apr 2018, at 19:24, Rubens Kuhl  wrote:
> 
> D-Link DMG-6661 as well. 
> 
> 
> Rubens
> 
> 
> On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG  
> wrote:
> So far we know about a few CPEs which answer for 1.1.1.1 themselves:
> 
> - Pace 5268
> - Calix GigaCenter
> - Various Cisco Wifi access points
> 
> If you know of others please send them my way so we can investigate.
> 
> Regards,
> Marty Strong
> --
> Cloudflare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
> 
> https://www.peeringdb.com/asn/13335
> 
> > On 2 Apr 2018, at 16:16, Jason Kuehl  wrote:
> >
> > Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change
> > week" I've already around a few peaces of equipment sets with 1.1.1.1
> >
> > On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes <
> > mattli...@rivervalleyinternet.net> wrote:
> >
> >> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is
> >> causing odd issues.
> >>
> >>> On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
> >>>
> >>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my
> >> router
> >>> and not any further. When I enter the IP into my browser, it opens the
> >>> login page for my router. So it appears 1.1.1.1 is used as a loopback in
> >> my
> >>> Calix router.
> >>>
> >>> 1.0.0.1 goes to the proper place fine.
> >>>
> >>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
> >>> wrote:
> >>>
>  Greetings,
> 
>  If anyone at 7018 wants to pass a message along to the correct folks,
>  please let them know that Cloudflare's new public DNS service (1.1.1.1)
>  is completely unusable for at least some of AT's customers.
> 
>  There is apparently a bug with some CPE (including the 5268AC). From
>  behind such CPE, the services at 1.1.1.1 are completely unreachable,
>  whether via (ICMP) ping, DNS, or HTTPS.
> 
>  Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
>  the following results:
> 
>  ping successful: icmp seq:0, time=2.364 ms
>  ping successful: icmp seq:1, time=1.085 ms
>  ping successful: icmp seq:2, time=1.160 ms
>  ping successful: icmp seq:3, time=1.245 ms
>  ping successful: icmp seq:4, time=0.739 ms
> 
>  RTTs to the CPE's default gateway are, at minimum, ~20 ms.
> 
>  A traceroute (using the same web-based diagnostic tool built-in to the
>  CPE) reports, simply:
> 
>  traceroute 1.1.1.1 with: 64 bytes of data
> 
>  1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
> 
>  I haven't bothered to report this to AT through the standard customer
>  support channels (for reasons that should be obvious to anyone who has
>  ever called AT's consumer/residential technical support) but if anyone
>  at AT wants to pass the info along to the appropriate group, it would
>  certainly be appreciated.
> 
>  Thanks,
>  -Jeremy
> 
>  --
>  Jeremy L. Gaddis
> 
> 
>  "The total budget at all receivers for solving senders' problems is
>  $0. If you want them to accept your mail and manage it the way you
>  want, send it the way the spec says to."  --John Levine
> 
> 
> >>>
> >>>
> >>> --
> >>> Darin Steffl
> >>> Minnesota WiFi
> >>> www.mnwifi.com
> >>> 507-634-WiFi
> >>>  Like us on Facebook
> >>> 
> >>
> >
> >
> >
> > --
> > Sincerely,
> >
> > Jason W Kuehl
> > Cell 920-419-8983
> > jason.w.ku...@gmail.com
> 
> 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[mike . lyon]

Because it would be wasteful not to use it???

> On Apr 2, 2018, at 11:48, Brett Watson  wrote:
> 
> 
> 
>> On Apr 2, 2018, at 10:18, John Levine  wrote:
>> 
>> In article <7db5fac7-972a-4eb6-89d9-b305a7233...@cloudflare.com> you write:
>>> If you know of others please send them my way so we can investigate. 
>> 
>> A lot of hotel and coffee shop captive portals use it for the login
>> and logout screens.  Don't know what the underlying software is, but
>> wander around London and hop on the wifi at coffee shops and hotels
>> and you'll run into it soon enough.
> 
> Tons of it in the US in hotels, airports, and any number of other places that 
> folks have already mentioned. Why we are still experimenting with IPv4 space 
> is a bit of a mystery to me.
> 
> -b
> 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Brett Watson]

> On Apr 2, 2018, at 10:18, John Levine  wrote:
> 
> In article <7db5fac7-972a-4eb6-89d9-b305a7233...@cloudflare.com> you write:
>> If you know of others please send them my way so we can investigate. 
> 
> A lot of hotel and coffee shop captive portals use it for the login
> and logout screens.  Don't know what the underlying software is, but
> wander around London and hop on the wifi at coffee shops and hotels
> and you'll run into it soon enough.

Tons of it in the US in hotels, airports, and any number of other places that 
folks have already mentioned. Why we are still experimenting with IPv4 space is 
a bit of a mystery to me.

-b

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Rubens Kuhl]

D-Link DMG-6661 as well.


Rubens


On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG 
wrote:

> So far we know about a few CPEs which answer for 1.1.1.1 themselves:
>
> - Pace 5268
> - Calix GigaCenter
> - Various Cisco Wifi access points
>
> If you know of others please send them my way so we can investigate.
>
> Regards,
> Marty Strong
> --
> Cloudflare - AS13335
> Network Engineer
> ma...@cloudflare.com
> +44 7584 906 055
> smartflare (Skype)
>
> https://www.peeringdb.com/asn/13335
>
> > On 2 Apr 2018, at 16:16, Jason Kuehl  wrote:
> >
> > Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change
> > week" I've already around a few peaces of equipment sets with 1.1.1.1
> >
> > On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes <
> > mattli...@rivervalleyinternet.net> wrote:
> >
> >> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this
> is
> >> causing odd issues.
> >>
> >>> On Apr 2, 2018, at 11:03, Darin Steffl 
> wrote:
> >>>
> >>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my
> >> router
> >>> and not any further. When I enter the IP into my browser, it opens the
> >>> login page for my router. So it appears 1.1.1.1 is used as a loopback
> in
> >> my
> >>> Calix router.
> >>>
> >>> 1.0.0.1 goes to the proper place fine.
> >>>
> >>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
> >>> wrote:
> >>>
>  Greetings,
> 
>  If anyone at 7018 wants to pass a message along to the correct folks,
>  please let them know that Cloudflare's new public DNS service
> (1.1.1.1)
>  is completely unusable for at least some of AT's customers.
> 
>  There is apparently a bug with some CPE (including the 5268AC). From
>  behind such CPE, the services at 1.1.1.1 are completely unreachable,
>  whether via (ICMP) ping, DNS, or HTTPS.
> 
>  Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
>  the following results:
> 
>  ping successful: icmp seq:0, time=2.364 ms
>  ping successful: icmp seq:1, time=1.085 ms
>  ping successful: icmp seq:2, time=1.160 ms
>  ping successful: icmp seq:3, time=1.245 ms
>  ping successful: icmp seq:4, time=0.739 ms
> 
>  RTTs to the CPE's default gateway are, at minimum, ~20 ms.
> 
>  A traceroute (using the same web-based diagnostic tool built-in to the
>  CPE) reports, simply:
> 
>  traceroute 1.1.1.1 with: 64 bytes of data
> 
>  1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
> 
>  I haven't bothered to report this to AT through the standard
> customer
>  support channels (for reasons that should be obvious to anyone who has
>  ever called AT's consumer/residential technical support) but if
> anyone
>  at AT wants to pass the info along to the appropriate group, it
> would
>  certainly be appreciated.
> 
>  Thanks,
>  -Jeremy
> 
>  --
>  Jeremy L. Gaddis
> 
> 
>  "The total budget at all receivers for solving senders' problems is
>  $0. If you want them to accept your mail and manage it the way you
>  want, send it the way the spec says to."  --John Levine
> 
> 
> >>>
> >>>
> >>> --
> >>> Darin Steffl
> >>> Minnesota WiFi
> >>> www.mnwifi.com
> >>> 507-634-WiFi
> >>>  Like us on Facebook
> >>> 
> >>
> >
> >
> >
> > --
> > Sincerely,
> >
> > Jason W Kuehl
> > Cell 920-419-8983
> > jason.w.ku...@gmail.com
>
>

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Seth Mattinen]

On 4/2/18 10:49, David Conrad wrote:

Wait. What?

Why do you think 1/8 shouldn’t be used for anything?




I didn't say that.

In case this is a non-native English issue, "nobody should have been 
using" is past tense, which is to say everyone squatting on 1/8 space 
for their own purposes because it was "unassigned" shouldn't have been 
doing that.


~Seth

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[David Conrad]

Wait. What?

Why do you think 1/8 shouldn’t be used for anything?

Regards,
-drc

--

> On Monday, Apr 02, 2018 at 11:40 AM, Seth Mattinen  (mailto:se...@rollernet.us)> wrote:
> On 4/2/18 8:35 AM, Simon Lockhart wrote:
> >
> > This looks like a willy-waving exercise by Cloudflare coming up with the 
> > lowest
> > quad-digit IP. They must have known that this would cause routing issues, 
> > and
> > now suddenly it's our responsibility to make significant changes to live
> > infrastructures just so they can continue to look clever with the IP 
> > address.
>
>
> To be fair, nobody should have been using 1/8 for anything.


signature.asc
Description: PGP signature

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[John Levine]

In article <7db5fac7-972a-4eb6-89d9-b305a7233...@cloudflare.com> you write:
>If you know of others please send them my way so we can investigate. 

A lot of hotel and coffee shop captive portals use it for the login
and logout screens.  Don't know what the underlying software is, but
wander around London and hop on the wifi at coffee shops and hotels
and you'll run into it soon enough.

R's,
John

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Alan Buxey]

thats probably a key part of the experiment - to find locations and
systems where 1.1.1.1 is trashed.

it should be routable and its about time that vendors stopped messing
around in that space - hopefully this is
one of the sticks that prods people to start to behave - at which
point 1.0.0.0/8 will regain value too and can be used by APNIC
for other requirements.


as for those berating addresses used for experiments - there are MANY
networking experiments going on out there , the Internet itself
derives from one big ongoing experiment...and some would even say it
IS still an experiment.

alan

On 2 April 2018 at 17:04, John R. Levine  wrote:
>> This looks like a willy-waving exercise by Cloudflare coming up with the
>> lowest
>> quad-digit IP. They must have known that this would cause routing issues,
>> and
>> now suddenly it's our responsibility to make significant changes to live
>> infrastructures just so they can continue to look clever with the IP
>> address.
>
>
> Perhaps we can ask APNIC what the experiment is.  They surely know that
> 1.1.1.1 is messed up so I doubt that Matt expects every coffee shop in the
> world to bend to his will.
>
> Regards,
> John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for
> Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Hank Nussbacher]

On 02/04/2018 18:35, Simon Lockhart wrote:
> On Mon Apr 02, 2018 at 11:17:47AM -0400, John Levine wrote:
>> So it's routed deliberately but it sure looks like an experiment.
>> There's way too much equipment that treats 1.1.1.1 as magic for it to
>> work reliably.  Captive portals tend to use that address for the host
>> you contact to log out.
> Quite.
>
> This looks like a willy-waving exercise by Cloudflare coming up with the 
> lowest
> quad-digit IP. They must have known that this would cause routing issues, and
> now suddenly it's our responsibility to make significant changes to live
> infrastructures just so they can continue to look clever with the IP address.
>
> Simon

Perhaps they are running all  this to shake out exactly these type of
issues?  I think that is exactly why APNIC research is called for.

-Hank

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[James R Cutler]

> On Apr 2, 2018, at 11:35 AM, Simon Lockhart  wrote:
> 
> …
> This looks like a willy-waving exercise by Cloudflare coming up with the 
> lowest
> quad-digit IP. They must have known that this would cause routing issues, and
> now suddenly it's our responsibility to make significant changes to live
> infrastructures just so they can continue to look clever with the IP address.
> 


I am very impressed at Cloudflare’s forward thinking to force investing a 
significant amount of IPv4 infrastructure. This will obviously become even more 
important in the future as IPv6 withers away and is replaced by IPv4.

And, I repeat, please tell me how many end users know about or care about DNS, 
even after reading snake oil advertisements.

James R. Cutler
james.cut...@consultant.com
PGP keys at http://pgp.mit.edu

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[John R. Levine]

This looks like a willy-waving exercise by Cloudflare coming up with the lowest
quad-digit IP. They must have known that this would cause routing issues, and
now suddenly it's our responsibility to make significant changes to live
infrastructures just so they can continue to look clever with the IP address.


Perhaps we can ask APNIC what the experiment is.  They surely know that 
1.1.1.1 is messed up so I doubt that Matt expects every coffee shop in the 
world to bend to his will.


Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[nop]

On Mon, Apr 2, 2018, at 8:35 AM, Simon Lockhart wrote:
> quad-digit IP. They must have known that this would cause routing issues, and
> now suddenly it's our responsibility to make significant changes to live
> infrastructures just so they can continue to look clever with the IP address.

In this case, one only broke their own infrastructure by doing bad things or 
"being clever" by misusing space that isn't theirs in unintended ways; people 
doing things correctly would not have this issue...

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Seth Mattinen]

On 4/2/18 8:35 AM, Simon Lockhart wrote:


This looks like a willy-waving exercise by Cloudflare coming up with the lowest
quad-digit IP. They must have known that this would cause routing issues, and
now suddenly it's our responsibility to make significant changes to live
infrastructures just so they can continue to look clever with the IP address.



To be fair, nobody should have been using 1/8 for anything.

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Simon Lockhart]

On Mon Apr 02, 2018 at 11:17:47AM -0400, John Levine wrote:
> So it's routed deliberately but it sure looks like an experiment.
> There's way too much equipment that treats 1.1.1.1 as magic for it to
> work reliably.  Captive portals tend to use that address for the host
> you contact to log out.

Quite.

This looks like a willy-waving exercise by Cloudflare coming up with the lowest
quad-digit IP. They must have known that this would cause routing issues, and
now suddenly it's our responsibility to make significant changes to live
infrastructures just so they can continue to look clever with the IP address.

Simon
-- 
Simon Lockhart |   * Server Co-location * ADSL * Domain Registration *
   Director|  * Domain & Web Hosting * Connectivity * Consultancy * 
  Bogons Ltd   | *  http://www.bogons.net/  *  Email: i...@bogons.net  * 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Matt Hoppes]

“Routed briefly for passive testing” sounds to me like “black hole it because 
legitimate traffic shouldn’t be coming to your network from it”

> On Apr 2, 2018, at 11:23, Jason Kuehl  wrote:
> 
> Not saying you're wrong. But people did it for whatever reason.
> 
>> On Mon, Apr 2, 2018 at 11:12 AM, Justin Wilson  wrote:
>> 
>> 1.0.0.0/8 was assigned to APNIC in 2010.  Those who used it as a
>> placeholder were doing it wrong.  It is valid IP space. It just was not
>> assigned until 2010.
>> 
>> 
>> Justin Wilson
>> j...@mtin.net
>> 
>> www.mtin.net
>> www.midwest-ix.com
>> 
>>> On Apr 2, 2018, at 11:05 AM, Matt Hoppes > rivervalleyinternet.net> wrote:
>>> 
>>> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this
>> is causing odd issues.
>>> 
 On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
 
 I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my
>> router
 and not any further. When I enter the IP into my browser, it opens the
 login page for my router. So it appears 1.1.1.1 is used as a loopback
>> in my
 Calix router.
 
 1.0.0.1 goes to the proper place fine.
 
 On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
 wrote:
 
> Greetings,
> 
> If anyone at 7018 wants to pass a message along to the correct folks,
> please let them know that Cloudflare's new public DNS service (1.1.1.1)
> is completely unusable for at least some of AT's customers.
> 
> There is apparently a bug with some CPE (including the 5268AC). From
> behind such CPE, the services at 1.1.1.1 are completely unreachable,
> whether via (ICMP) ping, DNS, or HTTPS.
> 
> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
> the following results:
> 
> ping successful: icmp seq:0, time=2.364 ms
> ping successful: icmp seq:1, time=1.085 ms
> ping successful: icmp seq:2, time=1.160 ms
> ping successful: icmp seq:3, time=1.245 ms
> ping successful: icmp seq:4, time=0.739 ms
> 
> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
> 
> A traceroute (using the same web-based diagnostic tool built-in to the
> CPE) reports, simply:
> 
> traceroute 1.1.1.1 with: 64 bytes of data
> 
> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
> 
> I haven't bothered to report this to AT through the standard customer
> support channels (for reasons that should be obvious to anyone who has
> ever called AT's consumer/residential technical support) but if
>> anyone
> at AT wants to pass the info along to the appropriate group, it would
> certainly be appreciated.
> 
> Thanks,
> -Jeremy
> 
> --
> Jeremy L. Gaddis
> 
> 
> "The total budget at all receivers for solving senders' problems is
> $0. If you want them to accept your mail and manage it the way you
> want, send it the way the spec says to."  --John Levine
> 
> 
 
 
 --
 Darin Steffl
 Minnesota WiFi
 www.mnwifi.com
 507-634-WiFi
  Like us on Facebook
 
>>> 
>> 
>> 
> 
> 
> -- 
> Sincerely,
> 
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Marty Strong via NANOG]

So far we know about a few CPEs which answer for 1.1.1.1 themselves:

- Pace 5268
- Calix GigaCenter
- Various Cisco Wifi access points

If you know of others please send them my way so we can investigate. 

Regards,
Marty Strong
--
Cloudflare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

https://www.peeringdb.com/asn/13335

> On 2 Apr 2018, at 16:16, Jason Kuehl  wrote:
> 
> Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change
> week" I've already around a few peaces of equipment sets with 1.1.1.1
> 
> On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes <
> mattli...@rivervalleyinternet.net> wrote:
> 
>> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is
>> causing odd issues.
>> 
>>> On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
>>> 
>>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my
>> router
>>> and not any further. When I enter the IP into my browser, it opens the
>>> login page for my router. So it appears 1.1.1.1 is used as a loopback in
>> my
>>> Calix router.
>>> 
>>> 1.0.0.1 goes to the proper place fine.
>>> 
>>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
>>> wrote:
>>> 
 Greetings,
 
 If anyone at 7018 wants to pass a message along to the correct folks,
 please let them know that Cloudflare's new public DNS service (1.1.1.1)
 is completely unusable for at least some of AT's customers.
 
 There is apparently a bug with some CPE (including the 5268AC). From
 behind such CPE, the services at 1.1.1.1 are completely unreachable,
 whether via (ICMP) ping, DNS, or HTTPS.
 
 Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
 the following results:
 
 ping successful: icmp seq:0, time=2.364 ms
 ping successful: icmp seq:1, time=1.085 ms
 ping successful: icmp seq:2, time=1.160 ms
 ping successful: icmp seq:3, time=1.245 ms
 ping successful: icmp seq:4, time=0.739 ms
 
 RTTs to the CPE's default gateway are, at minimum, ~20 ms.
 
 A traceroute (using the same web-based diagnostic tool built-in to the
 CPE) reports, simply:
 
 traceroute 1.1.1.1 with: 64 bytes of data
 
 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
 
 I haven't bothered to report this to AT through the standard customer
 support channels (for reasons that should be obvious to anyone who has
 ever called AT's consumer/residential technical support) but if anyone
 at AT wants to pass the info along to the appropriate group, it would
 certainly be appreciated.
 
 Thanks,
 -Jeremy
 
 --
 Jeremy L. Gaddis
 
 
 "The total budget at all receivers for solving senders' problems is
 $0. If you want them to accept your mail and manage it the way you
 want, send it the way the spec says to."  --John Levine
 
 
>>> 
>>> 
>>> --
>>> Darin Steffl
>>> Minnesota WiFi
>>> www.mnwifi.com
>>> 507-634-WiFi
>>>  Like us on Facebook
>>> 
>> 
> 
> 
> 
> -- 
> Sincerely,
> 
> Jason W Kuehl
> Cell 920-419-8983
> jason.w.ku...@gmail.com

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Jason Kuehl]

Not saying you're wrong. But people did it for whatever reason.

On Mon, Apr 2, 2018 at 11:12 AM, Justin Wilson  wrote:

> 1.0.0.0/8 was assigned to APNIC in 2010.  Those who used it as a
> placeholder were doing it wrong.  It is valid IP space. It just was not
> assigned until 2010.
>
>
> Justin Wilson
> j...@mtin.net
>
> www.mtin.net
> www.midwest-ix.com
>
> > On Apr 2, 2018, at 11:05 AM, Matt Hoppes  rivervalleyinternet.net> wrote:
> >
> > Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this
> is causing odd issues.
> >
> >> On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
> >>
> >> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my
> router
> >> and not any further. When I enter the IP into my browser, it opens the
> >> login page for my router. So it appears 1.1.1.1 is used as a loopback
> in my
> >> Calix router.
> >>
> >> 1.0.0.1 goes to the proper place fine.
> >>
> >> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
> >> wrote:
> >>
> >>> Greetings,
> >>>
> >>> If anyone at 7018 wants to pass a message along to the correct folks,
> >>> please let them know that Cloudflare's new public DNS service (1.1.1.1)
> >>> is completely unusable for at least some of AT's customers.
> >>>
> >>> There is apparently a bug with some CPE (including the 5268AC). From
> >>> behind such CPE, the services at 1.1.1.1 are completely unreachable,
> >>> whether via (ICMP) ping, DNS, or HTTPS.
> >>>
> >>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
> >>> the following results:
> >>>
> >>> ping successful: icmp seq:0, time=2.364 ms
> >>> ping successful: icmp seq:1, time=1.085 ms
> >>> ping successful: icmp seq:2, time=1.160 ms
> >>> ping successful: icmp seq:3, time=1.245 ms
> >>> ping successful: icmp seq:4, time=0.739 ms
> >>>
> >>> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
> >>>
> >>> A traceroute (using the same web-based diagnostic tool built-in to the
> >>> CPE) reports, simply:
> >>>
> >>> traceroute 1.1.1.1 with: 64 bytes of data
> >>>
> >>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
> >>>
> >>> I haven't bothered to report this to AT through the standard customer
> >>> support channels (for reasons that should be obvious to anyone who has
> >>> ever called AT's consumer/residential technical support) but if
> anyone
> >>> at AT wants to pass the info along to the appropriate group, it would
> >>> certainly be appreciated.
> >>>
> >>> Thanks,
> >>> -Jeremy
> >>>
> >>> --
> >>> Jeremy L. Gaddis
> >>>
> >>>
> >>> "The total budget at all receivers for solving senders' problems is
> >>> $0. If you want them to accept your mail and manage it the way you
> >>> want, send it the way the spec says to."  --John Levine
> >>>
> >>>
> >>
> >>
> >> --
> >> Darin Steffl
> >> Minnesota WiFi
> >> www.mnwifi.com
> >> 507-634-WiFi
> >>  Like us on Facebook
> >> 
> >
>
>


-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[John Levine]

In article <20180402150821.ga24...@cmadams.net> you write:
>Once upon a time, Matt Hoppes  said:
>> Seeing as how 1.1.1.1 isn’t suppose to be routed
>
>[citation needed]

Look at the WHOIS info -- 1.1.1.0/24 is assigned to APNIC Research, and it says

remarks:++
remarks:+ Address blocks listed with this contact
remarks:+ are withheld from general use and are
remarks:+ only routed briefly for passive testing.
remarks:+
remarks:+ If you are receiving unwanted traffic
remarks:+ it is almost certainly spoofed source
remarks:+ or hijacked address usage.

There's a comment at the top saying:

descr:  APNIC and Cloudflare DNS Resolver project
descr:  Routed globally by AS13335/Cloudflare
descr:  Research prefix for APNIC Labs

So it's routed deliberately but it sure looks like an experiment.
There's way too much equipment that treats 1.1.1.1 as magic for it to
work reliably.  Captive portals tend to use that address for the host
you contact to log out.

R's,
John

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Jason Kuehl]

Just like "S3 dependency check day" Thus begins "National 1.1.1.1 change
week" I've already around a few peaces of equipment sets with 1.1.1.1

On Mon, Apr 2, 2018 at 11:05 AM, Matt Hoppes <
mattli...@rivervalleyinternet.net> wrote:

> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is
> causing odd issues.
>
> > On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
> >
> > I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my
> router
> > and not any further. When I enter the IP into my browser, it opens the
> > login page for my router. So it appears 1.1.1.1 is used as a loopback in
> my
> > Calix router.
> >
> > 1.0.0.1 goes to the proper place fine.
> >
> > On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
> > wrote:
> >
> >> Greetings,
> >>
> >> If anyone at 7018 wants to pass a message along to the correct folks,
> >> please let them know that Cloudflare's new public DNS service (1.1.1.1)
> >> is completely unusable for at least some of AT's customers.
> >>
> >> There is apparently a bug with some CPE (including the 5268AC). From
> >> behind such CPE, the services at 1.1.1.1 are completely unreachable,
> >> whether via (ICMP) ping, DNS, or HTTPS.
> >>
> >> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
> >> the following results:
> >>
> >>  ping successful: icmp seq:0, time=2.364 ms
> >>  ping successful: icmp seq:1, time=1.085 ms
> >>  ping successful: icmp seq:2, time=1.160 ms
> >>  ping successful: icmp seq:3, time=1.245 ms
> >>  ping successful: icmp seq:4, time=0.739 ms
> >>
> >> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
> >>
> >> A traceroute (using the same web-based diagnostic tool built-in to the
> >> CPE) reports, simply:
> >>
> >>  traceroute 1.1.1.1 with: 64 bytes of data
> >>
> >>  1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
> >>
> >> I haven't bothered to report this to AT through the standard customer
> >> support channels (for reasons that should be obvious to anyone who has
> >> ever called AT's consumer/residential technical support) but if anyone
> >> at AT wants to pass the info along to the appropriate group, it would
> >> certainly be appreciated.
> >>
> >> Thanks,
> >> -Jeremy
> >>
> >> --
> >> Jeremy L. Gaddis
> >>
> >>
> >> "The total budget at all receivers for solving senders' problems is
> >> $0. If you want them to accept your mail and manage it the way you
> >> want, send it the way the spec says to."  --John Levine
> >>
> >>
> >
> >
> > --
> > Darin Steffl
> > Minnesota WiFi
> > www.mnwifi.com
> > 507-634-WiFi
> >  Like us on Facebook
> > 
>



-- 
Sincerely,

Jason W Kuehl
Cell 920-419-8983
jason.w.ku...@gmail.com

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Justin Wilson]

1.0.0.0/8 was assigned to APNIC in 2010.  Those who used it as a placeholder 
were doing it wrong.  It is valid IP space. It just was not assigned until 2010.


Justin Wilson
j...@mtin.net

www.mtin.net
www.midwest-ix.com

> On Apr 2, 2018, at 11:05 AM, Matt Hoppes  
> wrote:
> 
> Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is 
> causing odd issues. 
> 
>> On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
>> 
>> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router
>> and not any further. When I enter the IP into my browser, it opens the
>> login page for my router. So it appears 1.1.1.1 is used as a loopback in my
>> Calix router.
>> 
>> 1.0.0.1 goes to the proper place fine.
>> 
>> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
>> wrote:
>> 
>>> Greetings,
>>> 
>>> If anyone at 7018 wants to pass a message along to the correct folks,
>>> please let them know that Cloudflare's new public DNS service (1.1.1.1)
>>> is completely unusable for at least some of AT's customers.
>>> 
>>> There is apparently a bug with some CPE (including the 5268AC). From
>>> behind such CPE, the services at 1.1.1.1 are completely unreachable,
>>> whether via (ICMP) ping, DNS, or HTTPS.
>>> 
>>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
>>> the following results:
>>> 
>>> ping successful: icmp seq:0, time=2.364 ms
>>> ping successful: icmp seq:1, time=1.085 ms
>>> ping successful: icmp seq:2, time=1.160 ms
>>> ping successful: icmp seq:3, time=1.245 ms
>>> ping successful: icmp seq:4, time=0.739 ms
>>> 
>>> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
>>> 
>>> A traceroute (using the same web-based diagnostic tool built-in to the
>>> CPE) reports, simply:
>>> 
>>> traceroute 1.1.1.1 with: 64 bytes of data
>>> 
>>> 1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
>>> 
>>> I haven't bothered to report this to AT through the standard customer
>>> support channels (for reasons that should be obvious to anyone who has
>>> ever called AT's consumer/residential technical support) but if anyone
>>> at AT wants to pass the info along to the appropriate group, it would
>>> certainly be appreciated.
>>> 
>>> Thanks,
>>> -Jeremy
>>> 
>>> --
>>> Jeremy L. Gaddis
>>> 
>>> 
>>> "The total budget at all receivers for solving senders' problems is
>>> $0. If you want them to accept your mail and manage it the way you
>>> want, send it the way the spec says to."  --John Levine
>>> 
>>> 
>> 
>> 
>> -- 
>> Darin Steffl
>> Minnesota WiFi
>> www.mnwifi.com
>> 507-634-WiFi
>>  Like us on Facebook
>> 
> 

RE: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Chris Gross]

That sounds like a provider problem with their configuration most likely. I run 
hundreds of 844E, 844Gs and have one at my house even, and it continues out 
fine for 1.1.1.1 when I was testing over the weekend with our config.

Chris Gross
IP Services Supervisor

-Original Message-
From: NANOG <nanog-boun...@nanog.org> On Behalf Of Darin Steffl
Sent: Monday, April 02, 2018 11:03 AM
To: North American Network Operators' Group <nanog@nanog.org>
Subject: Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router and 
not any further. When I enter the IP into my browser, it opens the login page 
for my router. So it appears 1.1.1.1 is used as a loopback in my Calix router.

1.0.0.1 goes to the proper place fine.

On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis <lists-na...@gadd.is>
wrote:

> Greetings,
>
> If anyone at 7018 wants to pass a message along to the correct folks, 
> please let them know that Cloudflare's new public DNS service 
> (1.1.1.1) is completely unusable for at least some of AT's customers.
>
> There is apparently a bug with some CPE (including the 5268AC). From 
> behind such CPE, the services at 1.1.1.1 are completely unreachable, 
> whether via (ICMP) ping, DNS, or HTTPS.
>
> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns 
> the following results:
>
>   ping successful: icmp seq:0, time=2.364 ms
>   ping successful: icmp seq:1, time=1.085 ms
>   ping successful: icmp seq:2, time=1.160 ms
>   ping successful: icmp seq:3, time=1.245 ms
>   ping successful: icmp seq:4, time=0.739 ms
>
> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
>
> A traceroute (using the same web-based diagnostic tool built-in to the
> CPE) reports, simply:
>
>   traceroute 1.1.1.1 with: 64 bytes of data
>
>   1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
>
> I haven't bothered to report this to AT through the standard 
> customer support channels (for reasons that should be obvious to 
> anyone who has ever called AT's consumer/residential technical 
> support) but if anyone at AT wants to pass the info along to the 
> appropriate group, it would certainly be appreciated.
>
> Thanks,
> -Jeremy
>
> --
> Jeremy L. Gaddis
>
>
> "The total budget at all receivers for solving senders' problems is 
> $0. If you want them to accept your mail and manage it the way you 
> want, send it the way the spec says to."  --John Levine
>
>


--
Darin Steffl
Minnesota WiFi
https://na01.safelinks.protection.outlook.com/?url=www.mnwifi.com=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128=Uwca5B1Fg0YSPmAwLRM63MGE%2BSBD8bTN%2FoGcVCvpUyc%3D=0
507-634-WiFi
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2Fminnesotawifi=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128=W4P%2BUzI82FABcW8sAkxaGNM2FJmVLmrix58KVgdxax0%3D=0>
 Like us on Facebook 
<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2Fminnesotawifi=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128=W4P%2BUzI82FABcW8sAkxaGNM2FJmVLmrix58KVgdxax0%3D=0>

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Chris Adams]

Once upon a time, Matt Hoppes  said:
> Seeing as how 1.1.1.1 isn’t suppose to be routed

[citation needed]

-- 
Chris Adams 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Matt Hoppes]

Seeing as how 1.1.1.1 isn’t suppose to be routed I’m not surprised this is 
causing odd issues. 

> On Apr 2, 2018, at 11:03, Darin Steffl  wrote:
> 
> I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router
> and not any further. When I enter the IP into my browser, it opens the
> login page for my router. So it appears 1.1.1.1 is used as a loopback in my
> Calix router.
> 
> 1.0.0.1 goes to the proper place fine.
> 
> On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
> wrote:
> 
>> Greetings,
>> 
>> If anyone at 7018 wants to pass a message along to the correct folks,
>> please let them know that Cloudflare's new public DNS service (1.1.1.1)
>> is completely unusable for at least some of AT's customers.
>> 
>> There is apparently a bug with some CPE (including the 5268AC). From
>> behind such CPE, the services at 1.1.1.1 are completely unreachable,
>> whether via (ICMP) ping, DNS, or HTTPS.
>> 
>> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
>> the following results:
>> 
>>  ping successful: icmp seq:0, time=2.364 ms
>>  ping successful: icmp seq:1, time=1.085 ms
>>  ping successful: icmp seq:2, time=1.160 ms
>>  ping successful: icmp seq:3, time=1.245 ms
>>  ping successful: icmp seq:4, time=0.739 ms
>> 
>> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
>> 
>> A traceroute (using the same web-based diagnostic tool built-in to the
>> CPE) reports, simply:
>> 
>>  traceroute 1.1.1.1 with: 64 bytes of data
>> 
>>  1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
>> 
>> I haven't bothered to report this to AT through the standard customer
>> support channels (for reasons that should be obvious to anyone who has
>> ever called AT's consumer/residential technical support) but if anyone
>> at AT wants to pass the info along to the appropriate group, it would
>> certainly be appreciated.
>> 
>> Thanks,
>> -Jeremy
>> 
>> --
>> Jeremy L. Gaddis
>> 
>> 
>> "The total budget at all receivers for solving senders' problems is
>> $0. If you want them to accept your mail and manage it the way you
>> want, send it the way the spec says to."  --John Levine
>> 
>> 
> 
> 
> -- 
> Darin Steffl
> Minnesota WiFi
> www.mnwifi.com
> 507-634-WiFi
>  Like us on Facebook
> 

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Darin Steffl]

I am behind a Calix router at home for my ISP and 1.1.1.1 goes to my router
and not any further. When I enter the IP into my browser, it opens the
login page for my router. So it appears 1.1.1.1 is used as a loopback in my
Calix router.

1.0.0.1 goes to the proper place fine.

On Sun, Apr 1, 2018 at 3:59 PM, Jeremy L. Gaddis 
wrote:

> Greetings,
>
> If anyone at 7018 wants to pass a message along to the correct folks,
> please let them know that Cloudflare's new public DNS service (1.1.1.1)
> is completely unusable for at least some of AT's customers.
>
> There is apparently a bug with some CPE (including the 5268AC). From
> behind such CPE, the services at 1.1.1.1 are completely unreachable,
> whether via (ICMP) ping, DNS, or HTTPS.
>
> Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
> the following results:
>
>   ping successful: icmp seq:0, time=2.364 ms
>   ping successful: icmp seq:1, time=1.085 ms
>   ping successful: icmp seq:2, time=1.160 ms
>   ping successful: icmp seq:3, time=1.245 ms
>   ping successful: icmp seq:4, time=0.739 ms
>
> RTTs to the CPE's default gateway are, at minimum, ~20 ms.
>
> A traceroute (using the same web-based diagnostic tool built-in to the
> CPE) reports, simply:
>
>   traceroute 1.1.1.1 with: 64 bytes of data
>
>   1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms
>
> I haven't bothered to report this to AT through the standard customer
> support channels (for reasons that should be obvious to anyone who has
> ever called AT's consumer/residential technical support) but if anyone
> at AT wants to pass the info along to the appropriate group, it would
> certainly be appreciated.
>
> Thanks,
> -Jeremy
>
> --
> Jeremy L. Gaddis
>
>
> "The total budget at all receivers for solving senders' problems is
> $0. If you want them to accept your mail and manage it the way you
> want, send it the way the spec says to."  --John Levine
>
>


-- 
Darin Steffl
Minnesota WiFi
www.mnwifi.com
507-634-WiFi
 Like us on Facebook

Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[Jeremy L. Gaddis]

Greetings,

If anyone at 7018 wants to pass a message along to the correct folks,
please let them know that Cloudflare's new public DNS service (1.1.1.1)
is completely unusable for at least some of AT's customers.

There is apparently a bug with some CPE (including the 5268AC). From
behind such CPE, the services at 1.1.1.1 are completely unreachable,
whether via (ICMP) ping, DNS, or HTTPS.

Using the 5268AC's web-based diagnostic tools, pinging 1.1.1.1 returns
the following results:

  ping successful: icmp seq:0, time=2.364 ms
  ping successful: icmp seq:1, time=1.085 ms
  ping successful: icmp seq:2, time=1.160 ms
  ping successful: icmp seq:3, time=1.245 ms
  ping successful: icmp seq:4, time=0.739 ms

RTTs to the CPE's default gateway are, at minimum, ~20 ms.

A traceroute (using the same web-based diagnostic tool built-in to the
CPE) reports, simply:

  traceroute 1.1.1.1 with: 64 bytes of data

  1: 1.1.1.1(1dot1dot1dot1.cloudflare-dns.com), time=0 ms

I haven't bothered to report this to AT through the standard customer
support channels (for reasons that should be obvious to anyone who has
ever called AT's consumer/residential technical support) but if anyone
at AT wants to pass the info along to the appropriate group, it would
certainly be appreciated.

Thanks,
-Jeremy

-- 
Jeremy L. Gaddis


"The total budget at all receivers for solving senders' problems is
$0. If you want them to accept your mail and manage it the way you
want, send it the way the spec says to."  --John Levine