Steve Atkins wrote: >> On Jan 21, 2016, at 11:57 AM, Steve Atkins <[email protected]> wrote: >> >> >> >>> On Jan 21, 2016, at 11:35 AM, Michael Wise <[email protected]> >>> wrote: >>> >>> Back In The Day, there was a BCP for shutting down a DNSBL that included >>> running a daily check of the IP 127.0.0.1 (which should never hit), IIRC, >>> as well as 127.0.0.2 (which should always return a hit); and if my memory >>> serves, if either criteria was different (both listed or neither listed), >>> the DNSBL should be flagged as not to be trusted. >>> >>> This is from memory, I remember a discussion … a decade or so ago? >>> >> It's an obviously sensible thing to do, simple, cheap and doesn't require >> any cooperation from the DNSBL operator more than all (but three) DNSBLs I >> know of already do. >> >> IIRC it's explicitly called out as something you can do in Chris and Matt's >> DNSBL RFC. >> >> > > http://tools.wordtothewise.com/rfc/rfc5782#section-5 (DNS Blacklists and > Whitelists, John Levine) > > "IPv4-based DNSxLs MUST contain an entry for 127.0.0.2 for testing > purposes. IPv4-based DNSxLs MUST NOT contain an entry for 127.0.0.1. > > ... > > The combination of a test address that MUST exist and an address that > MUST NOT exist allows a client system to check that a domain still > contains DNSxL data, and to defend against DNSxLs that deliberately > or by accident install a wildcard that returns an A record for all > queries. DNSxL clients SHOULD periodically check appropriate test > entries to ensure that the DNSxLs they are using are still operating." > > and > > http://tools.wordtothewise.com/rfc/6471#section-3.3 (Overview of Best Email > DNS-Based List (DNSBL) Operational Practices, Chris Lewis & Matt Sergeant) > > "Most IP address-based DNSBLs follow a convention of query entries for > IP addresses in 127.0.0.0/8 (127.0.0.0-127.255.255.255) to provide > online indication of whether the DNSBL is operational. Many, if not > most, DNSBLs arrange to have a query of 127.0.0.2 return an A record > (usually 127.0.0.2) indicating that the IP address is listed. This > appears to be a de facto standard indicating that the DNSBL is > operating correctly. > > ... > > Therefore, a positive > listing for 127.0.0.1 SHOULD indicate that the DNSBL has started > listing the world and is non-functional. >
I remember a lot of arguments over this which is why 'SHOULD' was used in the text. > ... > > 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." > I'm almost certain this text was put in after my/based on my feedback (because I remember giving the feedback that I specifically use this address for a functionality test.) >> I don't know of anyone who implemented it. >> I know at least 2 did (and I'd need to check up who it was) .. if you returned anything but 127.0.0.0/8 one mail server or filter would automatically stop using the particular list. but I don't believe that anyone did the 'must/must not' or require 127.0.0.2 to exist.... purely because there are valid reasons to list 127.0.0.1 (think RFC1918 address space DNSBl) and the failure to have a 127.0.0.2 address did not indicate working or failed DNSBl... in fact in the case of SORBS it gives you no indication at all... Originally in SORBS I had network entries for the test addresses... When i implemented "Automatic delisting after a timeout period" the test entries got delisted.. because of this back in 2003-5 I put in the export script a hard code of a 127.0.0.2 entry as the very first entry... Of course this means that if the export fails to connect to the DB or has another failure.. you'll get the 127.0.0.2 in the zone which some would consider "everything is ok" and then nothing be in the zone, or worse if it's a truncated file with a line such as 192. rbldnsd would list all of 192/8 (before MJT put in a catch/check for this.) I believe the original discussion about listing 127.0.0.1 was because of yet another f**kup I had... at SORBS we listed 127.0.0.1 as an open relay - because it was.. and because some toe-rag thought they'd f**k with me/SORBS.. this I thought was not really a problem - until I started receiving complaints from some sendmail users... apparently some configs/versions would not work correctly if 127.0.0.1 returned a positive in it's DNSbl checks... Of course knowing this certain "hats" wanted the check for 127.0.0.1 to disable the DNSbl check... to which my argument was always (and still is) a mail server should not mis-behave *in anyway* because of a DNSBl listing of 127.0.0.1 (just the same way it shouldn't misbehave if the lookup of a rDNS/PTR record returns 127.0.0.1...) -- Michelle Sullivan http://www.mhix.org/ _______________________________________________ mailop mailing list [email protected] https://chilli.nosignal.org/cgi-bin/mailman/listinfo/mailop
