What's new on the 127.0.0/24 block in 7?

Chris H. chris# at 1command.com
Tue Mar 4 08:03:32 UTC 2008


Quoting Mark Andrews <Mark_Andrews at isc.org>:

>
>> Quoting Mark Andrews <Mark_Andrews at isc.org>:
>>
>> >
>> >> Quoting Andy Dills <andy at xecu.net>:
>> >>
>> >> > On Mon, 3 Mar 2008, Chris H. wrote:
>> >> >
>> >> >> > Are you sure it's a /24 you are talking about? My 7.0 disks install
>> >> >> > 127.0.0.1/8 here.
>> >> >>
>> >> >> Really? Where did you get the install disc? Mine clearly doesn't. :(
>> >> >> All I am provided is 127.0.0.1 - not 127.0.0.2,3...
>> >> >
>> >> > 127.0.0.1/8 just means 127.0.0.1 with a netmask of 255.0.0.0. 
>> It doesn't
>> >> > imply a default behavior of binding to any other address than 
>> 127.0.0.1.
>> >> >
>> >> > But I'm still really confused what you're trying to do...
>> >> >
>> >> > See, the idea of returning multiple 127.0.0.X addressess within 
>> RBL is t
>> o
>> >> > convey different information while using a single zone.
>> >> >
>> >> > In the beginning, the RBLs would just reply with 127.0.0.1 and use
>> >> > different zones to imply different contexts...now you use a single zone
>> >> > with different 127.0.0.X addresses to convey the same information.
>> >> >
>> >> > But...you don't actually do anything with that resolution 
>> beyond determi
>> ne
>> >> > if a given record is listed or not. You don't actually need to 
>> configure
>> >> > or use the various 127.0.0.X addresses that might get returned.
>> >> >
>> >> > On the other hand, if you're using multiple rbldnsd instances, one per
>> >> > zone... hile it's a pain you can indeed configured rbldns to serve
>> >> > multiple zones. Or just bind the additional loopback instances
>> >>
>> >> Precisely! Sorry I apparently wasn't clearer in the beginning.
>> >> According to my conversations with the author of rbldnsd, rbldnsd was
>> >> returning REFUSED to all my requests on my FBSD-7 server.
>> >> Because it was unable to communicate on 127.0.0.2.
>> >
>> > 	If it returned REFUSED it could communicate.  REFUSED is a
>> > 	DNS rcode so the packet went to the server and a reply was
>> > 	returned.  This is a problem with a access control list in
>> > 	the rbldnsd configuration.  I can tell you that without
>> > 	ever having run rbldnsd.
>> >
>>
>> Yes, of course. Sorry, my bad. RBLDNSD's /log/ files contain REFUSED.
>> The dig, host,nslookup queries return
>>
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 58463
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
>>
>> Sorry. I should have taken more time to answer.
>>
>> --Chris H
>
> 	Which doesn't change the diagnosis.
>
> 	You are talking to the caching server which is talking to
> 	rbldnsd which returns REFUSED.  When the caching server
> 	runs out of servers to try it returns SERVFAIL to the
> 	original querier.

Hello Mark. Thank you for your thoughtful reply.
FWIW I'm hosting my own zone, out of my domain's address using a
different host name. I'm simply forwarding the requests to a different
port, so as to prevent port collision with the BIND. The zones are
answered our of 127.0.0.2 || 3.
I have absolutely no idea why FBSD v7 (on 2 machines) will only
dole out 127.0.0.1, while all my other servers running RELENG_6 all
dole out a /minimum/ of 127.0.0.1/8 by default. But, having just now
modified the default rc for ifconfig_lo0 to a 255.255.255.0 netmask
now makes a different response when querying rbldnsd.
Sending:
dig -p530 @my-domain.COM \
<some IP in the zone>.blackhole.my-domain.COM
now returns:
;; 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
The following query:
dig -p530 +norec @blackhole.my-domain.COM \
<some IP in the zone>.blackhole.my-domain.COM -t txt

Returns the same. So, adding the additional addresses on lo0
at least eliminated the NXDOMAIN. But of course, still "no joy".
OH, and no, I'm not using an auth file (zone). Didn't need one
on the working v6 server, and see no reason to think I should
need one here.

Thank you again, for your thoughtful response.

--Chris H

P.S. Right out of the BIND FAQ:
	zone "blackhole.my-domain.COM" {
	type forward;
	forward only;
	forwarders { <my servers primary IP> port 530; };
};

>
> 	P.S. you can test the rbldnsd directly if you want.
>
> 		dig -p port +norec @address query
>
> 	Mark
>
> --
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org
>



-- 
panic: kernel trap (ignored)





More information about the freebsd-stable mailing list