On Fri, 2011-03-04 at 08:15 +0100, Tollef Fog Heen wrote: > ]] Ben Hutchings > > Hi, > > | On Thu, Mar 03, 2011 at 05:20:37PM +0100, Tollef Fog Heen wrote: > | > | > To the extent this is a bug, it's a bug in the resolver that it does not > | > treat names with dots in them as absolute, but relative. I know this is > | > how it's been done in the past, but perhaps changing that to treating > | > names with as absolute would be a better solution. > | > | echo >>resolv.conf options ndots:15 > > Thanks for the suggestion, but this does not seem to do what I want, I think? > > ndots:n > sets a threshold for the number of dots which must appear in a name > given to res_query(3) (see resolver(3)) before an initial absolute > query will be made. The default for n is 1, meaning that if there > are any dots in a name, the name will be tried first as an absolute > name before any search list elements are appended to it. The value > for this option is silently capped to 15. > > I'd like it to not append the search list if there are dots at all. You could stop being lazy and type the dot on the end too. ;-) > so doing «getent hosts foo.bar» will only generate a query for > «foo.bar.», not for «foo.bar.$searchpath.» I misparsed your question because I assumed you were addressing the issue that Bastien pointed out in the message you replied to: > main security problem is resolver, > $host -v www.local > www.local > www.local.mydomain.com And I believe that the 'ndots' option does address that issue - to an extent. You still need DNSSEC or application-layer security to verify the answer, regardless of the presence of mDNS. Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
Description: This is a digitally signed message part