Matthew Sullivan wrote:
Chris Lewis wrote:
<t>If this indicator is missing (query of 127.0.0.2 returns NXDOMAIN),
the DNSBL should be considered non-functional.</t>
No - there are a few that do not have that address at the moment (they
probably should), but as another example - autoexpiry of the SORBS Proxy
DBs wiped out the test entrys until I hardcoded them in the DNSBl export
script to put the entries in regardless of a matching lookup. Consider
the following (not the wording, only the intent):
If 127.0.0.2 is missing the user should look at the status of the DNSbl
as it MAY be due to zone shutdown.
I do not think it onerous to suggest that existing DNSBLs that don't use
127.0.0.2 should, and there is enough current practise to suggest it
should be codified as a BCP.
Secondly, you'll notice I didn't say "considered shut down" or imply
permanence. If a DNSBL that publishes a 127.0.0.2 diagnostic _stops_
doing it, it is indeed operating out of specification (eg: what else is
going wrong?) at least temporarily, and probably shouldn't be used
further until it starts signalling 127.0.0.2 properly again.
By stating it this simply, it encourages automation, so if something
breaks down, email servers _could_ automatically stop trusting the returns.
<t>Note: In <xref target="down" /> it is noted that some DNSBLs
have shut down in such a way to list all of the Internet. Further,
in <xref target="reserved" />, DNSBL operators MUST NOT list
127.0.0.1. Therefore, a positive listing for 127.0.0.1 SHOULD
also be an indicator that the DNSBL is non-functional.</t>
Well the accidental inclusion of 1.0.0.127.dnsbl.sorbs.net did not
indicate the DNSbl was non-functional,
The wording above repeated - it was out of specification, and the rest
of it is in doubt. And in some situations it will cause unintended
blocking.
It's not too onerous IMO to expect DNSBLs to do such elementary basic
checking.
which is why I suggested using
either 255.255.255.255/32 (or earlier 0.0.0.1/32) the former is
theoretically impossible as a valid *usable* host address, the latter
is, just as 127.0.0.1, is a valid address.
Nobody is doing that - I don't want to suggest something too new.
<t>Other results, such as 127.0.0.3, may have different meanings.
This operational flag usage and meaning SHOULD be published on the
DNSBL's web site, and the DNSBL user SHOULD periodically test the
DNSBL.</t>
Agreed, though that is a client operation rather than a DNSBl operation.
(The other BCP/RFC/Section?)
This isn't the only MUST/SHOULD aimed at the DNSBL user, and I think
it's important in this context. Tho, it'd be repeated in a "using
DNSBLs" BCP (if there ever was one).
Some mail systems are unable to differentiate between these various
results or flags, however, so a public DNSBL MUST NOT include
opposing or widely different meanings -- such as 127.0.0.23 for
"sends good mail" and 127.0.0.99 for "sends bad mail" -- within the
same DNS zone.
Not sure why this is a MUST NOT. If people are dumb enough to use a
mixed list in a broken way they get what they deserve. What's the
justification?
"Suicidal administrator" prevention. JD suggested it. I like it, but
I'm not committed to it. Thoughts?
I disagree, simply: not in the same zone - but no problem with the same
DNSBl.
Would a SHOULD NOT instead be sufficient? A reword is probably better.
I did not read it correctly the first time around - read as 'the same
DNSbl' - not as 'the same DNS zone'
Okay, I'll leave it alone for now.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg