1

Let's say I need to change the CNAME for my subdomain test.mysite.example. I want it to go to a load balancer endpoint aws-my-endpoint.example.

But in creating the CNAME, I type it wrong. e.g. aw-my-endpoint.example.

Since it's possible that a client can cache DNS for up to 48hrs (despite what the TTL setting is), could this cause test.mysite.example to be down for 48hours? Even though I immediately fix the CNAME after noticing the typo?

  • 1
    " a client can cache DNS for up to 48hrs (despite what the TTL setting is), " Where does that come from exactly? This is mostly a myth. Recursive resolvers sometimes violate the TTL and cache results for longer than expected but this is usually the case of TTL insanely low already, typically under 5 minutes. – Patrick Mevzek Jul 23 at 4:33
  • tiger-computing.co.uk/myth-dns-propagation . this site is titled "the myth of dns propogation", yet it clearly states: "But there’s still a (minor) problem. Some ISPs configure their DNS servers to cache for long periods regardless of the TTL value. There’s not much you can do about that; even if you don’t use those ISPs yourself, you web visitors may do." – mcs Jul 23 at 15:24
  • The fact that some ISPs are bad apple is known, yes, but that has nothing to do with the myth that DNS changes propagate. They do not, as DNS is not top down, when you change your authoritative nameserver, nothing happens anywhere else, until some recursive nameserver query your authoritative one. So it is bottom up, not top down. Hence no propagation. – Patrick Mevzek Jul 23 at 15:26
  • makes sense. I guess instead of the term 'propogate', im meaning that your site could be down for up to 48hours "from the viewpoint of the client". – mcs Jul 23 at 17:44
  • But why 48hours? Why not 50? or 96? Why is 48 hours a magic value somehow? Or there is a study that tells that all bad ISPs cap their cache at 48 hours? I doubt so. Hence I prefer not to give specific timeframes in cases like that, besides that the TTL says, with the always caveat emptor that yes any actor on the network can misbehave and introduce pecularities. Note however that browsers favor more and more DNS over HTTPS and hence bypassing completely the ISP for name resolution... – Patrick Mevzek Jul 23 at 17:46
1

As soon as you change your records, one recursive nameserver can query for it, and hence grab the "bad" value and then cache it, for either its TTL or the negative TTL depending on what is the record and the response exactly.

If you did in fact really reload the nameservers with the bad value.

Also, there are offline checker. named-checkzone for example is capable of verifying multiple things on a zone before it is loaded for live queries (but not really for CNAME records, mostly for MX, SRV and NS ones). In the same way, a smart provider giving you some kind of UI for your DNS records could detect things like this beforehand (but it should be mostly a warning and not necessarily a block, you could want to enter such invalid CNAME in preparation of further operations later).

| improve this answer | |
  • "Negative TTL". So what is the worst case scenario for downtime with a TTL set for 5 minutes? – mcs Jul 23 at 14:55
  • The negative TTL is the last value in the SOA, previously called the Minimum TTL. If you query now for a not existing record, it will be cached by the recursive nameserver having asked for it, for a duration normally up to the negative TTL (which is 1 day for example in com.). If right after this query you add the record in your nameservers, it may not be seen for up the negative TTL delay. – Patrick Mevzek Jul 23 at 17:34
  • i see. im not familiar with the SOA. is this a file I need to be aware of along with the zone file? – mcs Jul 23 at 17:47
  • SOA is a one record type, that exists for all zones. It is in the zonefile. Do dig SOA with any domain and you will see it. – Patrick Mevzek Jul 23 at 21:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.