[rbldnsd] I HATE BIND - please help
Lyle Giese
lyle at lcrcomputer.net
Wed Mar 5 03:48:49 MSK 2008
Chris. wrote:
> On Tue, 04 Mar 2008 10:49:33 -0600, Lyle Giese wrote...
> Chris. wrote:
>
>> On Tue, 04 Mar 2008 22:56:19 +1300, Amos Jeffries wrote...
>>
>>
>>
>>> 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.
>>>
>>>
>>>
>> Hello, and thank you for your reply.
>> I tried as you suggested. But the DIG replied:
>>
>> Invalid option: +udp
>>
>> Thanks again.
>>
>> --Chris H
>>
>>
>>
>>>> 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
>>>>>> _______________
>>>>>>
>
> Hello Lyle, and thank you for your reply.
>
>
>> The correct option is +notcp and dig defaults to udp EXCEPT when doing
>> AXFR or IXFR requests.
>>
>
> Yes. This has always been my understanding. I thought perhaps it might
> have been some undocumented option.
>
>
>> I think the issue maybe that for some reason, your rbldnsd does NOT
>> think it's authoritative for that zone. Hence, the recursion requested
>> but not available.(rbldnsd does not do recursion at all.)
>>
>
> Yes. I was aware of that. I would have used +norec. But it seemed
> unnecessary.
>
>
>> rbldnsd will respond to 1.0.0.127.blackhole.spammers.com with your
>> default A record and TXT record(actually it's
>> x.0.0.127.blackhole.spammers.com), only IF it thinks it is
>> authoritative for that zone. It's built in as a test mechanism in
>> rbldnsd. You might want to double check your SOA and NS records in
>> your dataset.
>>
>
> Well. Just for clarity. Here's another look at my setup:
> # named.conf
> // #### LOCAL BLOCKLIST ####
>
> zone "blackhole.nospammers.COM" {
> type forward;
> forward only;
> forwarders { 00.000.000.000 port 530; };
> };
>
> # primary domain zone (nospammers.COM)
> ; NOSPAMMERS.COM
> ;
> $TTL 3600
> $ORIGIN nospammers.COM.
> @ SOA brickwall.spam-fighters.COM. noc.spam-fighters.COM. (
> 2007032115 ; serial
> 1800 ; refresh (30 min)
> 900 ; retry (15 min)
> 604800 ; expire (1 wk)
> 10800 ) ; minimum (3 hrs)
> NS ns.nospammers.COM.
> A 00.000.000.000
> NS ns.some-other-domain.
> NS yet.some-other.domain.
>
> MX mx.nospammers.COM.
>
> ns A 00.000.000.000
> HINFO IBM-PC/AT BSD/OS
> MX mx.nospammers.COM.
>
> blackhole NS ns
>
> # clients (ip4tset)
> :127.0.0.2:DENIED! Too much abuse from the $ network, goodbye...
> 1.1.1.1
> 2.2.2.2
> 3.3.3.3
> ...
> 8.8.8.8
> 9.9.9.9
> ...
>
> # RBLDNSD startup
> rbldnsd -u rbldns:rbldns -v -v -p /var/run/rbldnsd.pid -f \
> -c 1m -l rbldnsd.log -r /usr/local/etc/rbldnsd \
> -b 00.000.000.000/530 blackhole.nospammers.COM:ip4tset:clients
>
> # legend
> 00.000.000.000 = the primary domain/host internet routable IP
>
> I hope all this has helped clarify things a bit.
>
> Thank you again for your thoughtful input.
>
> --Chris H.
>
> P.S. The thread will be a bit buggered, as the only way I was
> able to reply was to strip the email to my editor, and paste
> it into the reply box. So the whole thread is one level
> short.
>
In your rbldnsd ip4tset data set, shouldn't you have two more lines?
$SOA ttl origindn persondn serial refresh retry expire minttl
$NS ttl nameserverdn nameserverdn...
The man page indicates the $SOA is optional but recommended, but does
not state that the $NS line is optional.
Lyle Giese
LCR Computer Services, Inc.
More information about the rbldnsd
mailing list