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.

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

[G2PC]

Le 05/08/2017 à 02:12, Pascal Hambourg a écrit :
> Le 04/08/2017 à 15:32, G2PC a écrit :
>> Box orange du domicile. Pas d'accès vers mon site internet hébergé chez
>> LWS, le site est sur mutualisé, ce n'est pas un vps ni un dédié.
>> Sinon, j'ai bien un accès total au réseau internet.
>
> 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.

Re: cannot get node dns program to work externally

[Lck Ras]

On 08/06/2017 10:42 AM, Aaron Gray 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.

Check if it's listening on localhost. Make sure that the server is not
listening on 127.0.0.1 'ss -unl'. Otherwise, you need to do a bit of
forwarding magic, but listening on the proper interface is a cleaner
solution, I believe.

> I have mainly been using :-
> 
> https://github.com/tjfontaine/node-dns/blob/master/examples/forwarder.js

>From what I can see from the code you linked, 127.0.0.1 is hardcoded.
Make sure you change that.

cannot get node dns program to work externally

[Aaron Gray]

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

[Pascal Hambourg]

Le 04/08/2017 à 15:32, G2PC a écrit :

Box orange du domicile. Pas d'accès vers mon site internet hébergé chez
LWS, le site est sur mutualisé, ce n'est pas un vps ni un dédié.
Sinon, j'ai bien un accès total au réseau internet.


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 ?

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

[G2PC]

Box orange du domicile. Pas d'accès vers mon site internet hébergé chez
LWS, le site est sur mutualisé, ce n'est pas un vps ni un dédié.
Sinon, j'ai bien un accès total au réseau internet.

( noter que je n'ai ni accès sous linux, ni windows, ni le téléphone,
cela uniquement depuis le domicile, depuis 10 jours. )

Si j'utilise un vpn ou tor, j'ai accès à mon site, depuis mon hôte Linux.
J'ai installé unbound.

J'ai supprimé cette config présentée ci-dessous, pour en revenir à
l'état initial : Pas d'accès à mon site. Utilisation d'un VPN pour avoir
accès.
Si je configure ipv6 dans sudo vi /etc/dhcp/dhclient.conf avec la
configuration ci-dessous je perd à nouveau l'accès à mon site
,exclusivement, malgré l'utilisation du VPN ! à ce moment la.


# Remplacer ou ajouter la ligne suivante :
# Pour IPv4
prepend domain-name-servers 8.8.8.8, 8.8.4.4;
# Pour IPv6
prepend domain-name-servers 2001:4860:4860::, 2001:4860:4860::8844;
# Pour IPv6 uniquement, vous pouvez utiliser Google Public DNS64 au
lieu  des adresses IPv6 ci-dessus.


##


Lws me dit que ça ne vient pas de chez eux pourtant, j'ai un message
d'erreur quand je test les DNS de mon domaine :

 Missing nameservers reported by your nameservers ERROR: One or more of
the nameservers listed at the parent servers are not listed as NS
records at your nameservers. The problem NS records are:
ns3.lwsdns.com
ns4.lwsdns.com
This is listed as an ERROR because there are some cases where nasty
problems can occur (if the TTLs vary from the NS records at the root
servers and the NS records point to your own domain, for example).


#


Les commandes suivantes ont été lancées avec le fichier de configuration
présenté ci-dessus.


sudo traceroute -n -w 2 -q 2 -m 30 2001:4860:4860::
traceroute to 2001:4860:4860:: (2001:4860:4860::), 30 hops max,
80 byte packets
connect: Le réseau n'est pas accessible
zsh: exit 1 sudo traceroute -n -w 2 -q 2 -m 30 2001:4860:4860::



dig @2001:4860:4860:: www.visionduweb.eu. 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @2001:4860:4860::
www.visionduweb.eu. 
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
zsh: exit 9 dig @2001:4860:4860:: www.visionduweb.eu. 


dig @2001:4860:4860:: ipv6.google.com. 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @2001:4860:4860:: ipv6.google.com. 
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
zsh: exit 9 dig @2001:4860:4860:: ipv6.google.com. 



dig @2001:4860:4860:: www.visionduweb.eu.  +cd

; <<>> DiG 9.10.3-P4-Ubuntu <<>> @2001:4860:4860::
www.visionduweb.eu.  +cd
; (1 server found)
;; global options: +cmd
;; connection timed out; no servers could be reached
zsh: exit 9 dig @2001:4860:4860:: www.visionduweb.eu.  +cd



