6 ms·

It's nice to have progress in some areas. However, I'm disappointed to observe that we're on to version 3 and the HTTP editors are still writing tortured thick

It's nice to have progress in some areas. However, I'm disappointed to observe that we're on to version 3 and the HTTP editors are still writing tortured thickets of handwaving cross-references to avoid specifying which DNS records it uses. Instead, HTTP continues to refer normatively to the http(s) URIs, which eventually confess: "This specification does not mandate a particular registered name lookup technology". and then everyone squats the A/AAAA address records by default, effectively denying them for any other purpose. There are some obvious consequential misbehaviours (such as the perennial "apex record" problem), but more broadly, HTTP subverts the DNS by de facto appropriating potentially all labels, and continuing to do so represents a middle finger in the face of every other protocol designer. This situation gets more rusted-on and harder to figure out remediation with each revision, and there's a lesson or two in here for anyone who develops protocols for a living.

zarzavat 4y ago
I don’t understand. What has DNS got to do with HTTP? If I connect to http://foobar.onion/ http://foobar.onion/ it’s not using DNS, isn’t that what they mean by “not requiring a particular lookup technology”? And what is the issue with A/AAAA records exactly?
- stock_toaster 4y ago
  I assume the parent was hoping for SRV record support.
  - inopinatus 4y ago
    SRV is a probably a smidgen shy of what HTTP needs in 2022, although if the protocol were invented today it’d be a shoo-in for resolution in the common case.
- inopinatus 4y ago
  This is pointless hairsplitting. RFC7686 is a DNS RFC, one that specifies and enables special application handling when stipulated conditions are met. Even if HTTP/3 defined its use of DNS records adequately, the special case still takes precedence and onion routing continues to occur in browsers supporting it. In my view the use of a special-case TLD is deeply problematic since it contains the potential to leak your use of Tor via applications or resolvers that do not grok the exception, but that's a design problem for another day. The problems with using host address records for service location are multifaceted but the most significant are a) their conflict with other services at the same label, most commonly when the web hosting requires a CNAME, which cannot co-exist with any other record, and b) they're crude; full-grown origin discovery could support priorities, fallbacks, protocol upgrades, variation by transport, alternate ports and more besides.
tsimionescu 4y ago
Doesn't SSH "subvert DNS" just as much, as it also relies on A/AAAA records when you type in `ssh user@fqdn.`? Or `ping fqdn.`, for that matter?
- inopinatus 4y ago
  No. Firstly, SSH is not used at the scale where any such misuse might be a problem. Secondly, SSH is used for connecting to specific hosts, which is what the A/AAAA records actually are (being by definition the host address).
  - Gordonjcp 4y ago
    So what's the problem then? Are you somehow thinking that if you have a web server serving HTTP traffic on a server, you need a different A record to connect to it with SSH? Because that is very much not how it works.
aidenn0 4y ago
Historically, isn't this what the "www" prefix to a URL is for? www.example.com for HTTP, ftp.example.com for ftp, &c.
- BlueTemplar 4y ago
  More like ftp://example.com ?
  - withinboredom 4y ago
    The “ftp://“ is a protocol/scheme and not part of the domain’s definition, hinting that the client should connect to port 21 of the A record. With a put ftp client, defining the scheme/protocol is not necessary.
- rjh29 4y ago
  Yeah and news/mail/telnet/irc. Not very common nowadays of course, although www still hangs around.
  - aidenn0 4y ago
    Mail has had MX records for a while, but yes for the rest.
ghoulish45 4y ago
There’s a lesson or two in understanding and respecting the difference between the two technologies you’re discussing. www.example.com. A 192.0.2.1, for example, will work for both HTTP and SSH and whatever else you want to put there. If you have SSH on 22/tcp and HTTP on 80/tcp and HTTP over TLS on 443/tcp, all of those are reachable via the same exact A record in DNS without even clarifying what port you intend. Plain “ssh www.example.com” would work just fine. That’s why your statements about subversion of the DNS and squatting on DNS RR types show you to not understand what you’re dealing with, which makes your emotional state about it even more discouraging. You seem to be upset that HTTP has a well-known port. That’s the only sense I can make from what you’re saying, anyway, because you’re ranting at something you seem to have an extremely loose grip on understanding. Hundreds, if not thousands, of protocols start their life with gethostbyname, which looks at A/AAAA. That’s not unique to HTTP and, more importantly, doesn’t deny the A and AAAA RRs for any other purpose. Your gripe makes no sense. The apex record problem has to do with the DNS specification and the behavior of CNAMEs. It was an issue before the Web existed (crazy, right?). I sense that your career has primarily been involved with DNS as an enabling mechanism for HTTP systems, probably mostly working with virtual DNS hosts like VIPs (given that you incorrectly distinguish “hosts” from the apparent squatting you’re observing in another comment) and you have next to zero context on how very different they are and how little they have to do with each other. Before you start accusing people of middle fingers and such, you might want to put aside your rage and question yourself: do I fully understand what I’m mad about?
- inopinatus 4y ago
  Welcome back, rosndo.
  - ghoulish45 4y ago
    - inopinatus 4y ago
      Someone who was banned, and briefly notorious for making wildly inaccurate personal judgements, piling on belittling invective in the woefully misguided belief it lend credence to their argument, seeking & sowing vehemence where none was present, and then creating additional accounts willy-nilly in hope of bypassing the inevitable. Which is to say, you were wrong in every pernicious assumption, and in a manner that thoroughly embodies the ghost of that individual, and consequently not worth anyone's energy debating with any further.
