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

Mark Andrews Mark_Andrews at isc.org
Tue Mar 4 06:19:42 UTC 2008


> 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.

	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


More information about the freebsd-stable mailing list