[dns-wg] Updating RIPE 203

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  <dot at dotat.at>  http://dotat.at

> On 11 Aug 2017, at 15:40, Carsten Strotmann <carsten at strotmann.de> 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
>