4 ms·

I don’t believe that there is anything necessarily which requires DNS configs to be global. You can shard your service behind multiple names: my-service-1.exa

I don’t believe that there is anything necessarily which requires DNS configs to be global. You can shard your service behind multiple names: my-service-1.example.com my-service-2.example.com my-service-3.example.com … Then you can create smoke tests which hit each phase of the DNS and if you start getting errors you stop the rollout of the service.

creatonez 11mo ago
Sure, but that doesn't really help for user-facing services where people expect to either type a domain name in their browser or click on a search result, and end up on your website every time. And the access controls of DNS services are often (but not always) not fine-grained enough to actually prevent someone from ignoring the procedure and changing every single subdomain at once.
- __turbobrew__ 11mo ago
  > Sure, but that doesn't really help for user-facing services where people expect to either type a domain name in their browser or click on a search result, and end up on your website every time. It does help. For example, at my company we have two public endpoints: company-staging.com company.com We roll out changes to company-staging.com first and have smoke tests which hit that endpoint. If the smoketests fail we stop the rollout to company.com. Users hit company.com
  - cowsandmilk 11mo ago
    That doesn’t help with rolling out updates to the DNS for company.com which is the point here. It’s always DNS because your pre-production smoke tests can’t test your production DNS configuration.
    - FLHerne 11mo ago
      If I'm understanding it right, the idea is that the DNS configuration for company-staging.com is identical to that for company.com - same IPs and servers, DNS provider, domain registrar. Literally the only differences are s/company/company-staging/, all accesses should hit the same server with the same request other than the Host header. Then you can update the DNS configuration for company-staging.com, and if that doesn't break there's very little scope for the update to company.com to go differently.
      - creatonez 11mo ago
        The purpose of a staged rollout is to test things with some percentage of actual real-world production traffic, after having already thoroughly tested things in a private staging environment. Your staging URL doesn't have that. Unless the public happens to know about it. The scope for it to go wrong is the differences in real-world and simulation. It's a good thing to have, but not a replacement for the concept of staged rollout.
  - deleted 11mo ago
    [deleted]
crazygringo 11mo ago
But users are going to example.com. Not my-service-33.example.com. So if you've got some configuration that has a problem that only appears at the root-level domain, no amount of subdomain testing is going to catch it.

creatonez 11mo ago

Sure, but that doesn't really help for user-facing services where people expect to either type a domain name in their browser or click on a search result, and end up on your website every time. And the access controls of DNS services are often (but not always) not fine-grained enough to actually prevent someone from ignoring the procedure and changing every single subdomain at once.

__turbobrew__ 11mo ago
> Sure, but that doesn't really help for user-facing services where people expect to either type a domain name in their browser or click on a search result, and end up on your website every time. It does help. For example, at my company we have two public endpoints: company-staging.com company.com We roll out changes to company-staging.com first and have smoke tests which hit that endpoint. If the smoketests fail we stop the rollout to company.com. Users hit company.com
- cowsandmilk 11mo ago
  That doesn’t help with rolling out updates to the DNS for company.com which is the point here. It’s always DNS because your pre-production smoke tests can’t test your production DNS configuration.
  - FLHerne 11mo ago
    If I'm understanding it right, the idea is that the DNS configuration for company-staging.com is identical to that for company.com - same IPs and servers, DNS provider, domain registrar. Literally the only differences are s/company/company-staging/, all accesses should hit the same server with the same request other than the Host header. Then you can update the DNS configuration for company-staging.com, and if that doesn't break there's very little scope for the update to company.com to go differently.
    - creatonez 11mo ago
      The purpose of a staged rollout is to test things with some percentage of actual real-world production traffic, after having already thoroughly tested things in a private staging environment. Your staging URL doesn't have that. Unless the public happens to know about it. The scope for it to go wrong is the differences in real-world and simulation. It's a good thing to have, but not a replacement for the concept of staged rollout.
- deleted 11mo ago
  [deleted]

crazygringo 11mo ago

But users are going to example.com. Not my-service-33.example.com. So if you've got some configuration that has a problem that only appears at the root-level domain, no amount of subdomain testing is going to catch it.