3 ms·
I like reordering of the named components to big-endian, but just for reference, the current system dates back to the idea of “search domains”, which allows you
by bluejekyll 2y ago
I like reordering of the named components to big-endian, but just for reference, the current system dates back to the idea of “search domains”, which allows you to do things like “www” and that takes you to “www.example.com” because that is in your search or domain list in your stub resolver config. (This behavior can be skipped by using the fqdn with a dot at the end, “www.example.com.”)
I think moving to a new ordering of the name would then imply that we’d either need a different DNS or a new separator for specifying the reverse name ordering (that’s compatible with existing URL syntax).
- yjftsjthsd-h 2y agoWell, that's why this is purely a time-travel fantasy - I don't think we'll ever get a do-over:) And I can see the appeal to search domains, but I think in hindsight they pretty much failed, and what utility they have can be replaced with local or internal or something - "internal.www" can still be your intranet site, but now it's explicit. Or if we go with the other suggestion to force country TLDs then maybe it's fine for local DNS resolvers to do nonstandard TLDs, though I'm not super fond of that.
- bluejekyll 2y agoIf we’re going to do some time travel, I’d also like to make the DNS packets easily versionable and add some space for additional version codes, the current extension mechanism with eDNS is quite cumbersome.
- yjftsjthsd-h 2y agoOh yeah, I don't usually work at that layer so didn't think about it, but I'd probably also make it TCP only so we could skip it being a DDoS vector.
- nine_k 2y agoIt would make it noticeably slower on the early Internet, though.
- Dylan16807 2y agoThat's such a big latency bottleneck though. If we're looking at simple solutions with only short-term state, then pad the request packets and truncate responses that are much bigger.