5 ms·

I can only agree, and further voice my strong disapproval at the continuing, damaging and absurd lack of DNS and IPv6 considerations, most notably the omission

I can only agree, and further voice my strong disapproval at the continuing, damaging and absurd lack of DNS and IPv6 considerations, most notably the omission of any discussion of endpoint resolution. Literally so: this protocol document does not specify how you determine which server to connect to. HTTP2 is, in definition, only very loosely coupled to IP despite making significant optimisations for TCP. Thus in implementation we simply get the same old mistakes and undefined behaviours. Issues with floating apex records, hacks based on IPv4/6 race conditions, unnecessary address wastage and so forth will continue; all derived from the colossal architectural wart of overloading the DNS host (A/AAAA) record as a service endpoint discovery mechanism. Once again, I say unto the peanut gallery: shoulda used SRV. The benefits are many and the downsides greatly overstated. I bemoan the missed opportunity.

tonyarkles 12y ago
What is a "floating apex record"? I googled it in quotations, and you appear to be the only person who has ever said that combination of words in Google's index.
- jacquesm 12y ago
  floating -> pointing to an old resource apex record -> alias for 'A' record (DNS parlance) So a 'floating apex record' is an A-record pointing to an old IP.
  - 0x0 12y ago
    I think "apex record" means the root domain name in a zone, and is unrelated to A records (except for the fact that you would usually make an A record for your apex so web browsers can reach your site even without a "www." subdomain/prefix)
    - jacquesm 12y ago
      That makes sense. Thanks!
  - meddlepal 12y ago
    Have you ever considered just saying 'A record' instead of 'Apex record' so the majority of people know what you're talking about? Not all of us are DNS wonks.
    - jacquesm 12y ago
      I was just trying to figure out what the GGGP meant, that wasn't my choice of words. I'm not a DNS wonk either.
      - meddlepal 12y ago
        Sorry about that. I see now that I responded to the wrong person.
- inopinatus 12y ago
  An apex record is one at the root of a DNS zone. Sometimes called "naked domains". For example, in "https://github.com/" https://github.com/" they are the records particularly for "github.com", rather than for subdomains that might exist such as "www.github.com" or "gist.github.com". Apex records have a particular restriction: they cannot be aliases, because the apex includes DNS metadata that is not allowed to be aliased[3]. Read on for how this becomes a problem. I've used the term "floating" as a visual metaphor, because what I'm about to describe lacks a universal standard name, because it is an ugly hack: HTTP resolves endpoints using host records, so an URL of "https://github.com" https://github.com" means looking up A and AAAA records for "github.com". Yes, the protocol is arrogant enough[1] to assume that your host address for the whole domain is that of the web server. (This is why we ended up prepending "www" to domain names, as a service selector). In response to the query you get an IP address. Unfortunately, IP addresses sometimes change without warning. The most common example today is the loadbalancer offered by Amazon Web Services. The solution to this is to use an alias record in your human-friendly domain, pointing at an hidden technical domain that the infrastructure provider keeps up-to-date (e.g. "my-elb-name-1-1160186271.ap-southeast-1.elb.amazonaws.com") This is fine for "www.example.com" but not the naked "example.com", because aliases are prohibited at the apex. As a result, DNS providers such as Route 53 have ended up with a hack: a spoofed record at the apex, one that tracks an external resource and synthesizes a fake A/AAAA response. Now you have a naked domain that tracks, or rather hopes to track, the correct endpoint. But it changes with the wind. Hence my description of it as "floating". There is no consistent name for this kludge. AWS calls it an alias, and for reliability concerns restrict it to their own infrastructure only; DME call it an "ANAME" record [2]. The model can even be readily implemented as a shell script run out of cron on your nameserver. It is fragile, it is often unreliable, it is not at all standardised, and it doesn't scale beyond one service. One better solution would be to require use of SRV records, which allow one to declare instead, for example, an "https" service for "example.com". Alongside, let's say, the xmpp service, sip service, or any other service you care to announce. SRV records can exist at the apex. They can also bundle the A and AAAA (IPv6) addresses for the resulting endpoints in the answer, and select alternative port numbers without bothering the user about it. Not quite a universal panacea: there is a minor hazard of zone cuts that could increase the number of client lookups, but that's an edge case, not one you can easily blunder into and also easy to fix. [1] HTTP/1.0 and earlier are forgiven, because they hail from a time when you just had a web server in a rack and called it "www". But HTTP/2 is supposed to respond to modern architectures. [2] http://www.dnsmadeeasy.com/services/aname-records/ http://www.dnsmadeeasy.com/services/aname-records/ [3] none of you comedians are allowed to mention DNAME records as the exotic counterexample.
EvanAnderson 12y ago
I can't agree enough about the missed opportunity to use SRV records. This would have been such a monumental step forward. Edit: It makes me a bit giddy (which makes sense if you factor in my being a sysadmin) to think about what SRV records would've done for load-balancing, running servers on non-standard ports, IP address exhaustion, and server migrations. Anybody who doesn't appreciate proper service-location hasn't ever done serious sysadmin work and, IMO, has no business designing protocols.
- AlyssaRowan 12y ago
  You ever tested them on a large scale? I think agl did; the state of DNS resolution is, I'm afraid, really not pretty.
  - justincormack 12y ago
    Have you got a reference?
haberman 12y ago
Grandparent says HTTP2 is a monstrosity, because it "includes a whole slew of features that we really don't need." You say you agree, because "the protocol does not specify how you determine what server to connect to." In other words, HTTP2 sucks because it simultaneously includes too many features, and not enough features. At least everyone can agree that they don't like it for some reason, even if the reasons themselves contradict each other.
- runeks 12y ago
  > At least everyone can agree that they don't like it for some reason, even if the reasons themselves contradict each other. How does too many features and missing features contradict each other? It's entirely possible for something to both have too many, unneeded features, while at the same time missing other important features.
- danneu 12y ago
  > In other words, HTTP2 sucks because it simultaneously > includes too many features, and not enough features. No, they are agreeing that it's a heap of extraneous features.

tonyarkles 12y ago

What is a "floating apex record"? I googled it in quotations, and you appear to be the only person who has ever said that combination of words in Google's index.

jacquesm 12y ago
floating -> pointing to an old resource apex record -> alias for 'A' record (DNS parlance) So a 'floating apex record' is an A-record pointing to an old IP.
- 0x0 12y ago
  I think "apex record" means the root domain name in a zone, and is unrelated to A records (except for the fact that you would usually make an A record for your apex so web browsers can reach your site even without a "www." subdomain/prefix)
  - jacquesm 12y ago
    That makes sense. Thanks!
- meddlepal 12y ago
  Have you ever considered just saying 'A record' instead of 'Apex record' so the majority of people know what you're talking about? Not all of us are DNS wonks.
  - jacquesm 12y ago
    I was just trying to figure out what the GGGP meant, that wasn't my choice of words. I'm not a DNS wonk either.
    - meddlepal 12y ago
      Sorry about that. I see now that I responded to the wrong person.
inopinatus 12y ago
An apex record is one at the root of a DNS zone. Sometimes called "naked domains". For example, in "https://github.com/" https://github.com/" they are the records particularly for "github.com", rather than for subdomains that might exist such as "www.github.com" or "gist.github.com". Apex records have a particular restriction: they cannot be aliases, because the apex includes DNS metadata that is not allowed to be aliased[3]. Read on for how this becomes a problem. I've used the term "floating" as a visual metaphor, because what I'm about to describe lacks a universal standard name, because it is an ugly hack: HTTP resolves endpoints using host records, so an URL of "https://github.com" https://github.com" means looking up A and AAAA records for "github.com". Yes, the protocol is arrogant enough[1] to assume that your host address for the whole domain is that of the web server. (This is why we ended up prepending "www" to domain names, as a service selector). In response to the query you get an IP address. Unfortunately, IP addresses sometimes change without warning. The most common example today is the loadbalancer offered by Amazon Web Services. The solution to this is to use an alias record in your human-friendly domain, pointing at an hidden technical domain that the infrastructure provider keeps up-to-date (e.g. "my-elb-name-1-1160186271.ap-southeast-1.elb.amazonaws.com") This is fine for "www.example.com" but not the naked "example.com", because aliases are prohibited at the apex. As a result, DNS providers such as Route 53 have ended up with a hack: a spoofed record at the apex, one that tracks an external resource and synthesizes a fake A/AAAA response. Now you have a naked domain that tracks, or rather hopes to track, the correct endpoint. But it changes with the wind. Hence my description of it as "floating". There is no consistent name for this kludge. AWS calls it an alias, and for reliability concerns restrict it to their own infrastructure only; DME call it an "ANAME" record [2]. The model can even be readily implemented as a shell script run out of cron on your nameserver. It is fragile, it is often unreliable, it is not at all standardised, and it doesn't scale beyond one service. One better solution would be to require use of SRV records, which allow one to declare instead, for example, an "https" service for "example.com". Alongside, let's say, the xmpp service, sip service, or any other service you care to announce. SRV records can exist at the apex. They can also bundle the A and AAAA (IPv6) addresses for the resulting endpoints in the answer, and select alternative port numbers without bothering the user about it. Not quite a universal panacea: there is a minor hazard of zone cuts that could increase the number of client lookups, but that's an edge case, not one you can easily blunder into and also easy to fix. [1] HTTP/1.0 and earlier are forgiven, because they hail from a time when you just had a web server in a rack and called it "www". But HTTP/2 is supposed to respond to modern architectures. [2] http://www.dnsmadeeasy.com/services/aname-records/ http://www.dnsmadeeasy.com/services/aname-records/ [3] none of you comedians are allowed to mention DNAME records as the exotic counterexample.

EvanAnderson 12y ago

I can't agree enough about the missed opportunity to use SRV records. This would have been such a monumental step forward. Edit: It makes me a bit giddy (which makes sense if you factor in my being a sysadmin) to think about what SRV records would've done for load-balancing, running servers on non-standard ports, IP address exhaustion, and server migrations. Anybody who doesn't appreciate proper service-location hasn't ever done serious sysadmin work and, IMO, has no business designing protocols.

AlyssaRowan 12y ago
You ever tested them on a large scale? I think agl did; the state of DNS resolution is, I'm afraid, really not pretty.
- justincormack 12y ago
  Have you got a reference?

haberman 12y ago

Grandparent says HTTP2 is a monstrosity, because it "includes a whole slew of features that we really don't need." You say you agree, because "the protocol does not specify how you determine what server to connect to." In other words, HTTP2 sucks because it simultaneously includes too many features, and not enough features. At least everyone can agree that they don't like it for some reason, even if the reasons themselves contradict each other.

runeks 12y ago
> At least everyone can agree that they don't like it for some reason, even if the reasons themselves contradict each other. How does too many features and missing features contradict each other? It's entirely possible for something to both have too many, unneeded features, while at the same time missing other important features.
danneu 12y ago
> In other words, HTTP2 sucks because it simultaneously > includes too many features, and not enough features. No, they are agreeing that it's a heap of extraneous features.