[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#182886: libc6: local hostnames containing a dot get forwarded outside when doing host-lookups.



* Vassilii Khachaturov <vassilii@tarunz.org> [030228 21:58]:
> > Thanks, I missed that. Being placed unter "internal variables" and
> > "debug" seems to have tricked me in ignoring this part.
> > 
> > There should at least be a sentence "search" to indicate that one has
> > to read the ndots-part to get a real search-path.

I've tested this some people by letting them open resolv.conf and
describing the problem. Noone found anything until they were told
to look for "options ndots". I suggest adding something like the
following to the manpage:

--- resolv.conf.5.orig  Sun Mar  2 18:10:44 2003
+++ resolv.conf.5       Sun Mar  2 18:34:38 2003
@@ -72,8 +72,14 @@
 This may be changed by listing the desired domain search path
 following the \fIsearch\fP keyword with spaces or tabs separating
 the names.
-Most resolver queries will be attempted using each component
+Resolver queries having less than 
+.B ndots 
+dots (default is 1) in them will be attempted using each component
 of the search path in turn until a match is found.
+For environments with multiple subdomains please read 
+.B options ndots:n
+below to avoid man-in-the-middle attacks and unnecessary
+traffic for the root-dns-servers.
 Note that this process may be slow and will generate a lot of network
 traffic if the servers for the listed domains are not local,
 and that queries will time out if no server is available


I think this should fix the problem of misleading documentation.


> > There is still the problem of an insecure default. Perhaps reassigning
> > a clone to the installer might be the best solution. 
> > 
> 
> I'm not sure yet if there is any secure default that makes sense for people
> with just one domain name (majority). 

I think there are mainly 3 classes of users:
- those with multiple domains
- those with a single domain but near/local nameserver.
- those with far away nameserver (dial-up-computers)

Slowdown by a secure default should mainly hit the third one, though
I guess they will resolv.conf mainly have set by some tools.
(I cannot feel any slowdown here by a options ndots:20 here, though
the net is quite slow and the nameserver two routers and several
streets away, so I guess second one should make no difference).

> Change the debian installer to start
> educating people about what happens if some.localdomain syntax is used
> unless ndots is adjusted?

At least if it lets one enter a "search"-line. I do not currently
remember if the base-floppies did and not yet looked in the new one
enough. If it only places the domain name there (or nothing at all so
the domainame is taken), one could hope that all computers are on the same
depth in hirachy. ( Accessing x.y.a.b from z.a.b would still have this
problem).

> Disallow search at all by default, so that even for a local
> domain one should always give an FQDN, whereas if someone wants the
> search logic, this should be done via a special config. tool that gives
> the warnings?

If it was switched off by default and the behaviour resonable described
in the manpage, one could leave the part with the tool away. (Though
this would be like disabling network to make it secure).

> Modify all the packages and runtime scripts (like dhcp client stuff) that
> changes the resolv.conf file to emit a commented warning there as well
> to educate users that want to change the file manually?

Hm, tools editing resolv.conf make the things difficult, indeed.
Though a hard coded standard of ndots:infinity in libresolv and
dial-up scripts adding a options ndots:1 may make things secure
and resonable fast for almost anyone. (Only exceptions would be
people dial-up to a multi-domain area or people hand-editing
a dial-up connection).

Hochachtungsvoll,
	Bernhard R. Link
-- 
The man who trades freedom for security does not deserve 
nor will he ever receive either. (Benjamin Franklin)



Reply to: