Andrew D Kirch wrote:
Chris Lewis wrote:
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.
As others indicated 'RHSBl'?
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.
Yeah I know what you are saying but really do you want to have people
start coding 'the DNSbl is shutdown if this does 127.0.0.2 does not exist'
By stating it this simply, it encourages automation, so if something
breaks down, email servers _could_ automatically stop trusting the returns.
The point I'm trying to make is that the presence of a test entry or not
should not indicate any issue other than simple oversight or possible
problem. On the other hand I do agree that we need to come to some
agreement that will cause a server or other automated process to
discontinue using a DNSbl when instructed by way of a special return.
Possible options I can see are:
Choose a specific entry to return for 'shutdown' ... suggestions so far:
127.0.0.2 when it doesn't exist. <- I disagree with this - reasons below
127.0.0.1 when returns positive. <- I disagree with this as 127.0.0.1 is
undesirable in most DNSbl's but it is not an error.
255.255.255.255 when returns positive (my suggestion).
When *any* lookup returns an address *not* in 127.0.0.0/8. (This will
catch all expired domains etc) <- don't recall the source, but would
also be very agreeable to me.
I've generally agreed with you, but I think this is a pretty low
barrier, and can fix issues for DNSBL's trying to shut down, especially
with third party software that use DNSBL's to filter spam.
Each is entitled to their comments, I have no problem in a disagreement,
I just think there are better ways that would not impact due to simple
oversight or error. We are looking for a definitive "see this behavior
and drop this from the config" command/result if we use something simple
it will negatively impact a lot of users in the event of a simple
mistake. Think on this - those who list the world... if they knew to
use an address other than in 127.0.0.0/8 I'm sure they would have (even
in OSIRU's case). In the event of sitefinder morons and other similar
DNS hijackers, the return of a valid (as in a routable/non RFC 1918) IP
would cause the software to stop using the DNSbl/DNSbl results, rather
than "listing the world". Relying on the presence of
2.0.0.127.some.domain to return an IP when valid means when the DNS is
hijacked by a 'sitefinder' the world+dog is listed.
Does that explain my reasoning and persistence on the issue a bit more?
/ Mat
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/asrg