6 ms·

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

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?

wmil 3y ago
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.
ranger207 3y ago
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
micw 3y ago
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").
- flyinghamster 3y ago
  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.
  - o11c 3y ago
    mDNS drafts actually date back to around 2000, which AFAICT precedes Microsoft's use.
    - mjcl 3y ago
      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 https://www.uv.es/martineu/ad/bibliaAD.pdf
nicholasjarnold 3y ago
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 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.
RiverCrochet 3y ago
> 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.
- bluGill 3y ago
  > 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.
  - iscoelho 3y ago
    This is not correct. RFC6598 defines CGNAT IP space as 100.64.0.0/10 (https://datatracker.ietf.org/doc/html/rfc6598 https://datatracker.ietf.org/doc/html/rfc6598). RFC1918 (private IP space) is a different allocation.
    - 3y ago
Hikikomori 3y ago
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.
throw0101d 3y ago
> 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.)
formerly_proven 3y ago
> 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).
cesarb 3y ago
> 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.
- bluGill 3y ago
  > 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.
  - iscoelho 3y ago
    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.
    - ArchOversight 3y ago
      > 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.
denkmoon 3y ago
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.

wmil 3y ago

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.

ranger207 3y ago

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

micw 3y ago

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").

flyinghamster 3y ago
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.
- o11c 3y ago
  mDNS drafts actually date back to around 2000, which AFAICT precedes Microsoft's use.
  - mjcl 3y ago
    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 https://www.uv.es/martineu/ad/bibliaAD.pdf

nicholasjarnold 3y ago

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 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.

RiverCrochet 3y ago

> 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.

bluGill 3y ago
> 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.
- iscoelho 3y ago
  This is not correct. RFC6598 defines CGNAT IP space as 100.64.0.0/10 (https://datatracker.ietf.org/doc/html/rfc6598 https://datatracker.ietf.org/doc/html/rfc6598). RFC1918 (private IP space) is a different allocation.
  - 3y ago

Hikikomori 3y ago

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.

throw0101d 3y ago

> 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.)

formerly_proven 3y ago

> 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).

cesarb 3y ago

> 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.

bluGill 3y ago
> 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.
- iscoelho 3y ago
  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.
  - ArchOversight 3y ago
    > 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.

denkmoon 3y ago

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.