Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #186861 > unrolled thread

sudo slow on DNS lookup, with invalid resolv.conf entries

Back to article view | Back to linux.debian.user

Contents

  sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 18:10 +0200
    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-15 19:00 +0200
      Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 21:30 +0200
        Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-15 22:00 +0200
          Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 23:10 +0200
            Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-15 23:20 +0200
              Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 23:40 +0200
                Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-16 00:10 +0200
                  Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-16 01:20 +0200
                    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-16 02:10 +0200
                      Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-17 22:40 +0200
                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-17 23:00 +0200
                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-18 00:10 +0200
                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-18 00:50 +0200
                            Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 01:00 +0200
                              Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-18 01:10 +0200
                                Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 09:00 +0200
                                  Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-18 18:40 +0200
                                    Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 20:20 +0200
                                      Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-18 20:50 +0200
                                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries Reco <recoverym4n@gmail.com> - 2017-09-18 22:50 +0200
                                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-19 00:00 +0200
                                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-18 22:50 +0200
                                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-19 00:00 +0200
                                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries deloptes <deloptes@gmail.com> - 2017-09-18 23:00 +0200
                                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-19 00:00 +0200
                                    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-19 00:10 +0200
                        Re: sudo slow on DNS lookup, with invalid resolv.conf entries Gene Heskett <gheskett@shentel.net> - 2017-09-18 00:50 +0200
                          Re: sudo slow on DNS lookup, with invalid resolv.conf entries Brian <ad44@cityscape.co.uk> - 2017-09-18 01:20 +0200
    Re: sudo slow on DNS lookup, with invalid resolv.conf entries Dan Ritter <dsr@randomstring.org> - 2017-09-15 23:10 +0200
      Re: sudo slow on DNS lookup, with invalid resolv.conf entries "x9p" <debian-user@x9pneu.com> - 2017-09-15 23:40 +0200

Page 2 of 2 — ← Prev page 1 [2]

#186972

	Hi.

On Mon, Sep 18, 2017 at 07:48:53PM +0100, Brian wrote:
> On Mon 18 Sep 2017 at 20:13:44 +0200, deloptes wrote:
> 
> > Reco wrote:
> > 
> > > The question is - since 'localhost.localdomain' is special, what happens
> > > if such hostname is chosen during the installation?
> > 
> > well, now we all know what happens :)
> 
> True, we know the OP has a problem with with sudo.

That's what lie on surface. Any software that implements
uname/gethostbyname sequence would exhibit similar behavior.


> What we do not know
> is the hostname he chose during the installation, although it looks like
> it was "localhost" from the second line of
> 
>   127.0.0.1       localhost                                                                                             
>   127.0.1.1       localhost

I agree.


> The installer recommends a single word for the hostname. The "single"
> aspect is the result of a number of years of experience and bug reports.

And let's not forget RFC 952 (obsoleted by RFC 1123), which states:

A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24
characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),
and period (.).  Note that periods are only allowed when they serve to
delimit components of "domain style names".


RFC 1123 lifts some restrictions:

One aspect of host name syntax is hereby changed: the restriction on the
first character is relaxed to allow either a letter or a digit.  Host
software MUST support this more liberal syntax.

Host software MUST handle host names of up to 63 characters and SHOULD
handle host names of up to 255 characters.


But does not says anything about dots, so restrictions of RFC 952 still
apply.


> Although "localhost.localdomain" is not an invalid hostname

I agree as long as 'invalid' is defined as 'kernel does not accept it'.
For instance, one can set nodename as 'localhost.local' and watch avahi
explode. Or, say, '_localhost', if one intends to wreak havoc in local
DNS's SRV records.
The kernel is surprisingly liberal at these things.


> the OP does not appear to have used it. (We have not been given the
> contents of his /etc/hostname explicitly).

True. We also did not see the contents of sysctl.conf (and those *other*
files that can store kernel tunables), custom init.d scripts and custom
systemd units if there were any.

To make things more confusing, 'localhost.localdomain' could be a
'transient' hostname, not a 'static' one (aka /etc/hostname).

It's one of those things I prefer to debug with auditd on. Too many
possibilities otherwise.


