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."
stetc/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
> sy
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
estetc
> # 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 looku
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
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
> > DN
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
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
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.
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,
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
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 mirr
; 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
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
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 o
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
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
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'a
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 nouve
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
oblem 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 D
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
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
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
> >
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
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?
> >
> >
> 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
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
>
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
>>
>> 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
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
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 t
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
>>
>> 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.
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
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
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
> >
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
>
> 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
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
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
> 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
-
-
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
> >
ing 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
o 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
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
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 th
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
x9p wrote:
> Should be on debian by default in my opinion.
... and truly it is
> 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 s
igned 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.
> >
>
er 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
ase 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
> 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
> 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
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 d
ot;
>
> 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 entr
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
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
> 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).
>
Und
ldomain"
>
> 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
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 mad
ort 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/
host 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 sho
> 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 misi
> 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
>
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
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
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
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
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
>>>
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
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
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
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
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
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
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
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
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
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éfa
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
ave
> 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 DN
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
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
>>>
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.
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
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
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
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
: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
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 th
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
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
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
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"
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
t 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
> 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
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 r
601 - 700 of 6790 matches
Mail list logo