Hacker News Reader

Comment by whartung | Hacker News Reader

I don't understand how this will work.

The "magic", as I understand it, of the 192.x.x.x network is that the Internet "knows" to not route it. Networking isn't my strength, so I don't know where, or what part of the my local network decides that 192.x.x.x can't be routed, and so doesn't. (I guess it's the router at the edge, but I don't know about internal routers.)

But anyway, however it's manifest, the "magic" of it is that 192 is "safe" because, at the assorted gateways that are emplaced on the Internet, that traffic just "stops".

So, how does ".internal" work? I mean, it's just a hostname, and DNS responds to queries about hostnames.

Would it work similarly where the DNS server "knows" where a request came from, and thus, "knows" that "oh this is internal traffic, so if they're asking for an .internal domain name, I can safely respond the appropriate IP"?

Is that how this supposed to work? Is that where the magic happens?

View on HN

> The "magic", as I understand it, of the 192.x.x.x network is that the Internet "knows" to not route it. Networking isn't my strength, so I don't know where, or what part of the my local network decides that 192.x.x.x can't be routed, and so doesn't.

First of all, it's 192.168.x.x, there are other networks which begin with 192 and are not treated as internal networks.

The trick is simple: it's not "the Internet knows to not route it", it's "the Internet doesn't know how to route it". These ranges (there are others, like 10.x.x.x) are reserved for private use, and will never be allocated for an Internet network. Since there's no network announcing it (and if some network mistakenly tries to announce a route to these addresses, they will be filtered since everyone knows there shouldn't be routes for it), any attempt to send a packet to it will go nowhere.

> they will be filtered since everyone knows there shouldn't be routes for it

That is why they know they can filter it. However the reason they bother is they often are using those addresses internally in their data center and so if someone else announces it their local network would break.

This is not a correct assumption.

1. RFC1918 space is not "filtered". It is unroutable, because no route exists on the internet.

1a. Effectively, this is the same result, however it is still an important distinction to note: telecom networks rarely ACL or "filter" transit traffic without a) an associated service offering (like DDoS Mitigation) b) a customer request or c) RPF.

1b. Telecom networks do however filter transit routes. RFC1918 routes would be filtered on internet BGP sessions.

2. It is infrequent that RFC1918 space is used internally in telecom networks. It does happen, but it is rare.

> 2. It is infrequent that RFC1918 space is used internally in telecom networks. It does happen, but it is rare.

I have worked at 2 different ISPs... RFC1918 is used EVERYWHERE, including on networks that customers can reach by sending packets through their modems/CPE. I am also familiar with the internal network of 3 others because we closely worked together during a bunch of merger/acquisitions/divestments/territory split-ups.

This caused a lot of fun when one customer ran nmap across all of RFC1918 space and hit internal security systems that were advertised across the ISPs backbone but were not properly filtered for traffic coming from customers because of a bug in a CMTS that failed to properly apply ACL's.

A lot of telecoms avoid it like the plague because: 1. it destroys network observability 2. they have so much IP space they don't even know what to do with it. /30 everything!

Management networks are a different story, but hey, some Tier 1's think they're so large they don't even need OOB anymore! (haha...)

RFC1918 space is perfectly routable, and it is routed all the time.

The fact that is is not routed throughout Internet is another thing.

It's implied in my message that I'm referring to the internet: "It is unroutable, because no route exists on the internet."

> Networking isn't my strength, so I don't know where, or what part of the my local network decides that 192.x.x.x can't be routed, and so doesn't.

It's a standard that is "enforced" in two places I think:

* Place 1: ISPs configure their carrier-grade routers to drop it if they receive it.

Technically, there really is nothing stopping an ISP from actually routing it, just like there is nothing preventing you from assigning an already-assigned address like one of Google's to a NIC in your LAN.

But ...

* Place 2: Internet registries won't give out IP blocks in these ranges. So no ISP can make an AS that has routes for these addresses.

Technically again, there really is nothing stopping a registry from assigning something in the block. Imagine if someone bribed a registry to give them out. These assignments are basically what makes the global BGP table that is the "top layer" routing information for the Internet.

But:

A) all registries would have to cooperate at once for it to be globally reachable - ARIN, RIPE, APNIC, AFRNIC, and LACNIC - and current geopolitics would almost guarantee that wouldn't happen. IPv4 space is scarce and valuable, so they'd really fight over it, and

B) everyone is already using it for private IP space anyway, so even if you hosted something on a publicly accessible 192.168.1.1, no one would be able to reach it due to existing configs and assumptions, so it would be pointless.

> So no ISP can make an AS that has routes for these addresses.

A lot of ISPs are using these addresses internally as part of a carrier grade NAT since there are not enough IPv4 addresses to go around. So they do give them out, they just don't route them except through their NAT system, and they wouldn't want to route them as any effort would break their system.

Of course some ISPs have more IPs free than others.

This is not correct.

