Quoting Joachim Fahrner (jf@???):

> 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 abuse@??? . 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.)