dig @localhost www.visionduweb.eu
; (2 servers found)
;; global options: +cmd
;; connection timed out; no servers could be reached
zsh: exit 9 dig @localhost Alienware-17-R3


#######


Je lis ses quelques pistes :
1. Your ISP limits the use of DNS, in particular when DNSSEC is involved, or
2. The Google DNS resolvers doesn't support DNSSEC.
3. Check if DNS service is up and running on the nameserver ? ( Je crois
que non. )


###


Verify that another open resolver can resolve the selected hostname :
dig www.example.com. @4.2.2.1
dig www.example.com. @4.2.2.2
dig www.example.com. @208.67.222.222
dig www.example.com. @208.67.220.220

Ok pour les 4. J'ai un retour fonctionnel.



Je ne vois pas quoi faire pour le moment, d'ou peut venir le problème,
par ou poursuivre l'investigation ?

Re: DHCP isn't updating DNS

[Joshua Schaeffer]

> You should consider moving towards "standard", but "interim"'s not a
> problem for now.
> https://deepthought.isc.org/article/AA-01091/0/ISC-DHCP-support-for-Standard-DDNS.html

I've actually made a few changes since I've posted this in trying to figure 
this out and I did change to standard. This appears to have not made any 
difference. DNS is still not getting updated, but I will definitely keep the 
setting at standard.
>
>>   allowclient-updates;
>
> I would recommend denying client-updates. This tells clients that they
> can do the DNS update themselves. Given that you're trying TSIGs below,
> that would mean deploying keys to all the clients etc etc. Better to
> "deny client-updates" and centralise the work through the DHCP server.

This was also a change I made. I definitely do not want (and do not allow) 
clients to update DNS, so I changed this to deny.
>
>
> Some other options I have are "update-static-leases on" (Make sure DNS
> is updated even for hosts with a static address) "update-optimization
> on" (Actually, for debugging purposes, I had that off for a while. If
> it's off the DNS will be updated every time. If it's on, then the DNS
> won't be updated if the lease hasn't changed. If you're changing from
> 'interim' to 'standard' you definitely want this off to ensure the
> records get changed).
I saw these as well when I reread through the dhcpd.conf man page, but haven't 
tried them yet. I'll give that a go.

>
> I'm assuming you've cut something out of your config here, but given the
> config above, there's nothing that applies the DDNS settings to hosts.
> The ddns-* settings should apply to everything in their current scope
> and below (so, if you've put them in your subnet6 block, for example,
> that should be fine).

Yes I didn't include my entire conf file as it is a little long. Here is my 
subnet6 declaration that I've been focusing on:

subnet6 2620:5:e000:201e::/64 {
default-lease-time2419200;
max-lease-time2419200;

# LDAP Servers.
pool6 {
allow members of "ldap_servers";
range6 2620:5:e000:201e:0:1::/96;
}
# Kerberos Servers.
pool6 {
allow members of "krb5_servers";
range6 2620:5:e000:201e:0:2::/96;
}
# DHCP Servers.
pool6 {
allow members of "dhcp_servers";
range6 2620:5:e000:201e:0:3::/96;
    }
# Puppet Servers.
pool6 {
allow members of "puppet_servers";
range6 2620:5:e000:201e:0:4::/96;
}
# DNS Servers.
pool6 {
allow members of "dns_servers";
range6 2620:5:e000:201e:0:5::/96;
}
# Catch-all DHCP group.
pool6 {
range6 2620:5:e000:201e:0:d::/96;
}
}

In particular I've been testing with a client that gets added to the 
"dhcp_servers" class. I know the classification works as the client actually 
gets an IP address in the the range specified, I just can't get DHCP to update 
the DNS servers with the  and PTR records. Since all my subnet's use the 
same ddns-* settings I don't specify this at the subnet or pool level, I just 
leave it in the top scope.

Thanks for your response,
Joshua Schaeffer

Re: DHCP isn't updating DNS

[Darac Marjal]

