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