Rbldns for text and data

[Denny Watson]

On 01/10/2019 12:08 PM, Alessandro Vesely via dev wrote:
> On Thu 10/Jan/2019 16:47:13 +0100 Denny Watson via dev wrote:
(snip)
>> I am not sure that I understand your question;
>>
>> You want to return TXT records when querying for A records?
> 
> 
> Rather the opposite, here's what I want:
> 
(snip)

I apologize for that.

> 
>> If this is the case, I would believe that your MTA wouldn't handle them as
>> you would expect, as the MTA asked for A and the DNS server responded with 
>> TXT.
> 
> Maybe the MTA will discard the TXT and just take the A it asked for.  However,
> since it is a DNSxL query where it used to ask for ANY, it may accept it.
> 

It may, but this appears to be outside of scope (see below)

> 
>> Had it asked for ANY, it would know how to handle (or at least look for
>> things that it could handle) in the response.
> 
> Yes.  However, ANY is going to be deprecated:
> https://tools.ietf.org/html/draft-ietf-dnsop-refuse-any-07
> 
> (That's still a draft but it made enough noise already.)
> 

I haven't been following this discussion, but reviewing the document
suggests that QTYPE ANY isn't being removed from the protocol, it's just
that you shouldn't expect it to be available when the requests hit the
final system authoritative for the labels you query, or if it is
available it might not contain the specific types that you might find
interesting.  This is dependent on that remote system's configuration.

> It is the A record which drives mail filter's behavior thereafter.  The TXT
> record is a useful addition, but it's not essential.  Wouldn't it be possible
> to add it to the response, as if it was a glue record?  Or would one need to
> patch the code to get such behavior?
> 

I am pretty sure that this would require a patch.  Responses to requests
for a specific type really should only respond with that type (and
perhaps glue)

> I'd bet I'm not alone with this problem, but cannot find "official" solutions.
> 
> 
>> If you want to use values that are returned via TXT records, it would be
>> best for the MTA to ask for these.
> 
> 
> That takes two queries instead of one.  A "correct" DNSBL query might possibly
> use a second query if the server doesn't push the A along with the TXT.  That's
> possible only if TXT and A always match.  If I were to patch the MTA I would
> provide for a fallback like so:
> 
> MTA -> TXT?
>        TXT    <-DNS
> MTA -> A?  # fallback
>        A      <-DNS
> 
> No second query here (wanted rbldns behavior):
> 
> MTA -> TXT?
>        A, TXT <-DNS
> 
> Nor here:
> 
> MTA -> TXT?
>        NXDOMAIN <-DNS
> 
> (Note that this is the wanted, DNSxL-specific behavior if the user configured
> the additional TXT for that DNSxL.  If the user configured A records only, it
> already works well.)

In cases such as this, I would expect the QTYPE ANY would still be
appropriate.  Again, for your own dnsbld instance that you control, I
would expect that ANY will still be supported for the foreseeable future.

OK, so if I understand this;

You are saying that when collisions in the zonefile exist that one
overwrites the other?

Example;
192.0.1.1
192.0.1.0/24


Having said all of that, I want to make sure that I understand your use
case.  Assumptions follow;

Your MTA is using A record responses to make filtering decisions -- this
is normal, and I would suggest the more proper way of doing this.  QTYPE
A records tend to be better suited for this than TXT records.

Your MTA is using TXT records for SMTP textual responses, or even for
the log files.



Side-note:
In the past, when I was managing MTAs, I didn't return the DNSBL's TXT
responses via SMTP and instead returned URLs for my own "postmaster"
webpage with a CGI flagged IP.  This was another lifetime ago, and I
would do silly things like reject only if on List-A and List-B, or
List-C but not List-D, and it was easier to explain it all and provide a
separate white-listing process for my systems outside of the reputation
providers (DNSBLs).