On Tue, Jul 25, 2017 at 10:43:45AM -0600, Joshua Schaeffer wrote:

  I'm having trouble getting my DHCPv6 server to update DNS and I'm not
  sure what I'm missing. From what I can tell I have everything setup
  and have tried numerous changes to the config file without success.
  Here is my named.conf.local file. I've tried allowing updates with
  both the update-policy and allow-update commands as well as through a
  key and just by IP address, but as far as I can tell the DHCP server
  isn't even attempting to communicate with the DNS server:

      root@blldns01:~# cat /etc/bind/named.conf.local
      //
      // Do any local configuration here
      //

      // Consider adding the 1918 zones here, if they are not used in
  your
      // organization
      include "/etc/bind/zones.rfc1918";
      include "/etc/bind/Kddns--rrs.+157+1.private";
      include "/etc/bind/Kddns-ptr-rrs.+157+1.private";

      key DHCP_UPDATER {
          algorithm HMAC-MD5.SIG-ALG.REG.INT;
          secret "==";
      };

      zone "appendata.net" in {
          type master;
          notify yes;
          file "/var/lib/bind/db.appendata.net";
          allow-update { 2620:5:e000:201e::4:1; };
      #    allow-update { key DHCP_UPDATER; };
      #    update-policy {
      #        grant "ddns--rrs" self *  TXT DHCID;
      #    };
      };

      zone "0.0.0.e.5.0.0.0.0.2.6.2.IP6.ARPA" in {
          type master;
          notify yes;
          file "/var/lib/bind/db.2620.5.e000";
          allow-update { 2620:5:e000:201e::4:1; };
      #    allow-update { key DHCP_UPDATER; };
      #    update-policy {
      #        grant "ddns-ptr-rrs" self * PTR TXT DHCID;
      #    };
      };

  In my dhcpd6.conf file I have my zones specified and have tried
  including the key file, declaring the key directly in the file, and
  simply not using the keys and just using IP based authentication.
  None of it has worked so far. I've also tried using primary and
  primary6 with the actual IP address in my zone declarations, but this
  hasn't made any difference:

      #
      # DDNS SETTINGS #
      #
      # The ddns-updates-style parameter controls whether or not the
  server will
      # attempt to do a DNS update when a lease is confirmed. We
  default to the
      # behavior of the version 2 packages ('none', since DHCP v2
  didn't
      # have support for DDNS.)
      ddns-updates        on;
      ddns-update-style    interim;


You should consider moving towards "standard", but "interim"'s not a
problem for now.
https://deepthought.isc.org/article/AA-01091/0/ISC-DHCP-support-for-Standard-DDNS.html


      allow            client-updates;


I would recommend denying client-updates. This tells clients that they
can do the DNS update themselves. Given that you're trying TSIGs below,
that would mean deploying keys to all the clients etc etc. Better to
"deny client-updates" and centralise the work through the DHCP server.


      ddns-domainname        "appendata.net.";
      ddns-rev-domainname    "ip6.arpa.";
      do-forward-updates    on;


Some other options I have are "update-static-leases on" (Make sure DNS
is updated even for hosts with a static address) "update-optimization
on" (Actually, for debugging purposes, I had that off for a while. If
it's off the DNS will be updated every time. If it's on, then the DNS
won't be updated if the lease hasn't changed. If you're changing from
'interim' to 'standard' you definitely want this off to ensure the
records get changed).



      # Include keys used to securely communicate with the DNS server.
      include            "/etc/keys/Kddns--rrs.+157+1.private";
      include            "/etc/keys/Kddns-ptr-rrs.+157+1.private";

      key DHCP_UPDATER {
          algorithm    HMAC-MD5.SIG-ALG.REG.INT;
          secret        "XXX==";
      };

      # Configuring zones for ddns-updates.
      zone appendata.net. {
          primary    ns1-int.appendata.net;
      #    primary6    2620:5:e000::a1;
      #    key    DHCP_UPDATER;            #  DNS key for RR's.
      }
      zone 0.0.0.e.5.0.0.0.0.2.6.2.ip6.arpa. {
          primary    ns1-int.appendata.net;
      #    primary6    2620:5:e000::a1;
      #    key    DHCP_UPDATER;            # PTR DNS key for RR's.
      }


I'm assuming you've cut something out of your config here, but given the
config above, there's nothing that applies the DDNS settings to hosts.
The ddns-* settings should apply to everything in their current scope
and below (so, if you've put them in your subnet6 block, for example,
that should be fine).



  I've tried putting various options and declarations in different
  scopes, but none of it has worked. The DHC

DHCP isn't updating DNS

[Joshua Schaeffer]

