[conspire] DNS ... data, requirements/recommendations, registrars & requirements, etc.

[Rick Moen]

Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):

> >And last, the management of the domains themselves (at the registrars)
> >has a bunch of best-practices constraints that closely tie in to the
> >DNS.  And this isn't well documented in a single place, let alone my
> >magazine articles, either.
> 
> As for much of the DNS data bits, I have my "cheat sheet" for the bits
> I'm most likely to not fully remember ... list probably isn't fully
> up-to-date, but probably the most commonly useful bit is towards the end:

As good a place as any to say that my _current_ candidate for a
reasonable DNS / domain-administration tutorial is Zytrax's online 
book 'DNS for Rocket Scientists', http://www.zytrax.com/books/dns/ .
I haven't read it in great detail, but the little bit I've read
seems promising.  Also, these are the guys who published the essential
'BIND9 Secure Template' pages, which ARAIK have now been merged into the
aforementioned book.

> $  ls -l RFCs_and_recommendations; cat RFCs_and_recommendations
> -rw------- 1 root bind 1184 Oct 29  2016 RFCs_and_recommendations
> ;RFCs:
> 1034 http://www.ietf.org/rfc/rfc1034.txt
> 1035 http://www.ietf.org/rfc/rfc1035.txt
> 1123 http://www.ietf.org/rfc/rfc1123.txt
> 1591 http://www.ietf.org/rfc/rfc1591.txt
> 2181 http://www.ietf.org/rfc/rfc2181.txt
> 2308 http://www.ietf.org/rfc/rfc2308.txt
> 2536 http://www.ietf.org/rfc/rfc2536.txt
> 3110 http://www.ietf.org/rfc/rfc3110.txt
> 3226 http://www.ietf.org/rfc/rfc3226.txt
> 3658 http://www.ietf.org/rfc/rfc3658.txt
> 4034 http://www.ietf.org/rfc/rfc4034.txt
> 4035 http://www.ietf.org/rfc/rfc4035.txt
> 4641 http://www.ietf.org/rfc/rfc4641.txt
> 4648 http://www.ietf.org/rfc/rfc4648.txt
> 4697 http://www.ietf.org/rfc/rfc4697.txt
> 5011 http://www.ietf.org/rfc/rfc5011.txt
> 5933 http://www.ietf.org/rfc/rfc5933.txt
> 6605 http://www.ietf.org/rfc/rfc6605.txt

But reading RFCs proves, in my experience, to be an abysmal way to learn
DNS or any similar topic.  They're just not efficient to learn from, 
probably for a lot of reasons I don't care to sit down and figure out.
Essential as a reference, but not a suitable tutorial, at all.

> Recommendations (requirements for some):
> NS matched between glue/authority and zone
> NS TTL - recommended same as authority TTL
> SOA TTL match to NS TTL
> MNAME - master
> RNAME - working email
> SERIAL YYYYMMDDnn (recommended) or unsigned 32-bit int (requierd)
> REFRESH 3600 - 86400 (1h - 1d)
> RETRY 900 - 28800 (3m - 8h) between 1/8 and 1/3 of REFRESH
> EXPIRY 604800 - 3600000 (1w - 1000h (5w6d16h))
> MINIMUM Negative Cache TTL 180 - 86400 (3m-1d)

The dnssuff.com 'DNS Report' CGI is useful in finding some of these 
desiderata, though I continue to politely disagree with the author's
contention on some, e.g., his statement that it's always a good idea for
a domain to have at least one backup MX.

(Because, in recent years, the author has been trying to monetise public
use of his CGIs, after a couple of uses of 'DNS Report', one must clear
HTTP cookies or the CGI will hold out its tin pan and request you to
subscribe for paid access.)

[snip DEnic stories]

> Don't know if it's still the case, but I recall from much earlier,
> in DE, if you bought a new bicycle, it came equipped with buit-in
> light, and fenders attached ... as required by law.

Heh.  Alles in ordnung!