rbldnsd returns NXDOMAIN for ENTs (Empty Non-Terminals)

[twesterhever]

Quoted from RFC 7816, section 3:

A problem can also appear when a name server does not react properly
to ENTs (Empty Non-Terminals). If ent.example.com has no resource
records but foobar.ent.example.com does, then ent.example.com is an
ENT. Whatever the QTYPE, a query for ent.example.com must return
NODATA (NOERROR / ANSWER: 0). However, some name servers incorrectly
return NXDOMAIN for ENTs. If a resolver queries only
foobar.ent.example.com, everything will be OK, but if it implements
QNAME minimisation, it may query ent.example.com and get an NXDOMAIN.
See also Section 3 of [DNS-Res-Improve] for the other bad
consequences of this bad behaviour.

It seems like rbldnsd shows exactly the same behaviour:

user@work:~$ host -t A 2.0.0.127.zen.spamhaus.org
2.0.0.127.zen.spamhaus.org has address 127.0.0.4
2.0.0.127.zen.spamhaus.org has address 127.0.0.2
2.0.0.127.zen.spamhaus.org has address 127.0.0.10
user@work:~$ host -t A 127.zen.spamhaus.org
Host 127.zen.spamhaus.org not found: 3(NXDOMAIN)

As mentioned above, the latter one must return NODATA instead of NXDOMAIN as some data below 127.zen.spamhaus.org is listed in the RBL indeed. The current behaviour was found to render applications behind resolvers using strict QNAME minimization (where no fallbacks using the FQDN queried by the client in the first place happen) unusable as the resolver stops after having received NXDOMAIN for the first ENT.

Worse, as RFC 5782, section 5, does not specify testing entries for URIBLs below the first hierarchy (such as dbltest.com.dbl.spamhaus.org), it is impossible to determine whether a URIBL is actually usable or not as test.dbl.spamhaus.org will always return NOERROR, while more realistic queries like example.com.dbl.spamhaus.org will silently fail as com.dbl.spamhaus.org returns NXDOMAIN instead of NODATA.

As far as I am concerned, RFC 7816 requires rbldnsd to return NODATA for Empty Non-Terminals. In my humble opinion, its' current behaviour is RFC-ignorant.

[ammammita]

Hello,

thanks for the feedback.

RBLDNSD was written in the last century, qname minimization was not yet existing so the whole code doesn't even take this chance into account.

There is also quite a lot of consensus in the SMTP World that qname minimization shouldn't be used on the resolvers used by mail servers. See http://postfix.1071664.n5.nabble.com/qname-minimization-and-privacy-breaks-dnsbl-in-postfix-tt103456.html#a103458 for an example.

A change to support this would require some efforts and we'd really like to learn about real world cases where this behaviour has caused issues.

[ammammita]

Going a bit deeper from the technical point of view, the dnset Dataset stores the data in such a way that implementing the requested feature impossible to implement. So, for domain names, if this feature is requested, a completely new dataset should be implemented.

For the IP(v4 and v6) datasets, all of them, we could implement a hackish solution so that when a query for a "partial" ip address is received, rbldnsd doesn't reply NXDOMAIN but NOERROR instead.

For example:

• a query for 3.2.1.zen.spamhaus.org would be always accepted, even if nothing is really listed
• a query for 3a.2.1.zen.spamhaus.org would not be accepted as that would imply an invalid ip address

Opinions ?

[rfc1036]

Please do: I see no downsides to this and an incomplete solution will still be better than being totally broken.

I also think that lack of support for ENTs for some data types should be well documented, because it is and has always been a bug: IIRC the first time that returning NXDOMAIN for ENTs was widely discussed as being broken was at the time of DNSSEC standardization work.

[ammammita]

I'm digging a bit more into the DN dataset.
The proper solution would be to rewrite the entire dataset or, better, replacing it with another one that may support ENT (no regressions allowed). And this would be a huge effort that i'm not sure i want to address nowadays.

Another hackish solution would be that the DN dataset always returns NOERROR for every query.
For example, it would return NOERROR both for

• com.dbl.spamhaus.com
  and
• thistldisfake.dbl.spamhaus.org

This would most probably break caching for NXDOMAIN entities, though (and this consideration applies also for the IP datasets with the hack applied).

This solution would probably be too aggressive. Opinions are welcomed on this topic as well.

Regarding the code: should this feature be always enabled or should it be enabled by a configure option ?

[dennywatson]

I am reviewing RFC7816 and currently pondering its ramifications. I'll probably have a better idea what I would want to do later after a bit of testing.

Currently, I have concerns that returning NODATA (NOERROR / ANSWER: 0) would result in client implementations as non-listing (generating false-negitives). IIRC, years ago there was discussion that dnsbl-clients should treat NODATA (NOERROR / ANSWER: 0) as a non-listing. Again, I need to review and better understand the RFC to see where edge cases may exist for clients.

