[rbldnsd] I HATE BIND - please help

Tue Mar 4 12:56:19 MSK 2008

Chris. wrote:
> On Mon, 3 Mar 2008 14:25:14 +0000 (UTC), Chris. wrote...
> 
>> On Sun, 02 Mar 2008 23:50:21 +0300, Michael Tokarev wrote...
>>
>>> Chris. wrote:
>>> []
>>>> FWIW both the working, and non-working installs were on BSD/OS
>>>> (FreeBSD).
>>> Ok.
>>>
>>>> FWIW both installs declared only localhost at 127.0.0.1 in their hosts
>>>> file.
>>> Irrelevant -- DNS internally works by using IP addresses only,
>>> never looking into hosts file.
>>>
>>>> FWIW both installs used only 1 (one) Internet Routable IP address on
>>>> the RBLDNS commandline.
>>> Irrelevant - 1, 10, 100 - makes no difference.
>>>
>>>> FWIW nospammers.COM, and nospammers.NET each have a different, and
>>>> valid internet routable addresses. Both names are fictitious in this
>>>> dialog, as I'm not ready to announce them until I have a working,
>>>> and stable RBLDNSD install. I hope that's understandable. :)
>>> By the way, you can have as many IP addresses for a domain [name] as
>>> you wish, including 0.  The opposite is true as well - as many domain
>>> names can live on a single IP address as necessary.
>> Understood. I currently host ~25 domains on one of my servers. I only
>> mentioned it, should it make a difference to RBLDNSD.
>>
>>>> FWIW other than the FQDN, and IP addresses, the only difference
>>>> between the 2 installs is the version of BSD, and the version of the
>>>> BIND.
>>> So this brings up my first question - the inability to bind to
>>> loopback other than 127.0.0.1.  I'm not an expert in FreeBSD, so it's
>>> not my game. Maybe it's version dependent, maybe some local settings
>>> or compile-time flag - I've no idea.  The thing is that one of your
>>> systems allows to bind to any 127.x.x.x address freely, while another
>>> does not.
>>>
>>> Note it's not rbldnsd who refuses to bind to 127.0.0.3 etc, it's the
>>> Operating System who does not permit it to do so.
>>>
>>> If you don't believe me, try the following perl program:
>>>
>>> --------- cut -------------
>>> #! /usr/bin/perl -W
>>> use Socket;
>>> socket(H, PF_INET, SOCK_DGRAM, 0) or die "socket: $!";
>>> my $sin = sockaddr_in(1053, inet_aton($ARGV[0] || "127.0.0.3"));
>>> bind(H, $sin) or die "bind: $!";
>>> print "success!\n";
>>> --------- cut -------------
>>>
>>> run it on your "working" machine (which allows to bind to
>>> non-127.0.0.1 addresses) and on your "non-working" machine.  Try
>>> without starting bind and/or rbldnsd or anything else (except
>>> network, obviously) - it does not matter which version of bind you're
>>> running.
>>>
>> I ran this on several of my servers. In /all/ cases, the script
>> returned:
>>
>> bind: Can't assign requested address at ./run-me.pl line 5.
>>
>> I also modified it to use 127.0.0.2
>>
>> it returned: bind: Can't assign requested address at ./run-me.pl line
>> 5.
>>
>> modifying it to 127.0.0.1 returned:
>>
>> Success!
>>
>> All attempts also included the server that successfully ran RBLDNSD.
>>
>>> Yet again: this issue (rbldnsd is unable to bind to 127.0.0.3 etc)
>>> is a completely separate issue, unrelated to any other.  You already
>>> worked around it(*) by using your PRIP instead of loopback range.
>> OK
>>
>>>> FWIW I realize that the thread has obscured my original post which
>>>> included my detailed (and working) config/setup. If you wish me to
>>>> repeat it, I would be more than happy to reproduce it here. Also, if
>>>> there is anything else required/desired to assist you, please let me
>>>> know, as I will be happy to oblige. ;)
>>> I just re-read your original message.  And to be fair, I don't see a
>>> question in it which I can answer...  You describe your working setup
>>> in full details, next you describe some other setup you want to
>>> achieve (which is different from your current setup, but by very
>>> small details), and next you ask if someone has a recipe...  But you
>>> already gave a recipe in your working setup, which needs only few
>>> changes to adopt.
>> I'm listening. :)
>>
>>>> FWIW I'm confident that this is a resolvable problem. As such, I
>>>> have begun creating
>>> They all definitely ARE solvable problems.  Let's start hunting them
>>> one-by-one.
>> That is always the most efficient diagnoses. :)
>>
>>>> a web interface to the RBLDNSD lists which can be manipulated from a
>>>> web browser, and stored in a DB. Hope this helps.
>>> Heh.  Maybe - I for one hate web interfaces ;)
>> Then you may be encouraged to know that I /only/ made the "web"
>> portion in an effort to permit requests to become whitelisted, and to
>> allow mail users to manipulate their own lists. The whole thing has
>> been incarnated from the scripts I've already created, and have
>> already been using to manipulate (manage) the lists from my terminal
>> (console), or cron. Point being; the web part isn't required to
>> accomplish everything it provides. The web part was only an "after
>> effect".
>>
>>>> OH. One more thing. It might be worth noting that there is a bug in
>>>> the 9.4 BIND related to name resolution (gethostbyname as I recall).
>>>> This may be the difference, which may require some sort of kludge to
>>>> work around - see; may be the trouble.
>>> bind does not use gethostbyname() library routine.
>> I only remember that there was a bug (freebsd related) regarding
>> gethostbyname(), in the way bind used/required it. Unfortunately
>> isc is /very/ secretive about their bugs, and I can't seem to find
>> it right now.
>>
>>> Regardless, it's not the bug to worry about in our case.
>> Good to know.
>>
>>>> Thank you again for taking the time to respond. Please do not
>>>> trouble yourself until you are feeling better. I will be more than
>>>> happy to wait until then. :)
>>> Yes I'm *much* better now.  When I wrote first reply to you, I had
>>> temp of 38.4C - it was a flu (grippe as we call it here).  Now I'm
>>> back to normal again.
>> Glad to hear it. Congratulations. :)
>>
>>> Ok, back to our horses/sheeps/whatever.
>>>
>>> From this thread I gavered the following your problems so far:
>>>
>>> 1) bind to loopback but non-127.0.0.1 address.  See above.  It's your
>>> job to find what's going on here, or ask on freebsd list(s) - again,
>>> you know better than me here.
>> 127.0.0.1 OK, > 127.0.0.1 !OK
>>
>>> 2)
>>> Duplicating my previous /working/ setup on the new server, /ALWAYS/
>>> 1204196045 <internet IP here>
>>> 165.193.171.124.blackhole.nospammers.NET A IN: REFUSED/0/61
>>>
>>> this means (provided you don't have any fancy stuff like acl enabled
>>> in rbldnsd) that it knows nothing about blackhole.nospammers.NET
>>> zone. and as such it just refuses to answer you.  Show the command
>>> line and actual domain name, or just check they match your
>>> expectations.  For example:
>>>
>>> rbldnsd ... f00.com:ip4set:data
>>>
>>> and query it as
>>>
>>> dig 1.2.3.4.foo.com ...
>>>
>>> it will return REFUSED, see why already? :)
>>>
>>> So, configure your system to allow binding to 127.0.0.2etc, bind
>>> rbldnsd somewhere there TO PORT 53 (standard DNS port), and use dig
>>> (or whatever) to query rbldnsd directly first.  Only after do the
>>> next step and debug it all correctly.  By the way, you can try
>>> dnsget utility from http://www.corpit.ru/mjt/udns.html -- it matches
>>> `host' utility from BIND and allows to specify port too (maybe dig
>>> has 'port' option as well? I don't remember).
>> Both nslookup, and bind allow port selection on queries.
>> nslookup -port=65536, for example.
>>
>>> 3) problem spotted by furio ercolessi (well spotted!) --
>>>
>>>>> # dig @my.internet.routable.IP 2.0.0.127.blackhole.nospammers.NET
>>>>> or:
>>>>> # dig @my.internet.routable.IP 3.0.0.127.blackhole.nospammers.NET
>>> ...
>>>>> The RBLDNSD logs all return:
>>>>> 1204196617 111.222.333.444 999.888.777.666.blackhole.nospammers.COM
>>>>> A IN: REFUSED/0/61
>>> this *smells* like that f00.com vs foo.com above!
>>>
>>>
>>> The rest.  Well.
>>>
>>> You're making.. strange conclusions.  Seriously.  Just this sequence:
>>>
>>> "..no matter how I query... rbldnsd writes "REFUSED" into log.. it's
>>> probably due to the fact that it refuses to bind to 127.0.0.2.. Only
>>> bind is different on the 2 machines, from which I conclude that
>>> rbldnsd is incompatible with some later version of bind".
>>>
>>> It's a set of 3 completely unrelated issues.  Yet you managed to glue
>>> them all together and make it so one is due to another.  It's..
>>> fantastic!
>> Thanks. :) Message received.
>>
>>> I don't want to offend you, not at all.  This is really interesting -
>>> I recall some very good politics, usually "big" politics, are able to
>>> do such things.  (Remember that today was President Elections day
>>> here in Russia ;)
>> LOL
>>
>>>
>>> Oh-oh.  This reply was much longer than previous - it is even
>>> longer than your original message! ;)
>> LOL Sorry, I was attempting to be concise. Hope that was OK.
>>
>>> Something like that, anyway... ;)
>> Thank you /very/ much for taking the time to make such a cohesive
>> and sensible reply out of such a garbled thread - /amazing/, truly!
>>
>> I'm still leaning on differences in the BIND from the one version
>> on the /working/ server vs. the version on the /non/ working server.
>> So I'll experiment some more, now armed with the knowledge you've
>> provided here, and I'll report back shortly.
>>
>> Thank you again!
>>
>> --Chris H
> 
> OK I spent the entire day /carefully/ going over both the server that
> rbldnsd worked on, and the one it doesn't. I couldn't find /any/ configs
> that were different in a way that would affect the loopback block -
> 127.0.0.1/8, for example. So, I hit the news group asking if there
> was a difference between the two versions of FBSD that affected the
> way it handles the loopback (also known as lo0). Everyone answered
> that there was no difference that they were aware of. So I altered
> the default rc for bootstrapping lo0, by adding a 255.255.255.0
> netmask. Then restarting the network without the BIND. After the
> network restarted, I then started RBLDNSD with the followingcommand:
> rbldnsd -u rbldns:rbldns -v -v -p /var/run/rbldnsd.pid -f \
> -c 1m -l rbldnsd.log -r /usr/local/etc/rbldnsd \
> -b 11.222.333.444/530 blackhole.nospammers.COM:ip4tset:clients
> 
> Sorry, I'm not /quite/ ready to share the IP/domain name yet.
> But really, it shouldn't really matter what numbers/domain.tld
> I use in this example. The IP resolves very well accross the
> internet. As does the domain.
> 
> Anyway, back to the scenario... RBLDNSD emits the following
> during startup:
> rbldnsd: listening on 11.222.333.444/530
> rbldnsd: ip4tset:clients: 20080303 235127: cnt=39416
> rbldnsd: zones reloaded, time 0.2e/0.2u sec
> rbldnsd: rbldnsd version 0.996a (27 Jul 2006) started (1 socket(s), 1 zone(s))
> 
> Then I started the BIND.
> 
> Performing dig -p530 @nospammers.COM \
> 10.111.234.65.blackhole.nospammers.COM -t txt
> emits:
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 1673
> ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available

Aha, that is different from _logging_ REFUSED.
IIRC dig uses TCP for its DNS requests. Try forcing a UDP request to 
rbldnsd ( dig +udp -p530 ... ) and see if it says the same thing.

> 
> Whoo Hoo! no more NXDOMAIN. BUT, of course even when I query against
> an address that /is/ in the clients zone file, I still receive REFUSED.
> Oh well, at least RBLDNSD has 127.0.0.2 now. Reloading both RBLDNSD,
> and the BIND provided no difference.
> 
> Sigh. I'm tired, and all out of thoughts. Any insight /greatly/ appreciated.
> 
> Thank you for all your time and consideration.
> 
> --Chris H
> 
>>> /mjt
>>> _______________________________________________
>>> rbldnsd mailing list
>>> rbldnsd at corpit.ru
>>> http://www.corpit.ru/mailman/listinfo/rbldnsd
>> _________________________________________________________________
>> http://fastmail.ca/ - Fast Secure Web Email for Canadians
>>
>> _______________________________________________
>> rbldnsd mailing list
>> rbldnsd at corpit.ru
>> http://www.corpit.ru/mailman/listinfo/rbldnsd
> _________________________________________________________________
>     http://fastmail.ca/ - Fast Secure Web Email for Canadians
> 
> _______________________________________________
> rbldnsd mailing list
> rbldnsd at corpit.ru
> http://www.corpit.ru/mailman/listinfo/rbldnsd