Rbldns for text and data

[Alessandro Vesely]

On Thu 10/Jan/2019 21:02:51 +0100 Denny Watson via dev wrote:
>>> 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.)


Now it's an RFC.  See attachment.


> 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.


You seem to be right.  It'd be nice if someone will say what DNSxLs are
supposed to do, typically return A + TXT on ANY.  Anyway, it seems that
omitting ANY was a premature decision of the MTA implementor.  Thank you for
the advice.


> [...]

> 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.


The MTA can accept a whitelisted message even if configured to
reject-on-SPF-fail. It then adds the dnswl record to the message header, like so:

Authentication-Results: wmail.tana.it;
    dnswl=pass dns.zone=list.dnswl.org
    policy.ip=127.0.6.2

Had a TXT record been found, the header field would also have had:

    policy.txt="bofh.it https://dnswl.org/s/?s=62352"


Almost always that information is redundant.  In this case, for example, I
already have this:

Received: from attila.bofh.it (attila.bofh.it [85.94.204.146])
  (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-GCM-SHA384)
  by wmail.tana.it with ESMTPS; Thu, 10 Jan 2019 21:02:58 +0100
  id 00000000005DC03D.000000005C37A4F2.00000A6B

However, sometimes the Received: is obscure, and there's no PTR, so that one
cannot tell what domain is responsible for the message.  In such cases,
policy.txt tells the domain name.  That feature makes a successful dnswl lookup
semantically equivalent to other email authentication  methods, such as SPF and
DKIM.

(The above Authentication-Results: field is not (yet) mentioned in the IANA
Email Authentication Parameters[*], because of the "dns.zone" which should have
been named something like "policy.zone" according to rfc7601.  I'll try again
after rfc7601bis will have been published.)

[*] https://www.iana.org/assignments/email-auth/email-auth.xml


> 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).


I find it useful to outsource also whitelisting.


Best
Ale
-- 





-------------- next part --------------
An embedded message was scrubbed...
From: rfc-editor@rfc-editor.org
Subject: RFC 8482 on Providing Minimal-Sized Responses to DNS Queries That Have QTYPE=ANY
Date: Thu, 10 Jan 2019 18:23:34 -0800 (PST)
Size: 7192
URL: <http://list.rbldnsd.io/pipermail/dev/attachments/20190111/44038667/attachment.eml>