9 ms·

Could you (or someone) explain this? (I'm not arguing, I'm interested.)

by SiVal 7y ago

faeyanpiraat 7y ago
I'm interested in this aswell.
Eikon 7y ago
You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly: - Given a record `@ IN ALIAS example.org.`. - Pull records at `example.org` (maybe with an AXFR request but usually just individual records). - Merge our domain APEX with `example.org` records we just pulled. - Reply to requester with the merged zone, discarding the ALIAS record. Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.
- cbg0 7y ago
  What's so "nasty" about using ALIAS? > Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`. This is only true for cookies that are not set as `HostOnly` as far as I'm aware.
  - Eikon 7y ago
    > What's so "nasty" about using ALIAS? It's a not standard and therefore, is not a generally applicable solution. When something not standard becomes common practice and is expected, here comes the pain.
    - XelNika 7y ago
      I don't really see the issue. It changes nothing from the DNS client's perspective.
      - toast0 7y ago
        From the DNS client's perspective, there is a positive and a negative. Positive: since the server with an alias record actually returns an A/AAAA, a client doesn't have to contact any more servers to get the results. Negative: the servers for the CNAME target may be faster, relevant if the name is used beyond the A/AAAA TTL but sooner than the TTL would be set for a CNAME); or the servers for the target may be providing much finer targeting than is possibly by proxying.
    - cbg0 7y ago
      > When something not standard becomes common practice and is expected, here comes the pain. I think that's the case with most popular features before they become a standard. Personally, I've used ALIAS on AWS without a hitch for years.
    - SteveNuts 7y ago
      The standard should be amended for the modern web then. AWS's (and I'm sure many other's) implementation of this for their various load balancing, CDN services, etc. are critical to the health of the web now.
  - chrisweekly 7y ago
    Re: "... only true for cookies that are not set as 'HostOnly'" Technically, you're right -- but that implies a commitment to vigilance in setting that attribute on every instance of every cookie across every page or endpoint on your apex domain. Further, if you ever want to support some use of a subdomain, you have to deal with the ability of any page therein to set cookies on ".example.com". And when you inevitably miss any instance of any of these, you're unlikely to notice, because everything will still function normally. So in practice, using the apex paints you into a corner and makes the domain less useful. There's also the issue of DDOS attacks and related problems, for which the fastest and simplest mitigation is updating DNS entries for your CNAME(s). Why take that option off the table?
  - belorn 7y ago
    > What's so "nasty" about using ALIAS? The DNS server provide implements this differently, but the two "common" methods I know of is either aggressive caching or caching on request. In both cases the server becomes the client, breaks geoip, and create complexity where errors can easily slip in.
- 867-5309 7y ago
  unless I am hosting separate sites/IPs on subdomains, or have a complex cookie situation, I think the www. prefix seems vestigial/legacy and completely unneeded. I am actually in the opposite camp of not including it at all and redirecting to non-www. it sounds awfully ambiguous in speech ("double-u double-u double-u dot", "all the double-us dot", "dub dub dub dot", etc.) and most times multiplies the syllabic length of a "catchy" address. I even had an older client who said "stop" instead of "dot", and another who used @www. in an email address. I also think it looks silly and unprofessional on business cards, on the side of vans, etc., especially when http:// http:// and/or a trailing fowardslash is also included cringe. if it MUST exist, DNS does not always have to be involved, it could just be a simple http 301 forward or vhost config. we don't add :80 or :443 to the end of a web address. let the browser handle all that.
  - slig 7y ago
    Now that Chrome is hiding the "www." it's going to look more and more legacy. I still use the "www." and probably will continue using, but for business cards and things like that I always use the bare domain.
  - gregmac 7y ago
    It's worth making it exist and doing a 301 redirect. There's some people that will still type it, and others that will link it without checking, and they'll just think your site is broken. You're fighting against the grain for what's essentially a couple lines of config. It's not much different than using TLS for everything, but still handling and redirecting http:// http:// traffic (also doing a 301 redirect).
    - toast0 7y ago
      It's also useful to set hsts for the whole domain. I'm opinionated enough to say if you type http://example.org/foo http://example.org/foo, I'm just going to redirect that to https://www.example.org/ https://www.example.org/ but reasonable people could disagree (especially since Chrome has been going back and forth on displaying the actual URL and something that's vaguely similar to it)
- jbverschoor 7y ago
  ALIAS is not a valid record.
- omnimus 7y ago
  Noob question: Lets say i am fine with all going to www. or other subdomains mainly because i like using cname to point to other server. I still need to set some Apex record no? if A is blank i dont have anything to do the redirect to www. or what i am missing? Thank you!
  - jedberg 7y ago
    Yes, you still need an apex record with an actual IP address. And ideally something listening at that IP address that will redirect to the www address on both http and https.
johannes1234321 7y ago
There is lots on the DNS already. For the security argument: Consider you run on `example.com` and at a later stage add `[blog|forum|support|...].example.com` suddenly cookies from `example.com` might leak to those Subdomains. If you put cookies on `www.example.com` they won't leak to those.
- Avamander 7y ago
  Not if you set the Domain attribute of the cookie properly, this is a poor software problem, not second-level domain problem.
  - johannes1234321 7y ago
    True, but simple mitigations can be powerful ... Sidenote: If leaking cookies to your own subdomains is a risk, one might also have other problems already. Point is: I explained the potential risk. Evaluating one has to do oneself

Could you (or someone) explain this? (I'm not arguing, I'm interested.)

by SiVal 7y ago

Could you (or someone) explain this? (I'm not arguing, I'm interested.)

faeyanpiraat 7y ago

I'm interested in this aswell.

Eikon 7y ago

You can only put CNAME records at the zone APEX if there is no other records kinds as a CNAME is supposed to be a synonymous. If you had records such as: @ IN A 127.0.0.1 @ IN CNAME example.org. The server could not answer anything sensible as you now just introduced an ambiguity. The "nasty tricks" I was referring to is basically records such as ALIAS that you may find at some providers. The way they work is roughly: - Given a record `@ IN ALIAS example.org.`. - Pull records at `example.org` (maybe with an AXFR request but usually just individual records). - Merge our domain APEX with `example.org` records we just pulled. - Reply to requester with the merged zone, discarding the ALIAS record. Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`.

cbg0 7y ago
What's so "nasty" about using ALIAS? > Regarding cookies, the issue is that they are passed to subdomains so cookies that you set for `example.org` are also accessible from `*.example.org`. This is only true for cookies that are not set as `HostOnly` as far as I'm aware.
- Eikon 7y ago
  > What's so "nasty" about using ALIAS? It's a not standard and therefore, is not a generally applicable solution. When something not standard becomes common practice and is expected, here comes the pain.
  - XelNika 7y ago
    I don't really see the issue. It changes nothing from the DNS client's perspective.
    - toast0 7y ago
      From the DNS client's perspective, there is a positive and a negative. Positive: since the server with an alias record actually returns an A/AAAA, a client doesn't have to contact any more servers to get the results. Negative: the servers for the CNAME target may be faster, relevant if the name is used beyond the A/AAAA TTL but sooner than the TTL would be set for a CNAME); or the servers for the target may be providing much finer targeting than is possibly by proxying.
  - cbg0 7y ago
    > When something not standard becomes common practice and is expected, here comes the pain. I think that's the case with most popular features before they become a standard. Personally, I've used ALIAS on AWS without a hitch for years.
  - SteveNuts 7y ago
    The standard should be amended for the modern web then. AWS's (and I'm sure many other's) implementation of this for their various load balancing, CDN services, etc. are critical to the health of the web now.
- chrisweekly 7y ago
  Re: "... only true for cookies that are not set as 'HostOnly'" Technically, you're right -- but that implies a commitment to vigilance in setting that attribute on every instance of every cookie across every page or endpoint on your apex domain. Further, if you ever want to support some use of a subdomain, you have to deal with the ability of any page therein to set cookies on ".example.com". And when you inevitably miss any instance of any of these, you're unlikely to notice, because everything will still function normally. So in practice, using the apex paints you into a corner and makes the domain less useful. There's also the issue of DDOS attacks and related problems, for which the fastest and simplest mitigation is updating DNS entries for your CNAME(s). Why take that option off the table?
- belorn 7y ago
  > What's so "nasty" about using ALIAS? The DNS server provide implements this differently, but the two "common" methods I know of is either aggressive caching or caching on request. In both cases the server becomes the client, breaks geoip, and create complexity where errors can easily slip in.
867-5309 7y ago
unless I am hosting separate sites/IPs on subdomains, or have a complex cookie situation, I think the www. prefix seems vestigial/legacy and completely unneeded. I am actually in the opposite camp of not including it at all and redirecting to non-www. it sounds awfully ambiguous in speech ("double-u double-u double-u dot", "all the double-us dot", "dub dub dub dot", etc.) and most times multiplies the syllabic length of a "catchy" address. I even had an older client who said "stop" instead of "dot", and another who used @www. in an email address. I also think it looks silly and unprofessional on business cards, on the side of vans, etc., especially when http:// http:// and/or a trailing fowardslash is also included cringe. if it MUST exist, DNS does not always have to be involved, it could just be a simple http 301 forward or vhost config. we don't add :80 or :443 to the end of a web address. let the browser handle all that.
- slig 7y ago
  Now that Chrome is hiding the "www." it's going to look more and more legacy. I still use the "www." and probably will continue using, but for business cards and things like that I always use the bare domain.
- gregmac 7y ago
  It's worth making it exist and doing a 301 redirect. There's some people that will still type it, and others that will link it without checking, and they'll just think your site is broken. You're fighting against the grain for what's essentially a couple lines of config. It's not much different than using TLS for everything, but still handling and redirecting http:// http:// traffic (also doing a 301 redirect).
  - toast0 7y ago
    It's also useful to set hsts for the whole domain. I'm opinionated enough to say if you type http://example.org/foo http://example.org/foo, I'm just going to redirect that to https://www.example.org/ https://www.example.org/ but reasonable people could disagree (especially since Chrome has been going back and forth on displaying the actual URL and something that's vaguely similar to it)
jbverschoor 7y ago
ALIAS is not a valid record.
omnimus 7y ago
Noob question: Lets say i am fine with all going to www. or other subdomains mainly because i like using cname to point to other server. I still need to set some Apex record no? if A is blank i dont have anything to do the redirect to www. or what i am missing? Thank you!
- jedberg 7y ago
  Yes, you still need an apex record with an actual IP address. And ideally something listening at that IP address that will redirect to the www address on both http and https.

johannes1234321 7y ago

There is lots on the DNS already. For the security argument: Consider you run on `example.com` and at a later stage add `[blog|forum|support|...].example.com` suddenly cookies from `example.com` might leak to those Subdomains. If you put cookies on `www.example.com` they won't leak to those.

Avamander 7y ago
Not if you set the Domain attribute of the cookie properly, this is a poor software problem, not second-level domain problem.
- johannes1234321 7y ago
  True, but simple mitigations can be powerful ... Sidenote: If leaking cookies to your own subdomains is a risk, one might also have other problems already. Point is: I explained the potential risk. Evaluating one has to do oneself