[rbldnsd] I HATE BIND - please help
Chris.
cth at fastmail.ca
Thu Mar 6 03:21:46 MSK 2008
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
;; QUESTION SECTION:
;99.249.22.103.blackhole.nospammers.com. IN TXT
;; Query time: 1 msec
;; SERVER: 00.000.000.000#1053(00.000.000.000)
;; WHEN: Wed Mar 5 16:14:46 2008
;; MSG SIZE rcvd: 55
Please note: In an effort to determine if it might be a port
issue. I changed the port from 530, to 1053 in both named.conf
and the command line I use to start RBLDNSD.
Wow. Am I frustrated.
Thank you for all your continued support.
--Chris H
>
> --Chris H
>
>> Lyle
>>
>> _______________________________________________
>> 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