Gordonjcp 4y ago
> and then everyone squats the A/AAAA address records by default, effectively denying them for any other purpose. Can you clearly and lucidly explain what you mean here? How is HTTP "denying" A records from pointing people to servers being used for other protocols?

zarzavat 4y ago

I don’t understand. What has DNS got to do with HTTP? If I connect to http://foobar.onion/ http://foobar.onion/ it’s not using DNS, isn’t that what they mean by “not requiring a particular lookup technology”? And what is the issue with A/AAAA records exactly?

stock_toaster 4y ago
I assume the parent was hoping for SRV record support.
- inopinatus 4y ago
  SRV is a probably a smidgen shy of what HTTP needs in 2022, although if the protocol were invented today it’d be a shoo-in for resolution in the common case.
inopinatus 4y ago
This is pointless hairsplitting. RFC7686 is a DNS RFC, one that specifies and enables special application handling when stipulated conditions are met. Even if HTTP/3 defined its use of DNS records adequately, the special case still takes precedence and onion routing continues to occur in browsers supporting it. In my view the use of a special-case TLD is deeply problematic since it contains the potential to leak your use of Tor via applications or resolvers that do not grok the exception, but that's a design problem for another day. The problems with using host address records for service location are multifaceted but the most significant are a) their conflict with other services at the same label, most commonly when the web hosting requires a CNAME, which cannot co-exist with any other record, and b) they're crude; full-grown origin discovery could support priorities, fallbacks, protocol upgrades, variation by transport, alternate ports and more besides.

tsimionescu 4y ago

Doesn't SSH "subvert DNS" just as much, as it also relies on A/AAAA records when you type in `ssh user@fqdn.`? Or `ping fqdn.`, for that matter?

inopinatus 4y ago
No. Firstly, SSH is not used at the scale where any such misuse might be a problem. Secondly, SSH is used for connecting to specific hosts, which is what the A/AAAA records actually are (being by definition the host address).
- Gordonjcp 4y ago
  So what's the problem then? Are you somehow thinking that if you have a web server serving HTTP traffic on a server, you need a different A record to connect to it with SSH? Because that is very much not how it works.

aidenn0 4y ago

Historically, isn't this what the "www" prefix to a URL is for? www.example.com for HTTP, ftp.example.com for ftp, &c.

BlueTemplar 4y ago
More like ftp://example.com ?
- withinboredom 4y ago
  The “ftp://“ is a protocol/scheme and not part of the domain’s definition, hinting that the client should connect to port 21 of the A record. With a put ftp client, defining the scheme/protocol is not necessary.
rjh29 4y ago
Yeah and news/mail/telnet/irc. Not very common nowadays of course, although www still hangs around.
- aidenn0 4y ago
  Mail has had MX records for a while, but yes for the rest.

ghoulish45 4y ago

There’s a lesson or two in understanding and respecting the difference between the two technologies you’re discussing. www.example.com. A 192.0.2.1, for example, will work for both HTTP and SSH and whatever else you want to put there. If you have SSH on 22/tcp and HTTP on 80/tcp and HTTP over TLS on 443/tcp, all of those are reachable via the same exact A record in DNS without even clarifying what port you intend. Plain “ssh www.example.com” would work just fine. That’s why your statements about subversion of the DNS and squatting on DNS RR types show you to not understand what you’re dealing with, which makes your emotional state about it even more discouraging. You seem to be upset that HTTP has a well-known port. That’s the only sense I can make from what you’re saying, anyway, because you’re ranting at something you seem to have an extremely loose grip on understanding. Hundreds, if not thousands, of protocols start their life with gethostbyname, which looks at A/AAAA. That’s not unique to HTTP and, more importantly, doesn’t deny the A and AAAA RRs for any other purpose. Your gripe makes no sense. The apex record problem has to do with the DNS specification and the behavior of CNAMEs. It was an issue before the Web existed (crazy, right?). I sense that your career has primarily been involved with DNS as an enabling mechanism for HTTP systems, probably mostly working with virtual DNS hosts like VIPs (given that you incorrectly distinguish “hosts” from the apparent squatting you’re observing in another comment) and you have next to zero context on how very different they are and how little they have to do with each other. Before you start accusing people of middle fingers and such, you might want to put aside your rage and question yourself: do I fully understand what I’m mad about?

inopinatus 4y ago
Welcome back, rosndo.
- ghoulish45 4y ago
  - inopinatus 4y ago
    Someone who was banned, and briefly notorious for making wildly inaccurate personal judgements, piling on belittling invective in the woefully misguided belief it lend credence to their argument, seeking & sowing vehemence where none was present, and then creating additional accounts willy-nilly in hope of bypassing the inevitable. Which is to say, you were wrong in every pernicious assumption, and in a manner that thoroughly embodies the ghost of that individual, and consequently not worth anyone's energy debating with any further.

Gordonjcp 4y ago

> and then everyone squats the A/AAAA address records by default, effectively denying them for any other purpose. Can you clearly and lucidly explain what you mean here? How is HTTP "denying" A records from pointing people to servers being used for other protocols?