[rfc1036]

Unless this is subject to serious testing then I believe that the evil we know (NXDOMAIN for ENTs) is better than trying something new like unexpected NODATA.

But I still suggest that you fix NODATA handling for the IP-related datasets, for which it should be easy and a correct solution.

[dennywatson]

Unless this is subject to serious testing then I believe that the evil we know (NXDOMAIN for ENTs) is better than trying something new like unexpected NODATA.

Informational;

Way back in 2006 one of the moderators of NANA.Blacklisting outlined how DNSBL clients should respond to "Empty non-error" responses. https://groups.google.com/g/news.admin.net-abuse.blocklisting/c/UIYFltOT4mA/m/59sRQw4UqwoJ
"While unusual, client implementations should ensure that responses where RCODE has been set to 0, and no answer is given, are treated as a negative listing."

Also it appears to have neither RFC5782 nor RFC6471 outline specifically how to handle empty non-error responses.

However, RFC8904 does suggest that returning empty non-error responses should be considered a non-listing;
"2. Method Details

The result of the method states how the query did, up to the interpretation of the returned data.
The method has four possible results:
[...]
none:
The query worked but yielded no A record or returned NXDOMAIN, so the sender is not whitelisted."

[dennywatson]

But I still suggest that you fix NODATA handling for the IP-related datasets, for which it should be easy and a correct solution.

Given that the rbldns-client passes the full QNAME to the resolver, and the resolver MUST respond with that full QNAME back to the client, with any QNAME minimization schemes (RFC7816 is categorized as "Experimental") being done by the resolver before responding to the client, this is unlikely to have an impact on the clients.

[dennywatson]

(snip)

Another hackish solution would be that the DN dataset always returns NOERROR for every query.
For example, it would return NOERROR both for

* com.dbl.spamhaus.com
  and

* thistldisfake.dbl.spamhaus.org

This would most probably break caching for NXDOMAIN entities, though (and this consideration applies also for the IP datasets with the hack applied).

Actually, I would believe that these entries would be cached properly. The resolver has an answer, and the answer is non-error. I would believe that resolvers would cache these replies just like any other replies.

Regarding the code: should this feature be always enabled or should it be enabled by a configure option ?

I would suggest that because RFC7816 is listed as experimental that this be presented as a command line flag to always return "empty non-error" instead of NXDOMAIN.

[ammammita]

I have pushed an implementation of thr qname minimization feature to the qname-minimization branch.

First of all you have to compile rbldnsd with the --enable-qnmin option in order to enable this feature.
Once done, nothing should change.

The qname minimization behaviour is activated ONLY for specific datasets.
To enable it for a dataset, you have to use the $QNMIN special entry that may be true or false.

As an example, this entry

#$QNMIN true

would enable a specific dataset to show the qname minimization behaviour.
This feature has been implemented in all datasets, including dnset.
The caveats described above will still apply.

This feature would need extensive testing so help and feedbacks from the community would be much appreciated.

[rfc1036]

The documentation is not clear:

• Maybe a better name would be "correct handling of empty non-terminal answers", since this is really about basic DNS rules and QNAME minimization just happens to expose the bug.
• Possibly breaking backward compatibility is mentioned, but the documentation should explain exactly what would be broken.
• Are there any other downsides when enabling this feature? E.g., is there a performance regression?

And what is the rationale for making this a compile-time option? Would building rbldnsd with --enable-qnmin cause a performance regression for a zone even without actually enabling the feature on it?

I do not think that the DNSBL RFCs need to specifically mention how NOERROR answers should be treated, because there are no deviations from the usual DNS standards and behaviours.

I have been pondering this a bit and now I agree with @dennywatson: since a NOERROR answer would be cached using the same rules of a NXDOMAIN answer then there will be no caching lifetime changes for "correct" queries.
And certainly no clients should ever consider a NOERROR answer as a listing: I highly doubt that such a broken client ever existed because (at least in the past) some people used to use BIND to serve DNSBLs and it would have returned correct answers for ENTs.

The only change that I can see when answering NOERROR instead of NXDOMIN for all non-listings is that a resolver receiving a NOERROR for faketld.dnsbldomain.net would still send a query for domain.faketld.dnsbldomain.net instead of correctly deducing than no subdomains exist. I do not know if this actually would have a practical impact, but it should be easy to measure for Spamhaus by turning on and off the feature for a while.

If no bad effects due to caching are measured then I even think that correct support of ENTs should be enabled by default because not breaking name servers implementing QNAME minimization (which is probably soon going to be "all of them") is much more important than not breaking already broken clients of which we are not even sure if any exists.

NOERROR answers should definitely be always turned on for queries to IP datasets, because we know exactly which queries should return NXDOMAIN and which ones NOERROR and because legitimate clients are not supposed to query for incomplete IPs, so there can be no concern about incorrect handing of NOERROR answers.

