[dns-wg] Updating RIPE 203

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