> What was the problem with his resolv.conf? Have I missed that?

OP used an unspecified VPN client which put an additional entry into
/etc/resolv.conf on start, but failed to clean it up on stop.

Reco

[toc] | [prev] | [next] | [standalone]

#186978

On Mon 18 Sep 2017 at 23:47:18 +0300, Reco wrote:

> On Mon, Sep 18, 2017 at 07:48:53PM +0100, Brian wrote:
> > On Mon 18 Sep 2017 at 20:13:44 +0200, deloptes wrote:
> > 
> > > Reco wrote:
> > > 
> > > > The question is - since 'localhost.localdomain' is special, what happens
> > > > if such hostname is chosen during the installation?
> > > 
> > > well, now we all know what happens :)
> > 
> > True, we know the OP has a problem with with sudo.
> 
> That's what lie on surface. Any software that implements
> uname/gethostbyname sequence would exhibit similar behavior.
> 
> 
> > What we do not know
> > is the hostname he chose during the installation, although it looks like
> > it was "localhost" from the second line of
> > 
> >   127.0.0.1       localhost                                                                                             
> >   127.0.1.1       localhost
> 
> I agree.
> 
> > The installer recommends a single word for the hostname. The "single"
> > aspect is the result of a number of years of experience and bug reports.
> 
> And let's not forget RFC 952 (obsoleted by RFC 1123), which states:
> 
> A "name" (Net, Host, Gateway, or Domain name) is a text string up to 24
> characters drawn from the alphabet (A-Z), digits (0-9), minus sign (-),
> and period (.).  Note that periods are only allowed when they serve to
> delimit components of "domain style names".
> 
> RFC 1123 lifts some restrictions:
> 
> One aspect of host name syntax is hereby changed: the restriction on the
> first character is relaxed to allow either a letter or a digit.  Host
> software MUST support this more liberal syntax.
> 
> Host software MUST handle host names of up to 63 characters and SHOULD
> handle host names of up to 255 characters.
> 
> But does not says anything about dots, so restrictions of RFC 952 still
> apply.
> 
> > Although "localhost.localdomain" is not an invalid hostname
> 
> I agree as long as 'invalid' is defined as 'kernel does not accept it'.
> For instance, one can set nodename as 'localhost.local' and watch avahi
> explode. Or, say, '_localhost', if one intends to wreak havoc in local
> DNS's SRV records.
> The kernel is surprisingly liberal at these things.
> 
> > the OP does not appear to have used it. (We have not been given the
> > contents of his /etc/hostname explicitly).
> 
> True. We also did not see the contents of sysctl.conf (and those *other*
> files that can store kernel tunables), custom init.d scripts and custom
> systemd units if there were any.
> 
> To make things more confusing, 'localhost.localdomain' could be a
> 'transient' hostname, not a 'static' one (aka /etc/hostname).
> 
> It's one of those things I prefer to debug with auditd on. Too many
> possibilities otherwise.
> 
> > What was the problem with his resolv.conf? Have I missed that?
> 
> OP used an unspecified VPN client which put an additional entry into
> /etc/resolv.conf on start, but failed to clean it up on stop.

Much clearer now. Your attention to explaining in detail is appreciated.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#186973

> True, we know the OP has a problem with with sudo. What we do not know
> is the hostname he chose during the installation, although it looks like
> it was "localhost" from the second line of
>
>   127.0.0.1       localhost
>   127.0.1.1       localhost
>

root@localhost:~# cat /etc/hostname
localhost

> The installer recommends a single word for the hostname. The "single"
> aspect is the result of a number of years of experience and bug reports.
> Although "localhost.localdomain" is not an invalid hostname the OP does
> not appear to have used it. (We have not been given the contents of his
> /etc/hostname explicitly).
>

I agree choosing "localhost" is wrong per-RFC. But I have been doing it
for years and stuff never broke. stretch+sudo 1.8.19p1-2.1 is a first. Bad
luck of me.

> What was the problem with his resolv.conf? Have I missed that?
>

