Because it’s super old fashioned. I’d expect that most of the time you host a website, you want your default domain to be the website, because that’s almost exclusively the one people might have to type in or read.
You can use content-type, accept, and/or user-agent headers to route to the appropriate non-html resources and APIs, or if you really need, those are the resources hidden behind client-specific or purpose-specific subdomains.
If they’re not making their default domain their website, then I don’t believe they take their website seriously.
There are many many reasons you don’t want to (or can’t) have the apex of your domain (what you’re calling the “default domain”) the primary domain name of your site. I thought you were going to argue in favor of like “home.[domain].com” or something.
The first and foremost issue is that if you wish to use a CDN, many CDN’s require a CNAME to function properly. You can’t have a CNAME share space with any other record (RFC 1912) which completely precludes using an MX record (for email) or TXT records for DKIM, SPF, and DMARC. (You need those for a secure email service). Having the CNAME sit as a subdomain of the apex (such as www) allows you to maintain those records in your domain while also serving people using that CNAME. (Some CDN’s such as Akamai even have special proprietary records that function like a CNAME while returning A records just to make this work)
I’m skeptical that you’re giving the full story, given the number of popular websites I see that use apex domains and have assets on the page that they’d want to deliver via CDN.
You don’t typical have your webpage itself delivered by CDN, you have your static assets delivered by CDN. Why can’t you put your static assets in a subdomain that gets a CNAME? Then your apex domain is also a host, and the webserver at the host is able to serve content / proxy according to the request headers.
If your entire website is static content, then I’m probably not taking it very seriously.
No, you’re right. There’s a much bigger story here. I was just trimming out a lot of it since I don’t normally run into people who can follow along easily. Akamai, for example, uses the proprietary AKAMAICDN record to allow the functionality of a CNAME. For example: foo.com AKAMAICDN’s to foo.com.edgekey.net (edgekey.net of course being the Akamai edge server suite). So someone using Akamai can do that to allow them to use the apex (but will still very likely have a www.foo.com CNAME foo.com setup to catch people who did a www anyway) Cloudflare uses CNAME flattening to “cheat” the CNAME rules by doing the CNAME DNS lookup internally and pretending to be authoritative for the request.
You don’t typical have your webpage itself delivered by CDN, you have your static assets delivered by CDN. Why can’t you put your static assets in a subdomain that gets a CNAME?
You can most certainly put static assets in a specific subdomain (and in fact, that’s how most setups are), but the CDN itself often requires handling the entire request at the beginning. You don’t want, for example, an A record at the apex pointing directly at your origin servers (terrible idea for security & performance; kind of defeats the purpose of the CDN), instead you want the user to connect to an edge server and have that edge server immediately serve the static content while the origin is contacted by the edge server for any non-static content that the user needs. This allows the CDN to do their cloud magic while your origin servers can do as little work as possible with as few people as possible. Effectively, you can block all requests to your servers that are not from your CDN. Many CDNs these days are also a major security feature.
So this is right at the limits of my understanding - I’m not a web admin, and I’m not a DNS dev; I’m a webapp backend dev. I’m coming at this from the perspective of best-practices for API and service design.
I’m generally talking about webpages that are services, both because that’s what I work on, and because that’s when trust actually matters to me. In these cases, a lot of page content is dynamic and cannot be hosted by a CDN.
For domains that are hosting services, it makes sense to have a subdomain for each service or class or service, but the only client that makes the URL visible is the browser so I want my landing page to not require typing in a subdomain, to reduce friction.
Subdomains are then defined by their purpose to the user, not by the type of resource they’re hosting. The typo of resource is determined by the accept header. If a client wants to access a resource using HTML or by xml or by json or by txt, they specify that in the header, and the webserver returns the resource in the requested representation.
Using a subdomain for a specific representation rather than for a specific utility seems lazy, which sets off red flags, if I’m required to enter it.
Edit, just in case it’s useful to explain what I mean by subdomain “purpose”.
To use a fictional version of Google where they didn’t have separate branding for all their services.
Search: search.google.com
Video: video.google.com
Music: music.video.com
Gmail: mail.google.com
Productivity suite: office.google.com
Etc.
These are what I feel subdomains are best used for. Clients can use headers to control how the resources for each of those services get represented. You don’t have representation-specific subdomains. If you only offer one service, then you don’t need subdomains; you can still have them but don’t force your users to use it, and probably still best to name it after the purpose, in case the company expands into other product domains.
It’s like the difference between “package by feature” and “package by layer”. Having a representation-specific subdomain is packaging by layer.
I’m skeptical that you’re giving the full story, given the number of popular websites I see that use apex domains and have assets on the page that they’d want to deliver via CDN.
Have you tried accessing a www subdomain on those popular websites? I guarantee you that they are there.
Why not? (Serious question, I’m a DNS engineer so this is super relevant to me)
Because it’s super old fashioned. I’d expect that most of the time you host a website, you want your default domain to be the website, because that’s almost exclusively the one people might have to type in or read.
You can use
content-type,accept, and/oruser-agentheaders to route to the appropriate non-html resources and APIs, or if you really need, those are the resources hidden behind client-specific or purpose-specific subdomains.If they’re not making their default domain their website, then I don’t believe they take their website seriously.
There are many many reasons you don’t want to (or can’t) have the apex of your domain (what you’re calling the “default domain”) the primary domain name of your site. I thought you were going to argue in favor of like “home.[domain].com” or something.
The first and foremost issue is that if you wish to use a CDN, many CDN’s require a CNAME to function properly. You can’t have a CNAME share space with any other record (RFC 1912) which completely precludes using an MX record (for email) or TXT records for DKIM, SPF, and DMARC. (You need those for a secure email service). Having the CNAME sit as a subdomain of the apex (such as www) allows you to maintain those records in your domain while also serving people using that CNAME. (Some CDN’s such as Akamai even have special proprietary records that function like a CNAME while returning A records just to make this work)
I’m skeptical that you’re giving the full story, given the number of popular websites I see that use apex domains and have assets on the page that they’d want to deliver via CDN.
You don’t typical have your webpage itself delivered by CDN, you have your static assets delivered by CDN. Why can’t you put your static assets in a subdomain that gets a CNAME? Then your apex domain is also a host, and the webserver at the host is able to serve content / proxy according to the request headers.
If your entire website is static content, then I’m probably not taking it very seriously.
No, you’re right. There’s a much bigger story here. I was just trimming out a lot of it since I don’t normally run into people who can follow along easily. Akamai, for example, uses the proprietary AKAMAICDN record to allow the functionality of a CNAME. For example: foo.com AKAMAICDN’s to foo.com.edgekey.net (edgekey.net of course being the Akamai edge server suite). So someone using Akamai can do that to allow them to use the apex (but will still very likely have a www.foo.com CNAME foo.com setup to catch people who did a www anyway) Cloudflare uses CNAME flattening to “cheat” the CNAME rules by doing the CNAME DNS lookup internally and pretending to be authoritative for the request.
You can most certainly put static assets in a specific subdomain (and in fact, that’s how most setups are), but the CDN itself often requires handling the entire request at the beginning. You don’t want, for example, an A record at the apex pointing directly at your origin servers (terrible idea for security & performance; kind of defeats the purpose of the CDN), instead you want the user to connect to an edge server and have that edge server immediately serve the static content while the origin is contacted by the edge server for any non-static content that the user needs. This allows the CDN to do their cloud magic while your origin servers can do as little work as possible with as few people as possible. Effectively, you can block all requests to your servers that are not from your CDN. Many CDNs these days are also a major security feature.
So this is right at the limits of my understanding - I’m not a web admin, and I’m not a DNS dev; I’m a webapp backend dev. I’m coming at this from the perspective of best-practices for API and service design.
I’m generally talking about webpages that are services, both because that’s what I work on, and because that’s when trust actually matters to me. In these cases, a lot of page content is dynamic and cannot be hosted by a CDN.
For domains that are hosting services, it makes sense to have a subdomain for each service or class or service, but the only client that makes the URL visible is the browser so I want my landing page to not require typing in a subdomain, to reduce friction.
Subdomains are then defined by their purpose to the user, not by the type of resource they’re hosting. The typo of resource is determined by the
acceptheader. If a client wants to access a resource using HTML or by xml or by json or by txt, they specify that in the header, and the webserver returns the resource in the requested representation.Using a subdomain for a specific representation rather than for a specific utility seems lazy, which sets off red flags, if I’m required to enter it.
Edit, just in case it’s useful to explain what I mean by subdomain “purpose”.
To use a fictional version of Google where they didn’t have separate branding for all their services.
Search: search.google.com
Video: video.google.com
Music: music.video.com
Gmail: mail.google.com
Productivity suite: office.google.com
Etc.
These are what I feel subdomains are best used for. Clients can use headers to control how the resources for each of those services get represented. You don’t have representation-specific subdomains. If you only offer one service, then you don’t need subdomains; you can still have them but don’t force your users to use it, and probably still best to name it after the purpose, in case the company expands into other product domains.
It’s like the difference between “package by feature” and “package by layer”. Having a representation-specific subdomain is packaging by layer.
Have you tried accessing a www subdomain on those popular websites? I guarantee you that they are there.
That’s fine, but that’s not the url I had to type in or navigate to.
You said that you don’t trust it. Yet all of these websites have it.
What don’t you trust? Whether you type in www or not, it goes to the same place.
To me, it’s a sign of a lack of care, if their main landing page is at a subdomain specific to a type of resource (HTML).
I hesitate to trust service built with a perceived lack of care.