[moving this to BALUG-Talk - as at least my mostly general responses aren't really all that highly BALUG (admin) specific]
Thanks for the excellent review! :-)
Some comments, etc, in-line below:
From: "Rick Moen" rick@linuxmafia.com Subject: [BALUG-Admin] balug.org DNS review Date: Wed, 27 Sep 2017 09:25:12 -0700
Just checking on things, in the wake of the departure from Dreamhost.
Yea departing DreamHost.com!!! (A.k.a. nightmare host <sigh>).
- We have three nameservers. This is in the recommended range,
barely: RFC2182 section 5 recommends at least 3. RFC1912 section 2.8 recommends no more than 7.
If we have one or two more friends running auth nameservers, adding them would be gravy.
Or, ... even not bother a friend and ... There are some free/complementary DNS slave services out there for the taking by any and/or all ... most of 'em suck (perhaps some exceptions?)
However, probably of note and worthy of consideration ...
balug.org has registrar gandi ... gandi offers complimentary DNS slave services. Now, I wouldn't want to be (too) dependent upon any given registrar, but, as far as I'm aware and what I've seen thus far, gandi's DNS complimentary slave service is basically rock solid and good - only minor thing I've noticed is updates - it either ignores them, or takes some modest bit of time to process them. But it does fully respect the TTLs and relevant SOA times, so as far as I'm aware all is fully within required specifications. I do have at least one (other) domain that uses gandi slave DNS for *one* (and only one) of its slave DNS servers ... so again - not too much in the way of dependencies, and sufficiently easy to break free should there ever be need/reason.
Another possible freebie worthy of considering - he.net - with account (which BALUG has, and uses for its IPv6 tunnel), complimentary DNS slave services are also offered. They seem to mostly/basically be quite "good", but come with a few caveats of note. They support *most* - but not *all* - RR types. So ... that's potentially an issue. As for updates, same kind of deal as gandi - except I think he.net explicitly ignores update notifications; but again, works fine regarding TTLs and SOA timing values. But a few more caveats for he.net free DNS. The setup is a bit funky - no way to introduce it without some DNS gotchas when being implemented. Notably (at last I futzed with it), one has to put the delegation in place *first* - so there will be some non-zero time when one has lame NS server(s) - basically after they're delegated, but before they pull and serve the zone data - and they won't pull and serve the zone data until their DNS data checks show that they're delegated - kind'a a Catch-22. Also, don't know that one can feasibly do less than *all* of he.net's DNS servers - they give you a set, they expect you to delegate to them. If they find you're not delegated to them, they drop the service. And ... is that an all or nothing? Doesn't seem to be specified in their documentation, so ... results of delegating less than the full set may be unspecified. *Other* than those few significant caveats, as far as I'm aware, their DNS slave service works perfectly fine - I had (maybe still have?) it on some domain(s) I dealt with. May have dropped it due to the particular limitations and such, though. Oh, and one other possible caveat ... been a while since I read their documents ... there *may* be some traffic limit/caveat? ... or maybe not - I don't recall, I'd have to look over their documentation again.
Anyway, yes, those (gandi complimentary and he.net free) DNS slave services, have some potential issues/limitations to consider ... but to give 'em credit too, also have some advantages. Notably they are pretty darn high availability. So that's more than many can offer strung at home on the end of a DSL or cable line or such, or even some host - even if it's in a colo or cloud or the like - if it doesn't have a high availability partner. Then again, for the infrastructure much of such DNS supports, particularly high availability on the DNS can be overkill - when all the services themselves may not be that high in reliability/availability. But still - dang important to have good solid DNS ... as when *that* is down solid - clients on The Internet can't in general even find out that what they're trying to get to is up or down or what the status is, and this also tends to cause or further complicate issues with various services (e.g. SMTP, among others).
So ... yes, ... adding a reasonably good reliable (needn't be super high on the reliability) DNS server would be a good thing, ... or more than one, up to total count of about 7 (precise maximum that's still optimal also depends upon the length of the domain name and some other DNS data factors ... e.g. optimal maximum for root (.) is a number larger than 7 ... but root domain (.) also has the shortest possible domain name. For domain names that are highly long, optimal maximum may be somewhat lower than 7 ... but 7 is optimal maximum for *most* typical domain names.
- No glue records for one nameserver (ns1.linuxmafia.com), because it
is out-of-bailiwick for the .org TLD nameservers. This means queries to it are just a little slower than to the other two for which glue information gets supplied.
If you want to fix that, assign my nameserver IP (198.144.195.186) the name NS2.BALUG.ORG in the domain record, removing the entry for NS1.LINUXMAFIA.COM. That fixes the glue records at the parent (.org) zone. And then don't forget to make the same switch in the in-zone records served at master nameserver NS1.BALUG.ORG.
Yes, thanks, noted ... will probably get around to that (time, priorities, that one is modest work for only slight/teensy gain ... so ... will likely take longer to get to it).
- Information leakage. NS1.BALUG.ORG / 198.144.194.238 answers
(correctly) CHAOS class queries about its version.
:r! dig version.bind txt chaos @NS1.BALUG.ORG +short "9.9.5-9+deb8u14-Debian"
It'd be a good idea to turn this off. I like to return amusing lies, myself. My stanza in /etc/bind/named.conf.options :
options { directory "/var/cache/bind"; version "Shirley, you're joking"; hostname "ns1.linuxmafia.com"; //server-id is essentially redundant to hostname, default is none //server-id none; auth-nxdomain no; # conform to RFC1035 allow-recursion { [redacted] }; allow-query { [redacted] }; dnssec-validation yes; };
Ah yes. :-) "Of course", there's almost always tradeoffs regarding security. E.g. convenience/speed vs. ... well, security and some information not being so convenient/available.
As for DNS server identifying its software/version ... what [il]legitimate uses for that? Well, there's negligible legitimate use, so general best practice is to disable that - or put in some bogus or intentionally misleading string. Legitimate uses of it being there? Mostly negligible ... but there are some slight ones. E.g. for local or secured environments/networks, can be useful/convenient. E.g. not much harm/risk exposing it on 127.0.0.1 and ::1. But ... open to The Internet ... makes it easier for bots/attackers to know the specific target software ... and thus more likely to be able to successfully attack. However, even if the information isn't made available, software can be probed/"fingerprinted", so even if the version information is disabled or altered, attackers may still figure out - if not precisely the target version - at least often approximately the target software and approximate version or some version range. So ... it's bit of tradeoff ... make the information (much) less accessible (or not) - and make attacker's challenge some fair bit more difficult (but not hugely more difficult). Oh, I did say some negligible legitimate uses ... even on The Internet - software surveys - those *can* be used for legitimate purposes. Can also be abused - particularly if the data isn't quickly rolled up into the aggregate, but hangs around (or leaks) with specific IPs and corresponding software information, etc. ... and especially if that is leaked or exposed in bulk.
I'm also curious - and don't recall - been long time since I read about it ... txt chaos ... that mechanism was put in BIND many many moons ago. Is it entirely (or mostly) unique to BIND? ... in which case even serving up a "dummy" answer would identify it as some flavor of BIND server. Or ... has other DNS server software adopted that same mechanism for reporting version (most notably if it's in as a default - I think most DNS software can do class CHAOS, though probably almost nobody explicitly implements such). Anyway, depending on the various DNS server software behavior - it may be better to, if feasible, disable that response rather than just put in some dummy response. Anyway, ... I'm curious what current best practice is in that regard for DNS servers - and BIND DNS servers. And I don't think I've any issues with, e.g. disabling it. I think thus so far in my life I've used it one to perhaps a few times. It's a "feature" (offering up its software and version information via DNS query) which is of very close to zero legitimate usefulness.