AT&T updates firmware to block access to 1.1.1.1 • Hacker News Board

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

#131

Post by tuna-piano » Thu, May 03, 2018, 2:14 AM UTC

Here is the original Cloudflare post on what 1.1.1.1 is [1]. For those who don't know, 1.1.1.1 is Cloudflare's privacy focused DNS service. That means that when you type in www.google.com, that URL can be sent to 1.1.1.1, and then 1.1.1.1 resolves that URL an IP address and send the IP back to the user. All user requests are then sent to the IP address, not the URL. Supposedly this is better than using the DNS server of ATT+Comcast, because ATT+Comcast want your browsing history while Cloudflare does not.

What I don't understand is how this really helps user privacy much. If AT&T, Comcast, etc want to know your browsing habits, can't they still see the IP addresses you're browsing and figure out the URL from the IPs? I can't see that as too big an impediment, but maybe someone with more knowledge can share.

[1] https://blog.cloudflare.com/announcing-1111/

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

#132

Post by fyfy18 » Thu, May 03, 2018, 2:14 AM UTC

derekp7 wrote: post #81

wrigby wrote: post #62

Earlier quoted context omitted.

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 ge…

On a similar note, Docker for Mac assigns (or used to?) the IP address 192.168.99.100 to the VM that runs Docker. One day I was working in a coffee shop and got really confused as to why I couldn’t connect to my application, even though the server was running. Then I realised the coffee shop WiFi was using 192.168.99.0/24 for client IPs.

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

#133

Post by colordrops » Thu, May 03, 2018, 2:16 AM UTC

bb88 wrote: post #14

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.

The argument I've made is that if they're blocking certain parts of the internet, then they shouldn't be allowed to call themselves an Internet Service Provider.

Do you think anyone will notice or care if Spectrum or Verizon stops using the term ISP to describe themselves?

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

#134

Post by kbaker » Thu, May 03, 2018, 2:17 AM UTC

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…

IPv6 Unique Local Addressing is made for this scenario, with a low chance of collisions. fd: + 40 random bits, becomes your new /48.

https://tools.ietf.org/html/rfc4193

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

#135

Post by ben1040 » Thu, May 03, 2018, 2:17 AM UTC

IshKebab wrote: post #107

js2 wrote: post #75

This is likely due to incompetence, not malice. FWIW, it’s possible to bypass AT&T’s router: https://github.com/jaysoffian/eap_proxy That said, I tried 1.1.1.1 and found I had to switch back to Google DNS since Cloudflare intentionally doesn’t support EDNS Client Subnet which was causing my AppleTV’s to have trouble loading content.

Can you not just put the router in bridge mode and use a different sane one? In the UK Virgin forces you to use their moderately shit modem/router, but even that lets you use bridge mode.

The AT&T gateway doesn't offer a bridge mode.

The best you get is a "passthrough" mode where a router behind it will get assigned the public-facing IP so it doesn't ultimately behave like double-NAT, but the gateway still maintains an internal NAT table for everything going across.

You can't just use your own VDSL modem or plug your own router into the fiber ONT, as AT&T uses 802.1x auth and the key is burned into the gateway hardware.

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

#136

Post by noobermin » Thu, May 03, 2018, 2:19 AM UTC

jopsen wrote: post #49

noobermin wrote: post #12

Earlier quoted context omitted.

How is this not illegal?

Let's give them the benefit of the doubt, it's probably incompetence ;)

Low in the thread but is this a possibility?

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

#137

Post by walrus01 » Thu, May 03, 2018, 2:19 AM UTC

There are an astonishing number of corporate end users also using "unused" chunks /8 sized of IP space internally. As if rfc1918 wasn't big enough.

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

#138

Post by Abishek_Muthian » Thu, May 03, 2018, 2:20 AM UTC

Anyone else facing such issues with their ISP for 1.1.1.1 ?

Cloudflare DNS seems to be down for couple of major ISP's in India as well according to CF forums -

[ACT] https://community.cloudflare.com/t/cloudfare-dns-blocked-wit...

[Airtel] https://community.cloudflare.com/t/cloudflare-dns-not-workin...

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

#139

Post by ben174 » Thu, May 03, 2018, 2:24 AM UTC

tuna-piano wrote: post #131

Here is the original Cloudflare post on what 1.1.1.1 is [1]. For those who don't know, 1.1.1.1 is Cloudflare's privacy focused DNS service. That means that when you type in www.google.com, that URL can be sent to 1.1.1.1, and then 1.1.1.1 resolves that URL an IP address and send the IP back to the user. All user requests are then sent to the IP address, not the URL. Supposedly this is better than using the DNS server…

Got a link to the original hacker news article by chance? I’d like to see the comments

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

#140

Post by exabrial » Thu, May 03, 2018, 2:24 AM UTC

twexler wrote: post #103

exabrial wrote: post #51

File FCC complaints! This sorry if thing will definitely get a response.

No it won't. The FCC doesn't work for the the citizenry anymore, just for lobbyists.

I find the sappy, defeatest, whiney attitude with the FCC useless. File them if you're affected. They're cataloged and can be used as evidence in the future. The current administration is certainly against regulation, but blocking a DNS provider is an escalation. More than likely, this block is due to incompetence. My guess is ATT was using the IP internally for some purpose and is now getting DDOS'd.