[rbldnsd] I HATE BIND - please help
Chris.
cth at fastmail.ca
Thu Mar 6 08:27:15 MSK 2008
On Thu, 6 Mar 2008 04:41:36 +0000 (UTC), Chris. wrote...
> On Wed, 5 Mar 2008 20:37:37 -0700, Eric Langheinrich wrote...
>
>>
>>
>>
>> On Thu, 6 Mar 2008 02:49:41 +0000 (UTC), Chris. wrote...
>>
>>> On Wed, 5 Mar 2008 18:17:23 -0700, Eric Langheinrich wrote...
>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: rbldnsd-bounces at corpit.ru [mailto:rbldnsd-bounces at corpit.ru]
>>>> On Behalf Of Chris.
>>>> Sent: Wednesday, March 05, 2008 5:22 PM
>>>> To: rbldnsd at corpit.ru
>>>> Subject: Re: [rbldnsd] I HATE BIND - please help
>>>>
>>>> On Thu, 6 Mar 2008 00:03:03 +0000 (UTC), Chris. wrote...
>>>>
>>>>>> On Wed, 05 Mar 2008 14:29:21 -0600, Lyle Giese wrote...
>>>>>>
>>>>>>> Chris. wrote:
>>>>>>>> On Tue, 04 Mar 2008 18:48:49 -0600, Lyle Giese wrote...
>>>>>>>>
>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Hello Lyle, and thank you for your reply.
>>>>>>>>
>>>>>>>> Thanks for the "heads up". My previous, and /working/ install
>>>>>>>> on a different server didn't seem to require those entries. But
>>>>>>>> of course, this one /isn't/ working. So I took your advice. :)
>>>>>>>>
>>>>>>>> This is what the ip4tset looks like now:
>>>>>>>>
>>>>>>>> #$SOA 3600 blackhole.nospammers.COM postmaster.nospammers.COM
>>>>>>>> 2003101500 1800 900 604800 10800 #$NS 3600 ns.nospammers.COM
>>>>>>>> #$TTL 3600 :127.0.0.2:DENIED! Too much abuse from the $
>>>>>>>> network, goodbye.. 111.111.111.111
>>>>>>>> 222.222.222.222
>>>>>>>> 333.333.333.333
>>>>>>>> ...
>>>>>>>> 888.888.888.888
>>>>>>>> 999.999.999.999
>>>>>>>> ...
>>>>>>>>
>>>>>>>> After making this adjustment, I killed RBLDNSD, cleared the pid
>>>>>>>> file and started it up. Unfortunately performing dig against
>>>>>>>> any IP's in the ip4tset (or any other, for that matter) all
>>>>>>>> still return REFUSED.
>>>>>>>>
>>>>>>>> sigh.
>>>>>>>>
>>>>>>>> Anyway, thank you again for taking the time to respond.
>>>>>>>>
>>>>>>>> --Chris H
>>>>>>>>
>>>>>>>> P.S. Thanks also for the text based posting. :)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> Lyle Giese
>>>>>>>>> LCR Computer Services, Inc.
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> 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
>>>>>>>>
>>>>>>> Lines prepended with a # symbol become comment lines. So your
>>>>>>> $SOA or $NS lines have no effect on the zone files.
>>>>>>>
>>>>>>
>>>>>> Hello Lyle, and thank you
>>>>>> 1) for your thoughtful response
>>>>>> 2) for taking the time to provide a /text-only/ response. :)
>>>>>>
>>>>>> OK On to your response...
>>>>>>
>>>>>> According to the rbldnsd man page (as /I/ interpret it) listed
>>>>>> under the heading: "Special Entries"
>>>>>> The excerpt follows:
>>>>>> If a line starts with a dollar sign ($), hash character and a
>>>>>> dollar sign (#$), semicolon and dollar sign (;#) or colon and a
>>>>>> dollar sign (:$), it is interpreted in a special way, regardless
>>>>>> of dataset type (this is one exception where a line starting with
>>>>>> hash character is not ignored - to be able to use zone files for
>>>>>> both rbldnsd and for DJB's rbldns). The following keywords,
>>>>>> following a dollar sign, are recognized:
>>>>>>
>>>>>> The rest goes on to explain $SOA, $NS, $TTL, etc...
>>>>>>
>>>>>> But I'll surely take your advice, and remove the preceeding #
>>>>>> symbols, and hope for the best. :)
>>>>>>
>>>>>> I'll report back with my findings.
>>>>>>
>>>>>> Thank you again for your thoughtful response.
>>>>
>>>>> Sigh. All queries return: REFUSED - what a hostile application.
>>>>
>>>>> Here is some output:
>>>>
>>>>> ; <<>> DiG 9.4.2 <<>> -p1053 +norec @00.000.000.000
>>>> 99.249.22.103.blackhole.nospammers.COM
>>>>> -t txt
>>>>> ; (1 server found)
>>>>> ;; global options: printcmd
>>>>> ;; Got answer:
>>>>> ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 61065 ;;
>>>>> flags: qr;
>>>> QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>>>
>>>> Chris,
>>>>
>>>> The reason you are so frustrated at this point is that you refuse
>>>> to share the necessary information with us to be able to help you.
>>>>
>>>> Generally, you will get a refused if you are querying for a domain
>>>> the DNS server is not authoritative for. For example, if you are
>>>> querying nospammers.com and your zone is setup as nospammers.net.
>>>>
>>>> Make sure your queries actually match your zone setup.
>>>
>>> Hello, and thanks for your reply.
>>>
>>> I'm not sure I can follow you here. I've provided very concise
>>> information regarding my configuration(s), implementation, and
>>> ultimate gaol - which, at this point is to simply get it to work.
>>
>> Aside from the fact that half of your queries above don't match your
>> configuration of .net versus .com.
>
> Firstly, thank you for your prompt reply.
>
> @.net vs. .com; I attempted to clear any confusion in that area
> in my last reply. But OK. Fair enough.
>
>>
>> I was saying two things. First, verify that what you are querying
>> matches what you have setup in your zones in rbldnsd. The refused
>> indicates that they don't match.
>
> The most recent zone file I am currently using was posted recently in
> a reply to Lyle. As is the relevant entries in the BIND named.conf.
> They both look to be in "sync" to me. Do you see any conflict(s)?
>
>> Secondly, why are you hiding the real
>> IP and domain zone names when you are asking for help.
>
> Because I appreciate the fact that this mailing list is intended as
> a means of support and friendly discussion for the RBLDNSD. I can't
> help but consider, that because of the very purpose of the RBLDNSD; I
> would tend to think those /against/ it's cause would /also/ troll the
> list. I simply don't want the additional "noise" on my wire, while I
> am attempting to get the RBLDNSD functioning.
>
> If you honestly believe that my sharing the IP, and FQDN will make the
> difference, and you don't mind my contacting you "off list". I'd be
> willing to do so.
>
>>
>> The test I ran against my rbldnsd zones indicates that if the rbldnsd
>> server does not think it is authoritative for the zone, it will
>> refuse the query. This seems to be the exact scenario that you have
>> run into.
>
> Agreed. In all my years of experience with the BIND. This has also
> been the case. But I try to refrain from making /too/ many comparisons
> between the two. Because RBLDNSD is not the BIND. But OK. This seems
> reasonable.
>
>>
>>
>>>
>>> The /only/ 2 (two) items that I have not provided verbatim; is the
>>> IP, and the domain name. However, I provided a legend to clear any
>>> thing ambiguous - 00.000.000.000 = the Internet Routable IP address
>>> (only one). nospammers.COM = the FQDN used for that IP (also visible
>>> to the internet, and the only domain name) That is pretty darn
>>> clear, even to someone whom might be new to the DNS, and the
>>> internet - really. The nameserver = ns, that's pretty clear.
>>> blackhole = RBLDNSD's host name = that also, seems pretty clear. Do
>>> you need my administrative password to effectively assist in my
>>> getting the RBLDNSD working correctly? I'm sorry, but I'm having a
>>> difficult time understanding where anything in my gaol, and
>>> configuration could be considered at all ambiguous. I've gone to
>>> great lengths to provide all the dirty details. :) I noticed you
>>> mentioned .NET in your reply. While that is my /ultimate/ goal. My
>>> /current/ interest is simply to get the RBLDNSD working at all.
>>> Given that the primary host/domain name for this server is a .COM.
>>> I've decided using the .COM will provide least possibilities for
>>> complication. So the .COM domain is the one I'm currently working
>>> with.
>>
>> You've gone to great lengths to obfuscate the dirty details of your
>> configuration. The problem being this seems to be exactly where you
>> are getting hung up. Essentially, getting your IP and admin password
>> would probably get you the help your looking for sooner.
>
> See my response a little earlier in this reply above.
>
>>
>>>
>>> I dearly hope things are clearer now, and wish to thank you again
>>> for taking the time to respond.
>>>
>>> --Chris H
>>>
>>> P.S. I guess I should also probably mention that the ns for this
>>> domain (ns) always answers authoritatively for the domain(s) it is
>>> assigned - the logs (BIND) confirm this.
>>
>> If rbldnsd answers authoritatively for the query you wouldn't be
>> getting refused.
In the BIND, and according to the RBLDNSD man page, setting the so bit
is a matter of:
@ IN SOA <name server here>, or for short: @ SOA <name server here>
in the RBLDNSD:
$SOA
Is my man page out of date? Is there a /secret/ way that requires some
code to set the so bit in 0996a? I just don't get it. It /really/ isn't
difficult to read, and understand the man page for the RBLDNSD. The BIND
logs indicate that the so bit is set for my NS for the /same/ domain that
the RBLDNSD is /also/ given the so bit for /it's/ host name - $SOA blackhole.
Why is it such a problem for the RBLDNSD to be an authoritive DNS - or
authorative for at least itself?
Anyway, I just "bounced" the server a couple of times, hoping that a /clean/
environment might make the difference. I guess not. :(
--Chris out...
> What do the rbldnsd query logs show for the query?
>
> 1204194385 00.000.000.000 165.193.171.124.blackhole.nospammers.COM A
> IN: REFUSED/0/61 1204196017 00.000.000.000
> 165.193.171.124.blackhole.nospammers.COM A IN: REFUSED/0/61 1204196045
> 00.000.000.000 165.193.171.124.blackhole.nospammers.COM A IN:
> REFUSED/0/61 1204724879 00.000.000.000
> 127.0.0.3.blackhole.nospammers.COM TXT IN: REFUSED/0/51 1204724894
> 00.000.000.000 3.0.0.127.blackhole.nospammers.COM TXT IN: REFUSED/0/51
> 1204724904 00.000.000.000 4.0.0.127.blackhole.nospammers.COM TXT IN:
> REFUSED/0/51 1204724920 00.000.000.000
> 1.0.0.127.blackhole.nospammers.COM TXT IN: REFUSED/0/51 1204724933
> 00.000.000.000 127.0.0.1.blackhole.nospammers.COM TXT IN: REFUSED/0/51
> 1204762045 00.000.000.000 1.0.0.127.blackhole.nospammers.COM TXT IN:
> REFUSED/0/51 1204762055 00.000.000.000 blackhole.nospammers.COM TXT
> IN: REFUSED/0/41 1204762196 00.000.000.000 blackhole.nospammers.com
> TXT IN: REFUSED/0/41 1204762420 00.000.000.000
> 127.0.0.3.blackhole.nospammers.com TXT IN: REFUSED/0/51 1204762429
> 00.000.000.000 127.0.0.2.blackhole.nospammers.com TXT IN: REFUSED/0/51
> 1204762440 00.000.000.000 127.0.0.1.blackhole.nospammers.com TXT IN:
> REFUSED/0/51 1204762486 00.000.000.000
> 99.249.22.103.blackhole.nospammers.com TXT IN: REFUSED/0/55
>
> I guess it would have been easier to simply answer your last question
> with a simple:
>
> REFUSED. ;)
>
> I appreciate your taking the time to respond. Thanks.
>
> --Chris H
>
>>
>>>
>>> Thanks again.
>>
>>> P.P.S. I also forgot to mention that I ran /only/ RBLDNSD as the
>>> only name
>> server for over 3 hours today. Yet the replies always remain the
>> same: REFUSED.
>>
>> Running rbldnsd as the only name server doesn't solve the problem if
>> it doesn't think it is authoritative for the domain/sub-domain you
>> are querying against.
>>
>>
>>>
>>>
>>>>
>>>> -- Eric
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>>
>> _______________________________________________
>> 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
More information about the rbldnsd
mailing list