Hardcoded company nameserver in /etc/resolv.conf that only works when VPN
is up. VPN was down and problem appeared.

x9p

[toc] | [prev] | [next] | [standalone]

#186977

On Mon 18 Sep 2017 at 17:47:18 -0300, x9p wrote:

> > True, we know the OP has a problem with with sudo. What we do not know
> > is the hostname he chose during the installation, although it looks like
> > it was "localhost" from the second line of
> >
> >   127.0.0.1       localhost
> >   127.0.1.1       localhost
> 
> root@localhost:~# cat /etc/hostname
> localhost
> 
> > The installer recommends a single word for the hostname. The "single"
> > aspect is the result of a number of years of experience and bug reports.
> > Although "localhost.localdomain" is not an invalid hostname the OP does
> > not appear to have used it. (We have not been given the contents of his
> > /etc/hostname explicitly).
> 
> I agree choosing "localhost" is wrong per-RFC. But I have been doing it
> for years and stuff never broke. stretch+sudo 1.8.19p1-2.1 is a first. Bad
> luck of me.
> 
> > What was the problem with his resolv.conf? Have I missed that?
> 
> Hardcoded company nameserver in /etc/resolv.conf that only works when VPN
> is up. VPN was down and problem appeared.

Thank you for expanding on this. You did mention before the nameserver
you were using, but I missed the significance.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#186974

Brian wrote:

> True, we know the OP has a problem with with sudo. What we do not know
> is the hostname he chose during the installation, although it looks like
> it was "localhost"

He admitted he entered localhost when prompted at installation time.

regards

[toc] | [prev] | [next] | [standalone]

#186979

On Mon 18 Sep 2017 at 22:50:07 +0200, deloptes wrote:

> Brian wrote:
> 
> > True, we know the OP has a problem with with sudo. What we do not know
> > is the hostname he chose during the installation, although it looks like
> > it was "localhost"
> 
> He admitted he entered localhost when prompted at installation time.

Guilty, as charged, then. :) That's me. not reading carefully enough.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#186980

On Monday 18 September 2017 12:39:12 Reco wrote:

> 	Hi.
>
> On Mon, Sep 18, 2017 at 08:50:36AM +0200, deloptes wrote:
> > Gene Heskett wrote:
> > > 127.0.0.1 localhost.localdomain localhost
> >
> > Sorry but I did not understand if the problem is there or if the
> > problem is that it is not there?
>
> Long story short, OP has a misbehaving Debian stretch installation
> with the hostname (as in - /proc/sys/kernel/hostname) set to
> 'localhost.localdomain'.
> /etc/hosts lacks such entry.
> /etc/resolv.conf points to an absent DNS.
>
> The result is - every execution of sudo has an added 30-second
> execution time 'bonus'.
>
> > I guess this is put there at time of installation. I'll check few
> > virtual machines later to see how it was written.
>
> If the user chooses conventional hostname (even 'debian') during the
> installation - sure, they should put a record in /etc/hosts. Unsure
> about stretch, but they did so since etch.
>
> The question is - since 'localhost.localdomain' is special, what
> happens if such hostname is chosen during the installation?
>
> > IMO if you have working resolver it shouldn't matter much.
>
> Please read this thread's subject one more time. Last three words
> especially.
>
> Reco

The OP, if he has a router, should point resolv.conf  at it for the dns 
entry. The router will fwd the request to his ISP's dns servers. This 
will NOT resolve local names, so a hosts file with those translations is 
a good idea.

resolv.conf in that event, should have the nameservers address, and the 
search order "hosts dns", something like this:
nameserver 192.168.XX.1
search 	host	dns
domain	coyote.den

where the XX is the block his local network is in in the 192.168.xx.nn 
space. And if network mangler is installed, it should be stopped.

In either event, as long as the machine stays where it is, I'd become 
root and issue:
chattr +i resolv.conf just so N-M can't tear up a perfectly functioning 
network connection.

But thats just me. I like things that Just Work(TM).

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#186923

On Sunday 17 September 2017 16:39:25 x9p wrote:

