[rbldnsd] I HATE BIND - please help
Chris.
cth at fastmail.ca
Thu Mar 6 05:59:28 MSK 2008
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.
>
> 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.
>
> 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.
>
> 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.
>
>
>>
>> -- 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
_________________________________________________________________
http://fastmail.ca/ - Fast Secure Web Email for Canadians
More information about the rbldnsd
mailing list