Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

AT&T updates firmware to block access to 1.1.1.1

dslreports.com

Post reply on HN
Print view View original

81–90 of 382 posts

Re: AT&T updates firmware to block access to 1.1.1.1

#81

Post by derekp7 »

wrigby wrote: post #62
derekp7 wrote: post #43

Earlier quoted context omitted.

Whenever I've needed IP ranges for similar purposes (i.e., default IPs for container or VM internal / private networks) I've used ranges from RFC 5737 (192.0.2.0/24, 198.51.100.0/24, and 203.0.213.0/24). These are for reserved for documentation purposes, so it is highly unlikely that a customer would have these going in their own internal network. Not the best solution, but better than tying up a public /24 that we o…

We used to use RFC1918 (172.16/12 IIRC) addresses for the communication between internal nodes in a cluster-in-box system that I worked on, which worked great until we had a subnet collision on a customer's network. Leaves me wondering if link-local (169.254/16, fe80::/10) would have been a better option - while technically the customer could decide to make the external (customer-facing) network have a link-local int…

BTW, for those wondering what this particular failure scenario is: Let's use Docker's default 172.17.0.0/16 subnet as an example. So your docker host has iptable DNAT rules that routes a given "external" IP address (10.0.1.15) to a given docker container (172.17.25.92). That works great, unless you have a workstation on a subnet such as 172.17.81.0/24. When that workstation sends a packet to 10.0.1.15, that packet gets routed to the destination container 172.17.25.92. That container goes to reply, but the reply packet never makes it out to the original workstation because the container host thinks it is bound for something else on its version of the 172.17 subnet.

One workaround to this is to have the container host also put in an SNAT rule, so that anything that it forwards to a container would have the source IP address re-written to appear to come from the container host's IP, or the docker0 bridge IP (172.17.0.1/16)

Re: AT&T updates firmware to block access to 1.1.1.1

#82

Post by sarah180 »

bowersbros wrote: post #64
gaadd33 wrote: post #59

Earlier quoted context omitted.

I like to use 33.0.0.0/8 for that stuff since I don't believe any of those IPs are available on the open internet.

I can't see anything about the 33.0.0.0/8 range being reserved https://en.wikipedia.org/wiki/Reserved_IP_addresses

33.0.0.0/8 belongs to the Department of Defense. https://whois.arin.net/rest/net/NET-33-0-0-0-1/pft

Re: AT&T updates firmware to block access to 1.1.1.1

#83

Post by droopybuns »

jaas wrote: post #71

I'd say there is a 98% chance this is a bug in some firmware and a 2% chance AT&T is intentionally trying to block Cloudflare DNS. I get why people are paranoid about ISPs blocking content and net neutrality, but let's not cry wolf prematurely. The technical details here strongly suggest a bug rather than intentional blocking of 1.1.1.1 DNS traffic.

Can someone link to the firmware? It shouldn't be hard to binwalk this and figure out wtf is happening.

Also- If this was intentional- I'm betting they'd filter it for the mobile network as well. This has got to be a fuck-up.

Re: AT&T updates firmware to block access to 1.1.1.1

#84

Post by bbayles »

jaas wrote: post #71

I'd say there is a 98% chance this is a bug in some firmware and a 2% chance AT&T is intentionally trying to block Cloudflare DNS. I get why people are paranoid about ISPs blocking content and net neutrality, but let's not cry wolf prematurely. The technical details here strongly suggest a bug rather than intentional blocking of 1.1.1.1 DNS traffic.

You're absolutely right about this. This is almost certainly just there to block people who mistakenly paste in an example configuration somewhere.

Back in 2010 there were problems that came up when IANA started allocating out of 1.0.0.0/8 (e.g. [1]). Things that were once assumed to be unused started being used, leading to strange issues.

Also, why on earth would AT&T block 1.1.1.1 and not Google DNS and OpenDNS?

[1] https://bgpmon.net/issues-with-allocating-from-1-0-0-08/

Re: AT&T updates firmware to block access to 1.1.1.1

#85

Post by dingo_bat »

Good. If cloud fare is allowed to block sites from their hosting service based on opinions, then att should be allowed to do the same. Also fuck cloud fare for choosing 1.1.1.1 when any network engineer worth his salt would have told them it's going to cause problems. There are things like conventions and traditions, you break them at your own peril.

Re: AT&T updates firmware to block access to 1.1.1.1

#86

Post by loeg »

bowersbros wrote: post #64
gaadd33 wrote: post #59

Earlier quoted context omitted.

I like to use 33.0.0.0/8 for that stuff since I don't believe any of those IPs are available on the open internet.

I can't see anything about the 33.0.0.0/8 range being reserved https://en.wikipedia.org/wiki/Reserved_IP_addresses

https://www.iana.org/assignments/ipv4-address-space/ipv4-add...

It's allocated to "DLA Systems Automation Center," a branch of the US military. The addresses are probably used on NIPRNet/SIPRNet, but not publically routed. (Much like 22.0.0.0/8.)

Re: AT&T updates firmware to block access to 1.1.1.1

#87

Post by jjeaff »

jaas wrote: post #71

I'd say there is a 98% chance this is a bug in some firmware and a 2% chance AT&T is intentionally trying to block Cloudflare DNS. I get why people are paranoid about ISPs blocking content and net neutrality, but let's not cry wolf prematurely. The technical details here strongly suggest a bug rather than intentional blocking of 1.1.1.1 DNS traffic.

Then the odds appear to not be in our favor.

CF CEO tweets that 1.0.0.1 is also blocked.

https://twitter.com/eastdakota/status/991718955021623296

Others have confirmed that the ipv6 address belonging to CF appears to be blocked.

Re: AT&T updates firmware to block access to 1.1.1.1

#88

Post by sjwright »

jaas wrote: post #71

I'd say there is a 98% chance this is a bug in some firmware and a 2% chance AT&T is intentionally trying to block Cloudflare DNS. I get why people are paranoid about ISPs blocking content and net neutrality, but let's not cry wolf prematurely. The technical details here strongly suggest a bug rather than intentional blocking of 1.1.1.1 DNS traffic.

Having it seem like a bug would be an effective way to block it intentionally. The timing of such an unusual regression is suspicious. The fact that 1.0.0.1 is also blocked is also suspicious.

Re: AT&T updates firmware to block access to 1.1.1.1

#89

Post by dilap »

mabbo wrote: post #8

I wonder if anyone has considered some sort of legislation whereby internet service providers are not allowed to block or disrupt service to certain parts of the internet in order to promote their own business model.

NN seems like probably a good idea, but it's crazy to me how the whole internet went crazy over something with at-most marginal effects, but barely a peep over FOSTA which has already taken out vast swathes of valuable websites, craigslist personals perhaps most notably.

Re: AT&T updates firmware to block access to 1.1.1.1

#90

Post by jjeaff »

stefan_ wrote: post #45
bb88 wrote: post #21

Earlier quoted context omitted.

Because as it stands right now, AT&T sells you access to their network. What happens on their network is for AT&T to decide. With the FCC striking down net neutrality [1], AT&T is probably testing out the waters. [1] According to google, it's defined as: "the principle that Internet service providers should enable access to all content and applications regardless of the source, and without favoring or blocking partic…

If you can construe some horizontal where Cloudflare and AT&T are competitors it could of course still be illegal for AT&T to block the others services simply under antitrust law.

I'm sure ATT has cdn or similar services.
Post reply on HN