Re: Can't find the DNS Servers

[Darac Marjal]

On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote:

On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote:

On Mon, 25 Sep 2017, Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > as is documented in dhclient-script(8):
>
> Well now that's just EVIL. :-(

It's much more powerful than a single variable because you can have it
do *anything*.


No, you don't understand.  I had no idea that man page EXISTED!
For years, I have been searching back and forth and up and down in
dhclient(8) and dhclient.conf(5) and finding NOTHING.

Turns out the REASON I couldn't find anything was because some bright
spark decided to split the documentation into multiple man pages.


> Well now that's just EVIL. :-(


So, apparently the only way to find anything is to open umpteen terminal
windows, one man page in each terminal window.  Jump to the bottom of
each man page, find the SEE ALSO section, open EVERY linked man page in
another terminal window.  Recursively.  Then perform your searches in
every single window in parallel until one of them hits.


[cut]


All this grief and agony because they couldn't just put all the
information that THE MOST COMMON USE CASES will need into a single
document.


[tl;dr]

I think you might be under a misconception about what man pages are FOR.

From the first few lines of "man man":

 man - an interface to the on-line reference manuals

They are *reference* manuals. I believe that the point of man pages is 
to answer questions such as:


* What's the option for filtering out files: --filter or --exclude
* What was that weird option for doing something dangerous 
  "DoWhatIWant"... "YesIReallyMeanThis"... something like that.

* Can I perform this action recursively?

As a result, man pages are usually little more than lists of command 
line parameters which explanations of what they do.


What man pages generally DON'T cover are:

* How do I use this program for X?
* Why do I need this program?
* What the difference between this program and that program?
* How do I use this program with that program?

The GNU solution to that was the 'info' system. 'info' is a hyperlinked 
text format - a bit like having a web site on your computer. Look at 
the info page for grub, as an example: the information is grouped by 
topic, there's obscure things like limitations on the core size per 
platform and so on.


It's just a pity that most programs don't provide info pages.

--
For more information, please reread.


signature.asc
Description: PGP signature

Re: Can't find the DNS Servers

[tomas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, Sep 26, 2017 at 09:09:47AM -0400, Greg Wooledge wrote:

[...]

> No, you don't understand.  I had no idea that man page EXISTED!
> For years, I have been searching back and forth and up and down in
> dhclient(8) and dhclient.conf(5) and finding NOTHING.
> 
> Turns out the REASON I couldn't find anything was because some bright
> spark decided to split the documentation into multiple man pages.

To be fair, dhclient-script is figures in the output of

  man -k dhclient

And is mentioned several times in the dhclient man page (in the see-also
section, among other things).

> So let's see... I'll assume dhclient(8) is the root of the search
> tree.  This links to dhcpd(8), dhcrelay(8), dhclient-script(8),
> dhclient.conf(5), dhclient.leases(5), dhcp-eval(5).  So now I need
> to open 6 more windows, or 7 total.

Dhclient-script is also ref'd to from dhclient-conf(5). Alas, not in
the "see-also" section (IMHO it should be).

I know this would be preaching to the choir for the ones and lost on
the others -- but do give Emacs' WoMan mode a try. It is Emacs' man
page viewer, and does a good job of making clickable links of all
those embedded refs. Hypertext! (I know, I know: another story started
like this one and isn't ending well, but... ;-)

Don't get me wrong: it happens to me all the time that it's there,
in front of my nose, and I don't see it. I take this as a chance
to ask myself: "how would I have done that, as a writer, to help
my other self? how can I, as a reader, be smarter next time?)

Doumentation Is Hard (TM)

Cheers
- -- tomás
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlnKWbcACgkQBcgs9XrR2kbTKwCcCrVDUK3riaKtJ2vW7mTrxH2l
JZgAn1yjHGVLAtXNiHpD1Temy+QaV1dp
=LLxs
-END PGP SIGNATURE-

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 02:12:07PM -0700, Don Armstrong wrote:
> On Mon, 25 Sep 2017, Greg Wooledge wrote:
> > On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > > as is documented in dhclient-script(8):
> > 
> > Well now that's just EVIL. :-(
> 
> It's much more powerful than a single variable because you can have it
> do *anything*.

No, you don't understand.  I had no idea that man page EXISTED!
For years, I have been searching back and forth and up and down in
dhclient(8) and dhclient.conf(5) and finding NOTHING.

Turns out the REASON I couldn't find anything was because some bright
spark decided to split the documentation into multiple man pages.

> > Well now that's just EVIL. :-(

So, apparently the only way to find anything is to open umpteen terminal
windows, one man page in each terminal window.  Jump to the bottom of
each man page, find the SEE ALSO section, open EVERY linked man page in
another terminal window.  Recursively.  Then perform your searches in
every single window in parallel until one of them hits.

So let's see... I'll assume dhclient(8) is the root of the search
tree.  This links to dhcpd(8), dhcrelay(8), dhclient-script(8),
dhclient.conf(5), dhclient.leases(5), dhcp-eval(5).  So now I need
to open 6 more windows, or 7 total.

dhcpd(8) doesn't exist, because this isn't a server, so make it 6.

dhcrelay(8) doesn't exist.  Don't even know what that is.  5.

dhclient-script(8) links to dhclient(8), dhcpd(8), dhcrelay(8),
dhclient.conf(5), dhclient.leases(5).  No new windows.

dhclient.conf(5) links to dhcp-options(5), dhcp-eval(5),
dhclient.leases(5), dhcpd(8), dhcpd.conf(5).  dhcpd.conf(5) doesn't exist,
so just one new window, for dhcp-options(5).  I'm up to 6 open now.

dhclient.leases(5) links to dhclient(8), dhcp-options(5), dhclient.conf(5),
dhcpd(8), dhcpd.conf(5).  No new ones.

dhcp-eval(5) links to dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5),
dhcp-options(5), dhcpd(8), dhclient(8).  dhcpd.leases(5) doesn't exist,
so no new ones.

dhcp-options(5) links to dhcpd.conf(5), dhcpd.leases(5), dhclient.conf(5),
dhcp-eval(5), dhcpd(8), dhclient(8).  No new ones.

So I've got my 6 terminal windows open.  I've spent 10 minutes so far,
and I haven't even READ a single bit of any of the pages.  Just the
SEE ALSOs.

Now I get to try to wrack my brain for keywords, and repeat my keyword
searches 6 times, once in every window.

Turns out "resolv" (my first keyword) pops up in window #2, which is
dhclient-script(8), and also in window #6, dhcp-options(5).

>From there, you can guess what the next steps are, because apparently
you were already aware of the existence of dhclient-script(8).  If I'm
lucky, I'll focus on that page rather than dhcp-options(5) which is
very confusing, and seems to be talking in abstractions.  It sure as
hell doesn't clearly define what options go in what files, nor even
which options are for the client and which are for the server.  Their
only mentions of resolv.conf are in a DHCPV6 section.  What the hell
is DHCPV6?  Does it have something to do with IPv6?  How would I know
whether I'm using DHCPV6 or not?  Try searching for V6 in the other
five windows... nothing at all!  And so on.

All this grief and agony because they couldn't just put all the
information that THE MOST COMMON USE CASES will need into a single
document.

What are the most common use cases?  An excellent question.  Here's
my guess:

1) Client is plugged into the network without being configured.  Simply
   uses whatever the DHCP server spits out.  If that's wrong, too bad.

2) Client uses what the DHCP server spits out, but the administrator
   of the client will try to work around whichever bits of the DHCP
   server's responses are wrong.  In my experience, it's the nameservers
   that are most likely to need local adjustment.  That's why you have
   this thread.  And all the previous threads.  And all the web pages
   out there that advise people to use chattr +i.  And all the people
   who use chattr +i.  And all the self-proclaimed experts who say "No,
   you're doing it wrong!" but then don't offer a better way.
   
3) Client uses what the DHCP server spits out, but the administrator
   of the client is also the administrator of the DHCP server, and can
   correct things in the DHCP server to make all the clients happy.

The first use case needs no documentation at all.

The second use case needs some way for the admin of the client to be able
to search for resolv.conf in the documentation and actually FIND IT.
I searched in dhclient(8) and in dhclient.conf(5) and fid not find it.
I honestly, truly believed that I had done my best.  That I had put
in the required effort.  That I had been intelligent and diligent and
resourceful.  That I had given the software the benefit of the doubt,
but this feature was simply not present, or not documented anywhere.

