Hacker News Reader

Comment by mischov | Hacker News Reader

1.1.1.1 was working for me on AT&T after Cloudflare released 1.1.1.1, then shortly after that it ceased working.

Maybe the firmware update has a bug, but it's very suspiciously timed. Notice that the OP is dated April 2, while 1.1.1.1 was released April 1.

View on HN

This is what happened to me as well. It worked for a day or so and then stopped.

I have ATT U-verse internet service and use their Arris BGW210-700 gateway

One interesting thing is that if I go to the gateway management page, and use their diagnostic tools, I'm able to ping / traceroute the address - but I can't from any devices connected to the gateway

From gateway diag page:

PING 1.1.1.1 (1.1.1.1): 56 data bytes 64 bytes from 1.1.1.1: seq=0 ttl=64 time=0.568 ms 64 bytes from 1.1.1.1: seq=1 ttl=64 time=0.156 ms 64 bytes from 1.1.1.1: seq=2 ttl=64 time=0.164 ms 64 bytes from 1.1.1.1: seq=3 ttl=64 time=0.144 ms

--- 1.1.1.1 ping statistics --- 4 packets transmitted, 4 packets received, 0% packet loss round-trip min/avg/max = 0.144/0.258/0.568 ms

traceroute to 1.1.1.1 (1.1.1.1), 30 hops max, 38 byte packets 1 1dot1dot1dot1.cloudflare-dns.com (1.1.1.1) 0.285 ms 0.177 ms 0.090 ms

The times on the pings make it look like its hitting a loopback address instead. Pings to 8.8.8.8 from the diagnostics page take about 23 ms. No way 1.1.1.1 is completing in under 1ms haha

Yes, 1.1.1.1 is in use on your Arris device, the same issue with the 5268AC since day one.

A possible explanation is that the traffic from active use of 1.1.1.1 caused some backend service to get overloaded with traffic due to a faulty assumption that the address would never be used by customers. Anyone keep traceroutes while before the patch to see if there were errant stops or delays?

They had the choice of "fix the whole backend" or "block 1.x on the user end".

Guess we know which one was easier. If all this wild speculation is true, maybe they're working on a fix to the root cause and will roll back the patch when complete.

This would make the situation both due to incompetence and intentional.

1.1.1.1 is well known (based on the announcement from cloudflare anyway) to have tons of random traffic. That's part of the reason it wasn't implemented by others as a valid address for anything. Could the fact that they're simply allowing traffic at that address cause additional stress on AT&T's network?

I ask because I don't know. I figure any traffic headed that direction would go anyway it just wouldn't get routed very far with no valid destination.

Yeah. And there's also a lot of traffic going in Facebook's direction, for example. Hey, let's blackhole that too - and alleviate the stress on our network that comes from people using it. (In non-sarcastic tone: that doesn't make any sense.)

Based on what I understand, the amount of traffic headed to 1.1.1.1 is much more significant. I agree with you though, that wouldn’t be justification to block it. It looks like they’re also blocking 1.0.0.1 and the relevant ipv6 addresses which shouldn’t have the same traffic issue.

I doubt it's all that significant, it's a really small portion of traffic compared to a web page, javascript, css or images... and with caching even less of an impact.

The problem isn’t DNS traffic. The problem is that for years people have been using 1.1.1.1 in the configuration of software and devices when they didn’t have an up address to configure. The result is that when 1.1.1.1 becomes routable all that additional traffic flows there and AT&T along with other provides carries that traffic. I was wrong that AT&T was blocking it for honorable reasons but this is a still a significant amount of traffic.

If they were so determined to block it, why would they do it in firmware and not upstream? I think people are reading too much into this.

It's cheaper to do it on the mobile?

I was using 1.1.1.1 with AT&T Fiber and it stopped working. I didn't really question it, I figured maybe something went down at Cloudflare so I just switched my Mac back to using the defaults again. It never even occurred to me that AT&T might be blocking it.

Maybe stupid question, but why would AT&T block it?

They want you using their DNS for traffic snooping?

Pretty sure they don't block 8.8.8.8 though.

They can snoop on your DNS anyways.

Not with DNS over TLS. EDIT: Which CF supports.

So does Google DNS (using DNS-over-HTTPS), yet they haven't been blocked.

Same thing happened to me using at&t fiber.

A few others have mentioned this already, but 1.1.1.1 has become a colloquial private address, used either as a blackhole or as a destination for internal traffic. Sort of like how 555-5555 technically isn't reserved (only 555-01xx is, according to Wikipedia), but practically, it's not really a workable number and phone companies don't hand it out.

According to the announcement post, part of the reason that Cloudflare was allocated the 1.1.1.1 address is that they were ready and willing to handle the expected inundation of all kinds of bizarre traffic.

It seems that one of those "off-label" uses of 1.1.1.1 is an internal / network control interface on [some?] AT&T networks. I'm just speculating, but it's definitely possible that 1.1.1.1 suddenly becoming publicly routable and pointed to a real thing caused some problems. "Patch it out" may be an acceptable emergency response depending on the breakages, but not really acceptable long-term.

Not an acceptable thing to do silently though, in any term.

and the reports of 1.0.0.1?

Reply on news.ycombinator.com