[rbldnsd] I HATE BIND - please help
Lyle Giese
lyle at lcrcomputer.net
Wed Mar 5 23:29:21 MSK 2008
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.
Lyle
More information about the rbldnsd
mailing list