Serial numbers should ideally be managed automatically, so that you don't have to care, but ISO 8601 style is definitely the most friendly of the common options.
The minimum/negative TTL should match the default TTL, and I agree 1 hour is a good starting point. Regarding the refresh timer, NOTIFY should make it irrelevant, but there are cases like stealth secondaries where it still matters. I think that batch rebuild jobs are most easy to communicate to colleagues if they happen hourly, so the refresh time should probably be 1 hour, to match. (The result is that routine updates propagate within an hour if things are working properly, or two hours in awkward cases.) I agree with Paul that a short retry timer also makes sense, so recovery from failure is short. I use 15 minutes, but it is happily not something I have had to worry about :-) Novices are not expected to be responsible for DNSSEC but they might be looking after a zone signed by someone else. In a signed zone, the expiry time needs to be less than the RRSIG lifetime. A broken secondary should return an error (making resolvers try other, hopefully working, secondaries) before it returns bogus data. The default RRSIG lifetime (in BIND and I think other signers) is 30 days and records are re-signed weekly, so the default expiry time should be about 3 weeks (500 hours). Tony. -- f.anthony.n.finch <[email protected]> http://dotat.at > On 11 Aug 2017, at 15:40, Carsten Strotmann <[email protected]> wrote: > > 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_industrial_size_digger) > 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 >
