resolver broken on feisty? (was Re: sshd complains: POSSIBLE BREAK-IN ATTEMPT)

[Josef Wolf]

On Mon, Sep 17, 2007 at 09:38:22AM +1000, Karl Auer wrote:
> On Sun, 2007-09-16 at 14:21 +0200, Josef Wolf wrote:
> > > What do you have in /etc/nsswitch.conf on these two machines?
> > 
> > [ ... ]
> > hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
> > [ ... ]
> > 
> > Ah, it seems that here we come closer to the problem.  When I reduce this
> > line to "hosts: files" the problem diasappears.
> 
> Yes - but only if the box concerned has an entry in the hosts file, I
> assume?

Strange as it sounds: no.  I have _no_ such line in /etc/hosts, but the
problem still disappears when I reduce it to "hosts: files".

Unfortunately, the manpage for nsswitch.conf leaves open what _exactly_
mdns_minimal and mdns4 lookups do.  Any pointers?

> > With the original line, I see 2 problems:
> > 
> > 1. "[NOTFOUND=return]" appears before "dns".  This means that dns lookups
> >    will never be done?  Does this really make sense?
> 
> Um, I'd have expected nothing or "[NOTFOUND=continue]" (which is the
> default. So no, I don't think that makes sense. However, at the time
> that file was created, maybe you didn't have a resolv.conf or for some
> other reason dns was not available?

At installation time, this host (and its namesever settings) was
configured by dhcp.  The nameserver was definitely set correct and
was working at installation time because otherwise "apt-get update/upgrade"
(which I _always_ run immediately after the first reboot) would have
failed.

> I'm not sure, but the NOTFOUND may
> not apply if mdns is not available at all, only if it is there and says
> "not found". Personally I have disabled the whole zeroconf mess, which
> *may* be why my lookups all work in spite of having the same
> nsswitch.conf entries as you :-)

I don't like the idea to completely disable it.  I'd rather keep the
option to switch to zeroconf in the future, when the standard has
matured.

> Anyway, you could move dns to just after hosts, or remove the mdsn[4]
> entries, or change "return" to "continue". All of those should do the
> trick. BUT: raven.wolf.local must be in the hosts file or resolvable via
> the DNS, otherwise nothing can work.

Well, it _is_ resolvable via dns, so the quick'n'dirty fix would be to
simply remove the mdns entries.  But I'd prefer to do the right thing,
if only I knew what the right thing would be ;-)

> > 2. I have googled a little bit for mdns information.  It looks as if
> > the domain name ".wolf.local" that I have choosen for my internal
> > network (should not be visible from outside) collides with mdns.
> 
> Yes. But it should disable itself automagically if it sees anything in
> the domain ".local" anyway.

Are you sure about that?  Then there's a bug in the library?

> >    Now I wonder what domain names can be used for such purposes.  Is
> >    there something like "private" domain names (analogous to the rfc1918
> >    private addresses like 192.168.x.y?)
> 
> It's private - so pick whatever you like. That's what "private"
> means :-) How about ".private"?

But I would get into trouble if someone would officially register the
.private TLD ;-)