I'm having trouble getting my DHCPv6 server to update DNS and I'm not sure what 
I'm missing. From what I can tell I have everything setup and have tried 
numerous changes to the config file without success. Here is my 
named.conf.local file. I've tried allowing updates with both the update-policy 
and allow-update commands as well as through a key and just by IP address, but 
as far as I can tell the DHCP server isn't even attempting to communicate with 
the DNS server:

root@blldns01:~# cat /etc/bind/named.conf.local
//
// Do any local configuration here
//

// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";
include "/etc/bind/Kddns--rrs.+157+1.private";
include "/etc/bind/Kddns-ptr-rrs.+157+1.private";

key DHCP_UPDATER {
algorithm HMAC-MD5.SIG-ALG.REG.INT;
secret "==";
};

zone "appendata.net" in {
type master;
notify yes;
file "/var/lib/bind/db.appendata.net";
allow-update { 2620:5:e000:201e::4:1; };
#allow-update { key DHCP_UPDATER; };
#update-policy {
#grant "ddns--rrs" self *  TXT DHCID;
#};
};

zone "0.0.0.e.5.0.0.0.0.2.6.2.IP6.ARPA" in {
type master;
notify yes;
file "/var/lib/bind/db.2620.5.e000";
allow-update { 2620:5:e000:201e::4:1; };
#allow-update { key DHCP_UPDATER; };
#update-policy {
#grant "ddns-ptr-rrs" self * PTR TXT DHCID;
#};
};

In my dhcpd6.conf file I have my zones specified and have tried including the 
key file, declaring the key directly in the file, and simply not using the keys 
and just using IP based authentication. None of it has worked so far. I've also 
tried using primary and primary6 with the actual IP address in my zone 
declarations, but this hasn't made any difference:

#
# DDNS SETTINGS #
#
    # The ddns-updates-style parameter controls whether or not the server will
# attempt to do a DNS update when a lease is confirmed. We default to the
# behavior of the version 2 packages ('none', since DHCP v2 didn't
# have support for DDNS.)
ddns-updateson;
ddns-update-styleinterim;
allowclient-updates;
ddns-domainname"appendata.net.";
ddns-rev-domainname"ip6.arpa.";
do-forward-updateson;

# Include keys used to securely communicate with the DNS server.
include"/etc/keys/Kddns--rrs.+157+1.private";
include"/etc/keys/Kddns-ptr-rrs.+157+1.private";

key DHCP_UPDATER {
algorithmHMAC-MD5.SIG-ALG.REG.INT;
secret"XXX==";
};

# Configuring zones for ddns-updates.
zone appendata.net. {
primaryns1-int.appendata.net;
#primary62620:5:e000::a1;
#keyDHCP_UPDATER;#  DNS key for RR's.
}
zone 0.0.0.e.5.0.0.0.0.2.6.2.ip6.arpa. {
primaryns1-int.appendata.net;
#primary62620:5:e000::a1;
#keyDHCP_UPDATER;# PTR DNS key for RR's.
}

I've tried putting various options and declarations in different scopes, but 
none of it has worked. The DHCP server gives out an IP address just fine, but 
it doesn't look like it is even trying to update the  and PTR records.

Jul 25 10:22:56 blldhcp01 dhcpd[1489]: Solicit message from 
fe80::216:3eff:fe32:2d49 port 546, transaction ID 0x9D08B00
Jul 25 10:22:56 blldhcp01 dhcpd[1489]: Picking pool address 
2620:5:e000:201e:0:1:b41e:f2fe
Jul 25 10:22:56 blldhcp01 dhcpd[1489]: Advertise NA: address 
2620:5:e000:201e:0:1:b41e:f2fe to client with duid 
00:01:00:01:21:0a:2b:43:00:16:3e:32:2d:49 iaid = 1043475785 valid for 2419200 
seconds
Jul 25 10:22:56 blldhcp01 dhcpd[1489]: Sending Advertise to 
fe80::216:3eff:fe32:2d49 port 546
Jul 25 10:22:57 blldhcp01 dhcpd[1489]: Request message from 
fe80::216:3eff:fe32:2d49 port 546, transaction ID 0x6C757900
Jul 25 10:22:57 blldhcp01 dhcpd[1489]: Reply NA: address 
2620:5:e000:201e:0:1:b41e:f2fe to client with duid 
00:01:00:01:21:0a:2b:43:00:16:3e:32:2d:49 iaid = 1043475785 valid for 2419200 
seconds
Jul 25 10:22:57 blldhcp01 dhcpd[1489]: Sending Reply to 
fe80::216:3eff:fe32:2d49 port 546

