4 ms·

.ai is a valid domain name

by already 4y ago

riffic 4y ago
technically it's `ai.`
- eCa 4y ago
  Similarly, we’re on https://news.ycombinator.com./ (Weird new line to get the whole url displayed)
  - chrismorgan 4y ago
    No, that’s a different hostname. It will almost always resolve to the same IP address, and a large fraction of servers will serve the same content from the dotless and dotted forms, but they can serve something different (e.g. a redirect to the other form, or nothing), and it’s common for dotted versions of sites to be broken. All up, we’re not on the origin you showed.
    - hjV9H2bWu4ZhXPy 4y ago
      Nope, that's definitely the same hostname, and will always resolve to the same IP address, barring some real weirdness (someone's system applying the search domain to a domain that already contains dots, and then actually finding a result for `news.ycombinator.com.search.domain.`). And in fact even in the case of that weirdness, `news.ycombinator.com.` would get to the correct place, while `news.ycombinator.com` would NOT. Now, servers could certainly do the wrong thing when faced with a Host header ending in a `.`, but a) that's a bug in the web server (or browser, arguably - do they tack on a search domain to the Host header?) and b) is not a result of the wrong IP address etc. (It's also an HTTP-layer issue, not a DNS-layer issue, and doesn't apply to most other protocols.)
      - chrismorgan 4y ago
        It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple. When I said “almost always”, I was referring to search domains as the exception, I just didn’t think it worth clarifying (though I was amused by the fact that it’s the oft-broken-at-HTTP-and-above one that’s reliable at DNS). Look, the difference is trivially demonstrated and eCa’s original claim trivially falsified: unless you’ve gone out of your way already, at https://news.ycombinator.com/ https://news.ycombinator.com/ you’re logged in, at https://news.ycombinator.com./ https://news.ycombinator.com./ you’re not logged in, because the hostname and thus origin is different, and also they’re not same-site, and thus cookies and such are not shared. ai and www.ai might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything. ai and ai. might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything.
        hjV9H2bWu4ZhXPy 4y ago
        > It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple. Except that it is, in fact, the same hostname. "It's that simple." This is defined by DNS. Go open Wireshark and run `dig google.com @8.8.8.8 +nocookie` versus `dig google.com. @8.8.8.8 +nocookie`. Observe that the queries are identical other than the "Transaction ID" (and perhaps some IP or UDP-level randomness). Application-level software can get it wrong, but it is in fact the same hostname at a level that pretty much everyone uses. Application-level software getting it wrong does not invalidate that fact. You can not adopt an identifier from some other protocol, and then use it with a different meaning, without a bug. (Tangentially, this is why naming shouldn't be handled at the application layer, since it's already handled at lower levels. It's quite sad that no one wants to start moving HTTP towards SRV records.) > I was referring to search domains as the exception Yes, I assumed so, but as I pointed out, this would lead to the common one (news.ycombinator.com) being broken while the other (news.ycombinator.com.) would work (or else be broken by an application-layer bug, i.e. processing of the Host header causing it to break)! > ai and ai. might ... have one redirect to the other, might serve different content Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address. (And, as above, to do so would actually lead to the site being inaccessible for some people with search domains, since `ai` might actually be used as a subdomain, and `ai.` would still work for them but for a faulty application-layer configuration)

.ai is a valid domain name

riffic 4y ago

technically it's `ai.`

eCa 4y ago
Similarly, we’re on https://news.ycombinator.com./ (Weird new line to get the whole url displayed)
- chrismorgan 4y ago
  No, that’s a different hostname. It will almost always resolve to the same IP address, and a large fraction of servers will serve the same content from the dotless and dotted forms, but they can serve something different (e.g. a redirect to the other form, or nothing), and it’s common for dotted versions of sites to be broken. All up, we’re not on the origin you showed.
  - hjV9H2bWu4ZhXPy 4y ago
    Nope, that's definitely the same hostname, and will always resolve to the same IP address, barring some real weirdness (someone's system applying the search domain to a domain that already contains dots, and then actually finding a result for `news.ycombinator.com.search.domain.`). And in fact even in the case of that weirdness, `news.ycombinator.com.` would get to the correct place, while `news.ycombinator.com` would NOT. Now, servers could certainly do the wrong thing when faced with a Host header ending in a `.`, but a) that's a bug in the web server (or browser, arguably - do they tack on a search domain to the Host header?) and b) is not a result of the wrong IP address etc. (It's also an HTTP-layer issue, not a DNS-layer issue, and doesn't apply to most other protocols.)
    - chrismorgan 4y ago
      It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple. When I said “almost always”, I was referring to search domains as the exception, I just didn’t think it worth clarifying (though I was amused by the fact that it’s the oft-broken-at-HTTP-and-above one that’s reliable at DNS). Look, the difference is trivially demonstrated and eCa’s original claim trivially falsified: unless you’ve gone out of your way already, at https://news.ycombinator.com/ https://news.ycombinator.com/ you’re logged in, at https://news.ycombinator.com./ https://news.ycombinator.com./ you’re not logged in, because the hostname and thus origin is different, and also they’re not same-site, and thus cookies and such are not shared. ai and www.ai might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything. ai and ai. might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything.
      - hjV9H2bWu4ZhXPy 4y ago
        > It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple. Except that it is, in fact, the same hostname. "It's that simple." This is defined by DNS. Go open Wireshark and run `dig google.com @8.8.8.8 +nocookie` versus `dig google.com. @8.8.8.8 +nocookie`. Observe that the queries are identical other than the "Transaction ID" (and perhaps some IP or UDP-level randomness). Application-level software can get it wrong, but it is in fact the same hostname at a level that pretty much everyone uses. Application-level software getting it wrong does not invalidate that fact. You can not adopt an identifier from some other protocol, and then use it with a different meaning, without a bug. (Tangentially, this is why naming shouldn't be handled at the application layer, since it's already handled at lower levels. It's quite sad that no one wants to start moving HTTP towards SRV records.) > I was referring to search domains as the exception Yes, I assumed so, but as I pointed out, this would lead to the common one (news.ycombinator.com) being broken while the other (news.ycombinator.com.) would work (or else be broken by an application-layer bug, i.e. processing of the Host header causing it to break)! > ai and ai. might ... have one redirect to the other, might serve different content Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address. (And, as above, to do so would actually lead to the site being inaccessible for some people with search domains, since `ai` might actually be used as a subdomain, and `ai.` would still work for them but for a faulty application-layer configuration)