> Could it be a transient DNS/network problem? If it only You can check which nameservers are responsible:
1) with dns (/etc/resolv.conf) [user@server ~]$ dig +short radio-z.net ns robotns3.second-ns.com. ns1.first-ns.de. robotns2.second-ns.de. 2) with dns (tracing from dns root, asking every nameserver involved) [user@server ~]$ dig +trace radio-z.net ns . 454592 IN NS b.root-servers.net. net. 172800 IN NS a.gtld-servers.net. ;; Received 1168 bytes from 2001:500:9f::42#53(l.root-servers.net) in 16 ms radio-z.net. 172800 IN NS ns1.first-ns.de. ;; Received 687 bytes from 192.54.112.30#53(h.gtld-servers.net) in 21 ms radio-z.net. 86400 IN NS ns1.first-ns.de. ;; Received 138 bytes from 213.239.242.238#53(ns1.first-ns.de) in 25 ms 3) with whois [user@server ~]$ whois radio-z.net | egrep "Name Server" Name Server: NS1.FIRST-NS.DE Name Server: ROBOTNS2.SECOND-NS.DE Name Server: ROBOTNS3.SECOND-NS.COM And then ask all of them directly, like: [user@server ~]$ dig +short @ns1.first-ns.de mail.radio-z.net a 136.243.54.124 If this fails that nameserver does not respond or your dns query/answer gets lost in transit. Datacenters' dns resolvers are used by thousands of servers. While this usually works quite well I found it to be more stable to run a local dns resolver, especially for mailservers. Moreover, as Matus stated, a local resolver is better suited when using dns blocklists because most of them do have query limits. The chance of getting blocked by the blocklist is much lower using a local resolver because they just see a few queries from your source ip instead of thousands from the datacenter's resolver ip. Best regards Gerald