RFC6598 defines CGNAT IP space as 100.64.0.0/10 (https://datatracker.ietf.org/doc/html/rfc6598). RFC1918 (private IP space) is a different allocation.

> RFC6598 defines CGNAT IP space as 100.64.0.0/10

That's a relatively recent RFC; there are ISPs which have been using CGNAT for longer than that, and they do use RFC1918 addresses for their CGNAT (for instance, I know of one which used something in the 10.x.x.x range for CGNAT, which works in practice since most domestic networks use something in the 192.168.x.x range).

I'm familiar with CGNAT mostly on Cellular Networks. VZW (debatably largest CGNAT in USA?) uses RFC6598.

I'd be surprised (but not too surprised honestly) if the other ones haven't cleaned up the skeletons in their routers yet.

Squatting on DoD IP space was also the norm for an ISP I worked at...

Some people just want to watch the world burn.

The "magic" is that the TLD is reserved for internal use. Before, people used different domains like ".lan", ".local". Problem with those is that it can happen at any time that one of these becomes a valid TLD which can cause a lot of unexpected side effects (starting from "cannot reach somenicepage.lan because my local DNS resolved *.lan" to "someone registered server.lan and can not issue valid SSL certificates for my internal service").

Indeed, that has certainly happened to .local, which Microsoft once recommended using for internal purposes - before mDNS came about and .local wound up being used for mDNS instead.

mDNS drafts actually date back to around 2000, which AFAICT precedes Microsoft's use.

It's around the same time, I think. Windows 2000 & Active Directory were released in February 2000; MS training materials would have been released around the same time. I found at least one book[1] published in the year 2000 that discussed using .local as a private TLD.

[1] https://www.uv.es/martineu/ad/bibliaAD.pdf

The way DNS works, if a local resolver doesn't have the record for a domain name, then it'll ask a higher level resolver. This proposal says that .internal will never be added to those higher level resolvers so if your local resolver doesn't have a record for a .internal hostname then locally that hostname doesn't exist

The internet and routers doesn't do anything magic about internal network ranges, it's just a route like any other. What matters is how you configure the router and the routing protocols. An ISP can have internal routes advertised between their routers, at your edge you typically filter to only advertise your assigned ranges/supernets, ie 101.0.0/16 rather than all the small subnets they split it up to. They could also decide that internal ranges are filtered everywhere in their network.

> So, how does ".internal" work? I mean, it's just a hostname, and DNS responds to queries about hostnames.

I don't think this is the normative intent but you could certainly say that this TLD is reserved for use with the private IP range. That would mean that a) local resolvers would not forward requests to internet resolvers and b) local resolvers can reject records pointing to non-local IPs. That's not suuuper useful because you wouldn't get an answer anyway.

What would've been useful roughly 40 years ago is for ICANN to do something like this and also say "oh, and btw., domains under internet TLDs CANNOT resolve to non-internet (local, private) IPs". That would've preempted DNS rebinding and all related attacks.

It's of course impossible to do now because the "best practice" for the last ~15 years has been to register an internet domain and then use it for your internal network because there are no private TLDs and any TLD you come up with might be registered by someone else and suddenly become attacker-controlled over night (troublesome because now VPN leakage, which none of the Expensive Enterprise Client VPNs address, allows someone not-you to easily and globally impersonate you for leaked traffic and it's not even a rebinding attack in the narrow sense).

Arguably the "Old Guard" of IP networking did "a little oopsie whoopsie" with their "Thou shalt have no other networks before me, IP, your god" commandment (the idea that the IP stack exists to support exactly one network, the internet).

I think it's just reserving .internal for that use. So a network admin has a guarantee that he'll never have to deal with an external .internal domain.

Whereas something like .pri for private might one day be set up as a new TLD.

How this works is that .internal never appears in the root DNS servers, it's that simple.

Then, in my private DNS on my private network I create an authoritative .internal zone.

afaik the IANA is the body who is authoritative on this type of information. RFC1918[0] defines the address blocks reserved for private routing. From there it's up to various routers and their software to decide whether or not to actually flow the packets over their interfaces or not.

[0] https://www.rfc-editor.org/rfc/rfc1918.html

edit: I think I read the parent slightly incorrectly. I conflated TLD assignment with number assignment. Apologies.

> The "magic", as I understand it, of the 192.x.x.x network is that the Internet "knows" to not route it.

The Internet, at the end of the day, is not about technology, but an agreement: I send you traffic and you move it around, and you send me traffic and I move it around.

We all agree to use the same protocols (IP, BGP) and so can talk to each other, and the moving of bits can either be on a paid (ISPs) basis or non-paid (IXPs) basis.

As part of this everyone agrees to not move certain addresses (RFC 1918), and if they come across any, they filter/drop them as soon as possible.

Another part of this agreement is various vendors agree to the same rules, so your home firewall/router (Linksys, D-Link, Asus) acts in certain ways, which includes making sure that any traffic from (e.g.) 192.168/16 does not go out the interface labelled "WAN". (Though if it does, your ISP also agrees to filter it.)

Reply on news.ycombinator.com