Quoting Joachim Fahrner (j...@fahrner.name):
> Normally name resolution works fine, and tupac2.dyne.org is the only
> server with such errors in my postfix log. I'm using unbound on
> Devuan as a local caching recursive dns server.
Good choice.
> Could it be that dyne.org name servers have temporary connection
> problems?
On a quick, broad check, dyne.org DNS seems robust.
There are three network-diverse authoritative nameservers (refreshing to
see after observing far too many domains attempting to get by with two,
when RFCs require 3-7 auth nameservers[1]), all returning correct
responses on both UDP and TCP. The SOA EXPIRE value (86400 seconds) is
too short. RFC 1912 section 2.2 suggests a value between 1209600 and
2419200. I personally tend to go with 2419200 = 28 days. (This SOA
subfield denotes how long a secondary will still treat its copy of the
zone data as valid if it can't contact the primary.)
I can't exclude the possiblility that one or two of the three auth
nameservers occasionally flakes out, though that seems a-priori less
likely than some other cause. The DNS as a whole seems very competently
administered (and I'm persnickety about such things).
There are two small nitpicks I would make, that I hope would slightly
improve the domain's service:
1. Arguably it's a slight security error to permit the three
nameservers to give accurate responses when asked for their software
versions. I mean like this:
$ dig +short @ns.dyne.org dyne.org version.bind txt chaos
178.62.255.220
"9.9.5-9+deb8u11-Debian"
$ dig +short @ns2.dyne.org dyne.org version.bind txt chaos
178.62.255.220
"9.9.5-9+deb8u10-Debian"
$ dig +short @ns3.dyne.org dyne.org version.bind txt chaos
178.62.255.220
"9.9.5-9+deb8u11-Debian"
$
Compare my five auth nameservers for linuxmafia.com:
$ dig +short @ns1.linuxmafia.com linuxmafia.com version.bind txt chaos
198.144.195.186
"Shirley, you're joking"
[rick@linuxmafia]
$ dig +short @ns.primate.net linuxmafia.com version.bind txt chaos
198.144.195.186
[rick@linuxmafia]
$ dig +short @ns1.thecoop.net linuxmafia.com version.bind txt chaos
198.144.195.186
"Puddin Tane, ask me again, I'll tell you the same."
[rick@linuxmafia]
$ dig +short @ns.tx.primate.net linuxmafia.com version.bind txt chaos
198.144.195.186
[rick@linuxmafia]
$ dig +short @ns3.linuxmafia.com linuxmafia.com version.bind txt chaos
198.144.195.186
"none"
$
Example setup snippet from BIND9's Options stanza (on ns1.linuxmafia.com's
/etc/bind/named.conf.options) to curtail reporting of the VERSION.BIND
reference record in the CHAOS class:
version "Shirley, you're joking";
hostname "ns1.linuxmafia.com";
There are three RRs in the CHAOS class defined by RFC 4892:
VERSION.BIND, ID.SERVER, and HOSTNAME.BIND. The above two option lines
define two of the three. The third (ID.SERVER) fortunately defaults to
null ('none'), but can be explicitly defined, too, which is why I have
these comment lines to note the fact:
//server-id is essentially redundant to hostname, default is none
//server-id none;
Similar steps can and should be taken in NSD and other good
authoritative nameservers to control information leakage, IMO.[2]
2. The two MXes both refuse delivery of mail addressed to the
RFC-mandated abuse address.
50 5.1.1 : Recipient address rejected: User unknown in virtual
mailbox table
Because dyne.org accepts SMTP mail, RFC2142 Section 2 requires that the
domain accept mail addressed to ab...@dyne.org . Additionally, some
domains will consider suspcious any mail domain that fails
RFC-compliance testing including acceptance of mail addressed to the
postmaster or abuse accounts.
IMO, abuse@ is every bit as mandatory as postmaster@ is, for
SMTP-receiving domains.
Again, overall, the dyne.org DNS strikes me as excellent.
[1] Reference for minimum 3: RFC2182 section 5.
Reference for maximum 7: RFC1912 section 2.8.
[2] Hiding version numbers doesn't actually protect anything, but
giving attackers that information for free is never a good idea, and
on the public Internet there seems to be no legitimate purpose for
providing accurate values. (If there is, I've not seen it.)
_______________________________________________
Dng mailing list
Dng@lists.dyne.org
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
