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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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
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-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
In article <20180402150821.GA24937@cmadams.net> you write:
Once upon a time, Matt Hoppes <mattlists@rivervalleyinternet.net> 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
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: info@bogons.net *
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.
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 <sethm@rollernet.us (mailto:sethm@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.
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
On 3 Apr 2018, at 1:39 am, Seth Mattinen <sethm@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.
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: marka@isc.org
On 4/2/18 5:10 PM, Mark Andrews wrote:
On 3 Apr 2018, at 1:39 am, Seth Mattinen<sethm@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. 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
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...
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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
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 <johnl@iecc.com> 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, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. https://jl.ly
On Apr 2, 2018, at 11:35 AM, Simon Lockhart <simon@slimey.org> 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.cutler@consultant.com PGP keys at http://pgp.mit.edu
"how many end users know about or care about DNS, even after reading snake oil advertisements." None. Nobody cares. ----- Mike Hammett Intelligent Computing Solutions http://www.ics-il.com Midwest-IX http://www.midwest-ix.com ----- Original Message ----- From: "James R Cutler" <james.cutler@consultant.com> To: "North American Network Operators' Group" <nanog@nanog.org> Sent: Monday, April 2, 2018 11:07:32 AM Subject: Re: Cloudflare 1.1.1.1 public DNS broken w/ AT&T CPE
On Apr 2, 2018, at 11:35 AM, Simon Lockhart <simon@slimey.org> 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.cutler@consultant.com PGP keys at http://pgp.mit.edu
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
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" <simon@slimey.org> 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.
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" <simon@slimey.org> 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.
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
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" <bruns@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&T 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
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
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 j2sw@mtin.net www.mtin.net www.midwest-ix.com
On Apr 2, 2018, at 11:05 AM, Matt Hoppes <mattlists@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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
Not saying you're wrong. But people did it for whatever reason. On Mon, Apr 2, 2018 at 11:12 AM, Justin Wilson <lists@mtin.net> 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 j2sw@mtin.net
www.mtin.net www.midwest-ix.com
On Apr 2, 2018, at 11:05 AM, Matt Hoppes <mattlists@ 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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
“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 <jason.w.kuehl@gmail.com> wrote:
Not saying you're wrong. But people did it for whatever reason.
On Mon, Apr 2, 2018 at 11:12 AM, Justin Wilson <lists@mtin.net> 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 j2sw@mtin.net
www.mtin.net www.midwest-ix.com
On Apr 2, 2018, at 11:05 AM, Matt Hoppes <mattlists@ 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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely,
Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
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 < mattlists@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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely, Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 16:16, Jason Kuehl <jason.w.kuehl@gmail.com> 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 < mattlists@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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely,
Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
In article <7DB5FAC7-972A-4EB6-89D9-B305A723334F@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
On Apr 2, 2018, at 10:18, John Levine <johnl@iecc.com> wrote:
In article <7DB5FAC7-972A-4EB6-89D9-B305A723334F@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
Because it would be wasteful not to use it???
On Apr 2, 2018, at 11:48, Brett Watson <brett@the-watsons.org> wrote:
On Apr 2, 2018, at 10:18, John Levine <johnl@iecc.com> wrote:
In article <7DB5FAC7-972A-4EB6-89D9-B305A723334F@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
D-Link DMG-6661 as well. Rubens On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG <nanog@nanog.org> 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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype)
https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 16:16, Jason Kuehl <jason.w.kuehl@gmail.com> 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 < mattlists@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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely,
Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 19:24, Rubens Kuhl <rubensk@gmail.com> wrote:
D-Link DMG-6661 as well.
Rubens
On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG <nanog@nanog.org> 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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype)
https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 16:16, Jason Kuehl <jason.w.kuehl@gmail.com> 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 < mattlists@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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely,
Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
dont know if this is a problem but seeing different as paths for 1.0.0.1 and 1.1.1.1 in UK as lands 2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms 3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms 4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms 5 * * * 6 * * * 7 ve160.er2.thn.as50056.net (178.18.119.90) 3.786 ms 178.18.122.193 (178.18.122.193) 2.542 ms ve160.er2.thn.as50056.net (178.18.119.90) 3.736 ms 8 * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.350 ms * 2 185.61.135.25 (185.61.135.25) 3.172 ms 3.154 ms 3.130 ms 3 10.254.84.3 (10.254.84.3) 3.228 ms 3.525 ms 3.502 ms 4 31.28.72.22 (31.28.72.22) 3.781 ms 3.869 ms 3.857 ms 5 * * * 6 ve165.er1.the.as50056.net (94.126.43.225) 16.655 ms 9.496 ms 9.454 ms 7 lonap.as13335.net (5.57.81.75) 91.859 ms 2.484 ms 196.896 ms 8 1dot1dot1dot1.cloudflare-dns.com (1.0.0.1) 2.504 ms 2.804 ms 2.799 ms Colin
If they are for redundancy, wouldn't it be preferable to route them to different place to cover more fault scenarios. I would complain if they are routed to same place. On 2 April 2018 at 22:56, Colin Johnston <colinj@gt86car.org.uk> wrote:
dont know if this is a problem but seeing different as paths for 1.0.0.1 and 1.1.1.1 in UK as lands
2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms 3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms 4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms 5 * * * 6 * * * 7 ve160.er2.thn.as50056.net (178.18.119.90) 3.786 ms 178.18.122.193 (178.18.122.193) 2.542 ms ve160.er2.thn.as50056.net (178.18.119.90) 3.736 ms 8 * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.350 ms *
2 185.61.135.25 (185.61.135.25) 3.172 ms 3.154 ms 3.130 ms 3 10.254.84.3 (10.254.84.3) 3.228 ms 3.525 ms 3.502 ms 4 31.28.72.22 (31.28.72.22) 3.781 ms 3.869 ms 3.857 ms 5 * * * 6 ve165.er1.the.as50056.net (94.126.43.225) 16.655 ms 9.496 ms 9.454 ms 7 lonap.as13335.net (5.57.81.75) 91.859 ms 2.484 ms 196.896 ms 8 1dot1dot1dot1.cloudflare-dns.com (1.0.0.1) 2.504 ms 2.804 ms 2.799 ms
Colin
-- ++ytti
On Mon, Apr 2, 2018 at 8:14 PM, Saku Ytti <saku@ytti.fi> wrote:
If they are for redundancy, wouldn't it be preferable to route them to different place to cover more fault scenarios.
I would complain if they are routed to same place.
Better start complaining then :-) Kind regards, Job
Routing from ~150 locations, plenty of redundancy. https://www.cloudflare.com/network/ Regards, Marty Strong -------------------------------------- Cloudflare - AS13335 Network Engineer marty@cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 21:14, Saku Ytti <saku@ytti.fi> wrote:
If they are for redundancy, wouldn't it be preferable to route them to different place to cover more fault scenarios.
I would complain if they are routed to same place.
On 2 April 2018 at 22:56, Colin Johnston <colinj@gt86car.org.uk> wrote:
dont know if this is a problem but seeing different as paths for 1.0.0.1 and 1.1.1.1 in UK as lands
2 185.61.135.25 (185.61.135.25) 1.964 ms 72.824 ms 72.835 ms 3 10.254.84.3 (10.254.84.3) 2.671 ms 2.577 ms 2.601 ms 4 31.28.72.22 (31.28.72.22) 2.798 ms 2.897 ms 3.123 ms 5 * * * 6 * * * 7 ve160.er2.thn.as50056.net (178.18.119.90) 3.786 ms 178.18.122.193 (178.18.122.193) 2.542 ms ve160.er2.thn.as50056.net (178.18.119.90) 3.736 ms 8 * 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 3.350 ms *
2 185.61.135.25 (185.61.135.25) 3.172 ms 3.154 ms 3.130 ms 3 10.254.84.3 (10.254.84.3) 3.228 ms 3.525 ms 3.502 ms 4 31.28.72.22 (31.28.72.22) 3.781 ms 3.869 ms 3.857 ms 5 * * * 6 ve165.er1.the.as50056.net (94.126.43.225) 16.655 ms 9.496 ms 9.454 ms 7 lonap.as13335.net (5.57.81.75) 91.859 ms 2.484 ms 196.896 ms 8 1dot1dot1dot1.cloudflare-dns.com (1.0.0.1) 2.504 ms 2.804 ms 2.799 ms
Colin
-- ++ytti
On 4/2/18 14:58, Marty Strong via NANOG wrote:
Routing from ~150 locations, plenty of redundancy.
I recommend 9.9.9.9 to people (if they must use a public resolver) because Quad9/PCH serves local markets of all sizes with anycast nodes and peering, not just "major markets". Since I'm not in a major market I want to support those who support the small markets that are overlooked by the big guys.
So in all this discussion, what I'm finding interesting is that 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1 On 4/2/18 6:06 PM, Seth Mattinen wrote:
On 4/2/18 14:58, Marty Strong via NANOG wrote:
Routing from ~150 locations, plenty of redundancy.
I recommend 9.9.9.9 to people (if they must use a public resolver) because Quad9/PCH serves local markets of all sizes with anycast nodes and peering, not just "major markets". Since I'm not in a major market I want to support those who support the small markets that are overlooked by the big guys.
On 03/04/2018 01:39, Matt Hoppes wrote: You might be interested in these links which compare the services: https://medium.com/@nykolas.z/dns-resolvers-performance-compared-cloudflare-... https://webxtrakt.com/public-dns-performance -Hank
So in all this discussion, what I'm finding interesting is that 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1
On 4/2/18 6:06 PM, Seth Mattinen wrote:
On 4/2/18 14:58, Marty Strong via NANOG wrote:
Routing from ~150 locations, plenty of redundancy.
I recommend 9.9.9.9 to people (if they must use a public resolver) because Quad9/PCH serves local markets of all sizes with anycast nodes and peering, not just "major markets". Since I'm not in a major market I want to support those who support the small markets that are overlooked by the big guys.
1.1.1.1 not usable via Windstream peering in Chicago. # traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets ... 3 be4.agr01.chcg02-il.us.windstream.net (40.136.99.22) 5.158 ms 5.116 ms 7.565 ms 4 ae13-0.cr01.chcg01-il.us.windstream.net (40.136.99.44) 4.673 ms 4.644 ms 4.600 ms 5 et8-0-0-0.cr02.dlls01-tx.us.windstream.net (40.128.10.135) 27.136 ms 27.099 ms 27.053 ms 6 xe0-2-3-0.cr02.dnvt01-co.us.windstream.net (40.136.97.125) 29.075 ms 28.381 ms 28.336 ms 7 xe3-3-1-0.pe03.dums01-tx.us.windstream.net (173.189.57.195) 46.121 ms 46.193 ms 46.148 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 *^C # 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=248 time=43.2 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=248 time=43.9 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=248 time=42.8 ms ^C --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 42.892/43.344/43.915/0.489 ms # nslookup
server 1.1.1.1 Default server: 1.1.1.1 Address: 1.1.1.1#53 google.com ;; connection timed out; trying next origin ;; connection timed out; no servers could be reached
I'm finding it unreachable from at least one Level 3 router. I'm seeing behavior which makes me suspect 1.1.1.1/32 has been incorrectly defined an interface IP on that device; one of our locations gets an immediate ping response for 1.1.1.1, and a traceroute of one hop, which is that first upstream hop. 1.0.0.1 is reachable like normal across several hops. On 4/3/18, 1:36 PM, "NANOG on behalf of George Skorup" <nanog-bounces@nanog.org on behalf of george.skorup@cbcast.com> wrote: 1.1.1.1 not usable via Windstream peering in Chicago. # traceroute 1.1.1.1 traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 60 byte packets ... 3 be4.agr01.chcg02-il.us.windstream.net (40.136.99.22) 5.158 ms 5.116 ms 7.565 ms 4 ae13-0.cr01.chcg01-il.us.windstream.net (40.136.99.44) 4.673 ms 4.644 ms 4.600 ms 5 et8-0-0-0.cr02.dlls01-tx.us.windstream.net (40.128.10.135) 27.136 ms 27.099 ms 27.053 ms 6 xe0-2-3-0.cr02.dnvt01-co.us.windstream.net (40.136.97.125) 29.075 ms 28.381 ms 28.336 ms 7 xe3-3-1-0.pe03.dums01-tx.us.windstream.net (173.189.57.195) 46.121 ms 46.193 ms 46.148 ms 8 * * * 9 * * * 10 * * * 11 * * * 12 * * * 13 *^C # 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=248 time=43.2 ms 64 bytes from 1.1.1.1: icmp_seq=2 ttl=248 time=43.9 ms 64 bytes from 1.1.1.1: icmp_seq=3 ttl=248 time=42.8 ms ^C --- 1.1.1.1 ping statistics --- 3 packets transmitted, 3 received, 0% packet loss, time 2002ms rtt min/avg/max/mdev = 42.892/43.344/43.915/0.489 ms # nslookup > server 1.1.1.1 Default server: 1.1.1.1 Address: 1.1.1.1#53 > google.com ;; connection timed out; trying next origin ;; connection timed out; no servers could be reached
Great article! Thanks for sharing :) On Mon, Apr 2, 2018 at 11:12 PM, Hank Nussbacher <hank@efes.iucc.ac.il> wrote:
On 03/04/2018 01:39, Matt Hoppes wrote:
You might be interested in these links which compare the services: https://medium.com/@nykolas.z/dns-resolvers-performance- compared-cloudflare-x-google-x-quad9-x-opendns-149e803734e5 https://webxtrakt.com/public-dns-performance
-Hank
So in all this discussion, what I'm finding interesting is that 8.8.8.8 is actually more hops away from me than either 9.9.9.9 or 1.1.1.1
On 4/2/18 6:06 PM, Seth Mattinen wrote:
On 4/2/18 14:58, Marty Strong via NANOG wrote:
Routing from ~150 locations, plenty of redundancy.
I recommend 9.9.9.9 to people (if they must use a public resolver) because Quad9/PCH serves local markets of all sizes with anycast nodes and peering, not just "major markets". Since I'm not in a major market I want to support those who support the small markets that are overlooked by the big guys.
* Marty Strong via NANOG <nanog@nanog.org>
Routing from ~150 locations, plenty of redundancy.
Any plans to support NSID and/or "hostname.bind" to allow clients to identify which node is serving their requests? For example: $ dig @nsb.dnsnode.net. hostname.bind. CH TXT +nsid [...] ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ; NSID: 73 34 2e 6f 73 6c ("s4.osl") ;; QUESTION SECTION: ;hostname.bind. CH TXT ;; ANSWER SECTION: hostname.bind. 0 CH TXT "s4.osl" [...] Tore
On 2018-04-03 (Tue) at 01:22 EDT, Tore Anderson wrote:
Any plans to support NSID and/or "hostname.bind" to allow clients to identify which node is serving their requests? For example:
FWIW: $ dig @1.0.0.1 id.server. CH TXT [...] ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1536 ;; QUESTION SECTION: ;id.server. CH TXT ;; ANSWER SECTION: id.server. 0 CH TXT "dtw01" [...] -- Jeremy L. Gaddis
Very interesting... I just heard about this problem today from one of my friend’s who supports of the big SP network (Russia). He got complains from one of their peer. After short investigation he found that they blackholing 1.1.1.1. When I asked him about the reasons, he can’t explain because as he said “it was there from the Big Bang times”. BR, Andrey Slastenov
3 апр. 2018 г., в 20:41, Jeremy L. Gaddis <lists-nanog@gadd.is> написал(а):
On 2018-04-03 (Tue) at 01:22 EDT, Tore Anderson wrote: Any plans to support NSID and/or "hostname.bind" to allow clients to identify which node is serving their requests? For example:
FWIW:
$ dig @1.0.0.1 id.server. CH TXT [...] ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1536 ;; QUESTION SECTION: ;id.server. CH TXT
;; ANSWER SECTION: id.server. 0 CH TXT "dtw01" [...]
-- Jeremy L. Gaddis
On Mon, Apr 2, 2018 at 4:32 PM, Marty Strong <marty@cloudflare.com> 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
On a Xerox Phaser 3635MFP printer running the latest firmware, when attempting to configure it to use 1.1.1.1 for DNS, it throws the following error: "The following Alternate DNS Server 1 addresses are not permitted: 1.1.1.1 and 255.255.255.255". I suspect this was intended to prevent people from putting in an "invalid" placeholder, but the assumption that 1.1.1.1 would never be an actual DNS server that somebody might actually wish to use appears to have been unwise. Daniel Dent https://www.danieldent.com On 2018-04-02 12:32 PM, Marty Strong via NANOG wrote:
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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype)
https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 19:24, Rubens Kuhl <rubensk@gmail.com> wrote:
D-Link DMG-6661 as well.
Rubens
On Mon, Apr 2, 2018 at 12:26 PM, Marty Strong via NANOG <nanog@nanog.org> 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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype)
https://www.peeringdb.com/asn/13335
On 2 Apr 2018, at 16:16, Jason Kuehl <jason.w.kuehl@gmail.com> 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 < mattlists@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 <darin.steffl@mnwifi.com> 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 <lists-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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 <http://www.facebook.com/minnesotawifi> Like us on Facebook <http://www.facebook.com/minnesotawifi>
-- Sincerely,
Jason W Kuehl Cell 920-419-8983 jason.w.kuehl@gmail.com
Hello, On Mon, 2 Apr 2018 16:26:13 +0100 Marty Strong via NANOG <nanog@nanog.org> 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
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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype) https://www.peeringdb.com/asn/13335
On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン) <rol@witbe.net> wrote:
Hello,
On Mon, 2 Apr 2018 16:26:13 +0100 Marty Strong via NANOG <nanog@nanog.org> 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
Still believe in santa ? ;-) Good luck with that. Best regards. 2018-04-03 8:37 GMT+02:00 Marty Strong via NANOG <nanog@nanog.org>:
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 marty@cloudflare.com +44 7584 906 055 smartflare (Skype)
https://www.peeringdb.com/asn/13335
On 3 Apr 2018, at 07:22, Paul Rolland (ポール・ロラン) <rol@witbe.net> wrote:
Hello,
On Mon, 2 Apr 2018 16:26:13 +0100 Marty Strong via NANOG <nanog@nanog.org> 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
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-bounces@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&T 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-nanog@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&T'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&T through the standard customer support channels (for reasons that should be obvious to anyone who has ever called AT&T's consumer/residential technical support) but if anyone at AT&T 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&data=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128&sdata=Uwca5B1Fg0YSPmAwLRM63MGE%2BSBD8bTN%2FoGcVCvpUyc%3D&reserved=0 507-634-WiFi <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2Fminnesotawifi&data=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128&sdata=W4P%2BUzI82FABcW8sAkxaGNM2FJmVLmrix58KVgdxax0%3D&reserved=0> Like us on Facebook <https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.facebook.com%2Fminnesotawifi&data=02%7C01%7C%7C44b0d324ba284c19f9b108d598ab2d27%7C453303889ca9424bbe1a29721272041d%7C1%7C0%7C636582783328080128&sdata=W4P%2BUzI82FABcW8sAkxaGNM2FJmVLmrix58KVgdxax0%3D&reserved=0>
participants (38)
-
Alan Buxey -
Alejandra Moreno -
Andrey Slastenov -
blakangel＠gmail.com -
Brett Watson -
Brielle Bruns -
Chris Adams -
Chris Gross -
Colin Johnston -
Daniel Dent -
Darin Steffl -
David Conrad -
David Hubbard -
Florian Weimer -
George Skorup -
Hank Nussbacher -
James R Cutler -
Jason Kuehl -
Jeremy L. Gaddis -
Job Snijders -
John Levine -
John R. Levine
-
Justin Wilson -
Mark Andrews -
Marty Strong -
Matt Hoppes -
Mike Hammett -
mike.lyon＠gmail.com -
nop＠imap.cc -
Paul Rolland (ポール・ロラン) -
Rhys Williams -
Rubens Kuhl -
Saku Ytti -
Seth Mattinen -
Simon Lockhart -
Stephen Satchell -
Tore Anderson -
Youssef Bengelloun-Zahr