No subject
Thu Feb 28 12:08:37 MSK 2008
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.
</pre>
</blockquote>
<pre wrap="">127.0.0.1 OK, > 127.0.0.1 !OK
</pre>
<blockquote type="cite">
<pre wrap="">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 <a class="moz-txt-link-freetext" href="http://www.corpit.ru/mjt/udns.html">http://www.corpit.ru/mjt/udns.html</a> -- it
matches `host' utility from BIND and allows to specify port too
(maybe dig has 'port' option as well? I don't remember).
</pre>
</blockquote>
<pre wrap="">Both nslookup, and bind allow port selection on queries.
nslookup -port=65536, for example.
</pre>
<blockquote type="cite">
<pre wrap="">3) problem spotted by furio ercolessi (well spotted!) --
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""># 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
</pre>
</blockquote>
</blockquote>
<pre wrap="">...
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">The RBLDNSD logs all return:
1204196617 111.222.333.444
999.888.777.666.blackhole.nospammers.COM A IN: REFUSED/0/61
</pre>
</blockquote>
</blockquote>
<pre wrap="">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!
</pre>
</blockquote>
<pre wrap="">Thanks. :) Message received.
</pre>
<blockquote type="cite">
<pre wrap="">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 ;)
</pre>
</blockquote>
<pre wrap="">LOL
</pre>
<blockquote type="cite">
<pre wrap="">Oh-oh. This reply was much longer than previous - it is even
longer than your original message! ;)
</pre>
</blockquote>
<pre wrap="">LOL Sorry, I was attempting to be concise. Hope that was OK.
</pre>
<blockquote type="cite">
<pre wrap="">Something like that, anyway... ;)
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Hello, and thank you for your reply.
I tried as you suggested. But the DIG replied:
Invalid option: +udp
Thanks again.
--Chris H
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">/mjt
_______________</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<br>
The correct option is +notcp and dig defaults to udp EXCEPT when doing
AXFR or IXFR requests.<br>
<br>
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.)<br>
<br>
<br>
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.<br>
<br>
Lyle Giese<br>
LCR Computer Services, Inc.<br>
<br>
</body>
</html>
--------------050606050102020601040102--
More information about the rbldnsd
mailing list