> When you hit “save”, the serial number (se) incremented to reflect the change. As clients everywhere evicted their last-retrieved cached copy of the pets.com

> When you hit “save”, the serial number (se) incremented to reflect the change. As clients everywhere evicted their last-retrieved cached copy of the pets.com zone, your new change (with its new serial) bubbled out across the internet, and some indeterminate time later it finished going “live”. This sorta implies the serial number has something to do with the caching mechanism, but it doesn’t. Record caching is based on the record TTLs only (which the author later mentions). The serial number was originally used by the BIND master/slave replication mechanism for zone files (so called “zone transfers”[0]), which occur out of band of normal DNS lookups. Other name servers could use it for similar purposes, since the serial number is required in the SOA record, but I don’t know if an so. (In fact, the formatting shown for zone files is specific to BIND. Other name server implementations have their own ways of storing the zone records.) This entire piece is written in a way that gives me a feeling that the author doesn’t fully understand DNS. That said, I do somewhat blame the original DNS RFCs. For a long time BIND was the only name server implementation, and the RFCs themselves reflect this with RFC 883 and its updates being as much about BIND itself as about DNS. The DNS RFCs are kinda unusual in that way. It would be like there being an RFC for a specific httpd implementation as part of the http RFCs. [0] https://cr.yp.to/djbdns/axfr-notes.html https://cr.yp.to/djbdns/axfr-notes.html