On that note, I should answer their question: Was this article helpful? with No.
For example, when I look up google.com and then reverse-lookup the IP address, I get sfo07s13-in-f14.1e100.net (you'd get something different depending where you are). The name sfo07s13-in-f14 could tell someone where to look if that machine is misbehaving.
If they'd named it sfo07s13-in-f14.google.com, then browsing to that URL sends google cookies. If it's some server from a recent acquisition that may not be up to Google's level of security, that's dangerous.
Even fairly small companies are well-advised to have a domain name for their brand and a separate domain name for their infrastructure.
google.com -> subdomain.1e100.net -> server IP address
rDNS: server IP address -> subdomain.1e100.net
Is this the correct understanding?
But don't you already have the IP address of the misbehaving machine?
The name sfo07s13-in-f14 is mnemonic to Google engineers -- it's probably in San Francisco data center 7. Also, that server probably has both an IPv4 and IPv6 address. Also, sometimes IP addresses change but you want servers to keep their identity. So names are convenient.
You can also embed other information in the reverse name, such as the region, datacenter, floor, switch, rack, or unit number of the machine. It can be incredibly easy to locate the machine by just looking at its reverse name. "Oh, 1.2.3.4 is in us-east-1, on floor 3, in rack 27, unit 5. Let me go check the network cable."
a) your public web presence, www.widgets.com for marketing, sales, customer web portal, customer billing, and so forth.
b) your domain name used for public reverse DNS for your ARIN, RIPE, APNIC etc IP space, for an ISP that has its own AS, such as as12345.net. This is the function that the 1e100 domain serves for Google.
c) your internal domain name that is used by your management network to address every piece of network equipment, hypervisor, virtual machine and so forth. This could be something like "widgets.internal". The company internal DNS servers that never touch the public Internet will be authoritative master/slave for this, and your intranet clients will be set up to query these DNS servers. Your reverse DNS for all of your RFC1918 IP space (10.x, 172.16.x, 192.168.x, etc) will have forward/reverse matches for everything that you manage and monitor in your network, so that automated tools can crawl the network and auto discover/auto-provision new equipment.
Internet users outside of your intranet will never see item C, but it definitely exists in a lot of companies' infrastructure.
Struggling to remember why, but I heard people mad about .local
The recommended practice, AFAIK, is to register a public domain for the purpose. See the recent HN discussion of .home.arpa for all the reasoning and arguments and counter-counter-counter-points.
So far I've read you suggest .taco, .burrito, and .burritocorp as good TLDs to pick. This is terrible advice.
Purchase a public domain name from a real TLD - use it knowing it's yours, and never going to conflict.
Typically the name would be something relevant to your needs, such as the name of the company, or AS number. I think what you don't get is that the public root name servers do not need to have anything to do with an entirely internal dns infrastructure.
Not suggesting icann is going to crash and burn either, but that "real" TLD relevance to what you do in rfc1918 IP space in a network that is not routed to the internet is minimal at best.
Bet you $5 that Google's actual internal dns for the oob, SNMP management, automated provisioning tools which control those 1e100 hosts is not 1e100, and is not a zonefile you can find cached anywhere public. They built their own internal dns for it. Have seen the same at two large CDNs. Their internal authoritaive DNS servers for their management IP space have no connection whatsoever to the public internet or to the lettered root nameservers.
1.1.1.1 wasn't part of the internet either, and, guess what it does today?...
> and is not a zonefile you can find cached anywhere public
You seem to be conflating owning a legitimate domain name for the purpose of internal use with making the DNS records from that domain's zone public. One does not imply the other.
Buy the domain, know you will never conflict with something, and you're done (bar renewal!).
I'm trying to picture a co-worker telling the team they went ahead and put all the management interfaces in the .burrito domain in order to save the company $10 in domain registrar fees.
Namespaces are abstract things that exist outside of the realm of actual network connectivity, and enable you to plan for all kinds of hypotheticals.
See: http://www.mdmarra.com/2012/11/why-you-shouldnt-use-local-in...
On a large scale for all internal stuff you are going to have your own, internal root and intermediate CA. The root CA signs the intermediate CA, the intermediate CA then signs SSL/TLS certificates for your internal infrastructure things.
As an example for a mid sized ISP with such a setup, the internal ticket portal for the NOC is accessible only while physically in the office or when on the VPN, speaks TLS1.2 only to standard web browser clients, and its URL is https://portal.tickets.burrito
where the "burrito" is obviously not the real name, I've changed it for this example, but the choice of TLD in your own internal DNS infrastructure is totally arbitrary.
Then the individual clients all have the public certs for the internal corporate root and intermediate CA installed in them, so that they trust certificates signed by the internal CA.
If you're big enough to care about having a serious multi-state-scale intranet, you probably don't want to be reliant upon external CAs to sign your stuff. Having your own internal CAs lets you do a lot of other things as well, without additional cost, such as sign per-client-device certificates as well.
Currently, the only reserved TLDs are:
- [RFC 6761] example
- [RFC 6761] invalid
- [RFC 6761] localhost
- [RFC 6761] test
- [RFC 6762] local
- [RFC 7686] onion
With the exception of localhost, local, and onion, these can be used without any worry about future use. Any others should be considered real TLDs and not be used unless you actually own the domain name under that TLD.
[RFC 6761]: https://tools.ietf.org/html/rfc6761
[RFC 6762]: https://tools.ietf.org/html/rfc6762
[RFC 7686]: https://tools.ietf.org/html/rfc7686
Let's say I have an ISP named Burrito Corporation.
I want to uniquely address equipment in my private management IP space VRF and have a proper hostname for every piece of equipment, both for "forward" and rDNS.
It's a pretty common setup to have internal BIND servers which are authoritative master/slave for the TLD .burritocorp , which also have an ACL allowing the internal IP space (10/8, etc) to query them. Then set up all internal DNS stub resolvers/client devices to query those servers.
Now I have a core POP in Toronto and I've decided to use airport codes for site names, so the internal management IP interfaces for things at that site might get a hostname which is hierarchically contained under yyz01.ca.burritocorp
It is unlikely in the extreme that ICANN is ever going to create a TLD named "burritocorp".
I am not suggesting that people go and try to use self-created TLDs for things that have real world IPs in the global BGP4 routing table. See section 6.1 of RFC6761.
For example, my username is enzanki_ars. Let's say I set up enzanki.ars at home as a host for an in home only server. Now let's say that a new country registers .ars as a new TLD, for example Argentina as ARS is the ISO 4217 currency code for the Argentine peso. Now I am stepping over someone else's TLD, an someone could even register enzanki.ars before me and start using it.
My personal policy is "just because you can doesn't mean you should." If I wanted to disrespect the process we have in place to prevent people from stepping over other people's domains, I would have set up enzanki.ars already. Until then, 192.168.0.0/16 is how I reference my hosts at home.
Edit: See also: https://www.iana.org/assignments/special-use-domain-names/sp... for an up to date list of special use domains. "home.arpa." was recently assigned as one, and I may start using that one at home.
With a totally internal DNS setup it doesn't matter even if ICANN does decide to create a ".ars" TLD someday. In such a theoretical setup, your clients are all querying your own internal DNS servers, and you are not publishing or pushing anything to the root nameservers. Your use of internal hostnames and rDNS for ".ars" internally does not conflict with or hurt anybody's use of their own domains in the real-world .ars out on the public Internet, and neither does their use of the domain affect your non-internet-connected management network. There is no "stepping over other domains".
And in the usages of 1.1.1.1, no one was publishing anything on BGP or pushing it out to global routing tables. However, they were building their own infrastructure (and, in the case of consumer routers, their customers' infrastructure) on the assumption that this portion of the namespace would never refer to an external resource they'd actually want to access.
Similarly, if you use .ars, you're taking up that namespace from the perspective of your internal users. If at some point it turns out that there is some resource under that name that you want to access, you're going to have a hell of a time rebuilding your infrastructure to not use that name.
tl;dr don't use random names in a globally-managed namespace. Even if you're the only person seeing those name -> resource mappings, you can end up with inconsistencies between your own usage and the globally-managed version.
No, you're not, because an internal management network does not have a gateway out to the internet. The management VRF does not talk to the global routing table. There would be no way to access a public .ars website even if you did not take its namespace.
Nothing is really safe. Maybe an emoticon? IIRC, the use of emoticons was stopped after someone registered the poop symbol on .la.
https://en.wikipedia.org/wiki/Internationalized_domain_name
https://panic.com/blog/the-worlds-first-emoji-domain/
unicode 1f32e is the taco emoji, so i think I will be migrating all my internal things to http://servername.1f32e
That changed; this is what people are / were mad about.
The point is that some standard CAN change any other similar thing at any point in the future; particularly now that you can buy a TLD.
Thus the lesson is, buy a real name and reserve the namespace.
you even get a link to the RFC when installing kubernetes with the default domain name (which is local). I sadly forgot the number, so cant cite it.
from wikipedia:
> The Internet Engineering Task Force (IETF) standards-track RFC 6762 (February 20, 2013) reserves the use of the domain name label local as a pseudo-top-level domain for hostnames in local area networks that can be resolved via the Multicast DNS name resolution protocol.[1] Any DNS query for a name ending with the label local must be sent to the mDNS IPv4 link-local multicast address 224.0.0.251, or its IPv6 equivalent FF02::FB. Domain name ending in local, may be resolved concurrently via other mechanisms, e.g., unicast DNS.
To clarify:
It /used/ to be that .local wasn't mentioned in any standard.
Don't do anything like .local (a non TLD and not part of a standard), because there is now a history of standards being created that break existing private deployments, and also because OTHER TLD like things can now be purchased as TLDs. That is why the current best practice is now to have an internal subdomain of a real domain (even if not globally published).
One issue with doing this is that it tends to break in various wonderful ways when you internally use Windows and Active Directory.
Even if the internal hostnames only resolve to a non-globally-routable IP address somewhere in 10/8 or 172.16/12, etc.
In other words when exposing hostnames and addresses of your internal infrastructure to the public internet has meaningful security ramifications then you have considerably more critical security problem.
Registering a domain prevents those names from being used for other purposes in the future. Your domain does not have to have valid NS addresses. Even if a domain has NS record with a valid address of the authoritative name server, that server does not have to respond to requests from the public internet. It doesn't even have to have to be accessible on the public internet.
Register a domain for internal use and run an internal name server on e.g. 10.x.y.z that handles your private IP space, and configure the local recursive resolver name servers to hand out your internal server's address when asked about the associated NS record. At the same time, set the real NS records for your internal domain to e.g. a traditional DNS hosting service that returns a CNAME pointing to your public domain. (the public internet only sees *.private.example.com as a CNAME to www-public-name-com.example.com)
The convenience is about not having whatever VPN solution you use to inject DNS recursors into laptop's OS, which end ups being not reasonably solvable when you have two such VPNs you have to use at once.
The benefits of being able to resolve internal IPs external isn't even really a benefit - if I can't resolve internal.hostname.domain then I'm not on the VPN, which means I can't reach the machine anyway, so where's the benefit?
A perfect example of why this threat isn't merely theoretical is the $36k bug bounty that Google paid out recently[0]. With additional knowledge of their internal network exposed by the information leak from DNS, the damage a blackhat could have done is untold.
The problem isn't the exposition of hostnames and addresses, the problem is if blackhats do manage to get access to the internal network (through whatever means; breaking into the VPN, a hole in the firewall, social engineering, RCE in the public facing website as in Google's case), it's undoubtedly easier if they've been given a list of juicy targets, rather than have to discover them for themselves.
[0]https://sites.google.com/site/testsitehacking/-36k-google-ap...
The only other organization I know of that has done that is Comcast, which has been a leader in forcing vendor ipv6 support because they literally exhausted 10/8 for their management networks.
Sorry, I'm slightly confused.
I browse newproduct.google.com. My browser calls the DNS, asking for the IP. The IP comes back as 192.168.0.1 [1]. It connects to 192.168.0.1. Gets hit by an XSS, and sends your cookie value to evildoer.example.com.
How would it help you that the reverse-IP of 192.168.0.1 issfo07s13-in-f14.1e100.net? The browser doesn't know that. It thinks its going to newproduct.google.com.
[1]. Yup, that number is just an example.
The point is that Google (or any company with the same mindset) scopes down the number of machines that can receive your google.com cookie. Even their own machines often don't need it to do their job, so it's not worth the security risk to have your cookie sent more than necessary.
Browser will send cookies to X.google.com and it will not to X.1e100.net. Ok.
But how is that problematic in this case? Why will X.google.com misbehave when it recieves google's cookies? Why will it be online in the first place if it is not yet up to apropiate security standards?
Google decided to let all their IPs return a reverse DNS lookup under the 1e100 domain name. It makes things simpler when you want to figure out who’s connecting to your servers, for example.
Why? Or rather I guess, How does it make things simpler?
# dig -x 172.217.5.14 +short
lga15s49-in-f14.1e100.net.
ord38s19-in-f14.1e100.net.
# dig lga15s49-in-f14.1e100.net. +short
172.217.5.14
# dig lga15s49-in-f14.1e100.net. +short
172.217.5.14
The first command (dig -x) checks the PTR record for the IP address 172.217.5.14. It returns two PTR records: lga15s49-in-f14.1e100.net. and ord38s19-in-f14.1e100.net.[0]. Those are subdomains of 1e100.net, which we know Google owns. However, you can set a PTR to pretty much whatever you want, so we now take an additional step as well. We run the dig command again to check the A records for the domains. This returns the same IP address we started with, which is good. Since Google controls the DNS for 1e100.net we can be reasonably sure that it is in fact a Google server. This is called Forward-confirmed reverse DNS (FCrDNS) and is one tool you can use to determine the ownership of an IP address. For example, it is frequently used as a weight in email spam filters. Although, because of the intricacies of email, in that case it is usually not used for identification and instead used as a general purpose check to determine whether a mail server is rogue or not, since spam servers very often do not have proper FCrDNS.
There are other tools to determine who owns an IP address, like whois, but in some instances one will garner useful information and the other will not. So it's nice to have both at your disposal.
[0] As a side note: the trailing . in those PTR records returned by dig is not a typo. All domains actually end in a dot, it's just usually implied.
Sorry but to the average user, the domain name 1e100.net doesn't ring a bell at all at this point. They would still have to look up the IP in ARIN/RIPE/etc to see that the IP range is effecively owned by a company called Google.
Do you really need a hostname at all? Wouldn't be the ARIN/RIPE/etc entry be sufficient to know who "owns" said IP address?
One example: say you have a $200/mo dedicated server customer, as an ISP, you're giving them a /29 of public IP space. That /29 exists as a vlan subinterface of one of your juniper routers and is trunked across the datacenter through various switches to the server. Let's say it's vlan 2659. Somewhere in the public rDNS for the default gateway IP of that /29, you would have the string "vl2659”.
Google has done something a little bit different here, it's not their AS number, but same general concept.
Try this:
> dig google.com
;; ANSWER SECTION:
google.com. 299 IN A 172.217.164.110
> nslookup 172.217.164.110
Non-authoritative answer:
110.164.217.172.in-addr.arpa name = sfo03s18-in-f14.1e100.net.
yebyen:~$ host google.com
google.com has address 172.217.10.46
google.com has IPv6 address 2607:f8b0:4006:803::200e
...
yebyen:~$ host 172.217.10.46
46.10.217.172.in-addr.arpa domain name pointer lga34s13-in-f14.1e100.net.This allows flexibility in infrastructure — you can swap machines in and out (e.g. by updating public DNS records, updating the machines’ IP addresses, or adding them to (or removing them from) a load balanced pool behind a reverse proxy). But you still need a way to reference individual machines regardless of whether they’re serving or not.
That’s where domains like 1e100.net come in — a system of concrete (non-abstract) references to specific machines in your infrastructure.
$ ping google.com
PING google.com (172.217.7.206) 56(84) bytes of data.
64 bytes from iad30s10-in-f14.1e100.net (172.217.7.206): icmp_seq=1 ttl=48 time=0.676 ms