> > Since the /etc/hosts file can also contain aliases, the ideaL way
> > would seem to be to make use of that. Example:
> > 192.168.x.z	localhost.localdomain	localhost
>
> You are right, this solves the problem of the DNS lookup / X seconds
> delay to run sudo even with a buggy DNS server:
>
> root@localhost:~# head -1 /etc/hosts
> 127.0.0.1       localhost localhost.localdomain
>
In this case it should make only microseconds difference, but the first 
name given s/b the FQDN, the 2nd and other space separated strings on 
the same line would be the alias's.  In the above case, that would 
interchange the pair of strings. But I doubt if the time difference 
could be measured w/o some fancy machine assistance.

> Should be on debian by default in my opinion.

I agree, but I don't have permission to even blow the whistle on this 
train called linux. :) Basically someone decides its more secure, 
without considering the amount of time that 1000 others like you will 
expend restoring what is to you, normal near instant operation.  Maybe 
it is a good idea, but the person who made that change is too busy 
hiding from the hordes to even consider sticking up his keyboard and 
justifying the change, including what we have to change to keep 
everything running.
> x9p


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

[toc] | [prev] | [next] | [standalone]

#186926

On Sun 17 Sep 2017 at 18:43:18 -0400, Gene Heskett wrote:

> On Sunday 17 September 2017 16:39:25 x9p wrote:
> 
> > > Since the /etc/hosts file can also contain aliases, the ideaL way
> > > would seem to be to make use of that. Example:
> > > 192.168.x.z	localhost.localdomain	localhost
> >
> > You are right, this solves the problem of the DNS lookup / X seconds
> > delay to run sudo even with a buggy DNS server:
> >
> > root@localhost:~# head -1 /etc/hosts
> > 127.0.0.1       localhost localhost.localdomain
> >
> In this case it should make only microseconds difference, but the first 
> name given s/b the FQDN, the 2nd and other space separated strings on 
> the same line would be the alias's.  In the above case, that would 
> interchange the pair of strings. But I doubt if the time difference 
> could be measured w/o some fancy machine assistance.
> 
> > Should be on debian by default in my opinion.
> 
> I agree, but I don't have permission to even blow the whistle on this 
> train called linux. :) Basically someone decides its more secure, 
> without considering the amount of time that 1000 others like you will 
> expend restoring what is to you, normal near instant operation.  Maybe 
> it is a good idea, but the person who made that change is too busy 
> hiding from the hordes to even consider sticking up his keyboard and 
> justifying the change, including what we have to change to keep 
> everything running.

The last time I recollect this "someone" sticking his head above
the parapet was in the thread beginning at

 https://lists.debian.org/debian-devel/2013/07/msg00809.html

The hordes retreated in the face of strong technical (non-security
related) argument.

-- 
Brian.

[toc] | [prev] | [next] | [standalone]

#186874

On Fri, Sep 15, 2017 at 12:46:09PM -0300, x9p wrote:
> 
> I was getting > 30sec to complete "sudo su" on a host. This host had
> invalid entries in resolv.conf and I realized sudo was doing 5 seconds
> lookup on each entry searching for "localhost.localdomain"
> 
> sudo is 1.8.19p1 @ stretch.
> 
> Believe no DNS lookups should be made... even for localhost

You should have a localhost entry in /etc/hosts. If you have
configured your /etc/sudoers to specify "localhost.localdomain",
then you should also have a localhost.localdomain entry in
/etc/hosts, or your should change the sudoers config to just 
reference "localhost".

-dsr-

[toc] | [prev] | [next] | [standalone]

#186878

> You should have a localhost entry in /etc/hosts. If you have
> configured your /etc/sudoers to specify "localhost.localdomain",
> then you should also have a localhost.localdomain entry in
> /etc/hosts, or your should change the sudoers config to just
> reference "localhost".
>

No changes were made to the /etc/sudoers except this:

myuser ALL=(ALL) NOPASSWD:ALL

I did not touched any Host_List. Debian by default do not come with
localhost on /etc/sudoers.

sudo binary does come with the "localhost" string in it.

root@localhost:~# strings /usr/bin/sudo | egrep localhost
localhost

x9p

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web