4 ms·

For me the link on HN is to https://dns.google/ https://dns.google/ but I'm pretty sure it's supposed to be to https://010.010.010.010/ https://010.010.010.010/

For me the link on HN is to https://dns.google/ https://dns.google/ but I'm pretty sure it's supposed to be to https://010.010.010.010/ https://010.010.010.010/ (which redirects, for me). Did the admins change it?

boramalper 5y ago
I was just about to edit my comment: either that is the case or HN automatically runs a reverse DNS query to get the domain name associated with the IP address in the submission URL?
- missingcolours 5y ago
  More likely they do an HTTP request and if there's a redirect they update the link.
  - boramalper 5y ago
    Indeed!
pxc 5y ago
Is that a real TLD?
- ignoramous 5y ago
  TLS certs can be issued to make them work with IP addresses, which is why https to 8.8.8.8 (octal: 010.010.010.010) works: https://cabforum.org/guidance-ip-addresses-certificates/ https://cabforum.org/guidance-ip-addresses-certificates/ See also: https://01.01.01.01/ https://01.01.01.01/ (btw: .google and .goog are valid TLDs)
  - tialaramex 5y ago
    Not explicitly mentioned in that CAB/F document, the PKIX standard that makes ipAddress SANs work actually defines them as numeric types with a set number of bits, so an ipAddress is literally a 32-bit or 128-bit value. This leaves no room for the ambiguity of the text rendering something like 010.010.010.010 in the certificate itself. Likewise the dnsName SAN type is defined in an alphabet for X.509 that literally can't represent fancy Unicode, so you can't mistakenly write certificates with dnsName SANs that give the Unicode name instead of the unambiguous punycode name stored in DNS. These two choices mean your browser can mechanically with 100% reliability check certificates in the Web PKI match the IP address or DNS name from the URL you believed you were visiting, whereas historically the abuse of "Common Name" features to write a human representation had nasty edge cases for both IP addresses and some DNS names.
- tialaramex 5y ago
  No, it's an IPv4 address. No TLD is allowed to be a series of digits in order to avoid any confusion about this. Whether your URL parser considers that octal IPv4 addresses are a reasonable thing is up to each individual parser. On the whole I'd suggest user-facing software should not permit this because it's pointlessly confusing. Rust took a patch that says if you try to convert (for example) 010.010.010.010 to an IPv4 address that's an error, which again I think is reasonable for the same reason. In the patch feedback several people want it to mean 10.10.10.10 and others think it should mean 8.8.8.8 and eventually it seems to become clear to both groups that this is itself a terrible sign for their positions, since if you expected one but got the other now your software has unexpected behaviour, whereas if you got an error you can fix your program to do whatever it was you intended. So hence the error behaviour won. [Edited to add: It has been pointed out to me that maybe the poster meant .google. Yes, that's a TLD owned by Google. They applied for, and received a number of "new gTLDs" from ICANN, some like .dev are open for you to register 2LDs in, others like .google are only for their own use. Running TLDs likely costs Google somewhere in the region of a million dollars per year to maintain, but that's a drop in the ocean for a large tech company.]
  - pxc 5y ago
    Yeah, I meant the .google name the IP redirects you to in the browser
    - phantomathkg 5y ago
      Of course it is, part of gTLD https://newgtlds.icann.org/en/program-status/delegated-strings https://newgtlds.icann.org/en/program-status/delegated-strin...
- fragmede 5y ago
  Without getting into the existential question of what does it mean to be real, yes [0]. It's one of the sponsored modern TLDs[1], along with the likes of .horse, .cat (not what you think), .wiki, .club, etc. [0] https://en.m.wikipedia.org/wiki/.google https://en.m.wikipedia.org/wiki/.google [1] https://en.m.wikipedia.org/wiki/Sponsored_top-level_domain https://en.m.wikipedia.org/wiki/Sponsored_top-level_domain
  - pxc 5y ago
    > Without getting into the existential question of what does it mean to be real I think what I meant was mostly > will all or most DNS servers other than Google's resolve .google addresses I didn't realize Google had bought their own TLD. I'm not sure how I feel about the sponsored TLDs. I think I like them, mostly. I think I don't love how .google is centered on a single corporation in the same way that I don't like how .gov and .mil have always been so US-centric. In a way it feels like an intrusion, or somehow misplaced
dang 5y ago
Our software follows redirects now. Obviously that's not correct in cases like this; but it's so much of an improvement in other cases that I don't want to roll it back. Not sure what to do yet really. I've changed the URL above back to https://010.010.010.010/ https://010.010.010.010/ now. Thanks!
- JoshTriplett 5y ago
  Interestingly, Firefox canonicalizes such links to the decimal IP address: if you hover over it, you see https://8.8.8.8/ https://8.8.8.8/ , and if you click on it that's where you end up.

boramalper 5y ago

I was just about to edit my comment: either that is the case or HN automatically runs a reverse DNS query to get the domain name associated with the IP address in the submission URL?

missingcolours 5y ago
More likely they do an HTTP request and if there's a redirect they update the link.
- boramalper 5y ago
  Indeed!

pxc 5y ago

Is that a real TLD?

ignoramous 5y ago
TLS certs can be issued to make them work with IP addresses, which is why https to 8.8.8.8 (octal: 010.010.010.010) works: https://cabforum.org/guidance-ip-addresses-certificates/ https://cabforum.org/guidance-ip-addresses-certificates/ See also: https://01.01.01.01/ https://01.01.01.01/ (btw: .google and .goog are valid TLDs)
- tialaramex 5y ago
  Not explicitly mentioned in that CAB/F document, the PKIX standard that makes ipAddress SANs work actually defines them as numeric types with a set number of bits, so an ipAddress is literally a 32-bit or 128-bit value. This leaves no room for the ambiguity of the text rendering something like 010.010.010.010 in the certificate itself. Likewise the dnsName SAN type is defined in an alphabet for X.509 that literally can't represent fancy Unicode, so you can't mistakenly write certificates with dnsName SANs that give the Unicode name instead of the unambiguous punycode name stored in DNS. These two choices mean your browser can mechanically with 100% reliability check certificates in the Web PKI match the IP address or DNS name from the URL you believed you were visiting, whereas historically the abuse of "Common Name" features to write a human representation had nasty edge cases for both IP addresses and some DNS names.
tialaramex 5y ago
No, it's an IPv4 address. No TLD is allowed to be a series of digits in order to avoid any confusion about this. Whether your URL parser considers that octal IPv4 addresses are a reasonable thing is up to each individual parser. On the whole I'd suggest user-facing software should not permit this because it's pointlessly confusing. Rust took a patch that says if you try to convert (for example) 010.010.010.010 to an IPv4 address that's an error, which again I think is reasonable for the same reason. In the patch feedback several people want it to mean 10.10.10.10 and others think it should mean 8.8.8.8 and eventually it seems to become clear to both groups that this is itself a terrible sign for their positions, since if you expected one but got the other now your software has unexpected behaviour, whereas if you got an error you can fix your program to do whatever it was you intended. So hence the error behaviour won. [Edited to add: It has been pointed out to me that maybe the poster meant .google. Yes, that's a TLD owned by Google. They applied for, and received a number of "new gTLDs" from ICANN, some like .dev are open for you to register 2LDs in, others like .google are only for their own use. Running TLDs likely costs Google somewhere in the region of a million dollars per year to maintain, but that's a drop in the ocean for a large tech company.]
- pxc 5y ago
  Yeah, I meant the .google name the IP redirects you to in the browser
  - phantomathkg 5y ago
    Of course it is, part of gTLD https://newgtlds.icann.org/en/program-status/delegated-strings https://newgtlds.icann.org/en/program-status/delegated-strin...
fragmede 5y ago
Without getting into the existential question of what does it mean to be real, yes [0]. It's one of the sponsored modern TLDs[1], along with the likes of .horse, .cat (not what you think), .wiki, .club, etc. [0] https://en.m.wikipedia.org/wiki/.google https://en.m.wikipedia.org/wiki/.google [1] https://en.m.wikipedia.org/wiki/Sponsored_top-level_domain https://en.m.wikipedia.org/wiki/Sponsored_top-level_domain
- pxc 5y ago
  > Without getting into the existential question of what does it mean to be real I think what I meant was mostly > will all or most DNS servers other than Google's resolve .google addresses I didn't realize Google had bought their own TLD. I'm not sure how I feel about the sponsored TLDs. I think I like them, mostly. I think I don't love how .google is centered on a single corporation in the same way that I don't like how .gov and .mil have always been so US-centric. In a way it feels like an intrusion, or somehow misplaced

dang 5y ago

Our software follows redirects now. Obviously that's not correct in cases like this; but it's so much of an improvement in other cases that I don't want to roll it back. Not sure what to do yet really. I've changed the URL above back to https://010.010.010.010/ https://010.010.010.010/ now. Thanks!

JoshTriplett 5y ago
Interestingly, Firefox canonicalizes such links to the decimal IP address: if you hover over it, you see https://8.8.8.8/ https://8.8.8.8/ , and if you click on it that's where you end up.