[rbldnsd] I HATE BIND - please help
Chris.
cth at fastmail.ca
Thu Mar 6 07:41:36 MSK 2008
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. 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
More information about the rbldnsd
mailing list