rbldnsd blacklist question
Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Thoughts?
Re: rbldnsd blacklist question
On Tue, 16 Sep 2008, Marc Perkel wrote: Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Isn't general practice to bitmap the last octet if you're going to convey multiple pieces of information? -- John Hardin KA7OHZhttp://www.impsec.org/~jhardin/ [EMAIL PROTECTED]FALaholic #11174 pgpk -a [EMAIL PROTECTED] key: 0xB8732E79 -- 2D8C 34F4 6411 F507 136C AF76 D822 E6E6 B873 2E79 --- W-w-w-w-w-where did he learn to n-n-negotiate like that? --- Tomorrow: the 221st anniversary of the signing of the U.S. Constitution
Re: rbldnsd blacklist question
John Hardin wrote: On Tue, 16 Sep 2008, Marc Perkel wrote: Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Isn't general practice to bitmap the last octet if you're going to convey multiple pieces of information? If you have a situation where there might be more than one answer for a given query, and you are content with having a maximum of 7 possible answers, then... again, if both of these these things are true... then the best system by far is the following: .2 = situation #1 .4 = situation #2 .8 = situation #3 .16 = situation #4 .32 = situation #5 .64 = situation #6 .128 = situation #7 As multiple situations occur, add together the octets above. For example, .138 would mean that situations #1, #3, #7 happened. That way, anywhere from one to all seven attributes can be encapsulated as one single number, with any combination of these being clearly decipherable. From a programming perspective, do the following: If octet = 128 then #7 happened octet = octet - 128 End If If octet = 64 then #6 (also?) happened octet = octet - 64 End If If octet = 32 then #5 (also?) happened octet = octet - 23 End If etc Which is a less fancy way of saying what John Hardin said about bitmap the last octet... but I thought that spelling it out this way might be helpful for some. -- Rob McEwen http://dnsbl.invaluement.com/ [EMAIL PROTECTED] +1 (478) 475-9032
Re: rbldnsd blacklist question
On Tue, 2008-09-16 at 20:12 +0200, mouss wrote: Marc Perkel wrote: Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Thoughts? returning multiple results is easier to manage (you can point to a single dns entry and have a single TXT record) and to parse. for example, I could do (in postfix): check_rbl_client mark.example=127.0.0.3 warn_if_reject check_rbl_client mark.example=127.0.0.4 check_rbl_client mark.example some people use bitmasks instead. but this is harder to parse/implement. after all, spamhaus, sorbs, spamcop, .. don't use bitmasks. True, but uribl and surbl do. SpamAssassin makes it easy to use that syntax. I doubt I would use Marc's list as a postfix death penalty, but it's conceivable it might garner a point or two towards a SpamAssassin score. -- Daniel J McDonald, CCIE #2495, CISSP #78281, CNX Austin Energy http://www.austinenergy.com signature.asc Description: This is a digitally signed message part
Re: rbldnsd blacklist question
Marc Perkel wrote: Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Thoughts? +1 for bitmasking the data. --Blaine
Re: Re: rbldnsd blacklist question
John Hardin wrote: div class=moz-text-flowed style=font-family: -moz-fixedOn Tue, 16 Sep 2008, Marc Perkel wrote: Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Isn't general practice to bitmap the last octet if you're going to convey multiple pieces of information? Isnt it simple enough to write the zone file in 2 different formats and map them to 2 different zone names to support both bitmasked and multiple response if there is value in having both? URIBL uses bitmasks, but doesnt need to as we dont cross list domains to multiple lists. -- Dallas Engelken [EMAIL PROTECTED] http://uribl.com
Re: Re: rbldnsd blacklist question
Rob McEwen wrote: div class=moz-text-flowed style=font-family: -moz-fixedJohn Hardin wrote: On Tue, 16 Sep 2008, Marc Perkel wrote: Looking from opinions from people running rbl blacklists. I have a list that contains a lot of name based information. I'm about to add a lot more information to the list and what will happen is that when you look up a name you might get several results. For example, a hostname might be blacklisted, be in a URIBL list, be in a day old bread list, and a NOT QUIT list. So it might return 4 results like 127.0.0.2, 127.0.0.6, 127.0.0.7, 127.0.0.8. Is this what would be considered best practice. My thinking is that having one list that returns everything is very efficient. Isn't general practice to bitmap the last octet if you're going to convey multiple pieces of information? If you have a situation where there might be more than one answer for a given query, and you are content with having a maximum of 7 possible answers, then... Why just 7? You have 2 other octets to use.. 127.X.Y.Z - X and Y dont have to be zeros... 512 possibilities if you use all the bit on all 3 octets (but I'd avoid loopback 127.0.0.1). 448 possibilities if you only count bit 1 settable on octet 2 and 3 (ie 127.1.1.2) 343 if you avoid setting bit 1 altogether on any octet (ie 127.2.2.2) -- Dallas Engelken [EMAIL PROTECTED] http://uribl.com
