7 ms·

Servers need a name that's different from the product(s) they're serving. For example, when I look up google.com and then reverse-lookup the IP address, I get

by tlb 8y ago

Servers need a name that's different from the product(s) they're serving. 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.

EarthIsHome 8y ago
So, for example, the domain google.com points to the domain sfo07s13-in-f14.1e100.net (depending on where you're browsing) which then points to an IP address of the server that's serving you the content. google.com -> subdomain.1e100.net -> server IP address Then when you run a reverse DNS on the IP address, you get sfo07s13-in-f14.1e100.net. rDNS: server IP address -> subdomain.1e100.net So, like you said, if something is wrong with the server, you can run a reverse DNS on the IP address to get the subdomain sfo07s13-in-f14.1e100.net. Is this the correct understanding? But don't you already have the IP address of the misbehaving machine?
- tlb 8y ago
  Yes. 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.
- peterwwillis 8y ago
  Lots of people look at IP addresses. Most of the people who find the "1e100.net" records in their network logs would have no easy way of knowing that 1.2.3.4 (or whatever) was a Google IP. The reverse lookup allows you to easily find out what domain it belongs to (1e100.net, which a Google search shows is a Google address). 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."
walrus01 8y ago
Adding to your last paragraph: Medium to large sized ISPs and web entities are also highly likely to use a third domain, which never touches the public internet. You might have: 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.
- unethical_ban 8y ago
  Is it not recommended for the Part C to be done with a third, yet publicly owned, domain? Instead of widgets.local or widgets.internal, it would be widgets-internal.com or something. Struggling to remember why, but I heard people mad about .local
  - mjevans 8y ago
    It USED to be that .local was fine; no one else and no other standard used it. 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.
    - y4mi 8y ago
      the gTLD local is already registered and can't be 'stolen'. DNS servers should never route a query for that domain. 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.
greenhouse_gas 8y ago
>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. 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.
- sowbug 8y ago
  Your example is not the same as the one in the comment you replied to. You picked a product hostname. The example was an infrastructure hostname. 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.
int0x80 8y ago
Sorry but I dont follow. I hope you can clarify. What's the disadvantage for providing a PTR -> sfo07-blah.google.com instead of sfo07-blah.1e100.net? 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?

by tlb 8y ago

EarthIsHome 8y ago

So, for example, the domain google.com points to the domain sfo07s13-in-f14.1e100.net (depending on where you're browsing) which then points to an IP address of the server that's serving you the content. google.com -> subdomain.1e100.net -> server IP address Then when you run a reverse DNS on the IP address, you get sfo07s13-in-f14.1e100.net. rDNS: server IP address -> subdomain.1e100.net So, like you said, if something is wrong with the server, you can run a reverse DNS on the IP address to get the subdomain sfo07s13-in-f14.1e100.net. Is this the correct understanding? But don't you already have the IP address of the misbehaving machine?

tlb 8y ago
Yes. 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.
peterwwillis 8y ago
Lots of people look at IP addresses. Most of the people who find the "1e100.net" records in their network logs would have no easy way of knowing that 1.2.3.4 (or whatever) was a Google IP. The reverse lookup allows you to easily find out what domain it belongs to (1e100.net, which a Google search shows is a Google address). 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."

walrus01 8y ago

Adding to your last paragraph: Medium to large sized ISPs and web entities are also highly likely to use a third domain, which never touches the public internet. You might have: 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.

unethical_ban 8y ago
Is it not recommended for the Part C to be done with a third, yet publicly owned, domain? Instead of widgets.local or widgets.internal, it would be widgets-internal.com or something. Struggling to remember why, but I heard people mad about .local
- mjevans 8y ago
  It USED to be that .local was fine; no one else and no other standard used it. 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.
  - y4mi 8y ago
    the gTLD local is already registered and can't be 'stolen'. DNS servers should never route a query for that domain. 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.

greenhouse_gas 8y ago

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

sowbug 8y ago
Your example is not the same as the one in the comment you replied to. You picked a product hostname. The example was an infrastructure hostname. 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.

int0x80 8y ago

Sorry but I dont follow. I hope you can clarify. What's the disadvantage for providing a PTR -> sfo07-blah.google.com instead of sfo07-blah.1e100.net? 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?