Dear colleagues, RIPE document 203 "Recommended for DNS SOA values" gives recommendations for the values of the SOA record used in simple and stable zones. The document has been aimed at beginner level DNS administrators, to give guidance when creating a zone file. <https://www.ripe.net/publications/docs/ripe-203> The document has been successful, and despite its age, it is still being used and referred to today. Over time the document has aged and the recommendations given in the text are not a good match for today's Internet DNS anymore. Some while ago Peter Koch and I volunteered in the RIPE DNS WG to update the document. In my work (DNS training, consulting and support), I get occasional requests for recommendations for SOA values to use. This shows that such a document is still useful today. Before starting the process of wordsmithing the entire text, we would like to discuss the new values here in the mailing list. The aim for the document is not to provide the one and only set of "correct" values (there are many), but a set of values that are "not wrong" in most DNS use cases. Also keep in mind that the document should be of help for novice DNS administrators with relative simple zones (less than 1000 RRs, no more than 1 change/week). Large zones, very agile zones with dynamic changes, specialty zones like Active Directory zones are out of scope of the document. Like the original document, we present one set of values, not ranges. The document should be a "as simple as possible" starting point for new DNS admins. Copy and pasting is encouraged. As Roland v. Rijswijk mentioned in his talk at SHA 2017 last weekend (recommendation --> "OpenINTEL: digging in the DNS with an industrial size digger" https://media.ccc.de/v/SHA2017-130-openintel_digging_in_the_dns_with_an_indu...) the Internet is build on the premise of de-centralization. To support DNS operators today that like to run their own DNS infrastructure (instead going central in "the cloud"), the entry barrier for setting up a simple but working DNS zone should be as low as possible. The original SOA values for RIPE 203: example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 1999022301 ; serial YYYYMMDDnn 86400 ; refresh ( 24 hours) 7200 ; retry ( 2 hours) 3600000 ; expire (1000 hours) 172800 ) ; minimum ( 2 days) the new proposed and updated values $TTL 3600 example.com. 3600 SOA dns.example.com. hostmaster.example.com. ( 2017080101 ; serial YYYYMMDDnn 7200 ; refresh ( 2 hours) 1800 ; retry ( 30 minutes) 3600000 ; expire (1000 hours) 3600 ) ; minimum/negative TTL ( 1 hour) One observation from the past years is that in situations where the time required for an DNS change is longer that the average working day (8 hours), the change is more likely to fail. Operators get distracted and abandon the change or pick up the change at a later day having lost the context of the original intend for the change. The new values are chosen in a way that most changes to the DNS zone and infrastructure can be done in one work day. Lower values will cause more DNS queries and more load on the DNS infrastructure (resolver and authoritative server), but recent experiments ("How the TTL reducing impacted the .cz zone" https://en.blog.nic.cz/2017/05/18/how-the-ttl-reducing-impacted-the-cz-zone/) has shown that the effects are manageable. Some changes to the DNS infrastructure (like change of delegation information) depends on the TTL values used in the parent domain, but we also see a trend to use lower TTL values in the parent zones as well ("Keeping DNS Parents and Children in Sync at Internet Speed!, Olafur Gudmundsson, Cloudflare" https://ripe70.ripe.net/presentations/51-RIPE-20150309-cf-DNS.pdf). Given these constraints, we would like to get feedback from the mailing list on the new values: * do you see potential issues with the proposed values for zones that are in scope of the document? Best regards Carsten Strotmann