[rbldnsd] Using rbldnsd to blacklist websites

[Michael Tokarev]

Wayne Sherman wrote:
[]
>>  com:dnset:com.data
>>
>> where com.data contains:
>>
>>   :127.0.0.2:Bad domain
>>   .baddom1
>>   .baddom2
>>   ...
>>
>> Ditto for .net, .org, .biz etc...
> 
> That is how I have been testing.  I have to parse and reformat the
> "hosts" files anyway, I might as well split them up into different
> dataset files.  Does having multiple datasets like this have any
> performance implications, either positive or negative?

I don't think so - unless you'll have MANY TLDs (root DNSBL zone lookup
(to find the appropriate dataset(s)) is sequential, while in-dataset
lookup uses faster algorithm).  There's certain memory saving due to
split like that - no need to store .com suffix for every domain in
that zone ;)

[]
>> "Not answer" - how's that?  Just ignore the "not listed" queries and let
>> it time out?  Or what?
> 
> Those quotes are from the bind reference guide here:
> http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#options
> (under the "forward" keyword)
> 
> Exactly what the documentation means by "not answer the question" is not
> explained.  I think a NOERROR reply with the answer section empty would
> do it.  Replying that way is mentioned here in a different context:

No it's not.  "No answer" is just that - no answer.  Ie, we query some NS,
and it just does not reply to our query (down, unreachable etc).  So after
a timeout, NAMED tries next alternative.  Any positive answer (and NOERROR
reply IS a positive answer, regardless of how many entries in ANSWER section
it contains) causes any sane nameserver to stop here and return that answer
to original client.

Maybe, just maybe, NAMED will treat REFUSED or SERVFAIL replies in a similar
way, but I'd not rely on this - too hackish.

> http://www.cctec.com/maillists/nanog/historical/0204/msg00559.html
> 
> "We've noticed that some sites like news.bbc.co.uk are running broken
> DNS servers that return NXDOMAIN for AAAA queries rather than NOERROR
> with zero answers."
> 
> "there are name server implementations (probably load balancing product)
> that responds with NXDOMAIN, when it should respond with NOERROR with
> empty reply."

It's about a bit different thing.

>>> make that change pretty easily in the source, but it would be nice to do
>>> it as a command line option. Even better would be some help from the
>>> author. In fact, it might be nice to to have the option to return
>>> NXDOMAIN for blacklisted web domains instead of 127.0.0.2. The browser
>>> then won't try to talk to localhost.
>>
>> To me, it all looks like a.. umm... nonsense.  It's one large kludge.
>> Including usage of rbldnsd here.
> 
> I understand rbldnsd is designed to be an rbl for email systems, and it
> works a certain way according to that purpose.  I need a "WEBDNSBL"
> server (my own term) which works in slightly different way.  But,
> rbldnsd *already does 99.9%* of what a WEBDNSBL would need.  *If* bind
> works the way I think, then rbldnsd just needs one or two things to be a
> good WEBDNSBL:

The issue here is whenever BIND works this way.  And the answer is - no,
it's not.  Pretty much like any conforming (caching, recursive) nameserver.

> 1) Return some predefined address (like 127.0.0.2) for all BL entries
>    (rbldnsd already does this now with no changes)
> 
> 2) *or optionally* return NXDOMAIN for all BL entries
>    (not strictly required, but might be nice to have, since a browser
>    would not waste time trying to access a page at the loopback address)

That's probably not difficult to implement, but it requires a sort of
"reverse" (or inverted) dataset.

> 3) Return NOERROR with an empty answer section for domains names it does
> not have.

That's not difficult either, but see above - it wont help.

> (I could test if this works with binds "forward first" with only #3
> implemented)

You can easily hack it in, for testing.  Use generic dataset, add, say,
MX record for some name, and query that name for any other RR type
(like A for example) - you'll get positive (NOERROR) reply with empty
answer section (this can be done with any other NS as well).

You can try to see how other codes works.  To test REFUSED replies, add
an ACL "dataset" which contains address of your recursive/caching NS, so
that all queries from it will be REFUSED by rbldnsd.  To test SERVFAIL,
add a regular NS (like, BIND), specify a master zone, but don't create
a zonefile for it - NAMED should return SERVFAIL for such a zone.  But
again, I argue you to NOT do that - it's too klugdy.

>> I understand what you want to do and why.  But I don't think it can
>> easily be done without changes in your CACHING nameserver.
> 
> You may be right, but it depends on binds behavior and what exactly
> triggers it to "find the answer on its own" when using the "forward
> first" option.

It depends on the standard(s) really... ;)

/mjt