2

History: Everything starts with this log entry

postfix/smtpd[10001]: warning: x.x.x.x.list.dsbl.org: RBL lookup error: Host or domain name not found. Name service error for name=x.x.x.x.list.dsbl.org type=A: Host not found, try again

I've tried to resolve it manually, and indeed I've got a timeout. Trying to use Google's public DNS servers works fine, and here the drama begins:

I've configured the bind to allow recursion from localhost, and then switched the DNS server is /etc/resolv.conf to use 127.0.0.1 as a name server. Also, I've tried to specify google's public DNS servers as forwarders, and without them (asking the root servers). The results are identical:

dig a 1.2.3.4.list.dsbl.org

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a 1.2.3.4.list.dsbl.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 12810 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;1.2.3.4.list.dsbl.org. IN A

;; Query time: 0 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 04 12:55:36 UTC 2017 ;; MSG SIZE rcvd: 50

After 3-4 seconds, it fails. Trying the Google's public DNS:

dig a 1.2.3.4.list.dsbl.org @8.8.8.8

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a 1.2.3.4.list.dsbl.org @8.8.8.8 ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62982 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;1.2.3.4.list.dsbl.org. IN A

;; Query time: 28 msec ;; SERVER: 8.8.8.8#53(8.8.8.8) ;; WHEN: Wed Jan 04 12:57:28 UTC 2017 ;; MSG SIZE rcvd: 50

while this one works

dig a somedomain.com

; <<>> DiG 9.9.5-9+deb8u7-Debian <<>> a somedomain.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35713 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5

;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;somedomain.com. IN A

;; ANSWER SECTION: somedomain.com. 300 IN A 69.172.201.153

;; AUTHORITY SECTION: somedomain.com. 172800 IN NS sell.internettraffic.com. somedomain.com. 172800 IN NS buy.internettraffic.com.

;; ADDITIONAL SECTION: buy.internettraffic.com. 172800 IN A 64.96.240.54 buy.internettraffic.com. 172800 IN A 64.96.241.73 sell.internettraffic.com. 172800 IN A 176.74.176.176 sell.internettraffic.com. 172800 IN A 176.74.176.175

;; Query time: 49 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Wed Jan 04 12:56:30 UTC 2017 ;; MSG SIZE rcvd: 176

Footnote: Using only google's DNS in /etc/resolv.conf works fine locally, when I restart postfix, the file is being copied in /var/spool/postfix/etc/resolv.conf but still the same log that host could not be resolved.

What am I missing?

Improve this question

2 Answers 2

Reset to default
3

DSBL has been discontinued at the end of 2008; and for a good while (one year?) their DNS still resolved the queries.

While some old instructions might refer to their blacklist/domain, it is not advisable to have that list configured, as it is long gone, and the DNS requests do not resolve anymore.

Google DNS have shortcuts/optimisations to address known problems and this domain is probably in a blacklist or some sort of RPZ configuration; in their operation in large scale I would also do the same to addresses that are still configured at large, as trying to solve non-existant domains takes up valuable resources.

Somes similar configurations also are a part of being a "nice" netizen, as creating similar blacklists filter requests and the net result is saving up resources on the top root name servers (TLDs).

Reenforcing the idea of Google customisations, it is common knowledge they have custom code, and pretty well known they (used to) have some "unusual" functionalities, like for instance, ignoring too low TTLs in RR in the name of performance. (since then, BIND has created a global option to define the lower TTLs you accept for a RR, if I am not mistaken)

I have no idea as you have a server that survived so long with a dsbl.org blacklist configured, as when this address was discontinued we have to take it off from the blacklist configurations due to email server delays.

As requested, to blacklist a domain in BIND:

zone file in /etc/bind/rpz.db

*.list.dsbl.org CNAME   *.

add the zone file to named.conf or to a defined internal view:

zone "rpz" {
  type master;
  file "/etc/bind/rpz.db";
  allow-query { your_internal_network; };
};

Add to named.conf.options:

options {
   ...
   response-policy { zone "rpz"; };
}

Please also see:

Large zone file for bind9 : ad-blocking

Configure BIND as Forwarder only (no root hints), encrypted + RPZ blacklist / whitelist all together

Bind RPZ config with domains of various levels

Improve this answer
5
  • 1
    Thank you! I'm going to select this as an answer because of the Google's DNS suggestion. Actually I'm taking care of this server since few days, and exactly the delays forced me to take a closer look at the logs.
    – Stanimir Stoyanov
    Jan 4, 2017 at 13:14
  • 1
    (I also blacklist here a couple of domains like this, and also all RFC 1918 reverses requests in other not to overload root name servers with spurious requests)
    – Rui F Ribeiro
    Jan 4, 2017 at 13:15
  • Can you update your answer with a sample BIND config doing so? I believe it'll be useful. Thanks.
    – Stanimir Stoyanov
    Jan 4, 2017 at 13:18
  • sure, give me a couple of minutes.
    – Rui F Ribeiro
    Jan 4, 2017 at 13:20
  • 1
    Thank you, this will be a great help, as when it comes to forwarding, I was just disabling it and it makes a perfect sense to have such configuration.
    – Stanimir Stoyanov
    Jan 4, 2017 at 13:22
1

DSBL is GONE DSBL is GONE and highly unlikely to return. Please remove it from your mail server configuration.

Improve this answer
0

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .