On 10/19/2016 3:51 AM, Matus UHLAR - fantomas wrote:
are you REALLY sure the IP has to be reversed?
rbldns parses IP and reverses them by itself, if used in ip4* dataset.
When used in dnset, it should not be reversed.
Your most valid points do not apply to "dnset". they apply to ip4tset
and ip4set for sending-IP blacklists.
Let me explain... but before I explain, let me say that I'm not arguing
for any of this. These standards were put in place long before my time
(and are followed by SURBL and URIBL, too). Or, at least I didn't set
these standards. I MIGHT have been involved in some of the discussions
about this circa 2004, in internal discussions at SURBL - and in SA
discussions - but I think this was all set just a little before my time
in those forums.
So basically, if you look at the anatomy of a domain name... from left
to right, you get into a higher hierarchy.
So in "foo.example.com"
"foo" is drilling into detail. while "example.com" is the bigger
picture. And then ".com" is an even bigger picture! In a domain, as you
get FURTHER to the right, you go to a HIGHER hierarchy or level.
But IPs are the opposite. For an IPv4 IP, the leftmost number is the
highest in the hierarchy, and you drill down into more detail as you
move to the right.
For this reason, it was decided a long time ago... that for URI DNSBL
blacklists that use "dnset", the IP should be reversed in the source file.
Therefore, in the data file, the test point IP:
127.0.0.1
shows up as
1.0.0.127
And then when the client queries that IP, the query is formatted as follows:
1.0.0.127.example.com
(where example.com is the URI blacklist's host name)
And, likewise, ALL of the major anti-spam software, (such as
SpamAssassin), automatically reverses the IP when that (forward-ordered)
IP is extracted from a base of a URL found in the body of a spam, and
then this is appended to the beginning of a URI blacklist's hostname,
for checking against a URIBL blacklists (such as SURBL, URIBL, or my own
ivmURI list)
This decision to do it this way PROBABLY had something to do with trying
to get rbldnsd engine to NOT have to internally treat IPs and
domains/host-names differently. otherwise, it would have had to "know"
to reverse IPs, but yet know to NOT reverse domains or host names. (and
who knows what TLDs could be coming up in the future?)
In contrast, IPs found in sending IP data files (for ip4tset and ip4set)
don't have this inconsistency problem. So it make sense to just leave
them in forward-order, for EASY readability... and then just allow
rbldnsd to reverse order them on-the-fly. (thank God - I'd go nuts if my
ip4tset and ip4set were all in reverse order! meanwhile, IPs in URIBL
data files are usually a TINY percentage of the listings!)
----------------------------------------------------------------------
Having said all of that, for regular sending0IP blacklists, (just as you
said) the IP is NOT in reverse order in the file. But rbldnsd "knows" to
reverse order it in memory, before it is compared to the reverse-ordered
query that comes in from the client.
So you're correct when you say, "rbldns parses IP and reverses them by
itself" ... but that only applies to sending-IP blacklists, set up with
ip4tset and ip4set in rbldnsd.
As shown, dnset operates differently for IP addresses found in URIBL
blacklists.
----------------------------------------------------------------------
This was a trip down memory lane for me.
--
Rob McEwen
invaluement