(Hi @dennywatson, you may remember me from the Brussels or Dublin M3AAWG...)

[dennywatson]

(parts snipped and reordered)

(Hi @dennywatson, you may remember me from the Brussels or Dublin M3AAWG...)

Hi, and yes. Also, you and I are aware of each other in other forums -- going back decades.

The documentation is not clear:

* Maybe a better name would be "correct handling of empty non-terminal answers", since this is really about basic DNS rules and QNAME minimization just happens to expose the bug.

Perhaps. I would also like to avoid RFC7816, as I feel it is poorly written. In an attempt for advocacy I feel that it appears to suffer from some logical facilities, glosses over some potential problems, purports to solve more than it actually does, and has potential misunderstandings of what was written in RFCs 1034 and 1035. Reading it with a critical eye, I'm not a fan. I don't have the time to dissect RFC7816 to reveal all of its potential flaws.

Having said that, yes ENTs probably shouldn't respond NXDOMAIN.

* Possibly breaking backward compatibility is mentioned, but the documentation should explain exactly what would be broken.

(reordered)

I do not think that the DNSBL RFCs need to specifically mention how NOERROR answers should be treated, because there are no deviations from the usual DNS standards and behaviours.

In a past life, I had maintained a qmail install, and can think of one example... Though this an unusual one that most likely suffers from a host of other issues. DJB chains could be constructed where that DNSBLs are queried and qmail's rblsmtpd triggered based on the setting of RBLSMTPD variable. Decades ago there was a dns package called firedns (might still exist, I haven't bothered to look) and its command line client would exit non-zero on NXDOMAIN. One could set this up with a string of logical ands resulting in the combination of a listing in two or more positive listings being required for actual blocking of email. This strategy could suffer from other problems such as wildcarding because a domainer has bought the domain, and/or SERVERROR problems, but it is an example of how someone may have implemented a dnsbl in such a way as there might exist problems.

!!! Implementation of this feature is a policy decision that should be expressed to its userbase !!!

(reordered)

I have been pondering this a bit and now I agree with @dennywatson: since a NOERROR answer would be cached using the same rules of a NXDOMAIN answer then there will be no caching lifetime changes for "correct" queries.
And certainly no clients should ever consider a NOERROR answer as a listing: I highly doubt that such a broken client ever existed because (at least in the past) some people used to use BIND to serve DNSBLs and it would have returned correct answers for ENTs.

* Are there any other downsides when enabling this feature? E.g., is there a performance regression?

Increased protocol traffic, and reduced response time to the client.

Tested against Unbound. I am somewhat concerned that unbound doesn't appear to cache empty no-error in any way and appears to always wants to traverse the full path when it sees empty non-error. I would need to take a critical look at 1034 and 1035 to determine if this behavior is broken. My gut says that, "You have received an authoritative non-error answer, cache that! If you are going to implement an experimental RFC -- then you need to add code to accommodate what you are doing," again; I need to review 1034 and 1035.

Over-query would appear to always be the case for NXDOMAIN.

And what is the rationale for making this a compile-time option? Would building rbldnsd with --enable-qnmin cause a performance regression for a zone even without actually enabling the feature on it?

I'm not opposed to adding it into default (perhaps at a later date) as the behavior is controlled by the zonefile.

The only change that I can see when answering NOERROR instead of NXDOMIN for all non-listings is that a resolver receiving a NOERROR for faketld.dnsbldomain.net would still send a query for domain.faketld.dnsbldomain.net instead of correctly deducing than no subdomains exist. I do not know if this actually would have a practical impact, but it should be easy to measure for Spamhaus by turning on and off the feature for a while.

If no bad effects due to caching are measured then I even think that correct support of ENTs should be enabled by default because not breaking name servers implementing QNAME minimization (which is probably soon going to be "all of them") is much more important than not breaking already broken clients of which we are not even sure if any exists.

NOERROR answers should definitely be always turned on for queries to IP datasets, because we know exactly which queries should return NXDOMAIN and which ones NOERROR and because legitimate clients are not supposed to query for incomplete IPs, so there can be no concern about incorrect handing of NOERROR answers.

I see this as more of a known query width issue, and rework of the existing data structures to accommodate searching that structure. Yes, for an IP based either IPv4 or IPv6 this is a known width. For domainnames, less so.

Overall, I have opinions. These are only opinions, and they are only mine;

RFC7816;

• Errata needs to be published.

Unbound;

• Cache non-error empty responses probably should be done. Further discussion on this topic should be had elsewhere.
• I had issues with unbound listening on 127.0.0.1 and rbldnsd on 127.0.0.2.. not sure what was going on, I had to bring up an aliased interface and put rbldnsd on 192.0.2.1.

Debian;

• Setting default use of an experimental RFC when installing Unbound seems... Odd.