The third use case... well, that's not me right now.  In the past I
have set up a DHCP server on an OpenBSD 

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 12:49:22PM -0700, Gary Roach wrote:
> On 09/23/2017 09:31 PM, Cindy-Sue Causey wrote:
> > On 9/23/17, Gary Roach <gary719_li...@verizon.net> wrote:
> > > Hi all.
> > > I have been trying for several day to get firefox to work on a newly
> > > installed Debian Stretch system. It Seems that Firefox can't find a DNS
> > > server. I am having the same problem with apt-get update. None of my
> > > mirrors can be reached. Ping works just fine. I can't even reach the
> > > other computers on my home network if I use their names. IP addresses
> > > work OK. I have installed resolvconf and followed several installation
> > > instructions to no avail. The name servers for my router
> > > (192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed
> > > in the correct file (can't remember which one). This system worked fine
> > > when first installed. I installed qemu-kvm on the system and I think in
> > > broke things.I've run out of ideas.
> > > 
> > > Please help
> > 
> An addition is necessary here. The problem started when I installed the
> qemu-kvm virtual machine. Now the Kubuntu system - the guest - network
> access works fine. But the host machine can't find the DNS servers. This
> makes no sense.

And it never make any sense unless you troubleshoot it.

Please post these things from the problematic PC:

ip a l

ip ro l

cat /etc/resolv.conf

"tcpdump -nvi any udp port 53 or tcp port 53" run while doing
"getent hosts www.google.com"

Reco

Re: Can't find the DNS Servers

[Celejar]

On Mon, 25 Sep 2017 08:56:54 -0400
Greg Wooledge <wool...@eeg.ccf.org> wrote:

> On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:

...

> > I have
> > installed resolvconf 
> 
> *shudder*
> 
> I mean, unless this is a laptop or a tablet or a phone or something.
> Then it may be appropriate, because you might actually WANT your
> resolv.conf file to be rewritten every time the wind changes direction.
> 
> For desktop machines with a static internal network configuration, it's
> an abomination.  And unfortunately it's not the only malevolent fiend
> trying to usurp control of your resolv.conf file.  There's also dhclient,
> and network-manager, and systemd-resolved, and who knows what else.

Just to clarify, on my laptop, I do want resolvconf installed, since
when I'm on my home LAN, I want to use the DNS server running on the
local router / gateway, and when I'm anywhere else, I want to use the
ISP's nameservers. With resolvconf, I add a "dns-nameservers
nnn.nnn.nnn.nnn" line to the LAN section of /etc/network/interfaces to
accomplish this via resolvconf.

Celejar

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 25 September 2017 13:53:17 Greg Wooledge wrote:

> On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> > Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > > For me, its a root session, and a "chattr +i resolv.conf"
> >
> > Here we have a saying that roughly translates to :
> > "When you have a hammer, any problem looks like a nail."
>
> No.  Seriously, just stop.
>
> Those of us who have done chattr +i on one or more systems have, in
> many cases, TRIED OTHER SOLUTIONS first and found them wanting.
>
> Take me for example.
>
> At work, I edited /etc/dhcp/dhclient.conf and removed the options that
> tell dhclient to ask for domain-name-servers (et al.).  This works
> fine for me at work.  The DHCP servers at work respect my wish not to
> be given a domain-name-server, so dhclient never touches resolv.conf
> and everyone is happy.
>
> Then I tried the same thing at home.
>
> The results were NOT the same.
>
> The Belkin plastic router at home sends me a domain-name-server even
> if I do not ask for one.  And dhclient apparently overwrites
> resolv.conf every time it receives a domain-name-server from the DHCP
> server.
>
> EVEN IF IT DID NOT REQUEST ONE.
>
> So, the solution that I used at work does not work at home.
>
> You know what DOES work, though?
>
> chattr +i works.
>
> Do I prefer this solution?  No.
>
> Would I be happier if I could use a more elegant solution?  Yes.
>
> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"?  YES!
>
> Does it?  NO!
>
> Do I expect it ever to have one in the future?  BWA-hahahaha!  No.
>
> So we use what works, because the other choices don't fucking work.
>
> This is not about lack of creativity.
>
> It is not about being too blind or ignorant or stubborn to use the
> other solutions.  ("Everything looks like a nail.")
>
> This is about the other soluttions NOT WORKING.
>
> It is about ISC being too blind or ignorant or stubborn to consider
> that many people run the DHCP client software WITHOUT being the ones
> in charge of the DHCP server on the same network.
>
> Or, not considering that many people use cheap plastic consumer-grade
> routers that don't behave the same way the ISC DHCP server behaves.
>
> Am I getting through yet?

I am with Greg on this one. And I HAVE tried everything the man pages 
tell me, and it does NOT work, so I do what DOES WORK.  Someday, maybe 
dhcpd will be smart enough to actually do what we tell it to do.

But that day hasn't even shown a cloud of dust on the time horizon I can 
see from a 83 yo in <2 weeks viewpoint.

Because all you so-called experts THINK it works  ok the way it is, we 
get badmouthed and called idiots.  Bad dog, no biscuit, not even the 
smell of one in an all static network situation.

Something that I have been dealing with on a daily basis now for 
something like 24 years at a tv station as its CE. We were, I think, the 
first tv station in the US to have a web page, folks had to dial it up 
for the first 6 months. Then we bought a block of 16 addresses, and a 
56k line, and put the amiga that served it on one of the addresses. Jim 
and I wrote that web server in ARexx.

If you want to be called an expert, first go fix dhcpd. Or n-m, but it 
likely uses dhcpd to do its damage. Then ask to be called an expert.

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 

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 25 September 2017 12:10:10 Reco wrote:

>   Hi.
>
> On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote:
> > > I mean, unless this is a laptop or a tablet or a phone or
> > > something. Then it may be appropriate, because you might actually
> > > WANT your resolv.conf file to be rewritten every time the wind
> > > changes direction.
> > >
> > > For desktop machines with a static internal network configuration,
> > > it's an abomination.  And unfortunately it's not the only
> > > malevolent fiend trying to usurp control of your resolv.conf file.
> > >  There's also dhclient, and network-manager, and systemd-resolved,
> > > and who knows what else.
> > >
> > > See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/>
> > > for some of your options.  Of course, before you can apply any of
> > > those suggestions, you have to seize back control of your
> > > resolv.conf file in the first place.  Make sure it's a FILE and
> > > not a symlink, and put the correct content into it.  Make sure
> > > name resolution works.  Then choose your favorite solution to keep
> > > the file under YOUR control.
> >
> > For me, its a root session, and a "chattr +i resolv.conf"
> > If for some reason you need to edit it later, you'll have to use the
> > -i argument first. As long as that +i bit is set, its protected from
> > everything but a mke2fs.
>
> A common misconception. Here's how a determined userspace can beat
> immutable bit:
>
> # mkdir testetc
> # touch testetc/resolv.conf
> # chattr +i testetc/resolv.conf
> # mv testetc/ testetc.orig
> # mkdir testetc
> # touch testetc/resolv.conf
> # echo evil dns > testetc/resolv.conf
>
> Of course you could try to counter that with "chattr +i /etc", but
> doing *that* should break an unimaginable number of things.
>
> If you really need immutable /etc/resolv.conf you should try the
> Read-Only Root Debian - [1].
>
> [1] https://wiki.debian.org/ReadonlyRoot
>
> Reco

Unforch, this isn't /root stuffs, but /etc stuffs.  And it works. And I 
could care less how disappointed n-m or dhcpd is.  Or even resolvconf 
itself. Particularly when its as buggy as a 10 day old road kill in 
August.

Yes, there is a place for dhcp, but its for sure not on a home, small 
number of machines network thats all static.
 

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>

Re: Can't find the DNS Servers

[Don Armstrong]

On Mon, 25 Sep 2017, Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> > as is documented in dhclient-script(8):
> 
> Well now that's just EVIL. :-(

It's much more powerful than a single variable because you can have it
do *anything*.

But since most people don't care about that power, resolvconf is a much
better method to use to manage resolv.conf than chattr or any of the
other hacks. It does the right thing in almost every case and has hooks
for dhclient, NetworkManger, pppd, ifupdown, dnsmasq, etc.

-- 
Don Armstrong  https://www.donarmstrong.com

2: There is no out. There is only in.
  -- "The Prisoner (2009 Miniseries)"

Re: Can't find the DNS Servers

[Gary Roach]

On 09/23/2017 09:31 PM, Cindy-Sue Causey wrote:

On 9/23/17, Gary Roach <gary719_li...@verizon.net> wrote:

Hi all.
I have been trying for several day to get firefox to work on a newly
installed Debian Stretch system. It Seems that Firefox can't find a DNS
server. I am having the same problem with apt-get update. None of my
mirrors can be reached. Ping works just fine. I can't even reach the
other computers on my home network if I use their names. IP addresses
work OK. I have installed resolvconf and followed several installation
instructions to no avail. The name servers for my router
(192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed
in the correct file (can't remember which one). This system worked fine
when first installed. I installed qemu-kvm on the system and I think in
broke things.I've run out of ideas.

Please help


An addition is necessary here. The problem started when I installed the 
qemu-kvm virtual machine. Now the Kubuntu system - the guest - network 
access works fine. But the host machine can't find the DNS servers. This 
makes no sense.


Gary R

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 12:20:45PM -0700, Don Armstrong wrote:
> as is documented in dhclient-script(8):

Well now that's just EVIL. :-(

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 09:59:26PM +0300, Reco wrote:
> I need to ask - what are you using instead of proper DHCP client?

titan:~$ dpkg -l | grep dhc
ii  isc-dhcp-client   4.3.5-3   
amd64DHCP client for automatically obtaining an IP address
ii  isc-dhcp-common   4.3.5-3   
amd64common manpages relevant to all of the isc-dhcp packages

> Every DHCP client worthy of its name (ISC one, for instance) allows one
> to redefine every part of client configuration via hooks.
> For instance dhcpcd that I use has this specific example in its manpage:
> 
> So to stop dhcpcd from touching your DNS settings or starting
> wpa_supplicant you would do:- nohook resolv.conf, wpa_supplicant

titan:~$ man dhclient | grep resolv
titan:~$ man dhclient.conf | grep resolv
titan:~$ dhclient --help 2>&1 | grep resolv
titan:~$ 

So, your solution was to rip isc-dhcp-client entirely out of the system
and replace it with something else.

Mine was to chattr +i resolv.conf.

The cyberciti.biz FAQ page gives another solution that involves
creating an sh function in some undocumented directory to overwrite
some undocumented internal part of the DHCP client with a function that
does nothing.

What I mean by undocumented: according to the web page, the directory
used to be named /etc/dhcp3/dhclient-enter-hooks.d/ and yet:

titan:~$ man dhclient | grep hook
titan:~$ man dhclient.conf | grep hook
titan:~$ 

I have not tested this solution.  I'm just assuming that it will work
if we replace the old directory name with the new one (/etc/dhcp/...).
I would expect the "hooks.d" part to be in there somewhere.  It's not.

So, if you want to disparage me because I could have done this secret
undocumented ridiculously intrusive thing that one can only learn about
from a third party web page, sure, go ahead.  Tell me how stupid and
lazy I am for preferring a simple command that just WORKS over this
undocumented hook thing, at the same time that you yourself THREW THE
ENTIRE SOFTWARE PACKAGE AWAY rather than try to deal with it.

Fine: I'm stupid and lazy and ignorant and unwilling to learn.

But at least my computer works (now).

Re: Can't find the DNS Servers

[Don Armstrong]

On Mon, 25 Sep 2017, Greg Wooledge wrote:
> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"?  YES!
> 
> Does it?  NO!

It does. Simply:

cat - < /etc/dhcp/dhclient-enter-hooks.d/disablemakeresolvconf
make_resolv_conf() { : ; }
EOF

as is documented in dhclient-script(8):

   When it starts, the client script first defines a shell function,
   make_resolv_conf , which is later used to create the
   /etc/resolv.conf file. To override the default behaviour,
   redefine this function in the enter hook script.


-- 
Don Armstrong  https://www.donarmstrong.com

An elephant: A mouse built to government specifications.
 -- Robert Heinlein _Time Enough For Love_ p244

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 01:53:17PM -0400, Greg Wooledge wrote:

> Would I be happier if I could use a more elegant solution?  Yes.

Being disappointed with built-in Zyxel DHCP server I merely disabled it
and set up a proper ISC DHCP server. I don't know, it's probably
unelegant to you, but it's not a DHCP server unless ISC made it.


> Should the dhclient program have a CONFIG FILE OPTION to say
> "NEVER TOUCH THE resolv.conf FILE"?  YES!
> 
> Does it?  NO!

I need to ask - what are you using instead of proper DHCP client?
Every DHCP client worthy of its name (ISC one, for instance) allows one
to redefine every part of client configuration via hooks.
For instance dhcpcd that I use has this specific example in its manpage:

So to stop dhcpcd from touching your DNS settings or starting
wpa_supplicant you would do:- nohook resolv.conf, wpa_supplicant


> Do I expect it ever to have one in the future?  BWA-hahahaha!  No.

But the future *is* here already.


> So we use what works, because the other choices don't fucking work.

Tsk, tsk. Language. Also, of course they work.

Reco

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 07:32:05PM +0200, Pascal Hambourg wrote:
> Le 25/09/2017 à 17:33, Gene Heskett a écrit :
> > 
> > For me, its a root session, and a "chattr +i resolv.conf"
> 
> Here we have a saying that roughly translates to :
> "When you have a hammer, any problem looks like a nail."

No.  Seriously, just stop.

Those of us who have done chattr +i on one or more systems have, in
many cases, TRIED OTHER SOLUTIONS first and found them wanting.

Take me for example.

At work, I edited /etc/dhcp/dhclient.conf and removed the options that
tell dhclient to ask for domain-name-servers (et al.).  This works fine
for me at work.  The DHCP servers at work respect my wish not to be
given a domain-name-server, so dhclient never touches resolv.conf and
everyone is happy.

Then I tried the same thing at home.

The results were NOT the same.

The Belkin plastic router at home sends me a domain-name-server even
if I do not ask for one.  And dhclient apparently overwrites resolv.conf
every time it receives a domain-name-server from the DHCP server.

EVEN IF IT DID NOT REQUEST ONE.

So, the solution that I used at work does not work at home.

You know what DOES work, though?

chattr +i works.

Do I prefer this solution?  No.

Would I be happier if I could use a more elegant solution?  Yes.

Should the dhclient program have a CONFIG FILE OPTION to say
"NEVER TOUCH THE resolv.conf FILE"?  YES!

Does it?  NO!

Do I expect it ever to have one in the future?  BWA-hahahaha!  No.

So we use what works, because the other choices don't fucking work.

This is not about lack of creativity.

It is not about being too blind or ignorant or stubborn to use the
other solutions.  ("Everything looks like a nail.")

This is about the other soluttions NOT WORKING.

It is about ISC being too blind or ignorant or stubborn to consider that
many people run the DHCP client software WITHOUT being the ones in
charge of the DHCP server on the same network.

Or, not considering that many people use cheap plastic consumer-grade
routers that don't behave the same way the ISC DHCP server behaves.

Am I getting through yet?

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 17:33, Gene Heskett a écrit :


For me, its a root session, and a "chattr +i resolv.conf"


Here we have a saying that roughly translates to :
"When you have a hammer, any problem looks like a nail."

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 12:21:49PM -0400, Greg Wooledge wrote:
> On Mon, Sep 25, 2017 at 07:10:10PM +0300, Reco wrote:
> > A common misconception. Here's how a determined userspace can beat
> > immutable bit:
> > 
> > # mkdir testetc
> > # touch testetc/resolv.conf
> > # chattr +i testetc/resolv.conf
> > # mv testetc/ testetc.orig
> > # mkdir testetc
> > # touch testetc/resolv.conf
> > # echo evil dns > testetc/resolv.conf
> 
> You'd have to replace all the other files in /etc as well, or the
> system wouldn't work very well.  But that's not the point.  The point
> isn't to harden the system against an attacker bent on subverting your
> name lookups.  It's to protect your locally modified configuration file
> from being overwritten by well-meaning but stupid software programs.

If the program misbehaves and it cannot be changed - why bother keeping
such program in your OS? I mean, it's Debian maillist, right? Everything
that's misbehaves can be fed to 'apt-get purge' and replaced with
something more sensible.


> (And yes, there are other ways to achieve that, but I've already posted
> the <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> URL
> in this thread.  Oops, I did it again.)

An interesting link. It lacks my second favorite approach though (first
one being read-only root filesystem):

iptables -t nat -A OUTPUT -p udp ! -d  --port 53 -j DNAT \
--to-destination :53

iptables -t nat -A OUTPUT -p tcp ! -d  --port 53 -j DNAT \
--to-destination :53

ip6tables -A OUTPUT -p udp --dport 53 -j REJECT
ip6tables -A OUTPUT -p tcp --dport 53 -j REJECT

Let them overwrite my resolv.conf with all kinds of gibberish, but it
will resolve the way *I* want it.

Reco

Re: Can't find the DNS Servers

[Nemeth Gyorgy]

2017-09-24 18:14 keltezéssel, Reco írta:
>
> Please post these things from the problematic PC:
>
> ip a l
>
> ip ro l
>
> cat /etc/resolv.conf
and cat /etc/nsswitch.conf

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 07:10:10PM +0300, Reco wrote:
> A common misconception. Here's how a determined userspace can beat
> immutable bit:
> 
> # mkdir testetc
> # touch testetc/resolv.conf
> # chattr +i testetc/resolv.conf
> # mv testetc/ testetc.orig
> # mkdir testetc
> # touch testetc/resolv.conf
> # echo evil dns > testetc/resolv.conf

You'd have to replace all the other files in /etc as well, or the
system wouldn't work very well.  But that's not the point.  The point
isn't to harden the system against an attacker bent on subverting your
name lookups.  It's to protect your locally modified configuration file
from being overwritten by well-meaning but stupid software programs.

(And yes, there are other ways to achieve that, but I've already posted
the <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> URL
in this thread.  Oops, I did it again.)

Re: Can't find the DNS Servers

[Reco]

Hi.

On Mon, Sep 25, 2017 at 11:33:50AM -0400, Gene Heskett wrote:
> > I mean, unless this is a laptop or a tablet or a phone or something.
> > Then it may be appropriate, because you might actually WANT your
> > resolv.conf file to be rewritten every time the wind changes
> > direction.
> >
> > For desktop machines with a static internal network configuration,
> > it's an abomination.  And unfortunately it's not the only malevolent
> > fiend trying to usurp control of your resolv.conf file.  There's also
> > dhclient, and network-manager, and systemd-resolved, and who knows
> > what else.
> >
> > See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> for
> > some of your options.  Of course, before you can apply any of those
> > suggestions, you have to seize back control of your resolv.conf file
> > in the first place.  Make sure it's a FILE and not a symlink, and put
> > the correct content into it.  Make sure name resolution works.  Then
> > choose your favorite solution to keep the file under YOUR control.
> 
> For me, its a root session, and a "chattr +i resolv.conf"
> If for some reason you need to edit it later, you'll have to use the -i 
> argument first. As long as that +i bit is set, its protected from 
> everything but a mke2fs.

A common misconception. Here's how a determined userspace can beat
immutable bit:

# mkdir testetc
# touch testetc/resolv.conf
# chattr +i testetc/resolv.conf
# mv testetc/ testetc.orig
# mkdir testetc
# touch testetc/resolv.conf
# echo evil dns > testetc/resolv.conf

Of course you could try to counter that with "chattr +i /etc", but doing
*that* should break an unimaginable number of things.

If you really need immutable /etc/resolv.conf you should try the
Read-Only Root Debian - [1].

[1] https://wiki.debian.org/ReadonlyRoot

Reco

Re: Can't find the DNS Servers

[Gene Heskett]

On Monday 25 September 2017 08:56:54 Greg Wooledge wrote:

> On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:
> > I have been trying for several day to get firefox to work on a newly
> > installed Debian Stretch system. It Seems that Firefox can't find a
> > DNS server. I am having the same problem with apt-get update. None
> > of my mirrors can be reached.
>
> ls -ld /etc/resolv.conf
> cat /etc/resolv.conf
> dpkg -l resolvconf network-manager
> grep ^hosts: /etc/nsswitch.conf
>
> > Ping works just fine.
>
> pinging what?
>
> > I can't even reach the other computers
> > on my home network if I use their names. IP addresses work OK.
>
> LAN configuration can be done in several ways.  For most small home
> LANs, you probably just want to put the IPs and hostnames in
> /etc/hosts on each machine.
>
> For larger or fancier setups, you can configure a private DNS server.
>
> > I have
> > installed resolvconf
>
> *shudder*

Uncontrollably.

> I mean, unless this is a laptop or a tablet or a phone or something.
> Then it may be appropriate, because you might actually WANT your
> resolv.conf file to be rewritten every time the wind changes
> direction.
>
> For desktop machines with a static internal network configuration,
> it's an abomination.  And unfortunately it's not the only malevolent
> fiend trying to usurp control of your resolv.conf file.  There's also
> dhclient, and network-manager, and systemd-resolved, and who knows
> what else.
>
> See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> for
> some of your options.  Of course, before you can apply any of those
> suggestions, you have to seize back control of your resolv.conf file
> in the first place.  Make sure it's a FILE and not a symlink, and put
> the correct content into it.  Make sure name resolution works.  Then
> choose your favorite solution to keep the file under YOUR control.

For me, its a root session, and a "chattr +i resolv.conf"
If for some reason you need to edit it later, you'll have to use the -i 
argument first. As long as that +i bit is set, its protected from 
everything but a mke2fs.

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>

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 15:54, Greg Wooledge a écrit :

On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote:

Prepare to be disappointed if you modify directly resolv.conf, because the
software which wrote it first could rewrite it after you, as DHCP clients do
each time they renew the lease.


In a battle between me and stupid new software programs, I always win
in the end.


I hope so. The user shall prevail.


I will do whatever it takes to make the software behave correctly,
even if what it takes is REMOVING the software.


For sure. But there is the forcible way and the graceful way.

Here is a little experience of mine.
I had a host configured with DHCP. As expected, dhclient wrote the IPv4 
DNS addresses received from the DHCP server into resolv.conf. My network 
also had an IPv6 router sending advertisements containing IPv6 DNS 
addresses and I wanted that addresses to be included in resolv.conf, so 
I installed rdnssd. Unfortunatly, both dhclient and rdnssd rewrote 
resolv.conf, erasing the addresses added by the other. Either DNS 
addresses worked, but it was not what I wanted. Then I installed 
resolvconf and resolv.conf now contained both IPv4 addresses from 
dhclient and IPv6 addresses from rdnssd.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 03:45:06PM +0200, Pascal Hambourg wrote:
> Prepare to be disappointed if you modify directly resolv.conf, because the
> software which wrote it first could rewrite it after you, as DHCP clients do
> each time they renew the lease.

In a battle between me and stupid new software programs, I always win
in the end.

I will do whatever it takes to make the software behave correctly,
even if what it takes is REMOVING the software.

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 15:24, Greg Wooledge a écrit :


I think it's better for all the unix-like systems to work the same way
(the way that they have all done for the last 30+ years), rather than
each one doing something different.

Sadly, there was never any uniformity in how interfaces, IPs, netmasks
and routes are configured.


These two statements contradict each other.
If there was never any uniformity, then Unix-like systems have not 
worked the same way for the 30+ years.



But /etc/resolv.conf is a universal standard.  You can log into ANY
unix-like system and see what nameservers it's using


Yes. But I do not think that the Unix standard defines the way the file 
should be created and modified.



and correct them if they're wrong


Prepare to be disappointed if you modify directly resolv.conf, because 
the software which wrote it first could rewrite it after you, as DHCP 
clients do each time they renew the lease.



(though you may need to remove the chattr +i bit before
you can write to the file).


Ugly hack.

Some software modify the DNS server list. IMO, better bear with it and 
learn how to control them.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Mon, Sep 25, 2017 at 03:14:02PM +0200, Pascal Hambourg wrote:
> Besides, resolvconf is required for the dns-nameservers option in
> /etc/network/interfaces to have any effect with static configuration. Don't
> you think it is better to have all the IP parameters (IP address, mask,
> gateway, DNS) in a single config file ?

No.

I think it's better for all the unix-like systems to work the same way
(the way that they have all done for the last 30+ years), rather than
each one doing something different.

Sadly, there was never any uniformity in how interfaces, IPs, netmasks
and routes are configured.  So, we just have to live with every system
being different for that stuff.

But /etc/resolv.conf is a universal standard.  You can log into ANY
unix-like system and see what nameservers it's using, and correct them
if they're wrong (though you may need to remove the chattr +i bit before
you can write to the file).

Re: Can't find the DNS Servers

[Pascal Hambourg]

Le 25/09/2017 à 14:56, Greg Wooledge a écrit :

On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:


I have installed resolvconf


*shudder*

I mean, unless this is a laptop or a tablet or a phone or something.
Then it may be appropriate, because you might actually WANT your
resolv.conf file to be rewritten every time the wind changes direction.


resolvconf does not do this.
Besides, resolvconf is required for the dns-nameservers option in 
/etc/network/interfaces to have any effect with static configuration. 
Don't you think it is better to have all the IP parameters (IP address, 
mask, gateway, DNS) in a single config file ?



For desktop machines with a static internal network configuration, it's
an abomination.  And unfortunately it's not the only malevolent fiend
trying to usurp control of your resolv.conf file.  There's also dhclient,
and network-manager, and systemd-resolved, and who knows what else.


resolvconf is designed to prevent these pieces of software to write 
directly in resolv.conf, giving you better control. Without resolvconf, 
all of them wildy rewrite resolv.conf without taking the others into 
account.

Re: Can't find the DNS Servers

[Greg Wooledge]

On Sat, Sep 23, 2017 at 06:03:12PM -0700, Gary Roach wrote:
> I have been trying for several day to get firefox to work on a newly
> installed Debian Stretch system. It Seems that Firefox can't find a DNS
> server. I am having the same problem with apt-get update. None of my mirrors
> can be reached.

ls -ld /etc/resolv.conf
cat /etc/resolv.conf
dpkg -l resolvconf network-manager
grep ^hosts: /etc/nsswitch.conf

> Ping works just fine.

pinging what?

> I can't even reach the other computers
> on my home network if I use their names. IP addresses work OK.

LAN configuration can be done in several ways.  For most small home LANs,
you probably just want to put the IPs and hostnames in /etc/hosts on
each machine.

For larger or fancier setups, you can configure a private DNS server.

> I have
> installed resolvconf 

*shudder*

I mean, unless this is a laptop or a tablet or a phone or something.
Then it may be appropriate, because you might actually WANT your
resolv.conf file to be rewritten every time the wind changes direction.

For desktop machines with a static internal network configuration, it's
an abomination.  And unfortunately it's not the only malevolent fiend
trying to usurp control of your resolv.conf file.  There's also dhclient,
and network-manager, and systemd-resolved, and who knows what else.

See <https://www.cyberciti.biz/faq/dhclient-etcresolvconf-hooks/> for
some of your options.  Of course, before you can apply any of those
suggestions, you have to seize back control of your resolv.conf file
in the first place.  Make sure it's a FILE and not a symlink, and put
the correct content into it.  Make sure name resolution works.  Then
choose your favorite solution to keep the file under YOUR control.

Re: Can't find the DNS Servers

[Reco]

Hi.

On Sun, Sep 24, 2017 at 08:55:51AM -0700, Gary Roach wrote:
> Don't know why but this message didn't show up on my email so am sending
> again. Thanks for the reply Cindy Sue.
> 
> Hi all.
> I have been trying for several day to get firefox to work on a newly
> installed Debian Stretch system. It Seems that Firefox can't find a DNS
> server. I am having the same problem with apt-get update. None of my mirrors
> can be reached. Ping works just fine. I can't even reach the other computers
> on my home network if I use their names. IP addresses work OK. I have
> installed resolvconf and followed several installation instructions to no
> avail. The name servers for my router (192.168.1.1)and both google servers
> at 8.8.8.8 and 8.8.4.4. are listed in the correct file (can't remember which
> one). This system worked fine when first installed. I installed qemu-kvm on
> the system and I think in broke things.I've run out of ideas.

Please post these things from the problematic PC:

ip a l

ip ro l

cat /etc/resolv.conf

"tcpdump -nvi any udp port 53 or tcp port 53" run while doing
"getent hosts www.google.com"

Reco

Can't find the DNS Servers

[Gary Roach]

Don't know why but this message didn't show up on my email so am sending 
again. Thanks for the reply Cindy Sue.


Hi all.
I have been trying for several day to get firefox to work on a newly 
installed Debian Stretch system. It Seems that Firefox can't find a DNS 
server. I am having the same problem with apt-get update. None of my 
mirrors can be reached. Ping works just fine. I can't even reach the 
other computers on my home network if I use their names. IP addresses 
work OK. I have installed resolvconf and followed several installation 
instructions to no avail. The name servers for my router 
(192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed 
in the correct file (can't remember which one). This system worked fine 
when first installed. I installed qemu-kvm on the system and I think in 
broke things.I've run out of ideas.


Please help

Gary R.

Re: Can't find the DNS Servers

[Cindy-Sue Causey]

On 9/23/17, Gary Roach <gary719_li...@verizon.net> wrote:
> Hi all.
> I have been trying for several day to get firefox to work on a newly
> installed Debian Stretch system. It Seems that Firefox can't find a DNS
> server. I am having the same problem with apt-get update. None of my
> mirrors can be reached. Ping works just fine. I can't even reach the
> other computers on my home network if I use their names. IP addresses
> work OK. I have installed resolvconf and followed several installation
> instructions to no avail. The name servers for my router
> (192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed
> in the correct file (can't remember which one). This system worked fine
> when first installed. I installed qemu-kvm on the system and I think in
> broke things.I've run out of ideas.
>
> Please help


Hi, Gary, I absolutely feel your pain. I've been locked out most of
the entire past week. Could mostly only access ~400 to 900 BITES per
second download once in a little while.

After some nosing around, I've initially stumbled upon a quick fix
that will help you at least upgrade right now. This came about k/t an
Ubuntu issue [0].

Yes, I know you're saying you can't access something like that right
now so this is posted in hopes someone can further translate that into
appropriate IP addresses (unless you're accessing from another
computer and can do that yourself, that is).

In the process of learning from that issue over there, this came up:

https://wiki.debian.org/SourcesList#Name_Resolution

VERY cool. It says you can temporarily change your
/etc/apt/sources.list by personalizing the following
*example*/*template*:

echo "deb http://128.30.2.26/debian testing main contrib" >
/etc/apt/sources.list

You simply tweak that to match one's own favored release (e.g. jessie,
stretch, buster, etc) such as it already exists within
/etc/apt/sources.list.

That is SO cool because the tip I learned from Ubuntu was about
tweaking your /etc/hosts. I like tweaking sources.list much better. I
think I like it mostly because it's something more familiar than other
files.

Afterthought is that, because you're only swapping out a domain name
for an IP address (and not touching ANYTHING ELSE), hopefully that
should just keep right on moving from where you left off last time. If
it was me doing this, I would make sure I had a safe backup copy of
sources.list to put back in place when things were solved. :)

So now we hopefully have you upgrading..

Oh, and yes, I know.. there are all kinds of the fancy commands the
rest of everyone uses to debug this type of topic. That right there
above is *so* easy to test drive and is surely a new toy for someone
besides me (too). I even tested http://128.30.2.26/debian/ = IT WORKS
as expected!!!

If it then still doesn't work after upgrading, you can do the tip from
the Ubuntu page where you pick and add appropriate /etc/hosts lines as
you need them. But you need the IP addresses. I've almost figured that
out but not quite.

As it turns out, we might have the power to get those right from our
terminals. I'm not sure if it would work for you, Gary, due to your
issues, but it's a quick install to test and see.

Via Google, I learned about "nslookup". "apt-cache search nslookup"
landed the "dnsutils" package (285kb for me).

Once installed, you type in "nslookup" (as a normal user) and hit
Enter. Then you type in the domain name that needs an IP equivalent.
You'll receive back something like this:

> deb.debian.org
Server: 192.168.0.1
Address:192.168.0.1#53

Non-authoritative answer:
deb.debian.org  canonical name = static.debian.org.
Name:   static.debian.org
Address: 130.89.148.14
Name:   static.debian.org
Address: 149.20.4.15
Name:   static.debian.org
Address: 5.153.231.4
Name:   static.debian.org
Address: 128.31.0.62

That didn't match what Debian Wiki provided so I next tested "dig"
which is also included in dnsutils. I'm not sure how to implement that
one so I'm going to send this off now. Maybe someone else is versed in
"dig" and can help decode its flags, etc. It looks far more powerful
than nslookup.. :)

Or maybe they know an even more productive tool with possibly easier
to remember flags. :)

Originally it had come to mind that there's always the option of
sharing files like these to check for formation and typos:

/etc/network/interfaces
/etc/hosts (before potential tweaking)
/etc/resolv.conf

Those interfaces and hosts files are places I have to touch on and
sometimes fill in some things for during each new debootstrap. That
tells me they're places where things can get messed up.

That /etc/resolv.conf always resolves itself for me, yayhoo, but maybe
something's not quite ok in yours. I'm saying that because my notes
are showing one thing, and now my own /etc/resolv.conf has apparently
populated itself with an additi

Can't find the DNS Servers

[Gary Roach]

Hi all.
I have been trying for several day to get firefox to work on a newly 
installed Debian Stretch system. It Seems that Firefox can't find a DNS 
server. I am having the same problem with apt-get update. None of my 
mirrors can be reached. Ping works just fine. I can't even reach the 
other computers on my home network if I use their names. IP addresses 
work OK. I have installed resolvconf and followed several installation 
instructions to no avail. The name servers for my router 
(192.168.1.1)and both google servers at 8.8.8.8 and 8.8.4.4. are listed 
in the correct file (can't remember which one). This system worked fine 
when first installed. I installed qemu-kvm on the system and I think in 
broke things.I've run out of ideas.


Please help

Gary R.

Re: Problème DNS qui commence à me brouter.....

[Vincent]

Tu peux essayer de jouer avec le cible LOG ( ou autre ) d'iptables qui
te donnera l'uid et pid du processus faisant la requêtes.

Le 22/09/2017 à 08:08, David Martin a écrit :
> Bonjour,
> 
> J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.
> 
> J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
> que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
> coté postgres)... le problème c'est que nous avons du le remettre en service
> car le postgres continue à requéter dessus.
> 
> Impossible de trouver quel service requete dessus, mon resolv.conf n'à
> plus trace
> de ce vieux DNS.
> 
> J'ai cherché via netstat et l'ensemble des fonctions qu'il propose pour
> vérifier ça,
> lsof non plus ne me sort rien, il doit bien y avoir un service mais lequel.
> 
> J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
> rien...
> 
> Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
> d'erreur au démarrage
> du réseau qui me dit que l'ip est déjà occupée (celle du postgres),
> alors que je n'ai aucune
> machine (enfin je crois) qui à la même ip que mon serveur.
> 
> Je cherche encore ... si vous avez une idée, une astuce.
> 
> ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres, mais
> les perfs tombent
> et les accès sont ralenti pour l'ensemble des applications et
> utilisateurs... c'est zarb
> 
> Par quoi commenceriez vous ?
> 
> 
>  
> 
> -- 
> david martin
> 


-- 
EON Vincent
http://www.lws.fr
--
Siége social:
LIGNE WEB SERVICES
4, RUE GALVANI
75017 PARIS - FRANCE
---

Ce message et toute pièce jointe sont confidentiels et doivent être
protégés contre toute divulgation. Si vous n'êtes pas le destinataire de
ce message, merci de téléphoner ou d'envoyer un email à l'expéditeur, et
de détruire ce message et toute pièce jointe.

Re: Problème DNS qui commence à me brouter.....

[Jonathan bartoua Schneider]

Hello,

Ton postgres aurait pas gardé les confs de resolvers dans son cache ?
Il y a des programmes qui font ça (genre apache).

Jonathan

Le 22 septembre 2017 à 14:29, G2PC <g...@visionduweb.com> a écrit :

> Le 22/09/2017 à 08:08, David Martin a écrit :
>
> Bonjour,
>
> J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.
>
> J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
> que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
> coté postgres)... le problème c'est que nous avons du le remettre en
> service
> car le postgres continue à requéter dessus.
>
> Impossible de trouver quel service requete dessus, mon resolv.conf n'à
> plus trace
> de ce vieux DNS.
>
> J'ai cherché via netstat et l'ensemble des fonctions qu'il propose pour
> vérifier ça,
> lsof non plus ne me sort rien, il doit bien y avoir un service mais lequel.
>
> J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
> rien...
>
> Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
> d'erreur au démarrage
> du réseau qui me dit que l'ip est déjà occupée (celle du postgres), alors
> que je n'ai aucune
> machine (enfin je crois) qui à la même ip que mon serveur.
>
> Je cherche encore ... si vous avez une idée, une astuce.
>
> ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres, mais
> les perfs tombent
> et les accès sont ralenti pour l'ensemble des applications et
> utilisateurs... c'est zarb
>
> Par quoi commenceriez vous ?
> --
> david martin
>
> Je suis loin d'être le plus compétent en réseau pour t'apporter une
> réponse valable, je me jette à l'eau, qui sait.
>
> Lors de mon installation de Unbound, j'ai compris qu'il y a différentes
> façons de configurer son réseau, avec différents outils.
>
> Peut être déjà tenter de savoir si ton fichier resolv.conf est " statique
> ", ou, généré par un autre service, comme le programme resolvconf ?
>
> Mes quelques notes sur les DNS concernent Unbound, et, ne sont pas
> abouties, mais, peut être que cela peut t'aider avec de nouvelles pistes :
> https://www.visionduweb.eu/wiki/index.php?title=Changer_de_DNS
>
> Je ne peux pas t'aider plus, d'autres auront des réponses plus précises et
> adaptées.
>



-- 
bartoua est votre ami

Re: Problème DNS qui commence à me brouter.....

[G2PC]

Le 22/09/2017 à 08:08, David Martin a écrit :
> Bonjour,
>
> J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.
>
> J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
> que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
> coté postgres)... le problème c'est que nous avons du le remettre en
> service
> car le postgres continue à requéter dessus.
>
> Impossible de trouver quel service requete dessus, mon resolv.conf n'à
> plus trace
> de ce vieux DNS.
>
> J'ai cherché via netstat et l'ensemble des fonctions qu'il propose
> pour vérifier ça,
> lsof non plus ne me sort rien, il doit bien y avoir un service mais
> lequel.
>
> J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
> rien...
>
> Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
> d'erreur au démarrage
> du réseau qui me dit que l'ip est déjà occupée (celle du postgres),
> alors que je n'ai aucune
> machine (enfin je crois) qui à la même ip que mon serveur.
>
> Je cherche encore ... si vous avez une idée, une astuce.
>
> ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres,
> mais les perfs tombent
> et les accès sont ralenti pour l'ensemble des applications et
> utilisateurs... c'est zarb
>
> Par quoi commenceriez vous ?
> -- 
> david martin
Je suis loin d'être le plus compétent en réseau pour t'apporter une
réponse valable, je me jette à l'eau, qui sait.

Lors de mon installation de Unbound, j'ai compris qu'il y a différentes
façons de configurer son réseau, avec différents outils.

Peut être déjà tenter de savoir si ton fichier resolv.conf est "
statique ", ou, généré par un autre service, comme le programme resolvconf ?

Mes quelques notes sur les DNS concernent Unbound, et, ne sont pas
abouties, mais, peut être que cela peut t'aider avec de nouvelles pistes
: https://www.visionduweb.eu/wiki/index.php?title=Changer_de_DNS

Je ne peux pas t'aider plus, d'autres auront des réponses plus précises
et adaptées.

Problème DNS qui commence à me brouter.....

[David Martin]

Bonjour,

J'ai un problème DNS que je n'arrive pas à résoudre, je m'explique.

J'ai un serveur, qui vraisemblablement envoi des requêtes à un serveur DNS
que nous avons coupé hier (pour 3 nouveaux serveurs donc nouvel adressage
coté postgres)... le problème c'est que nous avons du le remettre en service
car le postgres continue à requéter dessus.

Impossible de trouver quel service requete dessus, mon resolv.conf n'à plus
trace
de ce vieux DNS.

J'ai cherché via netstat et l'ensemble des fonctions qu'il propose pour
vérifier ça,
lsof non plus ne me sort rien, il doit bien y avoir un service mais lequel.

J'ai fait aussi un grep sur l'ip de ce vieux dns dans la partie /etc/,
rien...

Je ne sais plus quoi faire, la seule chose c'est que j'ai le message
d'erreur au démarrage
du réseau qui me dit que l'ip est déjà occupée (celle du postgres), alors
que je n'ai aucune
machine (enfin je crois) qui à la même ip que mon serveur.

Je cherche encore ... si vous avez une idée, une astuce.

ah oui, j'ai DROPé via iptables du vieux DNS l'ip de mon postgres, mais les
perfs tombent
et les accès sont ralenti pour l'ensemble des applications et
utilisateurs... c'est zarb

Par quoi commenceriez vous ?




-- 
david martin

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

[Gene Heskett]

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

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

[Brian]

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.

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

[Brian]

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.

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

[Brian]

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.

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

[deloptes]

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

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

[Reco]

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

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

[x9p]

> 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

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

[Brian]

On Mon 18 Sep 2017 at 15:41:48 -0300, x9p wrote:

> 
> >>
> >> I believe topic is closed with this.
> >
> > For the benefit of other users: what does your /etc/hosts look like now?
> >
> > --
> > Brian.
> >
> >
> 
> root@localhost:~# cat /proc/sys/kernel/hostname
> localhost.localdomain
> root@localhost:~# grep localhost /etc/hosts
> 127.0.0.1   localhost localhost.localdomain
> 127.0.1.1   localhost
> ::1 localhost ip6-localhost ip6-loopback

It is difficult to argue against success in solving a problem but I
wouldn't have 127.0.1.1 as localhost. Does 'cat /etc/hostname' also
give "localhost"?

-- 
Brian.

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

[Brian]

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

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

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

-- 
Brian.

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

[x9p]

>>
>> I believe topic is closed with this.
>
> For the benefit of other users: what does your /etc/hosts look like now?
>
> --
> Brian.
>
>

root@localhost:~# cat /proc/sys/kernel/hostname
localhost.localdomain
root@localhost:~# grep localhost /etc/hosts
127.0.0.1   localhost localhost.localdomain
127.0.1.1   localhost
::1 localhost ip6-localhost ip6-loopback
root@localhost:~#

x9p

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

[deloptes]

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 :)

regards

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

[Reco]

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

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

[Brian]

On Mon 18 Sep 2017 at 12:28:16 -0300, x9p wrote:

> Thanks for the memo. Seems the solution is to not call machine localhost,
> if insist in doing so, be sure it contains a "localhost.localdomain" line
> in /etc/hosts.
> 
> I believe topic is closed with this.

For the benefit of other users: what does your /etc/hosts look like now?

-- 
Brian.

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

[x9p]

>>
>> My chosen machine name was "localhost", problem partially lies here.
>
> Yeah, man.
>
> My uncle Harry had a similar problem when it occurred to him that--for
> reasons of simplicity and because of a failing memory--he might christen
> two recently-purchased kittens with identical names. Whenever he called
> one of them there would be a considerable delay (each of them assuming
> he was calling the other).
>
> Of course cats never come when you call them anyway (which is a clue
> the story may be apocryphal).
>
> BTW, did you get the memo?
>
> http://www.ietf.org/rfc/rfc1912.txt
>
>

>From rfc1912:

-
  Translating 127.0.0.1 into "localhost.dom.ain" can cause some
  software to connect back to the loopback interface when it didn't
  want to because "localhost" is not equal to "localhost.dom.ain".
-

Thanks for the memo. Seems the solution is to not call machine localhost,
if insist in doing so, be sure it contains a "localhost.localdomain" line
in /etc/hosts.

I believe topic is closed with this.

Thanks

x9p

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

[Curt]

On 2017-09-18, Greg Wooledge  wrote:
> On Mon, Sep 18, 2017 at 11:38:05AM +, Curt wrote:
>> On 2017-09-18, x9p  wrote:
>> > My chosen machine name was "localhost", problem partially lies here.
>> 
>> Yeah, man. 
>> 
>> My uncle Harry had a similar problem when it occurred to him that--for
>> reasons of simplicity and because of a failing memory--he might christen
>> two recently-purchased kittens with identical names. Whenever he called
>> one of them there would be a considerable delay (each of them assuming
>> he was calling the other).
>> 
>> Of course cats never come when you call them anyway (which is a clue
>> the story may be apocryphal). 
>
> The story makes more sense in this context if your uncle names his
> kitten "Me".

You're right. 

Your skit reminds me a little of "Who's on first?"

> Uncle Harry: "Have you seen Me?"
> Aunt Berta: "You're standing right there."
> Harry: "Not me.  Me."
> Berta; "Have you been drinking the rubbing alcohol again?"
>



-- 
"Time flies like an arrow. Fruit flies like a banana." Groucho

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

[Greg Wooledge]

On Mon, Sep 18, 2017 at 11:38:05AM +, Curt wrote:
> On 2017-09-18, x9p  wrote:
> > My chosen machine name was "localhost", problem partially lies here.
> 
> Yeah, man. 
> 
> My uncle Harry had a similar problem when it occurred to him that--for
> reasons of simplicity and because of a failing memory--he might christen
> two recently-purchased kittens with identical names. Whenever he called
> one of them there would be a considerable delay (each of them assuming
> he was calling the other).
> 
> Of course cats never come when you call them anyway (which is a clue
> the story may be apocryphal). 

The story makes more sense in this context if your uncle names his
kitten "Me".

Uncle Harry: "Have you seen Me?"
Aunt Berta: "You're standing right there."
Harry: "Not me.  Me."
Berta; "Have you been drinking the rubbing alcohol again?"

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

[Brian]

On Mon 18 Sep 2017 at 06:32:55 -0300, x9p wrote:

(Please watch your attributioms; it confuses matters. x9p did not write
this).

> > This is the default from the last stretch install
> >
> > $ cat /etc/hosts
> > 127.0.0.1       localhost
> > 127.0.1.1       fujitsu.mydomain    fujitsu
> >
> > so if mydomain or localdomain is not working it will delay.
> >
> > 127.0.1.1   fujitsu fujitsu.mydomain
> >
> > will not delay because fujitsu is the name of the machine.
> >
> > in my case mydomain was added at installation time, because cable was
> > plugged in and the computer (fujitsu) got its IP via the dhcp server on
> > the
> > local network.
> >
> > IMO you should look deeper in your use case and see why you get invalid
> > setup. The problem might be somewhere else.
> >
> > regards
> 
> My chosen machine name was "localhost", problem partially lies here.

The hosts manual says each host should have a line like

  IP_address canonical_hostname [aliases...]

By implication the catonical_hostname should be for one IP_address. You
have (had?)

  root@localhost:~# grep localhost /etc/hosts
  127.0.0.1   localhost
  127.0.1.1   localhost

The first line is ok; the canonical_hostname localhost has the address
127.0.0.1. The second line is not ok.

The file /etc/hostname has the system hostname; it should not be
"localhost". If it was "stretch" then the second line should be

  127.0.1.1   stretch

(This becomes a little more complicated if a mail server is one of the
services being run on the machine).

-- 
Brian.

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

[Curt]

On 2017-09-18, x9p  wrote:
>>
>> IMO you should look deeper in your use case and see why you get invalid
>> setup. The problem might be somewhere else.
>>
>> regards
>>
>>
>
> My chosen machine name was "localhost", problem partially lies here.

Yeah, man. 

My uncle Harry had a similar problem when it occurred to him that--for
reasons of simplicity and because of a failing memory--he might christen
two recently-purchased kittens with identical names. Whenever he called
one of them there would be a considerable delay (each of them assuming
he was calling the other).

Of course cats never come when you call them anyway (which is a clue
the story may be apocryphal). 

BTW, did you get the memo?

http://www.ietf.org/rfc/rfc1912.txt


> x9p
>
>
>


-- 
"Time flies like an arrow. Fruit flies like a banana." Groucho

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

[x9p]

>
> This is the default from the last stretch install
>
> $ cat /etc/hosts
> 127.0.0.1       localhost
> 127.0.1.1       fujitsu.mydomain    fujitsu
>
> so if mydomain or localdomain is not working it will delay.
>
> 127.0.1.1   fujitsu fujitsu.mydomain
>
> will not delay because fujitsu is the name of the machine.
>
> in my case mydomain was added at installation time, because cable was
> plugged in and the computer (fujitsu) got its IP via the dhcp server on
> the
> local network.
>
> IMO you should look deeper in your use case and see why you get invalid
> setup. The problem might be somewhere else.
>
> regards
>
>

My chosen machine name was "localhost", problem partially lies here.

x9p

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

[deloptes]

x9p wrote:

> If system hostname should ALWAYS be resolvable, whether there is network
> or no, the change in /etc/hosts
> from (default in stretch):
> 127.0.0.1       localhost
> to (my system):
> 127.0.0.1       localhost localhost.localdomain
> 
> is justifiable as it breaks (not literally break, just adds lot of delay)
> to sudo in a non-networked environment.

This is the default from the last stretch install

$ cat /etc/hosts
127.0.0.1       localhost
127.0.1.1       fujitsu.mydomain    fujitsu

so if mydomain or localdomain is not working it will delay.

127.0.1.1   fujitsu fujitsu.mydomain

will not delay because fujitsu is the name of the machine.

in my case mydomain was added at installation time, because cable was
plugged in and the computer (fujitsu) got its IP via the dhcp server on the
local network.

IMO you should look deeper in your use case and see why you get invalid
setup. The problem might be somewhere else.

regards

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

[deloptes]

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?

I guess this is put there at time of installation. I'll check few virtual
machines later to see how it was written.

IMO if you have working resolver it shouldn't matter much.

regards

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

[x9p]

> 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

>From the above URL:

From: Christoph Anton Mitterer 
Date: Tue, 30 Jul 2013 22:43:44 +0200

-
- The system hostname (and domainname if any) should ALWAYS be
resolvable, whether a network is up or not, regardless of which.
(Assuming that lo is always up, if not, many things break anyway.)

- "localhost" when added like this to /etc/hosts is basically like a TLD.
"localhost" is one of the reserved names, unlike ip6-localhost and friends
and unlike .localdomain.
...
...
...
Further, but this isn't the case anymore anyway,... we should not
generate localhost.localdomain.
...
...
...
-

If system hostname should ALWAYS be resolvable, whether there is network
or no, the change in /etc/hosts
from (default in stretch):
127.0.0.1   localhost
to (my system):
127.0.0.1   localhost localhost.localdomain

is justifiable as it breaks (not literally break, just adds lot of delay)
to sudo in a non-networked environment.

x9p

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

[Brian]

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.

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

[Gene Heskett]

On Sunday 17 September 2017 18:58:30 deloptes wrote:

> Gene Heskett wrote:
> > On Sunday 17 September 2017 16:54:27 deloptes wrote:
> >> x9p wrote:
> >> > Should be on debian by default in my opinion.
> >>
> >> ... and truly it is
> >
> > Not on the 3 other wheezy's nor on the one jessie machine I can
> > inspect in a couple minutes here.
> >
> > Cheers, Gene Heskett
>
> No idea, on any debian I installed local host maps to 127.0.0.1
>
> This is the default from the last stretch install
>
> $ cat /etc/hosts
> 127.0.0.1   localhost

The above is precisely my point, there is NOT a 

127.0.0.1 localhost.localdomain localhost 

entry in anyones /etc/hosts file unless THEY PUT IT THERE.

So while I seem to have fixed the OP's problem, the fix is now masking 
the real problem (and I haven't a clue what the heck that actually is)

 
> 127.0.1.1   fujitsu.mydomainfujitsu
>
> # The following lines are desirable for IPv6 capable hosts
>
> ::1 localhost ip6-localhost ip6-loopback
>
> ff02::1 ip6-allnodes
> ff02::2 ip6-allrouters
>
> Interesting to know why.
>
> If it is about localhost.localdomain  no idea where localdomain is
> coming from. Perhaps if you install in a local network without domain,
> or if you do not enter any.
>
> The line in stretch
>
> 127.0.1.1   fujitsu.mydomainfujitsu
>
> is new to me, but computer works with local dhcp/dns, so why bother
>
> regards


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>

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

[deloptes]

Gene Heskett wrote:

> On Sunday 17 September 2017 16:54:27 deloptes wrote:
> 
>> x9p wrote:
>> > Should be on debian by default in my opinion.
>>
>> ... and truly it is
> 
> Not on the 3 other wheezy's nor on the one jessie machine I can inspect
> in a couple minutes here.
> 
> Cheers, Gene Heskett

No idea, on any debian I installed local host maps to 127.0.0.1

This is the default from the last stretch install

$ cat /etc/hosts
127.0.0.1   localhost
127.0.1.1   fujitsu.mydomainfujitsu

# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Interesting to know why.

If it is about localhost.localdomain  no idea where localdomain is
coming from. Perhaps if you install in a local network without domain, or
if you do not enter any.

The line in stretch

127.0.1.1   fujitsu.mydomainfujitsu

is new to me, but computer works with local dhcp/dns, so why bother

regards

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

[Gene Heskett]

On Sunday 17 September 2017 16:54:27 deloptes wrote:

> x9p wrote:
> > Should be on debian by default in my opinion.
>
> ... and truly it is

Not on the 3 other wheezy's nor on the one jessie machine I can inspect 
in a couple minutes here.

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 

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

[Gene Heskett]

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>

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

[Brian]

On Sun 17 Sep 2017 at 22:54:27 +0200, deloptes wrote:

> x9p wrote:
> 
> > Should be on debian by default in my opinion.
> 
> ... and truly it is

Really? Not on any install I have done and not according to the netcfg
source package:

  * Don't make 'localhost.localdomain' the canonical hostname of 127.0.0.1. 

See Oct 2005 debian-devel discussion with Subject: localhost.localdomain,

  * Per Olofsson

- Map 127.0.0.1 to localhost in /etc/hosts, make the hostname   

  an alias instead.

-- 
Brian. 

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

[deloptes]

x9p wrote:

> Should be on debian by default in my opinion.

... and truly it is

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

[x9p]

> 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

Should be on debian by default in my opinion.

x9p

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

[Gene Heskett]

On Friday 15 September 2017 19:17:30 x9p wrote:

> > Thanks, now I see it.
> >
> > Your /etc/hosts says:
> >
> > 127.0.0.1   localhost
> > 127.0.1.1   localhost
> >
> > ::1 localhost ip6-localhost ip6-loopback
> >
> > Note the absence of localhost.localdomain.
> >
> >
> > Your hostname is "localhost.localdomain", as strace helpfully shows
> > us:
> >
> > uname({sysname="Linux", nodename="localhost.localdomain", ...})
>
> strangely i do not remember calling it localhost with domain
> localdomain, just localhost.
>
> > I won't say that specifying fqdn as nodename is wrong per se, but in
> > your case you don't have a record for your hostname in /etc/hosts.
> >
> > This *could* be the case that's nss-myhostname is designed for but
> > … it's the last in your nsswitch.conf so it cannot come into play.
> >
> > Therefore libc resolver you're using does exactly the same way it's
> > supposed to - search for localhost.localdomain in /etc/hosts first,
> > query DNS next.
> >
> >
> > Quick and dirty way to fix this is to add a record for
> > 'localhost.localdomain' in your /etc/hosts.
>
> Will do it, thanks
>
> > Correct, but painful way (I won't even try to predict what you could
> > break in your setup) to fix this is to ensure that your hostname is
> > 'localhost' verbatim.
>
> I still think correct way is sudo not try to access network functions
> in a setup where it does not need to - waste of time, code, and opens
> it to more bugs.
>
> Thanks for the analysis Reco.
>
> x9p

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

where x.z are the triplets (without the zero leading fill of course) 
corresponding to the class d of your local network.

Then you shouldn't have any dns problems if your resolv.conf is correct.

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

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

[x9p]

> Thanks, now I see it.
>
> Your /etc/hosts says:
>
> 127.0.0.1   localhost
> 127.0.1.1   localhost
> ::1 localhost ip6-localhost ip6-loopback
>
> Note the absence of localhost.localdomain.
>
>
> Your hostname is "localhost.localdomain", as strace helpfully shows us:
>
> uname({sysname="Linux", nodename="localhost.localdomain", ...})
>

strangely i do not remember calling it localhost with domain localdomain,
just localhost.

>
> I won't say that specifying fqdn as nodename is wrong per se, but in
> your case you don't have a record for your hostname in /etc/hosts.
>
> This *could* be the case that's nss-myhostname is designed for but …
> it's the last in your nsswitch.conf so it cannot come into play.
>
> Therefore libc resolver you're using does exactly the same way it's
> supposed to - search for localhost.localdomain in /etc/hosts first,
> query DNS next.
>
>
> Quick and dirty way to fix this is to add a record for
> 'localhost.localdomain' in your /etc/hosts.
>

Will do it, thanks

> Correct, but painful way (I won't even try to predict what you could
> break in your setup) to fix this is to ensure that your hostname is
> 'localhost' verbatim.
>

I still think correct way is sudo not try to access network functions in a
setup where it does not need to - waste of time, code, and opens it to
more bugs.

Thanks for the analysis Reco.

x9p

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

[Reco]

On Fri, Sep 15, 2017 at 06:32:17PM -0300, x9p wrote:
> 
> > Your snippet of strace output on pastebin is lacking the beginning.
> > What I'm currently interested in are:
> >
> > 1) Libraries and configuration files that sudo is opening (hence the
> > 'open' syscall). Thinking about it, make it 'open,stat'.
> >
> > 2) What kind of network sockets (short of kinda obvious UDP) sudo is
> > opening (hence the 'connect' syscall).
> >
> 
> Sorry for that, pasted the full output here.
> https://pastebin.com/0bV7JC1z
> 
> > Feel free to edit out all unnecessary details of course.
> 
> No need.

Thanks, now I see it.

Your /etc/hosts says:

127.0.0.1   localhost
127.0.1.1   localhost
::1 localhost ip6-localhost ip6-loopback

Note the absence of localhost.localdomain.


Your hostname is "localhost.localdomain", as strace helpfully shows us:

uname({sysname="Linux", nodename="localhost.localdomain", ...})


I won't say that specifying fqdn as nodename is wrong per se, but in
your case you don't have a record for your hostname in /etc/hosts.

This *could* be the case that's nss-myhostname is designed for but …
it's the last in your nsswitch.conf so it cannot come into play.

Therefore libc resolver you're using does exactly the same way it's
supposed to - search for localhost.localdomain in /etc/hosts first,
query DNS next.


Quick and dirty way to fix this is to add a record for
'localhost.localdomain' in your /etc/hosts.

Correct, but painful way (I won't even try to predict what you could
break in your setup) to fix this is to ensure that your hostname is
'localhost' verbatim.

Reco

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

[x9p]

> 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

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

[x9p]

> Your snippet of strace output on pastebin is lacking the beginning.
> What I'm currently interested in are:
>
> 1) Libraries and configuration files that sudo is opening (hence the
> 'open' syscall). Thinking about it, make it 'open,stat'.
>
> 2) What kind of network sockets (short of kinda obvious UDP) sudo is
> opening (hence the 'connect' syscall).
>

Sorry for that, pasted the full output here.
https://pastebin.com/0bV7JC1z

> Feel free to edit out all unnecessary details of course.

No need.

>
> PS Replying to debian-user@lists.debian.org is sufficient. There's no
> need to CC me, I'm subscribed to the list.
>

Sorry for that. I just hit "reply all", fixing.

x9p

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

[Reco]

On Fri, Sep 15, 2017 at 06:06:02PM -0300, x9p wrote:
> 
> > sudo(8) says:
> >
> >  sudo supports a plugin architecture for security policies and
> > input/output logging.  Third parties can develop and distribute their
> > own policy and I/O logging plugins to work seamlessly with the sudo
> > front end.  The default security policy is sudoers, which is configured
> > via the file /etc/sudoers, or via LDAP.
> >
> > And LDAP means TCP, and TCP usually mean DNS requests.
> >
> > So it's unusual (sudo does not exhibit such behavior here), but
> > possible.
> >
> 
> Agree there are situations where sudo does TCP. Disagree with that
> occurring in my simplistic setup. sudo should not hang for X seconds if my
> DNS servers are incorrect.
> 
> > A stray nameserver in resolv.conf, which can happen if resolvconf is
> > used carelessly. Even more weird things are always possible with
> > NetworkManager.
> 
> Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn
> this into a systemd talk.

Was not my intention. All those things can happen if one's using
sysvinit.


> >> > Specifically I'm interested with:
> >> >
> >> > grep hosts /etc/nsswitch.conf
> >> >
> >> > grep localhost /etc/hosts
> >> >
> >> > Reco
> >> >
> >>
> >> Did not touched these, are the default from stretch:
> >>
> >> root@localhost:~# grep hosts /etc/nsswitch.conf
> >> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
> >> root@localhost:~# grep localhost /etc/hosts
> >> 127.0.0.1   localhost
> >> 127.0.1.1   localhost
> >> ::1 localhost ip6-localhost ip6-loopback
> >
> > Curious. Can you reproduce the behaviour if sudo is run as root?
> > I propose to simplify things a bit (needs to be run as root):
> >
> 
> strace was already run as root (did "sudo su" as root to prove the point),
> otherwise strace would fail with "effective uid is not 0".

Your snippet of strace output on pastebin is lacking the beginning.
What I'm currently interested in are:

1) Libraries and configuration files that sudo is opening (hence the
'open' syscall). Thinking about it, make it 'open,stat'.

2) What kind of network sockets (short of kinda obvious UDP) sudo is
opening (hence the 'connect' syscall).

Feel free to edit out all unnecessary details of course.


PS Replying to debian-user@lists.debian.org is sufficient. There's no
need to CC me, I'm subscribed to the list.

Reco

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

[Dan Ritter]

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-

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

[x9p]

> sudo(8) says:
>
>  sudo supports a plugin architecture for security policies and
> input/output logging.  Third parties can develop and distribute their
> own policy and I/O logging plugins to work seamlessly with the sudo
> front end.  The default security policy is sudoers, which is configured
> via the file /etc/sudoers, or via LDAP.
>
> And LDAP means TCP, and TCP usually mean DNS requests.
>
> So it's unusual (sudo does not exhibit such behavior here), but
> possible.
>

Agree there are situations where sudo does TCP. Disagree with that
occurring in my simplistic setup. sudo should not hang for X seconds if my
DNS servers are incorrect.

> A stray nameserver in resolv.conf, which can happen if resolvconf is
> used carelessly. Even more weird things are always possible with
> NetworkManager.

Am too old, I like /etc/resolv.conf being just a file. Am avoiding to turn
this into a systemd talk.

>> resolv.conf is not a symlink to systemd, just a plain file. I explicitly
>> removed the symlink and created a normal file.
>
> And of course one can never disregard a misconfigured VPN script.
>
>
>
>> > Specifically I'm interested with:
>> >
>> > grep hosts /etc/nsswitch.conf
>> >
>> > grep localhost /etc/hosts
>> >
>> > Reco
>> >
>>
>> Did not touched these, are the default from stretch:
>>
>> root@localhost:~# grep hosts /etc/nsswitch.conf
>> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
>> root@localhost:~# grep localhost /etc/hosts
>> 127.0.0.1   localhost
>> 127.0.1.1   localhost
>> ::1 localhost ip6-localhost ip6-loopback
>
> Curious. Can you reproduce the behaviour if sudo is run as root?
> I propose to simplify things a bit (needs to be run as root):
>

strace was already run as root (did "sudo su" as root to prove the point),
otherwise strace would fail with "effective uid is not 0".

x9p

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

[Reco]

On Fri, Sep 15, 2017 at 04:28:31PM -0300, x9p wrote:
> 
> > Hi.
> 
> Hi.
> 
> >
> > While DNS lookups for localhost are unusual any reasonable configured
> > DNS should have no trouble resolving it. Especially since there are OSes
> > that try to resolve *everything* by default via including localhost (AIX
> > comes to mind).
> >
> 
> Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
> them.

sudo(8) says:

 sudo supports a plugin architecture for security policies and
input/output logging.  Third parties can develop and distribute their
own policy and I/O logging plugins to work seamlessly with the sudo
front end.  The default security policy is sudoers, which is configured
via the file /etc/sudoers, or via LDAP.

And LDAP means TCP, and TCP usually mean DNS requests.

So it's unusual (sudo does not exhibit such behavior here), but
possible.


> > While you mentioned misconfigured resolv.conf I believe your problem
> > lies somewhat deeper than this.
> 
> Actually it is deeper. I did not pay that much attention to the strace I
> did before.
> 
> https://pastebin.com/j0rw5Kgn
> 
> 10.1.2.9 is the DNS of the company I work for, turned out I had not
> connected to the VPN yet by the time i issued the sudo command.

A stray nameserver in resolv.conf, which can happen if resolvconf is
used carelessly. Even more weird things are always possible with
NetworkManager.

> resolv.conf is not a symlink to systemd, just a plain file. I explicitly
> removed the symlink and created a normal file.

And of course one can never disregard a misconfigured VPN script.



> > Specifically I'm interested with:
> >
> > grep hosts /etc/nsswitch.conf
> >
> > grep localhost /etc/hosts
> >
> > Reco
> >
> 
> Did not touched these, are the default from stretch:
> 
> root@localhost:~# grep hosts /etc/nsswitch.conf
> hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
> root@localhost:~# grep localhost /etc/hosts
> 127.0.0.1   localhost
> 127.0.1.1   localhost
> ::1 localhost ip6-localhost ip6-loopback

Curious. Can you reproduce the behaviour if sudo is run as root?
I propose to simplify things a bit (needs to be run as root):

strace -o /tmp/sudo -econnect,open sudo -i

Reco

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

[x9p]

> Hi.

Hi.

>
> While DNS lookups for localhost are unusual any reasonable configured
> DNS should have no trouble resolving it. Especially since there are OSes
> that try to resolve *everything* by default via including localhost (AIX
> comes to mind).
>

Understand, but disagree with sudo doing DNS lookups. Will fill a bug with
them.

> While you mentioned misconfigured resolv.conf I believe your problem
> lies somewhat deeper than this.

Actually it is deeper. I did not pay that much attention to the strace I
did before.

https://pastebin.com/j0rw5Kgn

10.1.2.9 is the DNS of the company I work for, turned out I had not
connected to the VPN yet by the time i issued the sudo command.

---

connect(6, {sa_family=AF_INET, sin_port=htons(53),
sin_addr=inet_addr("10.1.2.9")}, 16) = 0^M
poll([{fd=6, events=POLLOUT}], 1, 0)= 1 ([{fd=6, revents=POLLOUT}])^M
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2^M
poll([{fd=6, events=POLLIN}], 1, 5000)  = 0 (Timeout)^M

---

resolv.conf is not a symlink to systemd, just a plain file. I explicitly
removed the symlink and created a normal file.

> Specifically I'm interested with:
>
> grep hosts /etc/nsswitch.conf
>
> grep localhost /etc/hosts
>
> Reco
>

Did not touched these, are the default from stretch:

root@localhost:~# grep hosts /etc/nsswitch.conf
hosts:  files mdns4_minimal [NOTFOUND=return] dns myhostname
root@localhost:~# grep localhost /etc/hosts
127.0.0.1   localhost
127.0.1.1   localhost
::1 localhost ip6-localhost ip6-loopback

x9p

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

[Reco]

Hi.

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

While DNS lookups for localhost are unusual any reasonable configured
DNS should have no trouble resolving it. Especially since there are OSes
that try to resolve *everything* by default via including localhost (AIX
comes to mind).

While you mentioned misconfigured resolv.conf I believe your problem
lies somewhat deeper than this.

Specifically I'm interested with:

grep hosts /etc/nsswitch.conf

grep localhost /etc/hosts

Reco

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

[x9p]

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


sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\372\251\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=39}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\25\201\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=39}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=39}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2
sendmmsg(6, [{msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\313\265\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_OOB|MSG_PEEK},
msg_len=51}, {msg_hdr={msg_name=NULL, msg_namelen=0,
msg_iov=[{iov_base="\1\371\1\0\0\1\0\0\0\0\0\0\tlocalhost\vlocaldoma"...,
iov_len=51}], msg_iovlen=1, msg_controllen=0, msg_flags=MSG_PEEK},
msg_len=51}], 2, MSG_NOSIGNAL) = 2

Re: [nodejs] Re: cannot get node dns program to work externally

[Mikkel Wilson]

Aaron,

Listening to 127.0.0.1 and not on the other addresses would make this work 
on port 80 on localhost only. That's just how the TCP stack works. If you 
want to test this, find whatever your DHCP IP address is (`ifconfig en0`) 
and listen on that IP address. You should find that you can hit port 80 on 
that IP and not on localhost. Listening on 0.0.0.0 will listen on all 
available addresses on the host.

Best,
Mikkel

On Sunday, August 20, 2017 at 2:35:08 PM UTC-7, AaronNGray wrote:
>
> Mikkel,
>
> Cheers ! Knew it had to be sometyhing simple. Stange that port 80 works 
> with localhost 127.0.0.1 though ?
>
> Aaron
>
> On 10 August 2017 at 19:37, Mikkel Wilson <code...@gmail.com 
> > wrote:
>
>> I haven't run this locally to test, but you appear to be binding only to 
>> the localhost address: 
>> https://github.com/tjfontaine/node-dns/blob/master/examples/forwarder.js#L10
>>
>> This should exhibit the symptoms you mention and allow it to work on 
>> localhost and not on remote addresses. Change this from '127.0.0.1' to 
>> '0.0.0.0' to bind on all addresses and it should be available externally as 
>> well.
>>
>> Mikkel
>>
>>
>> On Monday, August 7, 2017 at 2:56:11 PM UTC-7, AaronNGray wrote:
>>>
>>> Hi,
>>>
>>> I have a node.js based dns program on port 53 and have it working as 
>>> localhost on debian 8.5 but I cannot seem to get it to work externally 
>>> despite getting the firewall rules right having tested them with Bind9.
>>>
>>> -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT
>>> -A OUTPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
>>> -A OUTPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
>>> -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT
>>>
>>> -A OUTPUT -p udp --sport 53 --dport 53 -j ACCEPT
>>> -A INPUT -p udp --dport 53 --sport 53 -j ACCEPT
>>>
>>>
>>> Also I have done :-
>>>
>>> setcap cap_net_bind_service=+ep /usr/bin/nodejs
>>>
>>> to allow node to work with ports less than 1024.
>>>
>>> I have my node dns program working on port 53 UDP with dig from 
>>> localhost but Basically not externally on the local network and cannot work 
>>> out why ?
>>>
>>> I have mainly been using :-
>>>
>>> 
>>> https://github.com/tjfontaine/node-dns/blob/master/examples/forwarder.js
>>>
>>> for testing.
>>>
>>> Its probably something obvious hope someone can help !
>>>
>>> -- 
>>> Aaron Gray
>>>
>>> Independent Open Source Software Engineer, Computer Language Researcher, 
>>> Information Theorist, and amateur computer scientist.
>>>
>> -- 
>> Job board: http://jobs.nodejs.org/
>> New group rules: 
>> https://gist.github.com/othiym23/9886289#file-moderation-policy-md
>> Old group rules: 
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> --- 
>> You received this message because you are subscribed to the Google Groups 
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to nodejs+un...@googlegroups.com .
>> To post to this group, send email to nod...@googlegroups.com 
>> .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/nodejs/ec063c84-9f7f-4c53-a18d-921e25ebf9ba%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/nodejs/ec063c84-9f7f-4c53-a18d-921e25ebf9ba%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
>
> -- 
> Aaron Gray
>
> Independent Open Source Software Engineer, Computer Language Researcher, 
> Information Theorist, and amateur computer scientist.
>

Re: [nodejs] Re: cannot get node dns program to work externally

[Aaron Gray]

Mikkel,

Cheers ! Knew it had to be sometyhing simple. Stange that port 80 works
with localhost 127.0.0.1 though ?

Aaron

On 10 August 2017 at 19:37, Mikkel Wilson <codeb...@gmail.com> wrote:

> I haven't run this locally to test, but you appear to be binding only to
> the localhost address: https://github.com/tjfontaine/node-dns/blob/
> master/examples/forwarder.js#L10
>
> This should exhibit the symptoms you mention and allow it to work on
> localhost and not on remote addresses. Change this from '127.0.0.1' to
> '0.0.0.0' to bind on all addresses and it should be available externally as
> well.
>
> Mikkel
>
>
> On Monday, August 7, 2017 at 2:56:11 PM UTC-7, AaronNGray wrote:
>>
>> Hi,
>>
>> I have a node.js based dns program on port 53 and have it working as
>> localhost on debian 8.5 but I cannot seem to get it to work externally
>> despite getting the firewall rules right having tested them with Bind9.
>>
>> -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT
>> -A OUTPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
>> -A OUTPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
>> -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT
>>
>> -A OUTPUT -p udp --sport 53 --dport 53 -j ACCEPT
>> -A INPUT -p udp --dport 53 --sport 53 -j ACCEPT
>>
>>
>> Also I have done :-
>>
>> setcap cap_net_bind_service=+ep /usr/bin/nodejs
>>
>> to allow node to work with ports less than 1024.
>>
>> I have my node dns program working on port 53 UDP with dig from localhost
>> but Basically not externally on the local network and cannot work out why ?
>>
>> I have mainly been using :-
>>
>> https://github.com/tjfontaine/node-dns/blob/master/examples/
>> forwarder.js
>>
>> for testing.
>>
>> Its probably something obvious hope someone can help !
>>
>> --
>> Aaron Gray
>>
>> Independent Open Source Software Engineer, Computer Language Researcher,
>> Information Theorist, and amateur computer scientist.
>>
> --
> Job board: http://jobs.nodejs.org/
> New group rules: https://gist.github.com/othiym23/9886289#file-
> moderation-policy-md
> Old group rules: https://github.com/joyent/node/wiki/Mailing-List-
> Posting-Guidelines
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> To post to this group, send email to nod...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/nodejs/ec063c84-9f7f-4c53-a18d-921e25ebf9ba%40googlegroups.com
> <https://groups.google.com/d/msgid/nodejs/ec063c84-9f7f-4c53-a18d-921e25ebf9ba%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Aaron Gray

Independent Open Source Software Engineer, Computer Language Researcher,
Information Theorist, and amateur computer scientist.

Re: dns secundario

[luis]

> Buenas tardes, hace rato quiero hacer lo de replicar dns, podias darme
> alguna guia si tienes de como hacerlo,
>
>
> Saludos
>
> --
> Este mensaje le ha llegado mediante el servicio de correo electronico que
> ofrece Infomed para respaldar el cumplimiento de las misiones del Sistema
> Nacional de Salud. La persona que envia este correo asume el compromiso de
> usar el servicio a tales fines y cumplir con las regulaciones establecidas
>
> Infomed: http://www.sld.cu/
>
Lee esto Salvador
https://aula128.wordpress.com/2014/11/16/dns-servidor-secundario-con-ubuntuserver/

http://sufriendoenredes.blogspot.com/2015/10/servidor-dns-secundario-ubuntu-1404.html

Brother hay que leer  estudiar, consulta tantans pag como puedas, as'i lo
he hecho y claro a veces pregunto a la lista cuando ya no puedo mas.

Espero que resuelvas

Re: dns secundario

[luis]

> Hola a todos
>
> Tengo 1 serv debian ver 7 con DNS primario
>
> En el segundo server tenía debian 8 con DNS secundario donde me replicaba
> del 1er dns al secundario sin problema, perfecto.
>
> Ahora en el DNS secundario isntalé debian 9 y no me replica las base de
> dados donde deben aparecer las PC de la zona directa y las rev
>
> Tenía salva de los ficheros de conf del 2do DNS, del secundario y los puse
> como tal pero no me replicad los .db donde están las ip y nombres de las
> PC.
>
> Alguna idea ??
>
> Agradezco toda ayuda
>

Ya el problema era dar permisos a la carpeta bind, g+w, espero que sirva a
muchos.
agradezco a todos

dns secundario

[luis]

Hola a todos

Tengo 1 serv debian ver 7 con DNS primario

En el segundo server tenía debian 8 con DNS secundario donde me replicaba
del 1er dns al secundario sin problema, perfecto.

Ahora en el DNS secundario isntalé debian 9 y no me replica las base de
dados donde deben aparecer las PC de la zona directa y las rev

Tenía salva de los ficheros de conf del 2do DNS, del secundario y los puse
como tal pero no me replicad los .db donde están las ip y nombres de las
PC.

Alguna idea ??

Agradezco toda ayuda

Re: cannot get node dns program to work externally

[Mikkel Wilson]

I haven't run this locally to test, but you appear to be binding only to 
the localhost 
address: 
https://github.com/tjfontaine/node-dns/blob/master/examples/forwarder.js#L10

This should exhibit the symptoms you mention and allow it to work on 
localhost and not on remote addresses. Change this from '127.0.0.1' to 
'0.0.0.0' to bind on all addresses and it should be available externally as 
well.

Mikkel

On Monday, August 7, 2017 at 2:56:11 PM UTC-7, AaronNGray wrote:
>
> Hi,
>
> I have a node.js based dns program on port 53 and have it working as 
> localhost on debian 8.5 but I cannot seem to get it to work externally 
> despite getting the firewall rules right having tested them with Bind9.
>
> -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT
> -A OUTPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
> -A OUTPUT -p udp --sport 53 --dport 1024:65535 -j ACCEPT
> -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT
>
> -A OUTPUT -p udp --sport 53 --dport 53 -j ACCEPT
> -A INPUT -p udp --dport 53 --sport 53 -j ACCEPT
>
>
> Also I have done :-
>
> setcap cap_net_bind_service=+ep /usr/bin/nodejs
>
> to allow node to work with ports less than 1024.
>
> I have my node dns program working on port 53 UDP with dig from localhost 
> but Basically not externally on the local network and cannot work out why ?
>
> I have mainly been using :-
>
> 
> https://github.com/tjfontaine/node-dns/blob/master/examples/forwarder.js
>
> for testing.
>
> Its probably something obvious hope someone can help !
>
> -- 
> Aaron Gray
>
> Independent Open Source Software Engineer, Computer Language Researcher, 
> Information Theorist, and amateur computer scientist.
>

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pierre L.]

Ok donc effectivement, ca réduit bien les pistes...

T'es directement branché au net via ta box ? Ou un petit routeur
"personnalisable" s'interpose entre ?
-> à voir un éventuel paramétrage dans la box (option rare à ma
connaissance) et/ou dans le routeur perso, un filtrage par parefeu qui
bloquerait cette IP en destination.
Exemple un routeur sous OpenWRT, DD-WRT, Tomato... des petits firmwares
très sympas dans lesquels ont peu paramétrer ce type de filtrage (dans
quel cas t'embistrouillerait !)



Le 09/08/2017 à 15:51, G2PC a écrit :
> Oui, mes 3 pc + téléphone n'ont pas accès.
>
> C'est pour cela que je pense à un filtrage volontaire.




signature.asc
Description: OpenPGP digital signature

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[G2PC]

Le 09/08/2017 à 10:17, Pierre L. a écrit :
> Humm, je n'ai pas suivi tout le fil... peut-être la question a-t-elle
> déjà été posée...
>
> Un autre ordi branché sur ton même réseau LAN de chez toi fait-il
> exactement la même chose ?
> Ton éventuel smartphone ou autre tablette... un NAS où tu aurais une
> console pour faire un traceroute ?
>
> Sinon étant chez un fournisseur concurrent, mon traceroute vers cette IP
> me répond correctement aussi.
>
>
>
> Le 08/08/2017 à 12:11, G2PC a écrit :
>> Ce qui ne m'étonne pas, une idée pour démontrer ce filtrage volontaire
>> de mes données ?
>
Oui, mes 3 pc + téléphone n'ont pas accès.

C'est pour cela que je pense à un filtrage volontaire.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[G2PC]

Le 09/08/2017 à 07:43, Pascal Hambourg a écrit :
> Le 08/08/2017 à 12:11, G2PC a écrit :
>>
>> Le 07/08/2017 à 23:49, Pascal Hambourg a écrit :
>>>
>>> Apparemment il n'y a pas de problème de connectivité entre Orange et
>>> l'hébergeur. Donc a priori soit il y a un blocage au niveau du
>>> réseau/box de G2PC, soit il y a un filtrage spécifique de son adresse
>>> IP publique quelque part en chemin.
>>
>> Ce qui ne m'étonne pas, une idée pour démontrer ce filtrage volontaire
>> de mes données ?
>
> As-tu redémarré ta box pour éliminer un dysfonctionnement transitoire
> ? D'autre part, cela te fera peut-être changer d'adresse IP publique.
>
> As-tu contacté le support de l'hébergeur en lui exposant la situation
> avec les différents résultats de traceroute ?
>
Oui, j'ai redémarré la box.

Non, je n'ai pas contacté l'hébergeur, je n'ai pas les codes
identifiants, et, le dialogue familial est rompu, je ne peux pas
travailler normalement.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pierre L.]

Humm, je n'ai pas suivi tout le fil... peut-être la question a-t-elle
déjà été posée...

Un autre ordi branché sur ton même réseau LAN de chez toi fait-il
exactement la même chose ?
Ton éventuel smartphone ou autre tablette... un NAS où tu aurais une
console pour faire un traceroute ?

Sinon étant chez un fournisseur concurrent, mon traceroute vers cette IP
me répond correctement aussi.



Le 08/08/2017 à 12:11, G2PC a écrit :
> Ce qui ne m'étonne pas, une idée pour démontrer ce filtrage volontaire
> de mes données ?




signature.asc
Description: OpenPGP digital signature

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 08/08/2017 à 12:11, G2PC a écrit :


Le 07/08/2017 à 23:49, Pascal Hambourg a écrit :


Apparemment il n'y a pas de problème de connectivité entre Orange et
l'hébergeur. Donc a priori soit il y a un blocage au niveau du
réseau/box de G2PC, soit il y a un filtrage spécifique de son adresse
IP publique quelque part en chemin.


Ce qui ne m'étonne pas, une idée pour démontrer ce filtrage volontaire
de mes données ?


As-tu redémarré ta box pour éliminer un dysfonctionnement transitoire ? 
D'autre part, cela te fera peut-être changer d'adresse IP publique.


As-tu contacté le support de l'hébergeur en lui exposant la situation 
avec les différents résultats de traceroute ?

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[G2PC]

Le 07/08/2017 à 23:49, Pascal Hambourg a écrit :
>> ~$ sudo tcptraceroute 91.216.107.158 80
>> traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte
>> packets
>>   1  router.asus.com (192.168.0.254)  0.389 ms  0.374 ms  0.827 ms
>>   2  192.168.1.1 (192.168.1.1)  1.300 ms  1.462 ms  1.528 ms
>>   3  80.10.234.173 (80.10.234.173)  2.835 ms  3.180 ms  3.570 ms
>
> Hmm, ce n'est pas de l'ADSL, n'est-ce pas ?
>
>>   4  ae102-0.ncidf203.Aubervilliers.francetelecom.net
>> (193.253.81.66)  2.762 ms  2.821 ms  2.895 ms
>>   5  ae43-0.nridf201.Aubervilliers.francetelecom.net
>> (193.252.98.145)  3.029 ms  3.161 ms  3.237 ms
>>   6  ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234)  3.536
>> ms  2.534 ms  2.623 ms
>>   7  193.253.13.206 (193.253.13.206)  2.769 ms  1.955 ms  1.924 ms
>>   8  ielo.th2-2.rt.hopus.net (37.77.34.5)  2.136 ms  2.227 ms  1.671 ms
>>   9  adista.customers-th2.ielo.net (212.85.149.54)  3.098 ms  3.117
>> ms  5.601 ms
>> 10  212.51.160.215 (212.51.160.215)  6.829 ms  6.907 ms  7.045 ms
>> 11  212.51.160.215 (212.51.160.215)  6.187 ms  6.270 ms  6.278 ms
>> 12  37.18.166.141 (37.18.166.141)  6.764 ms  6.609 ms  6.590 ms
>> 13  91.216.107.158 (91.216.107.158)   7.074 ms  6.882 ms 
>> 6.695 ms
>
> Merci à tous les deux pour vos tests.
> Apparemment il n'y a pas de problème de connectivité entre Orange et
> l'hébergeur. Donc a priori soit il y a un blocage au niveau du
> réseau/box de G2PC, soit il y a un filtrage spécifique de son adresse
> IP publique quelque part en chemin.
Ce qui ne m'étonne pas, une idée pour démontrer ce filtrage volontaire
de mes données ?

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 08/08/2017 à 01:26, Francois Lafont a écrit :

On 08/07/2017 11:49 PM, Pascal Hambourg wrote:


~$ sudo tcptraceroute 91.216.107.158 80
traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte packets
   1  router.asus.com (192.168.0.254)  0.389 ms  0.374 ms  0.827 ms
   2  192.168.1.1 (192.168.1.1)  1.300 ms  1.462 ms  1.528 ms
   3  80.10.234.173 (80.10.234.173)  2.835 ms  3.180 ms  3.570 ms


Hmm, ce n'est pas de l'ADSL, n'est-ce pas ?


En effet, je ne sais pas à quoi tu vois cela mais oui moi j'ai la
fibre monsieur. :)


A la latence entre la box et le réseau du FAI, qui se compte en dizaines 
de millisecondes avec l'ADSL.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Francois Lafont]

On 08/07/2017 11:49 PM, Pascal Hambourg wrote:

>> ~$ sudo tcptraceroute 91.216.107.158 80
>> traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte packets
>>   1  router.asus.com (192.168.0.254)  0.389 ms  0.374 ms  0.827 ms
>>   2  192.168.1.1 (192.168.1.1)  1.300 ms  1.462 ms  1.528 ms
>>   3  80.10.234.173 (80.10.234.173)  2.835 ms  3.180 ms  3.570 ms
> 
> Hmm, ce n'est pas de l'ADSL, n'est-ce pas ?

En effet, je ne sais pas à quoi tu vois cela mais oui moi j'ai la
fibre monsieur. :)

-- 
François Lafont

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 07/08/2017 à 07:56, Francois Lafont a écrit :


~$ sudo tcptraceroute 91.216.107.158 80
traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte packets
  1  router.asus.com (192.168.0.254)  0.389 ms  0.374 ms  0.827 ms
  2  192.168.1.1 (192.168.1.1)  1.300 ms  1.462 ms  1.528 ms
  3  80.10.234.173 (80.10.234.173)  2.835 ms  3.180 ms  3.570 ms


Hmm, ce n'est pas de l'ADSL, n'est-ce pas ?


  4  ae102-0.ncidf203.Aubervilliers.francetelecom.net (193.253.81.66)  2.762 ms 
 2.821 ms  2.895 ms
  5  ae43-0.nridf201.Aubervilliers.francetelecom.net (193.252.98.145)  3.029 ms 
 3.161 ms  3.237 ms
  6  ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234)  3.536 ms  2.534 
ms  2.623 ms
  7  193.253.13.206 (193.253.13.206)  2.769 ms  1.955 ms  1.924 ms
  8  ielo.th2-2.rt.hopus.net (37.77.34.5)  2.136 ms  2.227 ms  1.671 ms
  9  adista.customers-th2.ielo.net (212.85.149.54)  3.098 ms  3.117 ms  5.601 ms
10  212.51.160.215 (212.51.160.215)  6.829 ms  6.907 ms  7.045 ms
11  212.51.160.215 (212.51.160.215)  6.187 ms  6.270 ms  6.278 ms
12  37.18.166.141 (37.18.166.141)  6.764 ms  6.609 ms  6.590 ms
13  91.216.107.158 (91.216.107.158)   7.074 ms  6.882 ms  6.695 ms


Merci à tous les deux pour vos tests.
Apparemment il n'y a pas de problème de connectivité entre Orange et 
l'hébergeur. Donc a priori soit il y a un blocage au niveau du 
réseau/box de G2PC, soit il y a un filtrage spécifique de son adresse IP 
publique quelque part en chemin.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[MALGORNdg]

Bonjour,

On 08/07/2017 07:23 AM, Pascal Hambourg wrote:

> Il faudrait que d'autres abonnés d'Orange Livebox fassent le test pour savoir 
> si ça vient de ta box ou plus loin.  

En espérant que  çela pourra aider; Je suis chez Orange avec une
Livebox.

Voici les résultats que j'obtiens ( avec ma propre IP en premier ):


daniel@DAN-RE:~$ sudo tcptraceroute 192.168.1.11
Selected device lo, address 192.168.1.11, port 40707 for outgoing packets
Tracing the path to 192.168.1.11 on TCP port 80 (http), 30 hops max
 1  192.168.1.11 [open]  0.183 ms  0.142 ms  0.115 ms

daniel@DAN-RE:~$ sudo tcptraceroute 91.216.107.158 80
Selected device wlan0, address 192.168.1.11, port 34221 for outgoing packets
Tracing the path to 91.216.107.158 on TCP port 80 (http), 30 hops max
 1  192.168.1.1  4.321 ms  1.759 ms  1.784 ms
 2  80.10.123.32  13.514 ms  14.480 ms  13.387 ms
 3  10.125.221.74  14.629 ms  13.680 ms  13.951 ms
 4  ae54-0.ncidf206.Paris.francetelecom.net (81.253.131.66)  194.893 ms  
195.745 ms  194.708 ms
 5  ae46-0.nridf202.Paris.francetelecom.net (193.252.98.173)  195.584 ms  
196.846 ms  196.856 ms
 6  ae43-0.noidf002.Aubervilliers.francetelecom.net (193.252.98.238)  198.375 
ms  196.932 ms  197.522 ms
 7  193.253.13.202  197.363 ms  195.728 ms  196.686 ms
 8  ielo.std-1.rt.hopus.net (37.77.38.13)  197.533 ms  197.626 ms  197.706 ms
 9  te-0-0-frpar-th2-a9k1.rt.ielo.net (212.85.145.138)  197.521 ms  198.039 ms  
197.708 ms
10  adista.customers-th2.ielo.net (212.85.149.54)  198.490 ms  197.786 ms  
205.890 ms
11  212.51.160.215  202.748 ms  200.108 ms  202.547 ms
12  212.51.160.215  202.277 ms  202.897 ms  201.090 ms
13  37.18.166.141  201.957 ms  202.060 ms  201.617 ms
14  91.216.107.158 [open]  201.199 ms  202.003 ms  202.571 ms


Bien à vous.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Francois Lafont]

Bonjour,

On 08/07/2017 07:23 AM, Pascal Hambourg wrote:

> Il faudrait que d'autres abonnés d'Orange Livebox fassent le test pour savoir 
> si ça vient de ta box ou plus loin.
Je ne sais pas si ça pourra aider mais je suis chez Orange avec une Livebox 
même si j'utilise un LAN « dans » le LAN Orange [*] (mais je pense que ça ne 
devrait rien changer). Si jamais ça peut aider, j'ai ça :

~$ sudo tcptraceroute 91.216.107.158 80 
traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte packets
 1  router.asus.com (192.168.0.254)  0.389 ms  0.374 ms  0.827 ms
 2  192.168.1.1 (192.168.1.1)  1.300 ms  1.462 ms  1.528 ms
 3  80.10.234.173 (80.10.234.173)  2.835 ms  3.180 ms  3.570 ms
 4  ae102-0.ncidf203.Aubervilliers.francetelecom.net (193.253.81.66)  2.762 ms  
2.821 ms  2.895 ms
 5  ae43-0.nridf201.Aubervilliers.francetelecom.net (193.252.98.145)  3.029 ms  
3.161 ms  3.237 ms
 6  ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234)  3.536 ms  2.534 
ms  2.623 ms
 7  193.253.13.206 (193.253.13.206)  2.769 ms  1.955 ms  1.924 ms
 8  ielo.th2-2.rt.hopus.net (37.77.34.5)  2.136 ms  2.227 ms  1.671 ms
 9  adista.customers-th2.ielo.net (212.85.149.54)  3.098 ms  3.117 ms  5.601 ms
10  212.51.160.215 (212.51.160.215)  6.829 ms  6.907 ms  7.045 ms
11  212.51.160.215 (212.51.160.215)  6.187 ms  6.270 ms  6.278 ms
12  37.18.166.141 (37.18.166.141)  6.764 ms  6.609 ms  6.590 ms
13  91.216.107.158 (91.216.107.158)   7.074 ms  6.882 ms  6.695 ms

Note [*] : je voulais utiliser un router un peu plus configuration que cette 
merde de livebox alors j'ai un LAN avec un router Asus relié au LAN de la 
livebox avec du double NAT entre mon router Asus et la livebox. Le coup du 
double NAT c'est vraiment moche mais j'ai jamais pu trouver comment mettre une 
route statique sur une livebox et j'ai bien l'impression que c'est pas possible 
en fait.

-- 
François Lafont

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 06/08/2017 à 23:57, G2PC a écrit :



sudo tcptraceroute 91.216.107.158 80
traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte
packets
   1  192.168.1.1 (192.168.1.1)  14.199 ms  17.828 ms  17.804 ms


Je n'avais pas fait attention, mais 15 ms pour recevoir une réponse de 
la box, c'est énorme même en wifi. Est-ce que la box a été redémarrée 
depuis que le problème est apparu ?



Dans le cas d'un blocage avant la box orange, on l'aurait vu ? Filtre
parental ou autre routeur ?


En tout cas pas de blocage en sortie. Mais techniquement on ne peut pas 
exclure un blocage en entrée de ta box des paquets de réponse en 
provenance de ce serveur.



Ce serrait donc entre orange et LWS ?


Il faudrait que d'autres abonnés d'Orange Livebox fassent le test pour 
savoir si ça vient de ta box ou plus loin.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[G2PC]

Le 06/08/2017 à 23:12, Pascal Hambourg a écrit :
> Le 06/08/2017 à 22:27, G2PC a écrit :
>>
>> J'utilise, je pense, network-manager, en mode graphique, qui me
>> retourne,
>> broadcast : 192.168.1.255
>> masque de sous réseau 255.255.255.0
>> route par défaut 192.168.1.1
>> primary DNS 127.0.0.1
>>
>> cat /etc/resolv.conf
>> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by
>> resolvconf(8)
>> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
>> nameserver 127.0.2.1
>
> Ce n'est pas l'adresse de DNS retournée par NetworkManager. Peut-être
> forcée par resolvconf.
> Mais dans les deux cas, il s'agit de la machine elle-même, donc un
> serveur DNS local qui tourne sur la machine.
>> Yes, unbound a été installé.
>
>> search 208.67.222.222 208.67.220.220
>
> Cette ligne est aberrante. On ne met pas des adresses IP dans l'option
> search mais des domaines. Cf. man resolv.conf.
>> Ok pour l’aberration , il me faut voir comment la modifier, car,
resolv.conf est généré ( peut être par dhcp, ou, resolvconf )
>
>> A moins que je dois en fait configurer le programme resolvconf, que j'ai
>> découvert hier, mais, je ne l'ai pas utilisé, de moi même, hors, je lis
>> maintenant, juste plus haut, cette ligne : # Dynamic resolv.conf(5) file
>> for glibc resolver(3) generated by resolvconf(8) mais, cela n'explique
>> pas mes difficultés, il me semble. Quoi que, je ne sais pas qui est
>> 127.0.2.1 (?)
>
> C'est la machine elle-même, comme toutes les adresses IP qui
> commencent par 127.
>> Oui, je voulais dire, pour la fin de l'ip, 2.1 , je ne sais pas qui
la crée et l'utilise.
>
>> ip route
>> default via 192.168.1.1 dev wlp60s0  proto static  metric 600
>> 169.254.0.0/16 dev wlp60s0  scope link  metric 1000
>> 192.168.1.0/24 dev wlp60s0  proto kernel  scope link  src 192.168.1.15
>> metric 600
>
> RAS.
>
>> iptables-save
>> pas de retour.
>
> Donc pas de règles iptables qui pourraient bloquer des paquets.
>
>> dig www.visionduweb.eu.
>> ; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.visionduweb.eu.
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32603
>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>>
>> ;; OPT PSEUDOSECTION:
>> ; EDNS: version: 0, flags:; udp: 4096
>> ;; QUESTION SECTION:
>> ;www.visionduweb.eu.INA
>>
>> ;; ANSWER SECTION:
>> www.visionduweb.eu.4767IN    CNAMEvisionduweb.eu.
>> visionduweb.eu.4767INA91.216.107.158
>>
>> ;; Query time: 59 msec
>> ;; SERVER: 127.0.2.1#53(127.0.2.1)
>> ;; WHEN: Sun Aug 06 22:16:54 CEST 2017
>> ;; MSG SIZE  rcvd: 77
>
> Quel que soit le serveur DNS local qui tourne sur la machine, il fait
> son boulot et donne la réponse. Pas de problème de résolution DNS donc.
>
>> dig www.visionduweb.eu. @8.8.8.8
>
> Sans intérêt, c'était au cas où la commande précédente échouerait.
>
>> sudo tcptraceroute 91.216.107.158 80
>> traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte
>> packets
>>   1  192.168.1.1 (192.168.1.1)  14.199 ms  17.828 ms  17.804 ms
>>   2  80.10.115.251 (80.10.115.251)  48.646 ms  51.679 ms  54.955 ms
>>   3  10.123.205.86 (10.123.205.86)  57.371 ms 10.123.205.82
>> (10.123.205.82)  60.028 ms  63.286 ms
>>   4  ae43-0.nridf201.Aubervilliers.francetelecom.net (193.252.98.145)
>> 65.505 ms ae43-0.nridf202.Paris.francetelecom.net (193.252.98.150)
>> 68.439 ms ae43-0.nridf201.Aubervilliers.francetelecom.net
>> (193.252.98.145)  83.064 ms
>>   5  ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234)  85.892 ms
>> ae43-0.noidf002.Aubervilliers.francetelecom.net (193.252.98.238)  86.228
>> ms  86.450 ms
>>   6  193.253.13.202 (193.253.13.202)  86.726 ms 193.253.13.206
>> (193.253.13.206)  33.463 ms 193.253.13.202 (193.253.13.202)  40.527 ms
>>   7  ielo.std-1.rt.hopus.net (37.77.38.13)  41.441 ms
>> ielo.th2-2.rt.hopus.net (37.77.34.5)  49.579 ms ielo.std-1.rt.hopus.net
>> (37.77.38.13)  51.357 ms
>>   8  te-0-0-frpar-th2-a9k1.rt.ielo.net (212.85.145.138)  54.410 ms * *
>>   9  * * *
>> 10  * * *
>> 11  * * *
>> ...
>> 28  * * *
>> 29  * * *
>> 30  * * *
>
> Pas de problème de routage en sortie de ta box. Par contre ça coince
> plus loin en chemin. Ton adresse IP publique est peut-être filtrée, ou
> il y a un problème de routage aller ou retour (impossible de savoir)
> entre Orange et LWS. J'ai fait le tcptraceroute 

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 06/08/2017 à 22:27, G2PC a écrit :


J'utilise, je pense, network-manager, en mode graphique, qui me retourne,
broadcast : 192.168.1.255
masque de sous réseau 255.255.255.0
route par défaut 192.168.1.1
primary DNS 127.0.0.1

cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.2.1


Ce n'est pas l'adresse de DNS retournée par NetworkManager. Peut-être 
forcée par resolvconf.
Mais dans les deux cas, il s'agit de la machine elle-même, donc un 
serveur DNS local qui tourne sur la machine.



search 208.67.222.222 208.67.220.220


Cette ligne est aberrante. On ne met pas des adresses IP dans l'option 
search mais des domaines. Cf. man resolv.conf.



A moins que je dois en fait configurer le programme resolvconf, que j'ai
découvert hier, mais, je ne l'ai pas utilisé, de moi même, hors, je lis
maintenant, juste plus haut, cette ligne : # Dynamic resolv.conf(5) file
for glibc resolver(3) generated by resolvconf(8) mais, cela n'explique
pas mes difficultés, il me semble. Quoi que, je ne sais pas qui est
127.0.2.1 (?)


C'est la machine elle-même, comme toutes les adresses IP qui commencent 
par 127.



ip route
default via 192.168.1.1 dev wlp60s0  proto static  metric 600
169.254.0.0/16 dev wlp60s0  scope link  metric 1000
192.168.1.0/24 dev wlp60s0  proto kernel  scope link  src 192.168.1.15
metric 600


RAS.


iptables-save
pas de retour.


Donc pas de règles iptables qui pourraient bloquer des paquets.


dig www.visionduweb.eu.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.visionduweb.eu.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32603
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.visionduweb.eu.INA

;; ANSWER SECTION:
www.visionduweb.eu.4767INCNAMEvisionduweb.eu.
visionduweb.eu.4767INA91.216.107.158

;; Query time: 59 msec
;; SERVER: 127.0.2.1#53(127.0.2.1)
;; WHEN: Sun Aug 06 22:16:54 CEST 2017
;; MSG SIZE  rcvd: 77


Quel que soit le serveur DNS local qui tourne sur la machine, il fait 
son boulot et donne la réponse. Pas de problème de résolution DNS donc.



dig www.visionduweb.eu. @8.8.8.8


Sans intérêt, c'était au cas où la commande précédente échouerait.


sudo tcptraceroute 91.216.107.158 80
traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte packets
  1  192.168.1.1 (192.168.1.1)  14.199 ms  17.828 ms  17.804 ms
  2  80.10.115.251 (80.10.115.251)  48.646 ms  51.679 ms  54.955 ms
  3  10.123.205.86 (10.123.205.86)  57.371 ms 10.123.205.82
(10.123.205.82)  60.028 ms  63.286 ms
  4  ae43-0.nridf201.Aubervilliers.francetelecom.net (193.252.98.145)
65.505 ms ae43-0.nridf202.Paris.francetelecom.net (193.252.98.150)
68.439 ms ae43-0.nridf201.Aubervilliers.francetelecom.net
(193.252.98.145)  83.064 ms
  5  ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234)  85.892 ms
ae43-0.noidf002.Aubervilliers.francetelecom.net (193.252.98.238)  86.228
ms  86.450 ms
  6  193.253.13.202 (193.253.13.202)  86.726 ms 193.253.13.206
(193.253.13.206)  33.463 ms 193.253.13.202 (193.253.13.202)  40.527 ms
  7  ielo.std-1.rt.hopus.net (37.77.38.13)  41.441 ms
ielo.th2-2.rt.hopus.net (37.77.34.5)  49.579 ms ielo.std-1.rt.hopus.net
(37.77.38.13)  51.357 ms
  8  te-0-0-frpar-th2-a9k1.rt.ielo.net (212.85.145.138)  54.410 ms * *
  9  * * *
10  * * *
11  * * *
...
28  * * *
29  * * *
30  * * *


Pas de problème de routage en sortie de ta box. Par contre ça coince 
plus loin en chemin. Ton adresse IP publique est peut-être filtrée, ou 
il y a un problème de routage aller ou retour (impossible de savoir) 
entre Orange et LWS. J'ai fait le tcptraceroute depuis chez moi, les 
routeurs de l'hébergeur n'aident pas, ils ne renvoient aucun message 
ICMP et je reçois juste la réponse du serveur après plusieurs sauts sans 
réponse :


11  212.51.160.215 (212.51.160.215)  56.091 ms  54.446 ms *
12  * * *
13  * * *
14  * * *
15  * * *
16  * 91.216.107.158 (91.216.107.158) <syn,ack>  54.855 ms  56.317 ms

Donc impossible de savoir si ça coince sur le serveur ou avant dans ton cas.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[G2PC]

Le 06/08/2017 à 20:04, Pascal Hambourg a écrit :
> Le 06/08/2017 à 19:31, G2PC a écrit :
>>
>> Le site, c'est visionduweb.eu hébergé chez LWS
> www.visionduweb.eu.21600INCNAMEvisionduweb.eu.
> visionduweb.eu.21600INA91.216.107.158
>
> Le site a une adresse IPv4, et pas d'adresse IPv6. Se focaliser sur
> l'IPv6 était une perte de temps.
>
> Sur la machine cliente, sans VPN, TOR ou autre :
>
> Que contient le fichier /etc/resolv.conf ?
> Qu'affichent les commandes suivantes ?
>
> ip route
> iptables-save
> dig www.visionduweb.eu.
> dig www.visionduweb.eu. @8.8.8.8
> tcptraceroute 91.216.107.158 80
>
Voilà,
J'utilise, je pense, network-manager, en mode graphique, qui me retourne,
broadcast : 192.168.1.255
masque de sous réseau 255.255.255.0
route par défaut 192.168.1.1
primary DNS 127.0.0.1


Pour /etc/resolv.conf
cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by
resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 127.0.2.1
search 208.67.222.222 208.67.220.220


A moins que je dois en fait configurer le programme resolvconf, que j'ai
découvert hier, mais, je ne l'ai pas utilisé, de moi même, hors, je lis
maintenant, juste plus haut, cette ligne : # Dynamic resolv.conf(5) file
for glibc resolver(3) generated by resolvconf(8) mais, cela n'explique
pas mes difficultés, il me semble. Quoi que, je ne sais pas qui est
127.0.2.1 (?)
Mon tutoriel actuel sur le wiki :
https://www.visionduweb.eu/wiki/index.php?title=Changer_de_DNS



ip route
default via 192.168.1.1 dev wlp60s0  proto static  metric 600
169.254.0.0/16 dev wlp60s0  scope link  metric 1000
192.168.1.0/24 dev wlp60s0  proto kernel  scope link  src 192.168.1.15 
metric 600



iptables-save
pas de retour.



dig www.visionduweb.eu.
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.visionduweb.eu.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32603
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.visionduweb.eu.INA

;; ANSWER SECTION:
www.visionduweb.eu.4767INCNAMEvisionduweb.eu.
visionduweb.eu.4767INA91.216.107.158

;; Query time: 59 msec
;; SERVER: 127.0.2.1#53(127.0.2.1)
;; WHEN: Sun Aug 06 22:16:54 CEST 2017
;; MSG SIZE  rcvd: 77



dig www.visionduweb.eu. @8.8.8.8
; <<>> DiG 9.10.3-P4-Ubuntu <<>> www.visionduweb.eu. @8.8.8.8
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17691
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.visionduweb.eu.INA

;; ANSWER SECTION:
www.visionduweb.eu.11725INCNAMEvisionduweb.eu.
visionduweb.eu.11725INA91.216.107.158

;; Query time: 55 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Sun Aug 06 22:17:23 CEST 2017
;; MSG SIZE  rcvd: 77



sudo tcptraceroute 91.216.107.158 80
traceroute to 91.216.107.158 (91.216.107.158), 30 hops max, 60 byte packets
 1  192.168.1.1 (192.168.1.1)  14.199 ms  17.828 ms  17.804 ms
 2  80.10.115.251 (80.10.115.251)  48.646 ms  51.679 ms  54.955 ms
 3  10.123.205.86 (10.123.205.86)  57.371 ms 10.123.205.82
(10.123.205.82)  60.028 ms  63.286 ms
 4  ae43-0.nridf201.Aubervilliers.francetelecom.net (193.252.98.145) 
65.505 ms ae43-0.nridf202.Paris.francetelecom.net (193.252.98.150) 
68.439 ms ae43-0.nridf201.Aubervilliers.francetelecom.net
(193.252.98.145)  83.064 ms
 5  ae43-0.noidf001.Paris.francetelecom.net (193.252.98.234)  85.892 ms
ae43-0.noidf002.Aubervilliers.francetelecom.net (193.252.98.238)  86.228
ms  86.450 ms
 6  193.253.13.202 (193.253.13.202)  86.726 ms 193.253.13.206
(193.253.13.206)  33.463 ms 193.253.13.202 (193.253.13.202)  40.527 ms
 7  ielo.std-1.rt.hopus.net (37.77.38.13)  41.441 ms
ielo.th2-2.rt.hopus.net (37.77.34.5)  49.579 ms ielo.std-1.rt.hopus.net
(37.77.38.13)  51.357 ms
 8  te-0-0-frpar-th2-a9k1.rt.ielo.net (212.85.145.138)  54.410 ms * *
 9  * * *
10  * * *
11  * * *
...
28  * * *
29  * * *
30  * * *

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 06/08/2017 à 19:31, G2PC a écrit :


Le site, c'est visionduweb.eu hébergé chez LWS

www.visionduweb.eu. 21600   IN  CNAME   visionduweb.eu.
visionduweb.eu. 21600   IN  A   91.216.107.158

Le site a une adresse IPv4, et pas d'adresse IPv6. Se focaliser sur 
l'IPv6 était une perte de temps.


Sur la machine cliente, sans VPN, TOR ou autre :

Que contient le fichier /etc/resolv.conf ?
Qu'affichent les commandes suivantes ?

ip route
iptables-save
dig www.visionduweb.eu.
dig www.visionduweb.eu. @8.8.8.8
tcptraceroute 91.216.107.158 80

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[G2PC]

Le 06/08/2017 à 18:52, Pascal Hambourg a écrit :
> Le 06/08/2017 à 18:05, G2PC a écrit :
>> Le 05/08/2017 à 02:12, Pascal Hambourg a écrit :
>>>
>>> D'après les tests ci-dessous, tu n'as pas de connectivité IPv6 globale.
>>> Mais je ne vois pas le rapport avec ton site. Il n'est accessible
>>> qu'en IPv6 ?
>>>
>> Je pense être victime de stress test / stress tue.
>> Filtré volontairement sur la box, ou, via routeur ?
>> Le site étant accessible mondialement, je ne vois pas d'autres
>> explications.
>> Aucune idée pour contourner ? Hormis utiliser un vpn, ce qui me ralentit
>> et m'use ma santé du fait des ralentissements.
>
> Et à part ça, pas de réponse à ma question ?
> Tu pourrais donner le nom du site, ça aiderait déjà à y voir plus clair.
>
Je ne sais pas si le site n'est accessible que en IPv6 mais je ne pense pas.
Ce problème est survenu en fin de journée, il y a 10 / 15 jours, mon
système fonctionnait parfaitement pendant des semaines durant, avant cela.
Le site, c'est visionduweb.eu hébergé chez LWS qui me dit que le
problème viendrait de mon réseau.
J'ai accès à la totalité du web, hormis mon site.
Ca me fait pensé clairement à une panne volontaire, de la malveillance,
n'ayant changé aucune configuration de mon côté.
J'ai aussi vérifié mes options de sécurité, et, mon ip n'est pas
répertoriée, ni dans iptables, ni au niveau du site.
C'est une manipulation humaine et volontaire, qui me met dans le mur,
j'en suis persuadé.

Re: ipv6 - nom de domaine sur site mutualisé inaccessible - comment contourner avec linux unbound - google dns - opendns - configuration

[Pascal Hambourg]

Le 06/08/2017 à 18:05, G2PC a écrit :

Le 05/08/2017 à 02:12, Pascal Hambourg a écrit :


D'après les tests ci-dessous, tu n'as pas de connectivité IPv6 globale.
Mais je ne vois pas le rapport avec ton site. Il n'est accessible
qu'en IPv6 ?


Je pense être victime de stress test / stress tue.
Filtré volontairement sur la box, ou, via routeur ?
Le site étant accessible mondialement, je ne vois pas d'autres explications.
Aucune idée pour contourner ? Hormis utiliser un vpn, ce qui me ralentit
et m'use ma santé du fait des ralentissements.


Et à part ça, pas de réponse à ma question ?
Tu pourrais donner le nom du site, ça aiderait déjà à y voir plus clair.