And there is nothing in DNS's logs, even when set to DEBUG. Can anybody see 
what I'm missing. If I sniff the wire I can see that there isn't any 
communication between my DHCP and DNS servers, so I don't think its a firewall 
setting as its not even getting that far.

Thanks,
Joshua Schaeffer

Re: DNS dynamique

[Alban Vidal]

Bonjour Éric,

On 06/01/2017 09:47 AM, Eric Bernard wrote:
>
> Je dois installer un tout nouveau serveur dns dynamique (dns + dhcp )
> en virtuel (Vmware) et j'ai quelques questions, certainement bêtes, à
> l'esprit :
>
> - Debian 8 ou attendre la version 9 qui doit sortir mi-juin ?
>
> - En dehors d'installer les "open-vm-tools", y a-t-il d'autres
> précautions à prendre pour une utilisation sous vmware ?
>
> - J'ai regardé sur le net des tutos et je dois dire que les
> installations sont plus ou moins différentes l'une de l'autre, par
> exemple certains fichiers de conf dans /etc/bind/ ou dans
> /var/cache/bind/ ?
>
> Avez-vous dans vos cartons un tuto/site digne de ce nom sous la main
> car ce serveur sera en prod donc...
>
- Personnellement j'attendrais le 17, mais il est déjà possible de
préparer la configuration et de mettre en production à partir de la date
de sortie.

- Les open-vm-tools sont suffisants, je ne vois pas quoi installer d'autre.

- Concernant le répertoire /var/cache/bind/ bind9 s'en sert en tant que
cache, et non pas pour les fichiers de configuration.
Le fichiers de configurations sont bien à placer dans /etc/bind/.
Plus d'informations sur les répertoires sont disponibles dans la FHS [¹].

Le couplage serait donc bind9 + isc-dhcp-server ?

Pour les tutos je n'ai pas recherché, mais avec une recherche du genre «
bind9 isc-dhcp-server » il devrait y avoir ce qu'il faut.

[¹] https://fr.wikipedia.org/wiki/Filesystem_Hierarchy_Standard

Cordialement,

Alban



signature.asc
Description: OpenPGP digital signature

DNS dynamique

[Eric Bernard]

Bonjour la liste,

Je dois installer un tout nouveau serveur dns dynamique (dns + dhcp ) en 
virtuel (Vmware) et j'ai quelques questions, certainement bêtes, à 
l'esprit :


- Debian 8 ou attendre la version 9 qui doit sortir mi-juin ?

- En dehors d'installer les "open-vm-tools", y a-t-il d'autres 
précautions à prendre pour une utilisation sous vmware ?


- J'ai regardé sur le net des tutos et je dois dire que les 
installations sont plus ou moins différentes l'une de l'autre, par 
exemple certains fichiers de conf dans /etc/bind/ ou dans 
/var/cache/bind/ ?


Avez-vous dans vos cartons un tuto/site digne de ce nom sous la main car 
ce serveur sera en prod donc...



Merci de vos réponses !!!


Eric - Saumur

Connexion wifi dans un hôtel Brit avec Unbound - Réglage DNS

[G2PC]

Bonjour.
Brit Hotel.
Linux Mint Sarah avec Unbound.

/etc/resolv.conf
affiche :
nameserver 127.0.0.1
search lan

route
affiche :
Table de routage IP du noyau
Destination Passerelle Genmask Indic Metric Ref Use Iface
default 172.16.1.1 0.0.0.0 UG 0 0 0 wlp60s0
default 172.16.1.1 0.0.0.0 UG 600 0 0 wlp60s0
link-local * 255.255.0.0 U 1000 0 0 wlp60s0
172.16.1.0 * 255.255.255.0 U 600 0 0 wlp60s0

Décidément, je ne comprend pas, mais, j'arrive bien à avoir une page
d'accueil sous windows, qui me demande un mail de connexion . puis
me donne accès au web . ( de l'hotel ) 

Mais, pas moyen, avec Linux Sarah, surement à cause de Unbound et de mon
réglage.

Comment feriez vous sous Debian pour avancer sur ce problème pour
arriver à obtenir la page d'accueil de l'hotel ?

Je suppose que "le soucis" vient de l'ip 172.16.1.1
J'obtient une erreur de connexion avec cette ip lorsque je tente
d'accéder à google :
https://zs3.noodo-wifi.com/wifi-access/prod/login/?gw_address=172.16.1.1_port=2060_id=401=E4:A4:71:71:69:25=http%3A//www.google.fr/

RE: DNS hits

[Bonno Bloksma]

Hi Glenn,

>> Actually the current Bind in stable is just a blessing in this respect.
>> It - by default- just allows recursion for localnet, localhost.
>
> This server is still Wheezy. The virtual websites didn't work on Jessie 
> Apache (I have no idea why yet).
> 
>> So if you don't mess with it at all is does the right thing automagically.
> 
>> Most likely if you remove anything you tried to configure in the options it
>> will work just the way you want.
>
> I'd already done what Eduardo suggested in his post (config BIND to allow 
> recursion from only a specified list of IPs), and all was well -- as soon as 
> I tested it properly.
>
> FWIW, I ran dnstop for a while. I saw quite a bit of my own server at first, 
> but over few minutes, its output turned into a list of hits on my domains.
> Almost all from the 52, 54 area (AWS). I don't know, but I assume dnstop is 
> looking at packets before iptables processes them. If not, something is still 
> badly broken.

If you configure BIND to just respond to local requests then dnstop might still 
see the requests coming from other ip numbers, BIND just might not respond to a 
recurvice query.
AFAIK iptables has nothing to do with this. You cannot block dns requests at 
the iptables level as it cannot distinguish between a request for your own 
domain, to which BIND should respond, and a recursive request for another 
domain, which BIND should ignore.

Bonno Bloksma

Re: DNS hits

[Glenn English]

 > On Sat, Feb 11, 2017 at 2:07 PM, Henning Follmann <
hfollm...@itcfollmann.com
> wrote

Actually the current Bind in stable is just a blessing in this respect.
> It -by default- just allows recursion for localnet, localhost.
>

This server is still Wheezy. The virtual websites didn't work on Jessie
Apache (I have no idea why yet).


> So if you don't mess with it at all is does the right thing automagically.
>
> Most likely if you remove anything you tried to configure in the options it
> will work just the way you want.
>

I'd already done what Eduardo suggested in his post (config BIND to allow
recursion from only a specified list of IPs), and all was well -- as soon
as I tested it properly.


FWIW, I ran dnstop for a while. I saw quite a bit of my own server at
first, but over few minutes, its output turned into a list of hits on my
domains. Almost all from the 52, 54 area (AWS). I don't know, but I assume
dnstop is looking at packets before iptables processes them. If not,
something is still badly broken.

Also FWIW, At github there's a very nice shell script that downloads, from
Amazon, a list of the nets in AWS, creates iptables DROP commands for them,
and enters the commands into your iptables filter. Takes a little futzing
to make it run on Wheezy, but it runs out of the box on Jessie:

https://github.com/corbanworks/aws-blocker/blob/master/aws-blocker


The router seems reasonably quiet right now. Maybe the script kiddies are
all at church, praying for their souls...

-- 
Glenn English

Re: DNS hits

[Henning Follmann]

On Sat, Feb 11, 2017 at 04:11:13PM -0700, Glenn English wrote:
> On Sat, Feb 11, 2017 at 2:07 PM, Henning Follmann <hfollm...@itcfollmann.com
> > wrote:
> 
> > On Sat, Feb 11, 2017 at 10:58:54AM -0700, Glenn English wrote:
> >
>
[...]
 
> Does your DNS answer recursive queries?
> >
> 
> Oh, my lord. I didn't think it did -- I tried to configure BIND to do
> recursion only from my net. I just tried it from an external IP, and sure
> enough, it gave me an address for www.abc.com. But I just saw another
> config option that turns recursion off completely.
> ...
> I turned it off, and as expected, there's no recursion -- from my net or
> anywhere else. Bears a little more looking into. Surely there's a way to
> get BIND to do this little trick. Hopefully without going to that
> public/private mess. BIND is a mixed blessing.
> 

Actually the current Bind in stable is just a blessing in this respect.
It -by default- just allows recursion for localnet, localhost.

So if you don't mess with it at all is does the right thing automagically.

Most likely if you remove anything you tried to configure in the options it
will work just the way you want.

[...]

-H

-- 
Henning Follmann   | hfollm...@itcfollmann.com