Re: DNS query question

[Geert Stappers]

On Wed, Jun 12, 2024 at 06:42:04AM +0200, Marco Moock wrote:
> Am 12.06.2024 um 10:51:45 Uhr schrieb Jeff Peng:
> > Hello list,
> > 
> > I have made a successful query in one of my VPS as the following.
> > 
> > ~$ dig 235.84.36.104.zen.spamhaus.org
> > ;; QUESTION SECTION:
> > ;235.84.36.104.zen.spamhaus.org.IN  A
> > 
> > ;; ANSWER SECTION:
> > 235.84.36.104.zen.spamhaus.org. 852 IN  A   127.0.0.10
> > 
> > ;; Query time: 0 msec
> > ;; SERVER: 127.0.0.53#53(127.0.0.53)
> > 
> > 
> > But, the same query wouldn't success in another VPS as follows.
> > 
> > $ dig 235.84.36.104.zen.spamhaus.org
> > ;; QUESTION SECTION:
> > ;235.84.36.104.zen.spamhaus.org.IN  A
> > 
> > ;; Query time: 1 msec
> > ;; SERVER: 127.0.0.53#53(127.0.0.53)
> > 
> > 
> > The returned result is "NXDOMAIN".
> > 
> > Both nodes use systemd-resolve as DNS subresolver.
> > 
> > Do you know what's the reason behind this?
> 
> Spamhaus restricts queries from public resolvers.
> https://www.spamhaus.org/resource-hub/email-security/if-you-query-the-legacy-dnsbls-via-digitalocean-move-to-spamhaus-technologys-free-data-query-service/#the-headlines-for-those-in-a-hurry
> 
> 
> > Thanks.

Thanks for keeping context
Thanks for noting that response text is below previous text. Yes, keep
the discussion order.


Regards
Geert Stappers
Aware of people in different time zones
Creating awareness for that not all messages are read
Asking for standalone messages
-- 
Silence is hard to parse

Re: DNS query question

[Marco Moock]

Am 12.06.2024 um 10:51:45 Uhr schrieb Jeff Peng:

> Do you know what's the reason behind this?

Spamhaus restricts queries from public resolvers.
https://www.spamhaus.org/resource-hub/email-security/if-you-query-the-legacy-dnsbls-via-digitalocean-move-to-spamhaus-technologys-free-data-query-service/#the-headlines-for-those-in-a-hurry


-- 
Gruß
Marco

Send unsolicited bulk mail to 1718182305mu...@cartoonies.org

Re: DNS resolver issue

[Greg Wooledge]

On Mon, Jan 24, 2022 at 07:05:27AM -0500, Henning Follmann wrote:
> On Mon, Jan 24, 2022 at 10:14:23AM +, Bhasker C V wrote:
> > I am running  example.local domain on my interface(192.168.2.1)  (bind9)
> > The domain is resolving fine. However I want to use 1.1.1.1 public DNS
> > server for looking up other domains (external domains)
> > Hence I have put both servers in /etc/resolv.conf
> > 
> > ``` nameserver 1.1.1.1
> > nameserver 192.168.2.1
> > search example.local```

This is fundamentally wrong.  All of the nameservers are treated equally.
It's not a "try one, and if that says no such domain, try another" thing.
It only tries another one if the first one doesn't give any response at
all.

> If you already are using bind, wouldn't it be the simplest way
> to put 1.1.1.1 as a forward in your configuration and
> then just use 192.168.2.1 as your recursive resolver?

This.  You need to use *only* 192.168.2.1 as your nameserver, and you
need to configure whatever software is running on that IP address to
forward non-local requests out to the public DNS resolver(s) of your
choice.  That'll be configured within the DNS software, not in the
/etc/resolv.conf file.

Re: DNS resolver issue

[Henning Follmann]

On Mon, Jan 24, 2022 at 10:14:23AM +, Bhasker C V wrote:
> Hi all,
> 
>  Please could someone help me with  what I am doing wrong ?
> 
> I am running  example.local domain on my interface(192.168.2.1)  (bind9)
> The domain is resolving fine. However I want to use 1.1.1.1 public DNS
> server for looking up other domains (external domains)
> Hence I have put both servers in /etc/resolv.conf
> 
> ``` nameserver 1.1.1.1
> nameserver 192.168.2.1
> search example.local```
> 
[...]

If you already are using bind, wouldn't it be the simplest way
to put 1.1.1.1 as a forward in your configuration and
then just use 192.168.2.1 as your recursive resolver?

-H

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

Re: DNS resolver issue

[Reco]

Hi.

On Mon, Jan 24, 2022 at 10:14:23AM +, Bhasker C V wrote:
> $ dig +short server.example.local
> 192.168.2.2

Just in case, using ".local" domain that way violates RFC 6762.  There
are numerous ways to name your private domain, but ".local" is not a
proper name for that.

> Now, isnt the lookup supposed to fall back to next server if first one
> doesnt have an answer ?

Only if the first DNS is unreachable or returning SERVFAIL.
Your is returning NXDOMAIN, so this behaviour is expected.


> How does multiple DNS servers entry work in resolv.conf ?

Barring "options rotate", always try first nameserver specified for any
query, switch to the second if timeout (5 seconds by default, according
to resolv.conf(5), 30 seconds in practice) is reached.


Easiest way to solve your problem would be specify an public resolver
(1.1.1.1) in your bind configuration for anything but your domain, and
then use only 192.168.2.1 in your resolv.conf.

Reco

Re: dns failover a record

[didar]

On Mon, Jul 12, 2021 at 08:32:55AM -0400, Jeremy Hendricks wrote:
> The feature you need to look for is GSLB. I’d Google opensource and GSLB. I
> saw a few projects that should give you the functionality you need.
> 
> On Mon, Jul 12, 2021 at 8:23 AM Dan Ritter  wrote:
> 
> > Gokan Atmaca wrote:
> > > I want to do dns failover. There is no such feature in the bind
> > > service. It has RR feature but no Failover. I have 2 services. I want
> > > the A record to change automatically when one is inaccessible. Is
> > > there a tool you can recommend for this ?

Please explore PowerDNS. In my previous employment, our GSLB (Geo Service Load
Balancing) team was using it to provide this kind of service. AFAIK, custom
plugins had to be written to do what you want. Not sure, if there are any out of
the box features available now. A talented engineer had implemented it back in
2010 something while being an intern in 3 months!

HTH,
didar

> >
> >
> >
> > The most obvious way to do this is dynamic DNS updates. Set up your
> > servers to send a dynamic DNS update to your DNS server when they decide
> > that they are the new primary.
> >
> > Note that DNS TTL records are advisory, not mandatory, so it is
> > unlikely that all your traffic will switch over quickly to the
> > new primary. Losing connectivity for 3 minutes to 24 hours is
> > for various clients is more or less expected.
> >
> > -dsr-
> >
> >

-- 
The reward for working hard is more hard work.

Re: dns failover a record

[Jeremy Hendricks]

The feature you need to look for is GSLB. I’d Google opensource and GSLB. I
saw a few projects that should give you the functionality you need.

On Mon, Jul 12, 2021 at 8:23 AM Dan Ritter  wrote:

> Gokan Atmaca wrote:
> > I want to do dns failover. There is no such feature in the bind
> > service. It has RR feature but no Failover. I have 2 services. I want
> > the A record to change automatically when one is inaccessible. Is
> > there a tool you can recommend for this ?
>
>
>
> The most obvious way to do this is dynamic DNS updates. Set up your
> servers to send a dynamic DNS update to your DNS server when they decide
> that they are the new primary.
>
> Note that DNS TTL records are advisory, not mandatory, so it is
> unlikely that all your traffic will switch over quickly to the
> new primary. Losing connectivity for 3 minutes to 24 hours is
> for various clients is more or less expected.
>
> -dsr-
>
>

Re: dns failover a record

[Dan Ritter]

Gokan Atmaca wrote: 
> I want to do dns failover. There is no such feature in the bind
> service. It has RR feature but no Failover. I have 2 services. I want
> the A record to change automatically when one is inaccessible. Is
> there a tool you can recommend for this ?



The most obvious way to do this is dynamic DNS updates. Set up your
servers to send a dynamic DNS update to your DNS server when they decide
that they are the new primary.

Note that DNS TTL records are advisory, not mandatory, so it is
unlikely that all your traffic will switch over quickly to the
new primary. Losing connectivity for 3 minutes to 24 hours is
for various clients is more or less expected.

-dsr-

Re: dns failover a record

[IL Ka]

>
>
>  I have 2 services. I want
> the A record to change automatically when one is inaccessible.


Do you want the DNS server to ping your service and change "A" record?

There is no such feature AFAIK. You can use two different IPs for services
and provide both of them as A record.
This is called "round robin".

Clients may cache DNS response, so this approach may fail in any case.

You can share IP address between two servers: when one fails, another one
takes this address.

See https://en.wikipedia.org/wiki/Common_Address_Redundancy_Protocol
https://manpages.debian.org/unstable/ucarp/ucarp.8.en.html

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Nicholas Geovanis]

On Wed, Mar 31, 2021, 4:26 PM Moritz Kempe 
wrote:

> Up until now i used my AVM Fritz!Box (my router) with the (supported)
> firmware version FRITZ!OS-Version 07.21.
>
> Just now, i upgraded the firmware to FRITZ!OS-Version 07.25 and the DNS
> is now working on my Raspberry Pi 400.
>
>
> I cannot yet say, if my problem is solved but it seems like it. I will
> reply to this mail if the problem will reoccur
>

Wow, you're fast :-)
I feared you would find exactly those long DHCP discover sequences that you
noticed. I was just going back to see if the server that granted you was at
the address you were expecting.
Gruß Gott

Here is an changelog
> https://en.avm.de/fritz-lab/fresh-from-development/updates-improvements/
>
> > *Improved *- Update process more robust for potential DNS problems
> Or here in the German changelog
>
> https://avm.de/service/downloads/update-news/download/show/eyJkaXNwbGF5IjoiRlJJVFohQm94IDc1OTAiLCJ1cmwiOiJodHRwOlwvXC9kb3dubG9hZC5hdm0uZGVcL2ZyaXR6Ym94XC9mcml0emJveC03NTkwXC9kZXV0c2NobGFuZFwvZnJpdHoub3NcL2luZm9fZGUudHh0IiwiaGFzaCI6IjNiYmQ1ZTI5YTg4N2NjM2U3ZjRhZTRhOTY4YjE3OTNmYTA2MWU1NzA1Y2NkYjZlYjA2ODM2NWYwNjEzYWMzZjcifQ%3D%3D/
>
>
> *Behoben* IPv6: Im IPv6 Router Advertisement (RA) mit Option 25
> (Recursive DNS Server) wurden zum Teil Bits des Feldes "Reserved" gesetzt
>
> [EN] Fixed: IPv6 Router Advertisement (RA) with Option 25 (Recursive DNS
> Server) got manipulated bits at the field "Reserved"
>
>
> *Behoben* DNS-Anfragen des Typs "PTR" wurden teilweise nicht korrekt
> aufgelöst
>
> [EN] Fixed: DNS Querries with Type "PTR" wouldn't get resolved right.
>
>
> Could on of this changes be the cause of my problems, or the problems
> other people are also getting?
>
>

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

Up until now i used my AVM Fritz!Box (my router) with the (supported) 
firmware version FRITZ!OS-Version 07.21.


Just now, i upgraded the firmware to FRITZ!OS-Version 07.25 and the DNS 
is now working on my Raspberry Pi 400.



I cannot yet say, if my problem is solved but it seems like it. I will 
reply to this mail if the problem will reoccur.



Here is an changelog 
https://en.avm.de/fritz-lab/fresh-from-development/updates-improvements/



*Improved *- Update process more robust for potential DNS problems
Or here in the German changelog 
https://avm.de/service/downloads/update-news/download/show/eyJkaXNwbGF5IjoiRlJJVFohQm94IDc1OTAiLCJ1cmwiOiJodHRwOlwvXC9kb3dubG9hZC5hdm0uZGVcL2ZyaXR6Ym94XC9mcml0emJveC03NTkwXC9kZXV0c2NobGFuZFwvZnJpdHoub3NcL2luZm9fZGUudHh0IiwiaGFzaCI6IjNiYmQ1ZTI5YTg4N2NjM2U3ZjRhZTRhOTY4YjE3OTNmYTA2MWU1NzA1Y2NkYjZlYjA2ODM2NWYwNjEzYWMzZjcifQ%3D%3D/



*Behoben* IPv6: Im IPv6 Router Advertisement (RA) mit Option 25 
(Recursive DNS Server) wurden zum Teil Bits des Feldes "Reserved" gesetzt


[EN] Fixed: IPv6 Router Advertisement (RA) with Option 25 (Recursive DNS 
Server) got manipulated bits at the field "Reserved"



*Behoben* DNS-Anfragen des Typs "PTR" wurden teilweise nicht korrekt 
aufgelöst


[EN] Fixed: DNS Querries with Type "PTR" wouldn't get resolved right.


Could on of this changes be the cause of my problems, or the problems 
other people are also getting?

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

On 3/31/21 3:22 PM, Nicholas Geovanis wrote:
On Wed, Mar 31, 2021, 8:08 AM Moritz Kempe > wrote:


On 3/31/21 1:55 PM, Lee wrote:
> On 3/31/21, Moritz Kempe mailto:deblist%2bdeb...@moke12g.de>> wrote:
>> On 3/31/21 1:25 PM, Greg Wooledge wrote:
>>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
 -- Firefox Hmm. We’re having trouble finding that site. We can’t
 connect to the server at github.com .
 -- Chromium This site can’t be reachedCheck if there is a typo in
 github.com . DNS_PROBE_FINISHED_NXDOMAIN
 moke@rpi4-20201112:~$ host github.com 
Host github.com  not found:
 2(SERVFAIL)
>>> grep ^hosts: /etc/nsswitch.conf
>> --
>> hosts:          files mdns4_minimal [NOTFOUND=return] dns
mymachines
> I don't trust multicast dns, so in addition to turning it off
I've also got
> $ grep host /etc/nsswitch.conf
> # hosts:          files mdns4_minimal [NOTFOUND=return] dns
> hosts:          files dns
>
> Maybe worth a shot?

Changed my /etc/nsswitch.conf to

--

..

#hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines
hosts:  files dns
..

--

and rebooted the system. The behavior hasn't changed.

github.com  is still blocked. And dig is still
able to find the ip address.

Or do i have done something wrong?


I have found out, that i can restore some domains when running
"/sbin/dhclient" as root but not all. Github is still not accessible.


That's why I suggested checking for DHCP messages in the logs. But 
also logs upstream from your pi's. Each time you get a DHCP grant, 
potentially you've switched DNS servers.


Do you mean the logs at /var/log/syslog?

And for what i look out for?

Here are some entries, maybe you see something important for this issue.

--

Mar 31 14:39:04 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to 
255.255.255.255 port 67 interval 7
Mar 31 14:39:11 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to 
255.255.255.255 port 67 interval 20
Mar 31 14:39:31 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to 
255.255.255.255 port 67 interval 12
Mar 31 14:39:43 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to 
255.255.255.255 port 67 interval 19
Mar 31 14:40:02 rpi4-20201112 dhclient[5538]: DHCPDISCOVER on docker0 to 
255.255.255.255 port 67 interval 3

Mar 31 14:40:05 rpi4-20201112 dhclient[5538]: No DHCPOFFERS received.
Mar 31 14:40:05 rpi4-20201112 dhclient[5538]: No working leases in 
persistent database - sleeping.


-- This was logged for many times.

--

Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Internet Systems Consortium 
DHCP Client 4.4.1
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Copyright 2004-2018 
Internet Systems Consortium.
Mar 31 15:05:49 rpi4-20201112 ifup[478]: For info, please visit 
https://www.isc.org/software/dhcp/

Mar 31 15:05:49 rpi4-20201112 dhclient[478]: All rights reserved.
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: For info, please visit 
https://www.isc.org/software/dhcp/

Mar 31 15:05:49 rpi4-20201112 dhclient[478]:
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Listening on 
LPF/eth0/##:##:##:##:##:##    # censored by me
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Sending on 
LPF/eth0/##:##:##:##:##:## # censored by me

Mar 31 15:05:49 rpi4-20201112 dhclient[478]: Sending on Socket/fallback
Mar 31 15:05:49 rpi4-20201112 dhclient[478]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 8
Mar 31 15:05:50 rpi4-20201112 NetworkManager[417]:  
[1617195950.2281] dhcp-init: Using DHCP client 'internal'
Mar 31 15:05:57 rpi4-20201112 dhclient[478]: DHCPDISCOVER on eth0 to 
255.255.255.255 port 67 interval 14
Mar 31 15:05:58 rpi4-20201112 dhclient[478]: DHCPOFFER of 10.0.0.70 from 
10.0.0.1
Mar 31 15:05:58 rpi4-20201112 dhclient[478]: DHCPREQUEST for 10.0.0.70 
on eth0 to 255.255.255.255 port 67
Mar 31 15:05:58 rpi4-20201112 dhclient[478]: DHCPACK of 10.0.0.70 from 
10.0.0.1
Mar 31 15:06:38 rpi4-20201112 dhclient[478]: bound to 10.0.0.70 -- 
renewal in 3831703 seconds.


--

I used the command "cat /var/log/syslog | grep dhc"


And you said


But also logs upstream from your pi's.
do you mean the DHCP log from my router? Because i searched for one, but 
i haven't found one yet.


Or do you mean that i should use Wireshark to analyze my DHCP requests?


I haven't looked into networking on that level.

I would be nice, if you would give me an explanation or link a website 
which could do that.




Note: I haven't changed any networking configuration on this
device. I
haven't even enabled wifi.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Nicholas Geovanis]

On Wed, Mar 31, 2021, 8:08 AM Moritz Kempe 
wrote:

> On 3/31/21 1:55 PM, Lee wrote:
> > On 3/31/21, Moritz Kempe  wrote:
> >> On 3/31/21 1:25 PM, Greg Wooledge wrote:
> >>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>  -- Firefox Hmm. We’re having trouble finding that site. We can’t
>  connect to the server at github.com.
>  -- Chromium This site can’t be reachedCheck if there is a typo in
>  github.com. DNS_PROBE_FINISHED_NXDOMAIN
>  moke@rpi4-20201112:~$ host github.com Host github.com not found:
>  2(SERVFAIL)
> >>> grep ^hosts: /etc/nsswitch.conf
> >> --
> >> hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines
> > I don't trust multicast dns, so in addition to turning it off I've also
> got
> > $ grep host /etc/nsswitch.conf
> > # hosts:  files mdns4_minimal [NOTFOUND=return] dns
> > hosts:  files dns
> >
> > Maybe worth a shot?
>
> Changed my /etc/nsswitch.conf to
>
> --
>
> ..
>
> #hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines
> hosts:  files dns
> ..
>
> --
>
> and rebooted the system. The behavior hasn't changed.
>
> github.com is still blocked. And dig is still able to find the ip address.
>
> Or do i have done something wrong?
>
>
> I have found out, that i can restore some domains when running
> "/sbin/dhclient" as root but not all. Github is still not accessible.
>

That's why I suggested checking for DHCP messages in the logs. But also
logs upstream from your pi's. Each time you get a DHCP grant, potentially
you've switched DNS servers.

Note: I haven't changed any networking configuration on this device. I
> haven't even enabled wifi.
>
>

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

On 3/31/21 2:44 PM, Greg Wooledge wrote:

On Wed, Mar 31, 2021 at 01:42:36PM +0200, Moritz Kempe wrote:

grep ^hosts: /etc/nsswitch.conf

--
hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines

I don't know what "mymachines" is.  I don't see it in the man page.

What happens if you get rid of the "mymachines" field?


I have restarted my device with "mymachines" commented out.

It seems like, it behaviors the same.


-rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf
domain fritz.box
search fritz.box
nameserver 10.0.0.1

You're using a local caching resolver, or at least something that
forwards requests.  That's fine, if it works.  You might try probing
the DNS resolver at 10.0.0.1 to see whether it actually does work.


Do you mean like so?

--

moke@rpi4-20201112:~$ dig @10.0.0.1 debian.org

; <<>> DiG 9.16.13-Debian <<>> @10.0.0.1 debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13415
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;debian.org.            IN    A

;; ANSWER SECTION:
debian.org.        300    IN    A    149.20.4.15
debian.org.        300    IN    A    130.89.148.77
debian.org.        300    IN    A    128.31.0.62

;; Query time: 351 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: Wed Mar 31 15:11:15 CEST 2021
;; MSG SIZE  rcvd: 87
--


(There's a really good chance that 10.0.0.1 is your router, and that
your router implements a forwarding nameserver, which just passes
your requests to your ISP.  These router-based forwarding resolvers
can be a bit flaky sometimes.)

Yes, 10.0.0.1 is my router.

; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.debian.org.            IN    A

;; ANSWER SECTION:
www.debian.org.        229    IN    A 130.89.148.77
www.debian.org.        229    IN    A 149.20.4.15
www.debian.org.        229    IN    A 128.31.0.62

;; Query time: 35 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Mar 31 13:38:10 CEST 2021
;; MSG SIZE  rcvd: 91

That's good.  At least you're not blocking UDP packets or something like
that.  If the weird entry in nsswitch.conf doesn't turn out to be the
problem, and 10.0.0.1 turns out to be non-functional in some way, you
could use Google's resolvers as a fallback.


Yes, i could add a fallback resolver to every device but the advantage 
of the router is, that you can set a dns server for a whole network 
which is a feature i do not want to miss. Also is there still the 
question, why Debian on the Raspberry Pi 400 can't use a dns server, 
which can be used by all other devices.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

On 3/31/21 1:55 PM, Lee wrote:

On 3/31/21, Moritz Kempe  wrote:

On 3/31/21 1:25 PM, Greg Wooledge wrote:

On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:

-- Firefox Hmm. We’re having trouble finding that site. We can’t
connect to the server at github.com.
-- Chromium This site can’t be reachedCheck if there is a typo in
github.com. DNS_PROBE_FINISHED_NXDOMAIN
moke@rpi4-20201112:~$ host github.com Host github.com not found:
2(SERVFAIL)

grep ^hosts: /etc/nsswitch.conf

--
hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines

I don't trust multicast dns, so in addition to turning it off I've also got
$ grep host /etc/nsswitch.conf
# hosts:  files mdns4_minimal [NOTFOUND=return] dns
hosts:  files dns

Maybe worth a shot?


Changed my /etc/nsswitch.conf to

--

..

#hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines
hosts:  files dns
..

--

and rebooted the system. The behavior hasn't changed.

github.com is still blocked. And dig is still able to find the ip address.

Or do i have done something wrong?


I have found out, that i can restore some domains when running 
"/sbin/dhclient" as root but not all. Github is still not accessible.



Note: I haven't changed any networking configuration on this device. I 
haven't even enabled wifi.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Greg Wooledge]

On Wed, Mar 31, 2021 at 01:42:36PM +0200, Moritz Kempe wrote:
> > grep ^hosts: /etc/nsswitch.conf
> --
> hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines

I don't know what "mymachines" is.  I don't see it in the man page.

What happens if you get rid of the "mymachines" field?

> -rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf

> domain fritz.box
> search fritz.box
> nameserver 10.0.0.1

You're using a local caching resolver, or at least something that
forwards requests.  That's fine, if it works.  You might try probing
the DNS resolver at 10.0.0.1 to see whether it actually does work.

(There's a really good chance that 10.0.0.1 is your router, and that
your router implements a forwarding nameserver, which just passes
your requests to your ISP.  These router-based forwarding resolvers
can be a bit flaky sometimes.)

> ; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
> 
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.debian.org.            IN    A
> 
> ;; ANSWER SECTION:
> www.debian.org.        229    IN    A 130.89.148.77
> www.debian.org.        229    IN    A 149.20.4.15
> www.debian.org.        229    IN    A 128.31.0.62
> 
> ;; Query time: 35 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Mar 31 13:38:10 CEST 2021
> ;; MSG SIZE  rcvd: 91

That's good.  At least you're not blocking UDP packets or something like
that.  If the weird entry in nsswitch.conf doesn't turn out to be the
problem, and 10.0.0.1 turns out to be non-functional in some way, you
could use Google's resolvers as a fallback.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Lee]

On 3/31/21, Moritz Kempe  wrote:
> On 3/31/21 1:25 PM, Greg Wooledge wrote:
>> On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
>>> -- Firefox Hmm. We’re having trouble finding that site. We can’t
>>> connect to the server at github.com.
>>> -- Chromium This site can’t be reachedCheck if there is a typo in
>>> github.com. DNS_PROBE_FINISHED_NXDOMAIN
>>> moke@rpi4-20201112:~$ host github.com Host github.com not found:
>>> 2(SERVFAIL)
>> grep ^hosts: /etc/nsswitch.conf
> --
> hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines

I don't trust multicast dns, so in addition to turning it off I've also got
$ grep host /etc/nsswitch.conf
# hosts:  files mdns4_minimal [NOTFOUND=return] dns
hosts:  files dns

Maybe worth a shot?

Regards,
Lee

>
> --
>
>
>> ls -ld /etc/resolv.conf
> --
> -rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf
> --
>
>> cat /etc/resolv.conf
> --
> domain fritz.box
> search fritz.box
> nameserver 10.0.0.1
> --
>
>> dig @8.8.8.8 www.debian.org
> --
> ; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
> ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 512
> ;; QUESTION SECTION:
> ;www.debian.org.INA
>
> ;; ANSWER SECTION:
> www.debian.org.229INA 130.89.148.77
> www.debian.org.229INA 149.20.4.15
> www.debian.org.229INA 128.31.0.62
>
> ;; Query time: 35 msec
> ;; SERVER: 8.8.8.8#53(8.8.8.8)
> ;; WHEN: Wed Mar 31 13:38:10 CEST 2021
> ;; MSG SIZE  rcvd: 91
>
> --
>
>
> I hope i interpreted your mail in the right way.
>
>

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

On 3/31/21 1:25 PM, Greg Wooledge wrote:

On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
-- Firefox Hmm. We’re having trouble finding that site. We can’t 
connect to the server at github.com. 
-- Chromium This site can’t be reachedCheck if there is a typo in 
github.com. DNS_PROBE_FINISHED_NXDOMAIN 
moke@rpi4-20201112:~$ host github.com Host github.com not found: 
2(SERVFAIL) 

grep ^hosts: /etc/nsswitch.conf

--
hosts:  files mdns4_minimal [NOTFOUND=return] dns mymachines

--



ls -ld /etc/resolv.conf

--
-rw-r--r-- 1 root root 54 Mar 31 13:28 /etc/resolv.conf
--


cat /etc/resolv.conf

--
domain fritz.box
search fritz.box
nameserver 10.0.0.1
--


dig @8.8.8.8 www.debian.org

--
; <<>> DiG 9.16.13-Debian <<>> @8.8.8.8 www.debian.org
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 20269
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;www.debian.org.            IN    A

;; ANSWER SECTION:
www.debian.org.        229    IN    A 130.89.148.77
www.debian.org.        229    IN    A 149.20.4.15
www.debian.org.        229    IN    A 128.31.0.62

;; Query time: 35 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Wed Mar 31 13:38:10 CEST 2021
;; MSG SIZE  rcvd: 91

--


I hope i interpreted your mail in the right way.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Greg Wooledge]

On Wed, Mar 31, 2021 at 12:14:59AM +0200, Moritz Kempe wrote:
> -- Firefox
> Hmm. We’re having trouble finding that site.
> 
> We can’t connect to the server at github.com.

> -- Chromium
> This site can’t be reachedCheck if there is a typo in github.com.
> DNS_PROBE_FINISHED_NXDOMAIN

> moke@rpi4-20201112:~$ host github.com
> Host github.com not found: 2(SERVFAIL)

grep ^hosts: /etc/nsswitch.conf
ls -ld /etc/resolv.conf
cat /etc/resolv.conf
dig @8.8.8.8 www.debian.org

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

Am 31.03.21 um 09:23 schrieb Klaus Singvogel:

Moritz Kempe wrote:
[...]

I noticed the problem, while i was browsing the internet and got confused
because after a while some domains could not longer be found/connected to by
the browser. (On both, Firefox and Chromium)

I had similar issues, when I changed DNS configuration at my DSL router.

I enabled on my DSL router: TLS for DNS, and, parallel, switched to
public, non-censored DNS servers, as suggested by a large German computer
magazine.
I've done this too. I also activated dns over tls with a privacy dns 
server in my router but i haven't mentioned it because it, doesn't 
seemed like there was any connection between these changes. On all other 
devices this works just fine. And even when i change my dns server to 
the default one, the raspberry pi still has these problems. (I tested 
this before i wrote the first mail)

Those DNS servers were independent and respect more privacy, compared to
my ISP. But after a while I noticed, that those public DNS servers drop
requests and I saw your error messages at my side too, especially if there
were a lot of name resolutions in a short time period.


On my raspberry pi 400, this could be the case, but on my Debian Stretch 
PC it works just fine.


I do experience these issues only on my raspberry pi 400, with both of 
my operating systems.



Those errors vanished after a while (several minutes) and everything
worked as expected. But then, when resolving again a lot of domain names,
the issues were back. Especially when I download from S3 Amazon, because
the IP address for s3.[...].amazon.com changes every 10 seconds or so.


On my raspberry pi 400 they occurre and rarely fix themselves but the 
majority of these stays up for all eternity (or up to an shutdown).
It don't feels, like you described, it is more like an blocklist which 
is getting longer and longer (and forces me to use google when my 
favorite search engines are blocked).



Don't know, if both are related.

But my suggestion is to look at your DSL router: if you changed the
defaults for DNS, and, if so, switch back to original, default setting for
testing purpose.
I switched my routers dns server back to the ISPs and also rebootet my 
device.
But i wasn't able to get on github.com but at the same time i was able 
to get on the by the (German) CUII (Clearingstelle Urheberrecht im 
Internet) censored site s.to [0] which shouldn't be accessible because 
of the censoring from my ISP.

This worked with both my browsers, firefox and chromium.


Regards,
Klaus.


[0] i do not encourage anyone to watch (illegal) content on s.to, i only 
chose this domain to test if i am able to visit censored websites.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Moritz Kempe]

Am 31.03.21 um 09:23 schrieb Klaus Singvogel:

Moritz Kempe wrote:
[...]

I noticed the problem, while i was browsing the internet and got confused
because after a while some domains could not longer be found/connected to by
the browser. (On both, Firefox and Chromium)

I had similar issues, when I changed DNS configuration at my DSL router.

I enabled on my DSL router: TLS for DNS, and, parallel, switched to
public, non-censored DNS servers, as suggested by a large German computer
magazine.
I've done this too. I also activated dns over tls with a privacy dns 
server in my router but i haven't mentioned it because it, doesn't 
seemed like there was any connection between these changes. On all other 
devices this works just fine. And even when i change my dns server to 
the default one, the raspberry pi still has these problems. (I tested 
this before i wrote the first mail)

Those DNS servers were independent and respect more privacy, compared to
my ISP. But after a while I noticed, that those public DNS servers drop
requests and I saw your error messages at my side too, especially if there
were a lot of name resolutions in a short time period.


On my raspberry pi 400, this could be the case, but on my Debian Stretch 
PC it works just fine.


I do experience these issues only on my raspberry pi 400, with both of 
my operating systems.



Those errors vanished after a while (several minutes) and everything
worked as expected. But then, when resolving again a lot of domain names,
the issues were back. Especially when I download from S3 Amazon, because
the IP address for s3.[...].amazon.com changes every 10 seconds or so.


On my raspberry pi 400 they occurre and rarely fix themselves but the 
majority of these stays up for all eternity (or up to an shutdown).
It don't feels, like you described, it is more like an blocklist which 
is getting longer and longer (and forces me to use google when my 
favorite search engines are blocked).



Don't know, if both are related.

But my suggestion is to look at your DSL router: if you changed the
defaults for DNS, and, if so, switch back to original, default setting for
testing purpose.
I switched my routers dns server back to the ISPs and also rebootet my 
device.
But i wasn't able to get on github.com but at the same time i was able 
to get on the by the (German) CUII (Clearingstelle Urheberrecht im 
Internet) censored site s.to [0] which shouldn't be accessible because 
of the censoring from my ISP.

This worked with both my browsers, firefox and chromium.


Regards,
Klaus.


[0] i do not encourage anyone to watch (illegal) content on s.to, i only 
chose this domain to test if i am able to visit censored websites.

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Klaus Singvogel]

Moritz Kempe wrote:
[...]
> I noticed the problem, while i was browsing the internet and got confused
> because after a while some domains could not longer be found/connected to by
> the browser. (On both, Firefox and Chromium)

I had similar issues, when I changed DNS configuration at my DSL router.

I enabled on my DSL router: TLS for DNS, and, parallel, switched to
public, non-censored DNS servers, as suggested by a large German computer
magazine.

Those DNS servers were independent and respect more privacy, compared to
my ISP. But after a while I noticed, that those public DNS servers drop
requests and I saw your error messages at my side too, especially if there
were a lot of name resolutions in a short time period.

Those errors vanished after a while (several minutes) and everything
worked as expected. But then, when resolving again a lot of domain names,
the issues were back. Especially when I download from S3 Amazon, because
the IP address for s3.[...].amazon.com changes every 10 seconds or so.

Don't know, if both are related.

But my suggestion is to look at your DSL router: if you changed the
defaults for DNS, and, if so, switch back to original, default setting for
testing purpose.

Regards,
Klaus.
-- 
Klaus Singvogel
GnuPG-Key-ID: 1024R/5068792D  1994-06-27

Re: DNS problems on Raspberry Pi 400 (Debian 10.9)

[Nicholas Geovanis]

On Tue, Mar 30, 2021, 5:33 PM Moritz Kempe  wrote:

> Hello,
>
> since i upgraded my Raspberry Pi 400 (with regular Debian 10, not
> Raspberry PI OS) to the latest buster version, i am experiencing
> problems with dns, which i cannot replicate with any of my other devices
> (Debian Stretch amd64 workstation, Debian Buster amd64 server, Raspberry
> Pi 3b armhf raspberrypi OS). But i can replicate this behavior with
> another another micro sd flashcard with Twister OS on the (same)
> Raspberry Pi 400. Twister OS is an Debian / Raspberry Pi OS based OS
> which helps you to game on the Raspberry Pi 400.
>
> I noticed the problem, while i was browsing the internet and got
> confused because after a while some domains could not longer be
> found/connected to by the browser. (On both, Firefox and Chromium)
>
> -- Firefox
> Hmm. We’re having trouble finding that site.
>
> We can’t connect to the server at github.com.
>
> If that address is correct, here are three other things you can try:
>
>  Try again later.
>  Check your network connection.
>  If you are connected but behind a firewall, check that Firefox has
> permission to access the Web.
> --
>
> -- Chromium
> This site can’t be reachedCheck if there is a typo in github.com.
> DNS_PROBE_FINISHED_NXDOMAIN
> --
>
> And as time passes, more and more website will disappear.
> Which means, that after a hour only barely visited domains are left.
>
> And even stranger is the output of different dns tools:
>

Never saw that before said the man on fire :-) So just guesses:

Some weird DNS TTL issue? Or TTL incompatibility?
Strange DNS local caching issue? Maybe check resolv.conf and name service
config for new options or something.
Do you see any unexpected DHCP messages in the logs, maybe further upstream
from the pi's?

-- host github.com
> moke@rpi4-20201112:~$ host github.com
> Host github.com not found: 2(SERVFAIL)
> --
>
> -- dig github.com
> ; <<>> DiG 9.16.13-Debian <<>> github.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30900
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ;; QUESTION SECTION:
> ;github.com.IN  A
>
> ;; ANSWER SECTION:
> github.com. 27  IN  A   140.82.121.3
>
> ;; Query time: 343 msec
> ;; SERVER: 10.0.0.1#53(10.0.0.1)
> ;; WHEN: Tue Mar 30 23:31:01 CEST 2021
> ;; MSG SIZE  rcvd: 55
> --
>
> Dig seems to be able to get the ip from github.com but (the program)
> host, firefox and chromium can't.
>
> Some system information
>
> --
> moke@rpi4-20201112
> --
> OS: Debian GNU/Linux bullseye/sid aarch64
> Host: Raspberry Pi 400 Rev 1.0
> Kernel: 5.10.0-5-arm64
> Resolution: 1440x900, 1280x1024
> WM: awesome
> CPU: (4) @ 1.800GHz
> Memory: 606MiB / 3791MiB
> --
>
> My Raspberry Pi 400 is connected over Ethernet to my home router.
>
> Is there someone else, who experiences / has experienced this problem?
>
> PS: After i reboot the system all domains get unlocked (until they get
> locked again).
>
> Kind Regards
> Moritz Kempe
>
>

Re: dns cache for localdomain via djbdns

[tomas]

On Wed, Aug 12, 2020 at 03:51:11PM +0200, Patrick Frank wrote:
> 
> On 12.08.20 15:28, Dan Ritter wrote:
> >Greg Wooledge wrote:
> >>On Wed, Aug 12, 2020 at 02:59:23PM +0200, Patrick Frank wrote:
> 
> 
> Greg writes: You can execute the "./run" script by hand for testing
> purposes [...]
> 
> When I tried "exec envuidgid Gnscache ..." it logged me out.

No, not "it" logged you out. When you say "exec", you say "replace
the currently running process by that other". When  "that other"
terminates... it's done. So it won't come back to your shell. It's
gone. Basically, with "exec" you logged you out yourself, kind of.

Cheers
 - t


signature.asc
Description: Digital signature

Re: dns cache for localdomain via djbdns

[Greg Wooledge]

On Wed, Aug 12, 2020 at 03:51:11PM +0200, Patrick Frank wrote:
> Greg writes: You can execute the "./run" script by hand for testing
> purposes [...]
> 
> When I tried "exec envuidgid Gnscache ..." it logged me out.

So don't do that.  Test it with ./run instead, like I said.

> Greg writes: unicorn:~$ ls -l /etc/dnscache/
> 
> This directory is missing the "supervise" directory.

Because you haven't started the service yet.  That will be created
once daemontools runs it for the first time.

> Dan writes: svc -d /service/dnscache
> 
> It outputs: unable to control /service/dnscache: file does not exist

Because you haven't started the service yet.

You need to create the symlink to start the service.

Re: dns cache for localdomain via djbdns

[Patrick Frank]

On 12.08.20 15:28, Dan Ritter wrote:

Greg Wooledge wrote:

On Wed, Aug 12, 2020 at 02:59:23PM +0200, Patrick Frank wrote:



Greg writes: You can execute the "./run" script by hand for testing
purposes [...]

When I tried "exec envuidgid Gnscache ..." it logged me out.


Greg writes: unicorn:~$ ls -l /etc/dnscache/

This directory is missing the "supervise" directory.


Dan writes: svc -d /service/dnscache

It outputs: unable to control /service/dnscache: file does not exist


P.

Re: dns cache for localdomain via djbdns

[Dan Ritter]

Greg Wooledge wrote: 
> On Wed, Aug 12, 2020 at 02:59:23PM +0200, Patrick Frank wrote:
> > Hello,
> > 
> > on a Debian 10 host I created a virtual machine with very basic features
> > to build a dns cache for my home network with djbdns. I fail to understand
> > how Daemontools are used properly.
> > 
> > Following the instructions on http://cr.yp.to/djbdns/install.html went okay.
> > http://cr.yp.to/djbdns/run-cache-x.html at step 5 is where I am stuck.
> > 
> > When I go to /service/dnscache and execute "run" it says "starting" so I
> > try svstat /service/dnscache which outputs:
> > "/service/dnscache: unable to open supervise/ok: file does not exist"
> 
> You can execute the "./run" script by hand for testing purposes, to
> make sure you've written it correctly, but that's not how daemontools
> will run it.  If your test is successful, you should Ctrl-C (or otherwise
> terminate) the ./run script that you ran manually.  Make sure it dies.
> 
> You tell daemontools to run the service by creating a symbolic link
> from the /service directory to the directory where the run script
> lives.
> 
> For example:
> 
> unicorn:~$ ls -l /service
> total 0
> lrwxrwxrwx 1 root root 13 Jan 12  2018 dnscache -> /etc/dnscache/
> lrwxrwxrwx 1 root root 39 Jan 12  2018 qmail-deliverabled -> 
> /var/qmail/supervise/qmail-deliverabled/
> lrwxrwxrwx 1 root root 31 Jan 12  2018 qmail-send -> 
> /var/qmail/supervise/qmail-send/
> lrwxrwxrwx 1 root root 28 Jan 12  2018 qpsmtpd -> 
> /var/qmail/supervise/qpsmtpd/
> 
> unicorn:~$ ls -l /etc/dnscache/
> total 24
> drwxr-sr-x 2 root root 4096 Jan 12  2018 env/
> drwxr-sr-x 4 root root 4096 Jan 12  2018 log/
> drwxr-sr-x 4 root root 4096 Jan 12  2018 root/
> -rwxr-xr-x 1 root root  142 Jan 12  2018 run*
> -rw--- 1 root root  128 Jan 12  2018 seed
> drwx--S--- 2 root root 4096 Aug  2 09:00 supervise/
> 
> The presence of the symlink /service/dnscache is picked up by svscan,
> which launches a supervisor process.

This is all correct, but in addition:

svc -d /service/dnscache
  brings it down via the supervisor, similar to the action of
"service dnscache stop" or "/etc/init.d/dnscache stop"

svc -u /service/dnscache
  should start running it again

All of this clashes with manual invocation of ./run, so that has
to be killed before daemontools can take over.

-dsr-

Re: dns cache for localdomain via djbdns

[Greg Wooledge]

On Wed, Aug 12, 2020 at 02:59:23PM +0200, Patrick Frank wrote:
> Hello,
> 
> on a Debian 10 host I created a virtual machine with very basic features
> to build a dns cache for my home network with djbdns. I fail to understand
> how Daemontools are used properly.
> 
> Following the instructions on http://cr.yp.to/djbdns/install.html went okay.
> http://cr.yp.to/djbdns/run-cache-x.html at step 5 is where I am stuck.
> 
> When I go to /service/dnscache and execute "run" it says "starting" so I
> try svstat /service/dnscache which outputs:
> "/service/dnscache: unable to open supervise/ok: file does not exist"

You can execute the "./run" script by hand for testing purposes, to
make sure you've written it correctly, but that's not how daemontools
will run it.  If your test is successful, you should Ctrl-C (or otherwise
terminate) the ./run script that you ran manually.  Make sure it dies.

You tell daemontools to run the service by creating a symbolic link
from the /service directory to the directory where the run script
lives.

For example:

unicorn:~$ ls -l /service
total 0
lrwxrwxrwx 1 root root 13 Jan 12  2018 dnscache -> /etc/dnscache/
lrwxrwxrwx 1 root root 39 Jan 12  2018 qmail-deliverabled -> 
/var/qmail/supervise/qmail-deliverabled/
lrwxrwxrwx 1 root root 31 Jan 12  2018 qmail-send -> 
/var/qmail/supervise/qmail-send/
lrwxrwxrwx 1 root root 28 Jan 12  2018 qpsmtpd -> /var/qmail/supervise/qpsmtpd/

unicorn:~$ ls -l /etc/dnscache/
total 24
drwxr-sr-x 2 root root 4096 Jan 12  2018 env/
drwxr-sr-x 4 root root 4096 Jan 12  2018 log/
drwxr-sr-x 4 root root 4096 Jan 12  2018 root/
-rwxr-xr-x 1 root root  142 Jan 12  2018 run*
-rw--- 1 root root  128 Jan 12  2018 seed
drwx--S--- 2 root root 4096 Aug  2 09:00 supervise/

The presence of the symlink /service/dnscache is picked up by svscan,
which launches a supervisor process.

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 21/08/2019 à 23:17, Migrec a écrit :


La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle 
indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit 
son bail DHCP.
Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans 
le resolv.conf.


Ça me paraissait pas mal car si mon serveur DNS est down, celui de la 
box fait au moins la résolution "externe", non ?


Dans ce cas il faut faire en sorte que le DNS de la box soit positionné 
après le DNS local dans resolv.conf, et ce de façon fiable (donc pas en 
réordonnant les interfaces). Il me semble que resolvconf qui gère ton 
resolv.conf a des possibilités dans ce sens.

Re: DNS : pas de résolution en local

[Migrec]

Le 21/08/2019 à 20:42, Pascal Hambourg a écrit :

Le 21/08/2019 à 10:00, Migrec a écrit :

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :


Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.


Merci pour ces précisions.
Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf. 


Non. Ton problème est lié au fait que resolv.conf contient l'adresse 
d'un serveur DNS qui ne fournit pas les bonnes réponses.


Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf 
sont censés être équivalents et fournir les mêmes réponses, donc 
l'ordre ne devrait pas avoir d'importance.


En fait j'ai ceci :

INTERNET <-> LIVEBOX <---> (enp3s0) SERVEUR (enp2s0) <---> 
ROUTEUR <> POINT D'ACCES WIFI


La livebox fait DHCP (décodeur TV branché dessus via du CPL) et elle 
indique son IP interne (192.168.1.1) comme DNS lorsque le serveur reçoit 
son bail DHCP.
Le serveur fait du DHCP/DNS pour le réseau local. Son IP est donc dans 
le resolv.conf.


Ça me paraissait pas mal car si mon serveur DNS est down, celui de la 
box fait au moins la résolution "externe", non ?





Or ce fichier est dynamique et je n'ai pas trouvé comment modifier 
l'ordre. Ça semble lié au montage des interfaces réseau.
Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en 
enp3s0 (et vice-versa). De cette façon, c'est ok.


Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il 
ne fournit pas les bonnes réponses, il ne doit pas être inscrit dans 
resolv.conf. dhclient (request, supersede, prepend) et NetworkManager 
(méthode : "adresses automatiques uniquement") ont des options pour 
l'empêcher.


Entendu mais ça dépasse ce que je peux mettre en œuvre.

--
Migrec

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 21/08/2019 à 13:05, Daniel Huhardeaux a écrit :

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Ou alors les nameserver sont interrogés en même temps et la réponse 
du 1er répondant est utilisée.


Non.


Si. Exemple avec dnsmasq: si on ne met pas strict-order celui ci 
interroge tous les serveurs qui sont up et prend la réponse du 1er 
serveur qui a répondu.


Je parlais du résolveur de la libc utilisé par les programmes, pas d'un 
serveur DNS récursif.

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 21/08/2019 à 10:00, Migrec a écrit :

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :


Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.


Merci pour ces précisions.
Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf. 


Non. Ton problème est lié au fait que resolv.conf contient l'adresse 
d'un serveur DNS qui ne fournit pas les bonnes réponses.


Comme je l'ai écrit ci-dessus, tous les DNS inscrits dans resolv.conf 
sont censés être équivalents et fournir les mêmes réponses, donc l'ordre 
ne devrait pas avoir d'importance.


Or ce fichier est dynamique et je n'ai pas trouvé comment modifier 
l'ordre. Ça semble lié au montage des interfaces réseau.
Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 
(et vice-versa). De cette façon, c'est ok.


Pas fiable. Si un serveur DNS ne doit pas être interrogé parce qu'il ne 
fournit pas les bonnes réponses, il ne doit pas être inscrit dans 
resolv.conf. dhclient (request, supersede, prepend) et NetworkManager 
(méthode : "adresses automatiques uniquement") ont des options pour 
l'empêcher.

Re: DNS : pas de résolution en local

[Daniel Huhardeaux]

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :

Le 20/08/19 à 00:47, Migrec  a écrit :

Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi 
l'échec

de la résolution ne passe pas la main au serveur DNS local ?


Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 
1er ne répond pas.


En effet. Ou alors répond qu'une erreur interne l'empêche de fournir une 
réponse (SERVFAIL, REFUSED...). En revanche NXDOMAIN (domaine 
inexistant) n'est pas considéré comme une absence de réponse.



Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.


En fait ici il ne dit pas que le nom n'existe pas, sinon il aurait 
répondu avec status=NXDOMAIN. Il répond avec status=NOERROR et ANSWER=0, 
ce qui signifie normalement que le nom existe mais qu'il n'a pas 
d'enregistrement du type demandé (A=adresse IPv4). Pour un client cela 
revient au même, mais cette réponse n'est pas correcte. Si je fais la 
même requête à mon serveur DNS, j'obtiens bien status=NXDOMAIN.


Ou alors les nameserver sont interrogés en même temps et la réponse du 
1er répondant est utilisée.


Non.


Si. Exemple avec dnsmasq: si on ne met pas strict-order celui ci 
interroge tous les serveurs qui sont up et prend la réponse du 1er 
serveur qui a répondu. Ceci n'enlève rien à ton explication.


Extrait du fichier de conf:

# By  default,  dnsmasq  will  send queries to any of the upstream 



# servers it knows about and tries to favour servers to are  known 



# to  be  up.  Uncommenting this forces dnsmasq to try each query 



# with  each  server  strictly  in  the  order  they   appear   in 



# /etc/resolv.conf 



#strict-order



Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.

--
Daniel

Re: DNS : pas de résolution en local

[Migrec]

Le 21/08/2019 à 07:34, Pascal Hambourg a écrit :

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :

Le 20/08/19 à 00:47, Migrec  a écrit :

Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi 
l'échec

de la résolution ne passe pas la main au serveur DNS local ?


Parce qu'il me semble que la résolution n'utilise le 2e dns que si 
le 1er ne répond pas.


En effet. Ou alors répond qu'une erreur interne l'empêche de fournir 
une réponse (SERVFAIL, REFUSED...). En revanche NXDOMAIN (domaine 
inexistant) n'est pas considéré comme une absence de réponse.



Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.


En fait ici il ne dit pas que le nom n'existe pas, sinon il aurait 
répondu avec status=NXDOMAIN. Il répond avec status=NOERROR et 
ANSWER=0, ce qui signifie normalement que le nom existe mais qu'il n'a 
pas d'enregistrement du type demandé (A=adresse IPv4). Pour un client 
cela revient au même, mais cette réponse n'est pas correcte. Si je 
fais la même requête à mon serveur DNS, j'obtiens bien status=NXDOMAIN.


Ou alors les nameserver sont interrogés en même temps et la réponse 
du 1er répondant est utilisée.


Non.

Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.


Merci pour ces précisions.
Mon problème était lié à l'odre des DNS inscrits dans /etc/resolv.conf. 
Or ce fichier est dynamique et je n'ai pas trouvé comment modifier 
l'ordre. Ça semble lié au montage des interfaces réseau.
Du coup, j'ai inversé mes 2 cables ethernet et modifié enp2s0 en enp3s0 
(et vice-versa). De cette façon, c'est ok.


Merci pour les pistes.
--
Migrec

Re: DNS : pas de résolution en local

[Pascal Hambourg]

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :

Le 20/08/19 à 00:47, Migrec  a écrit :

Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec
de la résolution ne passe pas la main au serveur DNS local ?


Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 
1er ne répond pas.


En effet. Ou alors répond qu'une erreur interne l'empêche de fournir une 
réponse (SERVFAIL, REFUSED...). En revanche NXDOMAIN (domaine 
inexistant) n'est pas considéré comme une absence de réponse.



Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.


En fait ici il ne dit pas que le nom n'existe pas, sinon il aurait 
répondu avec status=NXDOMAIN. Il répond avec status=NOERROR et ANSWER=0, 
ce qui signifie normalement que le nom existe mais qu'il n'a pas 
d'enregistrement du type demandé (A=adresse IPv4). Pour un client cela 
revient au même, mais cette réponse n'est pas correcte. Si je fais la 
même requête à mon serveur DNS, j'obtiens bien status=NXDOMAIN.


Ou alors les nameserver sont interrogés en même temps et la réponse du 
1er répondant est utilisée.


Non.

Conclusion : tous les DNS mentionnés dans resolv.conf doivent être 
équivalents.

Re: DNS : pas de résolution en local

[Migrec]

Le 20/08/2019 à 11:00, Daniel Huhardeaux a écrit :

Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :

Le 20/08/19 à 00:47, Migrec  a écrit :

Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi 
l'échec

de la résolution ne passe pas la main au serveur DNS local ?


Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 
1er ne répond pas.

Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.


Ou alors les nameserver sont interrogés en même temps et la réponse du 
1er répondant est utilisée.




Visiblement, le premier répond que le nom n'existe pas.






Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.


C'est donc tout à fait logique ;-)

Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, 
ce sera plus efficace

(celui des box laissant parfois à désirer…)


Quand je dis celui de la box, c'est celui de mon FAI en fait. Mon 
serveur obtient son IP en DHCP depuis la box et le DNS est fournit avec.
Avant la mise à jour, ça fonctionnait bien, j'ai du modifier un 
paramètre DHCP/DNS mais je ne sais pas lequel.


PS : désolé de ne pas avoir répondu aux autres messages, je ne les ai 
pas tous eu (bounce).

--
Migrec

Re: DNS : pas de résolution en local

[Daniel Huhardeaux]

Le 20/08/2019 à 10:55, Daniel Caillibaud a écrit :

Le 20/08/19 à 00:47, Migrec  a écrit :

Ça peut paraître logique car la box n'a pas connaissance de mon réseau
local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec
de la résolution ne passe pas la main au serveur DNS local ?


Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne 
répond pas.
Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.


Ou alors les nameserver sont interrogés en même temps et la réponse du 
1er répondant est utilisée.





Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.


C'est donc tout à fait logique ;-)

Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera 
plus efficace
(celui des box laissant parfois à désirer…)


+1

--
Daniel

Re: DNS : pas de résolution en local

[Daniel Caillibaud]

Le 20/08/19 à 00:47, Migrec  a écrit :
> Ça peut paraître logique car la box n'a pas connaissance de mon réseau 
> local (elle est juste en liaison avec le serveur). Mais pourquoi l'échec 
> de la résolution ne passe pas la main au serveur DNS local ?

Parce qu'il me semble que la résolution n'utilise le 2e dns que si le 1er ne 
répond pas.
Ici le 1er répond que le nom n'existe pas, donc ça s'arrête là.

> Si j'inverse les 2 IP dans /etc/resolv.conf, ça fonctionne.

C'est donc tout à fait logique ;-)

Mais si tu as un resolver local, tu ne devrais utiliser que celui-là, ce sera 
plus efficace
(celui des box laissant parfois à désirer…)

-- 
Daniel

Je sais qu'il n'y a qu'une chance sur un million d'être dévoré
vivant par un lion sur les Champs Elysées, mais il suffit d'une fois.

Re: DNS SQUID

[Eriel Perez]

acabo creo de encontrar el problema.


las 2 pc, la del proxy y la del apache las dos son virtualizadas, pero 
entre ellas hago ping y no se ven. alguna sugerencia?


On 1/9/2019 4:14 PM, Paynalton wrote:
donde tienes tu gateway, lo mejor sería que usaras un archivo de 
configuración .pac para indicar a los navegadores qué segmentos de red 
no pasan por el proxy.

Re: DNS SQUID

[Paynalton]

Depende de la topología de tu red. Si instalaste squid en el mismo lugar
donde tienes tu gateway, lo mejor sería que usaras un archivo de
configuración .pac para indicar a los navegadores qué segmentos de red no
pasan por el proxy.

El mié., 9 de enero de 2019 2:52 p. m., Eriel Perez <
erielperezg...@gmail.com> escribió:

> Saludos amigos.
>
> Tengo mi squid que me resuelve perfectamente todas las paginas a
> internet. mas las que estan en mi intranet no.
>
> me explico mejor.
>
> tengo el servidor mio dns en 1 pc, el squid en otra y un simple apache
> en otra.
>
> salgo para internet mas no me resuelve por ejemplo site.domain.com que
> seria un host en el dns.
>
>
> en el navegador desde una pc interna sin proxy carga bien el site, mas
> el squid no me lo carga. tengo la directiva
>
> dns_nameservers domain.com
>
> establecida en el proxy y nada.
>
> alguna sugerencia.
>
> por cierto desde la misma pc donde esta el proxy
>
> nslookup site.domain.com
>
> funciona correctamente.
>
>
> slds.
>
>

Re: DNS Key rollover for dnsmasq [SOLVED}

[Rick Thomas]

On Oct 7, 2018, at 3:36 AM, Eduardo M KALINOWSKI  
wrote:

> On 07-10-2018 07:11, Rick Thomas wrote:
>> On further study, it seems that (in Debian Stretch, at least) the root KSK’s 
>> used by dnsmasq are taken from the file /usr/share/dns/root.ds, which is 
>> provided by the package dns-root-data; and that package seems to be part of 
>> the standard Stretch installation.  That file lists both keys (the new 
>> “20326” and the old “19036”). So it’s all set to go.  No need to panic…  (-:
> 
> Where did you get that information from? I found nothing about
> dns-root-data in dnsmasq package.
> 
> I'd just add a new trust-anchor to the configuration. Just copy and
> paste from https://github.com/imp/dnsmasq/blob/master/trust-anchors.conf
> 
> -- 
>   O que eu temo não e a estrategia do inimigo, mas os nossos
>   erros
>   -- Pericles, filosofo grego
> 
> Eduardo M KALINOWSKI
> edua...@kalinowski.com.br

Hi Eduardo,

I got it from “ps auww `prep dnsmasq`” then following up what I saw by looking 
in /etc/init.d/dnsmasq, which is called by systemd in 
“/lib/systemd/system/dnsmasq.service” (as is the case for lots of services that 
still rely on /etc/init.d for startup).

Enjoy!
Rick

Re: DNS Key rollover

[Rob van der Putten]

Hi there


On 04/10/2018 20:32, Reco wrote:


Please do not top post.

On Thu, Oct 04, 2018 at 02:15:52PM -0400, Default User wrote:

Hi, Henning.

I am running Unstable, with 4.18.0-2 amd-64 kernel, all updated.

I don't know anything about bind. How do I know what bind version I am
running, and if I need to do anything regarding the change you mentioned?


Stretch's bind has this public part of root's KSK:

# grep -A2 20326 /etc/bind/bind.keys
 # This key (20326) is to be published in the root zone in 2017.
 # Servers which were already using the old key (19036) should
 # roll seamlessly to this new one via RFC 5011 rollover. Servers


I have an old config with just contains 19036.
However, the mkeys file in /var/cache/bind/ contains both. I think this 
is due to 'dnssec-validation auto' in named.conf.



If you have the same - there's nothing to do.
If you don't - DNSSEC will stop working for you in seven days.
If you do not use BIND - there's nothing to do.



Regards,
Rob

Re: DNS Key rollover for dnsmasq [SOLVED}

[Rob van der Putten]

Hi there


On 07/10/2018 12:36, Eduardo M KALINOWSKI wrote:


On 07-10-2018 07:11, Rick Thomas wrote:

On further study, it seems that (in Debian Stretch, at least) the root KSK’s 
used by dnsmasq are taken from the file /usr/share/dns/root.ds, which is 
provided by the package dns-root-data; and that package seems to be part of the 
standard Stretch installation.  That file lists both keys (the new “20326” and 
the old “19036”). So it’s all set to go.  No need to panic…  (-:


Where did you get that information from? I found nothing about
dns-root-data in dnsmasq package.


It depends on dnsmasq-base, which recommends dns-root-data.
Stretch bind9 does not depend on dns-root-data. Backports does.


I'd just add a new trust-anchor to the configuration. Just copy and
paste from https://github.com/imp/dnsmasq/blob/master/trust-anchors.conf



Regards,
Rob

Re: DNS Key rollover for dnsmasq [SOLVED}

[Eduardo M KALINOWSKI]

On 07-10-2018 07:11, Rick Thomas wrote:
> On further study, it seems that (in Debian Stretch, at least) the root KSK’s 
> used by dnsmasq are taken from the file /usr/share/dns/root.ds, which is 
> provided by the package dns-root-data; and that package seems to be part of 
> the standard Stretch installation.  That file lists both keys (the new 
> “20326” and the old “19036”). So it’s all set to go.  No need to panic…  (-:

Where did you get that information from? I found nothing about
dns-root-data in dnsmasq package.

I'd just add a new trust-anchor to the configuration. Just copy and
paste from https://github.com/imp/dnsmasq/blob/master/trust-anchors.conf

-- 
O que eu temo não e a estrategia do inimigo, mas os nossos
erros
-- Pericles, filosofo grego

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: DNS Key rollover for dnsmasq [SOLVED}

[Rick Thomas]

H…

On further study, it seems that (in Debian Stretch, at least) the root KSK’s 
used by dnsmasq are taken from the file /usr/share/dns/root.ds, which is 
provided by the package dns-root-data; and that package seems to be part of the 
standard Stretch installation.  That file lists both keys (the new “20326” and 
the old “19036”). So it’s all set to go.  No need to panic…  (-:

Enjoy!
Rick

Re: DNS Key rollover

[Rick Thomas]

On Oct 4, 2018, at 11:32 AM, Reco  wrote:

> On Thu, Oct 04, 2018 at 02:15:52PM -0400, Default User wrote:
>> Hi, Henning.
>> 
>> I am running Unstable, with 4.18.0-2 amd-64 kernel, all updated.
>> 
>> I don't know anything about bind. How do I know what bind version I am
>> running, and if I need to do anything regarding the change you mentioned?
> 
> Stretch's bind has this public part of root's KSK:
> 
> # grep -A2 20326 /etc/bind/bind.keys
># This key (20326) is to be published in the root zone in 2017.
># Servers which were already using the old key (19036) should
># roll seamlessly to this new one via RFC 5011 rollover. Servers
> 
> If you have the same - there's nothing to do.
> If you don't - DNSSEC will stop working for you in seven days.
> If you do not use BIND - there's nothing to do.
> 
> Reco

How about if I’m using dnsmasq? I’m running a more or less stock stretch with 
dnsmasq and this is what I see when I go looking for trust-anchors:

 cat /usr/share/dnsmasq-base/trust-anchors.conf
# The root DNSSEC trust anchor, valid as at 30/01/2014

# Note that this is a DS record (ie a hash of the root Zone Signing Key) 
# If was downloaded from https://data.iana.org/root-anchors/root-anchors.xml

trust-anchor=.,19036,8,2,49AAC11D7B6F6446702E54A1607371607A1A41855200FD2CE1CDDE32F24E8FB5


Which, IIUC, says it’s using root trust anchor ID 19036 extracted on Jan 30, 
2014, not ID 20326 extracted any time in the last 12 months.

Is there an update I have missed applying?

Thanks!
Rick

Re: DNS Key rollover

[Default User]

On Thu, Oct 4, 2018 at 2:33 PM Reco  wrote:

> Hi.
>
> Please do not top post.
>
> On Thu, Oct 04, 2018 at 02:15:52PM -0400, Default User wrote:
> > Hi, Henning.
> >
> > I am running Unstable, with 4.18.0-2 amd-64 kernel, all updated.
> >
> > I don't know anything about bind. How do I know what bind version I am
> > running, and if I need to do anything regarding the change you mentioned?
>
> Stretch's bind has this public part of root's KSK:
>
> # grep -A2 20326 /etc/bind/bind.keys
> # This key (20326) is to be published in the root zone in 2017.
> # Servers which were already using the old key (19036) should
> # roll seamlessly to this new one via RFC 5011 rollover. Servers
>
> If you have the same - there's nothing to do.
> If you don't - DNSSEC will stop working for you in seven days.
> If you do not use BIND - there's nothing to do.
>
> Reco
>


Hi, guys.

I don't even know what bind is.  But did some checking. AFAIK I never
installed it, don't use it, and it does not appear to exist on my system.

So apparently it is irrelevant for me, and will be ignored for now.
Thanks for the info.

Re: DNS Key rollover

[Reco]

Hi.

Please do not top post.

On Thu, Oct 04, 2018 at 02:15:52PM -0400, Default User wrote:
> Hi, Henning.
> 
> I am running Unstable, with 4.18.0-2 amd-64 kernel, all updated.
> 
> I don't know anything about bind. How do I know what bind version I am
> running, and if I need to do anything regarding the change you mentioned?

Stretch's bind has this public part of root's KSK:

# grep -A2 20326 /etc/bind/bind.keys
# This key (20326) is to be published in the root zone in 2017.
# Servers which were already using the old key (19036) should
# roll seamlessly to this new one via RFC 5011 rollover. Servers

If you have the same - there's nothing to do.
If you don't - DNSSEC will stop working for you in seven days.
If you do not use BIND - there's nothing to do.

Reco

Re: DNS Key rollover

[john doe]

On 10/4/2018 8:15 PM, Default User wrote:
> Hi, Henning.
> 
> I am running Unstable, with 4.18.0-2 amd-64 kernel, all updated.
> 
> I don't know anything about bind. How do I know what bind version I am
> running, and if I need to do anything regarding the change you mentioned?
> 

Are you using BIND at all?

-- 
John Doe

Re: DNS Key rollover

[Default User]

Hi, Henning.

I am running Unstable, with 4.18.0-2 amd-64 kernel, all updated.

I don't know anything about bind. How do I know what bind version I am
running, and if I need to do anything regarding the change you mentioned?


On Thu, Oct 4, 2018, 09:11 Henning Follmann 
wrote:

> Hello Everybody,
> just a small reminder. In one week (yes seven days) a new root anker must
> be used for dnssec resolver.
> If you run bind9 from  current debian stretch you should be fine.
> If you roll your own bind.keys file make sure the key with serial
> 20326 is loaded.
>
> happy resolving,
> -H
>
>
> --
> Henning Follmann   | hfollm...@itcfollmann.com
>
>

Re: DNS server won't talk to me

[Francois Gouget]

On Fri, 20 Apr 2018, Greg Wooledge wrote:
[...]
> You misunderstand.  That's not the resolver that Francois is using.
> It's the authoritative name server for the domain he's trying to resolve
> (maibokun.com).
[...]
> As a *workaround*, sure, he could use a public resolver like Google's
> 8.8.8.8 as a sort of "proxy" that the Japanese name server is willing
> to talk to.  But short of that, he is completely cut off by the
> router on the Japanese end.

Yep. So much for the Internet being a peer-to-peer network :-(

So in the end I configured things to go through a public resolver (but 
not Google). And while I was at it I installed dnscrypt-proxy (which was 
in the news recently and which Bob Weber also mentioned).


-- 
Francois Gouget   http://fgouget.free.fr/
  145 = 1! + 4! + 5!

Re: DNS server won't talk to me

[Greg Wooledge]

On Fri, Apr 20, 2018 at 03:03:22PM +, Glenn English wrote:
> On Fri, Apr 20, 2018 at 10:50 AM, Francois Gouget  wrote:
> 
> > Indeed I cannot ping their DNS server (210.143.111.171) but I just
> > thought they blocked ICMP. However I noticed I can in fact ping it from
> > another host so I did a traceroute and the packets get blocked at the
> > penultimate hop:
> >
> > $ traceroute -n 210.143.111.171
> 
> That IP, according to whois, is in Japan. And those latency numbers a
> pretty big. Have you considered using a different DNS?

You misunderstand.  That's not the resolver that Francois is using.
It's the authoritative name server for the domain he's trying to resolve
(maibokun.com).

wooledg:~$ dig NS maibokun.com
[...]
;; ANSWER SECTION:
maibokun.com.   86400   IN  NS  ns3.fas.jp.
maibokun.com.   86400   IN  NS  ns.maibokun.com.

;; ADDITIONAL SECTION:
ns.maibokun.com.163881  IN  A   210.143.111.171
ns3.fas.jp. 77481   IN  A   210.143.111.241
[...]


As a *workaround*, sure, he could use a public resolver like Google's
8.8.8.8 as a sort of "proxy" that the Japanese name server is willing
to talk to.  But short of that, he is completely cut off by the
router on the Japanese end.

Re: DNS server won't talk to me

[Glenn English]

On Fri, Apr 20, 2018 at 10:50 AM, Francois Gouget  wrote:

> Indeed I cannot ping their DNS server (210.143.111.171) but I just
> thought they blocked ICMP. However I noticed I can in fact ping it from
> another host so I did a traceroute and the packets get blocked at the
> penultimate hop:
>
> $ traceroute -n 210.143.111.171

That IP, according to whois, is in Japan. And those latency numbers a
pretty big. Have you considered using a different DNS?

I just pinged them, and my numbers are also pretty big (143ms), from
Boulder, CO, USA. My latency to the Google DNS server (8.8.8.8) is a
bit under 10ms.

-- 
Glenn English

Re: DNS server won't talk to me

[Greg Wooledge]

On Fri, Apr 20, 2018 at 12:50:16PM +0200, Francois Gouget wrote:
> Indeed I cannot ping their DNS server (210.143.111.171) but I just 
> thought they blocked ICMP. However I noticed I can in fact ping it from 
> another host so I did a traceroute and the packets get blocked at the 
> penultimate hop:

That sounds like their Internet Service Provider may have blocked packets
from your subnet due to a denial of service attack, or spam, or similar
perceived malicious acts.

Or, it could be an accidental misconfiguration of a router.  (Theirs,
not yours.)

Re: DNS server won't talk to me

[Francois Gouget]

On Fri, 20 Apr 2018, Glenn English wrote:

> On Thu, Apr 19, 2018 at 11:44 PM, Francois Gouget  wrote:
> 
> > Are DNS servers banning queries from some residential addresses or
> > something like this?
> 
> I'm banning some, off and on, (I see massive hits from all over the
> globe on my DNS server -- ~100K hits a day above my rate limit). Have
> you tried to ping that unresponsive one to see if it's alive? Or a TCP
> Telnet connection to its port 53?

Indeed I cannot ping their DNS server (210.143.111.171) but I just 
thought they blocked ICMP. However I noticed I can in fact ping it from 
another host so I did a traceroute and the packets get blocked at the 
penultimate hop:

$ traceroute -n 210.143.111.171
traceroute to 210.143.111.171 (210.143.111.171), 30 hops max, 60 byte packets
[...]
21  60.37.54.202  296.022 ms 60.37.54.198  278.166 ms 122.1.245.126  274.472 ms
22  122.1.246.106  270.430 ms  275.228 ms 122.1.246.110  277.430 ms
23  211.0.221.30  273.257 ms  279.265 ms  277.767 ms
24  * * *

On the other host the traceroute finishes with:

19  60.37.54.202  158.630 ms 122.1.245.130  161.021 ms 122.1.245.126  154.684 ms
20  122.1.246.110  147.979 ms 122.1.246.106  149.896 ms 122.1.246.110  155.476 
ms
21  211.0.221.30  156.153 ms  144.694 ms  148.812 ms
22  210.143.111.171  156.433 ms  156.363 ms  159.304 ms


> Is it possible that you've exceeded their rate limit?

I have a script that would try to resolve the maibokun.com hostname once 
a day and the TTL on that appears to be 83334. So I would end up 
accessing their name server once a day. Of course now that it's not 
working and I have tried to figure out what's going on it's been quite a 
bit more.


-- 
Francois Gouget   http://fgouget.free.fr/
May your Tongue stick to the Roof of your Mouth with the Force of a Thousand 
Caramels.

Re: DNS server won't talk to me

[Glenn English]

On Thu, Apr 19, 2018 at 11:44 PM, Francois Gouget  wrote:

> Are DNS servers banning queries from some residential addresses or
> something like this?

I'm banning some, off and on, (I see massive hits from all over the
globe on my DNS server -- ~100K hits a day above my rate limit). Have
you tried to ping that unresponsive one to see if it's alive? Or a TCP
Telnet connection to its port 53? Is it possible that you've exceeded
their rate limit?

-- 
Glenn English

Re: DNS server won't talk to me

[Bob Weber]

On 4/19/18 7:44 PM, Francois Gouget wrote:

So I'm running a bind server and while it works I ran into a domain name
that it refuses to resolve: maibokun.com.

Digging into it, it looks like one DNS server is refusing to talk to me:

On my box:
$ host maibokun.com
;; connection timed out; no servers could be reached
$ host maibokun.com 210.143.111.171
;; connection timed out; no servers could be reached

Same thing on my laptop. But if I connect the laptop to another Wifi
network (thus changing it public IP address) or run the command on a
computer on the other side of the atlantic I get:

$ host maibokun.com
maibokun.com has address 210.188.220.102
maibokun.com mail is handled by 10 mail.maibokun.com.
$ host maibokun.com 210.143.111.171
Using domain server:
Name: 210.143.111.171
Address: 210.143.111.171#53
Aliases:

maibokun.com has address 210.188.220.102
maibokun.com mail is handled by 10 mail.maibokun.com.


Are DNS servers banning queries from some residential addresses or
something like this? Anyone else seeing the same issue?


Try having bind forward the requests to another public DNS server like opendns.  
You could even protect yourself by having opendns block malware and other bad 
sites.   My bind named.conf.options file has the forwarding setup like this.


        forwarders {
    // opendns
    //    208.67.222.222;
    //    208.67.220.220;
    127.0.2.1;
    };
    forward only;

If you are really worried that your DNS queries are being diverted by man in the 
middle attacks use dnscrypt-proxy.  I have dnscrypt-proxy listening on 127.0.2.1 
(as above shows) and forwarding bind's DNS queries to opendns (cisco) over a 
secure channel.  I even redirect all DNS (port 53 udp) queries to any server to 
my bind with a shorewall redirect rule (firewall).


This setup returns this from a host command:

host  maibokun.com
maibokun.com has address 210.188.220.102
maibokun.com mail is handled by 10 mail.maibokun.com.


--


*...Bob*

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

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

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

Re: DNS hits

[Eduardo M KALINOWSKI]

On 11-02-2017 21:11, Glenn English wrote:
>
> On Sat, Feb 11, 2017 at 2:07 PM, Henning Follmann
> > 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.

Naturally there is: in the options section (on Debian, in file
named.conf.options) put
allow-recursion {
  
};



-- 

Meu estilo é incentivar a controvérsia e estimular as pessoas a dizer o que 
pensam

--James Burke

Eduardo M KALINOWSKI
edua...@kalinowski.com.br

Re: DNS hits

[Glenn English]

Sorry, Andy. Here's another try, but to the list...


On Sat, Feb 11, 2017 at 8:40 PM, Glenn English  wrote:

>
>
> On Sat, Feb 11, 2017 at 6:33 PM, Andy Smith  wrote:
>
> If your nameserver offered recursion then it was most likely scanned
>> and added to a list of such servers, and is now being used to take
>> part in distributed denial of service attacks.
>>
>
> I think I was wrong earlier. I did try from an external IP, but I used the
> wrong one.
>
> I tested again from a known alien IP, and I checked with a
> RecursiveNameserverTest on the 'Net. Both tests said I wasn't recursive.
> BIND's config is apparently doing what it said it was doing.
>
>
>> If the really large amount of traffic that is appearing to come
>> from relatively few sources at any given time,
>
>
> No. It's not a small number of sources. There are 650 or so /15s and /16s
> at AWS, all of which are blocked, and several thousand around the world.
> (most in the US, though) A lot of those look like single hosts with just a
> few hits, so I tend to leave them alone, but others are several hosts on
> the same network. Those make it to the packet filter. I don't like Facebook
> and Microsofy anyway :-)
>
> But they just keep coming. And 'most anybody has a bigger pipe than I do.
> I think I may just be experiencing my first DDoS attack. Getting through
> the Cisco router configuration language was a lot easier and a lot more
> fun.
>
> As best I can tell from the replies I've received today, I've done things
> about as right as can be done in my situation. Just wait until they get
> tired of whacking an old T1, I guess...
>
> Thanks much, all.
>
> --
> Glenn English
>
>

Re: DNS hits

[Andy Smith]

Hi Glenn,

On Sat, Feb 11, 2017 at 04:11:13PM -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.

If your nameserver offered recursion then it was most likely scanned
and added to a list of such servers, and is now being used to take
part in distributed denial of service attacks.

If the really large amount of traffic that is appearing to come
from relatively few sources at any given time, then you may
actually be taking part in attack on those apparent sources. The
attackers forge a victim's source address and make a DNS query to an
open resolver for a large record, then the resolver sends that
answer back to the forged source. This inflicts a large amount of
traffic on a third party, as there will be potentially many
thousands of open resolvers doing this all at once.

If on the other hand the really large amount of traffic is coming
from hundreds or thousands of different hosts at once then it is
more likely that you are the victim and they are the open resolvers.

If you're facilitating the DDoS then closing your open resolver
should fix it though not immediately, as they won't know that it
stopped working for a while.

Some more information about the denial of service attacks which use
open recursive nameservers:

http://www.securiteam.com/securityreviews/5GP0L00I0W.html

Cheers,
Andy

-- 
https://bitfolk.com/ -- No-nonsense VPS hosting

Re: DNS hits

[Igor Cicimov]

On 12 Feb 2017 4:59 am, "Glenn English"  wrote:

Is anyone else getting thousands of hits on DNS?

I am, largely from Amazon's AWS. I've emailed Amazon's abuse (from whois),
Amazon's customer support, and added all the IP nets to my packet filter.

But AWS isn't the whole problem -- just the worst offender. And my little
T1 has been, sometimes, DoS'ed by the hits. They are coming from IPs all
over the world, from different sources every day, so I can't ask my ISP to
block them in their big pipe.

Does anybody have any idea how to stop them?

-- 
Glenn English



Your best option is to configure the server as authoritative only and allow
recursion from your private network only (if you haven't done so already)

Re: DNS hits

[Glenn English]

On Sat, Feb 11, 2017 at 2:07 PM, Henning Follmann  wrote:

> On Sat, Feb 11, 2017 at 10:58:54AM -0700, Glenn English wrote:
>
> Nothing about Debian.
>

No, but I've been a Debian user for several years, and the place I know to
ask to get to competent advice and such, is this list. And the server in
question is running Debian, FWIW.


> > Is anyone else getting thousands of hits on DNS?
>
> Hits how?.
>

There's a rate limiter on DNS in my iptables packet filter. The hits I'm
talking about show up in logwatch as log entries from my packet filter --
all of which have exceeded the rate limit. Often vastly.


> Do you run a DNS server with openly available zones?
>

Not sure what an 'open zone' is.


> Not enough information.
> Install dnstop and check what these requests are.
> And then there are so many questions.
>

Very sorry about that, and in retrospect I see what you mean.

But in another post, Henning Follmann suggested what I think will solve my
problem: move my DNS server to my ISP.

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.


> How big are your zones?


40 or so lines in the zone files. Not very big.


> Do you have zones?
>

Sure. I own 3 domains and do a few virtuals.


> Do you allow zone transfers?
>

That I'm pretty sure I don't.  (I saw 'pretty sure' because I was positive
I had recursion turned off for aliens.)


> Do you have multiple DNS servers running? Is your secondary seeing the same
> spike of traffic?
>

No, just one (setting up my servers in a new location). The plan is to hide
that one behind some firewalling (with recursion for the locals) and use
that nameserver from RIPE (that doesn't even know how to do recursion) as
slaves on the 'Net facing servers.

Or maybe get rid of the nameserver. But I do like the ability to go in and
modify things by myself and have it happen right now.

And it's not a spike -- it's (almost) continuous. I looked at the blinking
lights on the router just now, and it's pretty quiet. The script kiddies
must be taking a nap...

-- 
Glenn English

Re: DNS hits

[Henning Follmann]

On Sat, Feb 11, 2017 at 10:58:54AM -0700, Glenn English wrote:

Nothing about Debian.

Anyway...

> Is anyone else getting thousands of hits on DNS?

Hits how?.
Do you run a DNS server with openly available zones?

> 
> I am, largely from Amazon's AWS. I've emailed Amazon's abuse (from whois),
> Amazon's customer support, and added all the IP nets to my packet filter.
> 
> But AWS isn't the whole problem -- just the worst offender. And my little
> T1 has been, sometimes, DoS'ed by the hits. They are coming from IPs all
> over the world, from different sources every day, so I can't ask my ISP to
> block them in their big pipe.
> 
> Does anybody have any idea how to stop them?
> 

Not enough information.
Install dnstop and check what these requests are.
And then there are so many questions.

Does your DNS answer recursive queries?
How big are your zones? Do you have zones?
Do you allow zone transfers?

Do you have multiple DNS servers running? Is your secondary seeing the same
spike of traffic?


-H


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

Re: DNS hits

[Steve Kemp]

On Sat Feb 11, 2017 at 10:58:54 -0700, Glenn English wrote:

>Is anyone else getting thousands of hits on DNS?

  Yes, but that's because I host DNS for popular domains.

>But AWS isn't the whole problem -- just the worst offender. And my little
>T1 has been, sometimes, DoS'ed by the hits. They are coming from IPs all
>over the world, from different sources every day, so I can't ask my ISP to
>block them in their big pipe.

  It sounds like you're running your own DNS server on your instance.
 If that is the case, you might consider moving it to Amazon's route53
 infrastructure.  That would mean that your DNS wouldn't rely upon your
 personal machine, and you're already using AWS ..

  Failing that it might be that remote IPs are trying to exploit your
 server.  Have you tested you're not running an open-resolver, by
 accident?  You should (probably) be running DNS for only your chosen
 domains.

  But sadly, without more information, the best we can do is guess
 that you're being spidered and hammered for fun.  Reporting the abuse
 will likely make no difference, even though it should.

>Does anybody have any idea how to stop them?

  Stop hosting DNS on the machine, by moving it elsewhere.  Also
 sanity-check your configuration.  If this works, you'll have
 trouble, for example:

dig -t a example.com @your.ip.add.ress

Steve
-- 
# Git-based DNS host
https://dns-api.com/

Re: DNS

[Camaleón]

El Wed, 13 Jan 2016 13:37:50 -0500, Luis Ernesto Garcia reyes escribió:

> Saludos estoy configurando el servidor DNS con bind9 y al hacerle
> pruebas internas todo bien pero cuando en na pc externa configuro la red
> para que me reconosca el dns no funciona que puede ser.

Das pocos datos o mejor dicho, no das ninguno :-)

Manda la salida de estos comandos ejecutados desde alguno de los clientes 
que tiene configurado como servidor DNS el bind9:

dig @8.8.8.8 google.com
dig google.es
cat /etc/resolv.conf

Saludos,

-- 
Camaleón

Re: DNS

[listascor...@msjs.co]

El día 13 de enero de 2016, 15:37, Luis Ernesto Garcia reyes
 escribió:

Saludos estoy configurando el servidor DNS con bind9 y al hacerle pruebas 
internas todo bien pero cuando en na pc externa configuro la red para que me 
reconosca el dns no funciona que puede ser.






Hola OddieX,

Sí de pronto no tienes una discapacidad visual u otra, la cual podamos 
adaptarnos y comprender su situación y aceptarle el top posting; 
entonces, por favor; contesta en la parte de abajo, esto lo digo con el 
ánimo constructivo para que todos podamos seguir fácilmente la lectura 
del hilo ordenadamente... contestar debajo del mensaje del otro es lo 
más beneficioso y lo mejor para la mayoría...

tu aporte es tan valioso como el de todos...  gracias por tu aportación:

El 13/01/16 a las 16:41, OddieX escribió:
> Una respuesta muy tonta pero no das mucha info, asique te pregunto:
>
> Te fijaste si tenes el puerto 53 UDP abierto?
>
> nmap -sU -p53 host
>
> Sino hace un nsloockup google.com host...
>
>
>

Saludos;

Nota: Si quieren, cualquier persona puede copiar el mensaje acerca del 
top posting, y pegarlo como respuesta a cualquiera que haga top 
posting... ese mensaje, es una forma educada y respetuosa de incentivar 
a los de la lista a responder debajo del mensaje.

Gracias.

Re: DNS

[OddieX]

El día 13 de enero de 2016, 18:51, listascor...@msjs.co
 escribió:
>>
>> El día 13 de enero de 2016, 15:37, Luis Ernesto Garcia reyes
>>  escribió:
>>>
>>> Saludos estoy configurando el servidor DNS con bind9 y al hacerle pruebas
>>> internas todo bien pero cuando en na pc externa configuro la red para que me
>>> reconosca el dns no funciona que puede ser.
>>>
>>
>>
>
> Hola OddieX,
>
> Sí de pronto no tienes una discapacidad visual u otra, la cual podamos
> adaptarnos y comprender su situación y aceptarle el top posting; entonces,
> por favor; contesta en la parte de abajo, esto lo digo con el ánimo
> constructivo para que todos podamos seguir fácilmente la lectura del hilo
> ordenadamente... contestar debajo del mensaje del otro es lo más beneficioso
> y lo mejor para la mayoría...
> tu aporte es tan valioso como el de todos...  gracias por tu aportación:
>
> El 13/01/16 a las 16:41, OddieX escribió:
>> Una respuesta muy tonta pero no das mucha info, asique te pregunto:
>>
>> Te fijaste si tenes el puerto 53 UDP abierto?
>>
>> nmap -sU -p53 host
>>
>> Sino hace un nsloockup google.com host...
>>
>>
>>
>
> Saludos;
>
> Nota: Si quieren, cualquier persona puede copiar el mensaje acerca del top
> posting, y pegarlo como respuesta a cualquiera que haga top posting... ese
> mensaje, es una forma educada y respetuosa de incentivar a los de la lista a
> responder debajo del mensaje.
> Gracias.
>



Perdon es que tengo configurado el editor de gmail por defecto y
contesta en el top y me olvido! :/

Re: DNS

[OddieX]

Una respuesta muy tonta pero no das mucha info, asique te pregunto:

Te fijaste si tenes el puerto 53 UDP abierto?

nmap -sU -p53 host

Sino hace un nsloockup google.com host...




El día 13 de enero de 2016, 15:37, Luis Ernesto Garcia reyes
 escribió:
> Saludos estoy configurando el servidor DNS con bind9 y al hacerle pruebas 
> internas todo bien pero cuando en na pc externa configuro la red para que me 
> reconosca el dns no funciona que puede ser.
>

Re: DNS et resolv.conf

[Francois Lafont]

Bonsoir,

On 24/10/2015 09:58, Michel wrote:

>> T'es sûr que c'est autorisé et bien interprété ça ($IF_ADDRESS)
>> dans un resolv.conf ? Si oui, tu aurais une doc quelque part qui
>> l'explique parce que perso ça ne me dit rien du tout (mais ça ne
>> prouve rien bien sûr).
> 
> Effectivement, j'avais ça dans mon fichier /etc/network/interfaces du temps 
> ou 
> j'utilisais un script pour iptables. Je n'ai pas trouvé de doc à ce sujet...
> 
> En mettant ceci, ça fonctionne.
> # The primary network interface
> allow-hotplug eth0
> auto eth0
> iface eth0 inet static
>address 192.168.0.2
>netmask 255.255.255.0
>name Carte Ethernet
>broadcast 192.168.0.255
>network 192.168.0.0
>dns-nameservers 192.168.0.2 $IF_ADDRESS
>dns-search homeg.lan
> 
> 
> Ce qui est étonnant, c'est que si je mets $IF_ADDRESS_TEST, la ligne 
> n'apparaît pas alors qu'en gardant $IF_ADDRESS, c'est le nom de la variable 
> qui est inscrit dans le résolveur.

Je ne suis pas sûr t'avoir tout bien compris mais bon... si ça
marche alors tant mieux. ;) Ceci étant, si tu veux interroger
un serveur DNS local, utilise localhost comme adresse et basta,
ça me semble nettement plus simple.

-- 
François Lafont

Re: DNS et resolv.conf

[Michel]

Le samedi 24 octobre 2015, 00:13:19 Francois Lafont a écrit :
> Bonsoir,
> 
> On 23/10/2015 23:53, Michel wrote:
> > Voici mon /etc/resolv.conf :
> > 
> > [root@canoe]:~ # 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 $IF_ADDRESS
> 
>  ^^^
> 
> T'es sûr que c'est autorisé et bien interprété ça ($IF_ADDRESS)
> dans un resolv.conf ? Si oui, tu aurais une doc quelque part qui
> l'explique parce que perso ça ne me dit rien du tout (mais ça ne
> prouve rien bien sûr).

Effectivement, j'avais ça dans mon fichier /etc/network/interfaces du temps ou 
j'utilisais un script pour iptables. Je n'ai pas trouvé de doc à ce sujet...

En mettant ceci, ça fonctionne.
# The primary network interface
allow-hotplug eth0
auto eth0
iface eth0 inet static
   address 192.168.0.2
   netmask 255.255.255.0
   name Carte Ethernet
   broadcast 192.168.0.255
   network 192.168.0.0
   dns-nameservers 192.168.0.2 $IF_ADDRESS
   dns-search homeg.lan


Ce qui est étonnant, c'est que si je mets $IF_ADDRESS_TEST, la ligne 
n'apparaît pas alors qu'en gardant $IF_ADDRESS, c'est le nom de la variable 
qui est inscrit dans le résolveur.

--
Michel

Re: DNS et resolv.conf

[Francois Lafont]

Bonsoir,

On 23/10/2015 23:53, Michel wrote:
 
> Voici mon /etc/resolv.conf :
> 
> [root@canoe]:~ # 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 $IF_ADDRESS 
 ^^^

T'es sûr que c'est autorisé et bien interprété ça ($IF_ADDRESS)
dans un resolv.conf ? Si oui, tu aurais une doc quelque part qui
l'explique parce que perso ça ne me dit rien du tout (mais ça ne
prouve rien bien sûr).

-- 
François Lafont

Re: dns dinâmico

[Caio Ferreira]

lista

a todos, muito obrigado pela ajuda, deu certo.



 .''`.   Caio Abreu Ferreira
: :'  :  abreuf...@gmail.com
`. `'`   Debian User
  `-

2015-09-16 15:33 GMT-03:00 Alan Romão :

> Tem o www.no-ip.com que é de graça, mas tem que revalidar de 30 em 30 dias
>
> *From:* Caio Ferreira 
> *Sent:* Wednesday, September 16, 2015 10:48 AM
> *To:* dup 
> *Subject:* dns dinâmico
>
> Lista
>
> Alguém por acaso conhece algum serviço de DNS Dinâmico free? Eu encontrei
> alguns serviços, como o DynDNS, mas é pago?
>
> Eu montei um servidor owncloud em casa e estava querendo acessar de forma
> remota.
>
> desde já agradeço pela atenção.
>
>
> .''`.   Caio Abreu Ferreira
> : :'  :  abreuf...@gmail.com
> `. `'`   Debian User
>   `-
>

Re: dns dinâmico

[Leonardo Rocha]

On 30-09-2015 09:17, Caio Ferreira wrote:
> lista
>
> a todos, muito obrigado pela ajuda, deu certo.
>
>
>
>  .''`.   Caio Abreu Ferreira
> : :'  :  abreuf...@gmail.com 
> `. `'`   Debian User
>   `-
>
> 2015-09-16 15:33 GMT-03:00 Alan Romão  >:
>
> Tem o www.no-ip.com  que é de graça, mas tem
> que revalidar de 30 em 30 dias
>  
> *From:* Caio Ferreira 
> *Sent:* Wednesday, September 16, 2015 10:48 AM
> *To:* dup 
> *Subject:* dns dinâmico
>  
> Lista
>  
> Alguém por acaso conhece algum serviço de DNS Dinâmico free? Eu
> encontrei alguns serviços, como o DynDNS, mas é pago?
>  
> Eu montei um servidor owncloud em casa e estava querendo acessar
> de forma remota.
>  
> desde já agradeço pela atenção.
>
>
> .''`.   Caio Abreu Ferreira
> : :'  :  abreuf...@gmail.com 
> `. `'`   Debian User
>   `-
>
>
Bom, conheço o https://www.opendns.com/ e o OpenNic

Dá uma olhada em uma notícia sobre ele aqui:

http://www.megaleecher.net/Fast_Safe_And_Censor_Free_DNS_OpenNIC#axzz3nDwQvIFg

espero que ajude para o que precisa.
-- 
*Leonardo Rocha *
*Analista de Sistemas *
*GPG ID: 7E7D1FE2*
*GNU/Linux User: 586696*
Claro: (41) 8731-6868
Site: leonardorocha.eti.br 
Twitter: Leonardo Rocha 

Re: dns dinâmico

[Cláudio E. Elicker]

On Wed, 16 Sep 2015 10:48:32 -0300
Caio Ferreira  wrote:

> Lista
> 
> Alguém por acaso conhece algum serviço de DNS Dinâmico free? Eu
> encontrei alguns serviços, como o DynDNS, mas é pago?
> ...


https://lists.debian.org/debian-user/2014/04/msg00403.html



-- 
EMACS is my operating system; Linux is my device driver.

Re: dns dinâmico

[Tulio Simplicio]

Tem o no ip,  ja tentou?

Em qua, 16 de set de 2015 11:02 AM, Cláudio E. Elicker 
escreveu:

> On Wed, 16 Sep 2015 10:48:32 -0300
> Caio Ferreira  wrote:
>
> > Lista
> >
> > Alguém por acaso conhece algum serviço de DNS Dinâmico free? Eu
> > encontrei alguns serviços, como o DynDNS, mas é pago?
> > ...
>
>
> https://lists.debian.org/debian-user/2014/04/msg00403.html
>
>
>
> --
> EMACS is my operating system; Linux is my device driver.
>
>

Re: DNS (cache) no Jessie

[Flavio Menezes dos Reis]

Keppler, bom dia

Aí vai a receita de bolo:

- Instale o bind9
- Altere o arquivo /etc/bind/named.conf.options para:
acl authorized-clients {
   192.168.200.0/24;
   localhost;
   localnets;
};

options {
   directory /var/cache/bind;

   forwarders {
   8.8.8.8;
   };

   recursion yes;
   allow-query { authorized-clients; };
   forward only;


   dnssec-validation yes;
   dnssec-enable yes;
   auth-nxdomain no;# conform to RFC1035
   listen-on-v6 { any; }; };


- service bind9 restart

E pode apontar as estações para o IP do servidor

Em 6 de agosto de 2015 23:44, Dennis Gonçalves camaradaden...@gmail.com
escreveu:

 Amigo,

 você tem dnsmasq instalado na sua maquina? Pode ser que estivesse vindo
 por padrão na wheezy... mas isso não vou saber te informar.

 Minha experiência é só com redes domésticas, mas até onde sei não adianta
 apontar os pedidos de dns para o servidor local se este não estiver
 configurado para processá-los. Isso pode ser feito, como o Marcos falou,
 com regras de forward do iptables ou com um serviço de resolução local
 rodando no servidor.

 A segunda opção costuma ser implementada com dnsmasq, que é também um
 servidor DHCP (mas pode ser configurado só a parte de DNS). Pelo que
 relatou não penso que tenha necessidade de usar o bind, que é muito maior.

 https://wiki.debian.org/HowTo/dnsmasq

 Falou,
 Dennis


 Em 6 de agosto de 2015 19:37, Vítor Meneguzzi Groterhorst 
 vitor...@gmail.com escreveu:

 Também pode interessar:
 https://wiki.debian.org/Bind9

 https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04

 Se não me engano (não estou no Debian no momento para testar) o servidor
 DNS usado é o Bind9. Estão aí dois links sobre ele, se quiser dar uma
 olhada. O segundo é para Ubuntu mas creio que deva funcionar ok no Debian.

 Em 6 de agosto de 2015 19:23, Vítor Meneguzzi Groterhorst 
 vitor...@gmail.com escreveu:

 Você marcou a opção de instalar o servidor DNS durante a instalação (
 http://screenshots.debian.net/screenshot/tasksel)? Dé uma olhada na
 tasksel (equivalente a essa opção da instalação) do servidor DNS (
 https://wiki.debian.org/tasksel).


 @Rabatone
 Legal te ver por aqui, cara. Acabei de me inscrever, não sabia que você
 estava por aqui.

 Em 6 de agosto de 2015 19:02, Keppler jurgenkepp...@gmail.com
 escreveu:

 Não cara...pior que não




 Em 06-08-2015 18:43, Thiago T. Faioli escreveu:

 Não seria falta de rota no seu GW?
 Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com
 escreveu:

 Velho! Continua simples dessa forma...
 Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Diego!
 Não sei se expliquei direito.
 Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão
 com a internet, subir as regras do iptables (que inclusive compartilha a
 conexão) e pronto!
 Nas estações (tanto faz Windows/Linux) bastava apontar o *Gateway*
 padrão e o *DNS primario* destas estações para o IP do Servidor e
 tudo funcionava. Não tinha que fazer nenhum redirectnão tinha que 
 fazer
 nada!!!


 Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

 Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

 Se você vai simplesmente fazer um redirect do pedido, porque não
 configurar diretamente o DNS do Google (ou qualquer outro externo) nos
 máquinas locais?

 A ideia de usar uma máquina local como DNS não seria que ela
 fizesse um cache do DNS local que respondesse mais rapidamente às
 requisições do que ter que aguardar o pacote transitar até o servidor de
 DNS externo e voltar? (Lembrando que agora os DNS's do google não 
 respondem
 mais da américa latina, agora é tudo nos EUA para nós, ou seja, não é o
 melhor em termos de desempenho).


 Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que
 fazer nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um
 redirecionamento, tudo que for para a porta 53 do ip 192.168.200.254
 redireciona para o 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu
 colocar, por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google
 por exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas
 estações (Windows) elas não conseguem navegar (resolver os endereços), 
 ou
 seja, na configuração de rede sempre coloco como GATEWAY e DNS o ip do
 servidor, no caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no
 DNS por exemplo o ip do 

Re: DNS (cache) no Jessie

[Thiago T. Faioli]

Não seria falta de rota no seu GW?
Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com escreveu:

 Velho! Continua simples dessa forma...
 Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Diego!
 Não sei se expliquei direito.
 Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão com
 a internet, subir as regras do iptables (que inclusive compartilha a
 conexão) e pronto!
 Nas estações (tanto faz Windows/Linux) bastava apontar o *Gateway*
 padrão e o *DNS primario* destas estações para o IP do Servidor e tudo
 funcionava. Não tinha que fazer nenhum redirectnão tinha que fazer
 nada!!!


 Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

 Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

 Se você vai simplesmente fazer um redirect do pedido, porque não
 configurar diretamente o DNS do Google (ou qualquer outro externo) nos
 máquinas locais?

 A ideia de usar uma máquina local como DNS não seria que ela fizesse um
 cache do DNS local que respondesse mais rapidamente às requisições do que
 ter que aguardar o pacote transitar até o servidor de DNS externo e voltar?
 (Lembrando que agora os DNS's do google não respondem mais da américa
 latina, agora é tudo nos EUA para nós, ou seja, não é o melhor em termos de
 desempenho).


 Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que fazer
 nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um redirecionamento,
 tudo que for para a porta 53 do ip 192.168.200.254 redireciona para o
 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu
 colocar, por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no DNS
 por exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to
 debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com






 --
 
 Diego Rabatone Oliveira
 http://blog.diraol.eng.br
 diraol(arroba)diraol(ponto)eng(ponto)br
 Twitter: @diraol

Re: DNS (cache) no Jessie

[Keppler]

Não cara...pior que não



Em 06-08-2015 18:43, Thiago T. Faioli escreveu:


Não seria falta de rota no seu GW?

Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com 
mailto:thiago.fai...@gmail.com escreveu:


Velho! Continua simples dessa forma...

Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com
mailto:jurgenkepp...@gmail.com escreveu:

Olá Diego!
Não sei se expliquei direito.
Mas até o Debian-7, bastava instalar o Servidor, configurar a
conexão com a internet, subir as regras do iptables (que
inclusive compartilha a conexão) e pronto!
Nas estações (tanto faz Windows/Linux) bastava apontar o
_*Gateway*_ padrão e o *DNS primario* destas estações para o
IP do Servidor e tudo funcionava. Não tinha que fazer nenhum
redirectnão tinha que fazer nada!!!


Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

Se você vai simplesmente fazer um redirect do pedido,
porque não configurar diretamente o DNS do Google (ou
qualquer outro externo) nos máquinas locais?

A ideia de usar uma máquina local como DNS não seria que
ela fizesse um cache do DNS local que respondesse mais
rapidamente às requisições do que ter que aguardar o pacote
transitar até o servidor de DNS externo e voltar? (Lembrando
que agora os DNS's do google não respondem mais da américa
latina, agora é tudo nos EUA para nós, ou seja, não é o
melhor em termos de desempenho).


Em 6 de agosto de 2015 11:20, Keppler
jurgenkepp...@gmail.com mailto:jurgenkepp...@gmail.com
escreveu:

Olá Marcos, obrigado por sua resposta!

Nossa, porque tudo isso?...antes era tão simples!...não
tinha que fazer nada disso!



Em 06-08-2015 11:15, Marcos Carraro escreveu:

Bom Dia,

Instala um servidor DNS Cache no proprio FW, ou faz um
redirecionamento, tudo que for para a porta 53 do ip
192.168.200.254 redireciona para o 8.8.8.8

abraços

*--*
Att
Marcos Carraro
about.me/marcoscarraro http://about.me/marcoscarraro

Em 6 de agosto de 2015 10:38, Keppler
jurgenkepp...@gmail.com
mailto:jurgenkepp...@gmail.com escreveu:

Olá pessoal.
Até o Debian-7 sempre funcionou normal num servidor
firewall eu colocar, por exemplo, no
/etc/resolv.conf o DNS do Google: 8.8.8.8

No servidor tudo funciona normal, ou seja, se eu
pingar o Google por exemplo ele resolve bonitinho o
endereço.

Supondo que o IP do meu servidor seja
192.168.200.254,  nas estações (Windows) elas não
conseguem navegar (resolver os endereços), ou seja,
na configuração de rede sempre coloco como GATEWAY e
DNS o ip do servidor, no caso, 192.168.200.254.

Então agora, para poder navegar, tenho que colocar
nas estações no DNS por exemplo o ip do Google: 8.8.8.8

Aí sim elas navegam!

Como resolvo isso no Debian-8 ?

grato,
Jurgen


-- 
To UNSUBSCRIBE, email to

debian-user-portuguese-requ...@lists.debian.org
mailto:debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
mailto:listmas...@lists.debian.org
Archive:
https://lists.debian.org/55c36352.4000...@gmail.com







-- 


Diego Rabatone Oliveira
http://blog.diraol.eng.br http://blog.diraol.eng.br/
diraol(arroba)diraol(ponto)eng(ponto)br
Twitter: @diraol

Re: DNS (cache) no Jessie

[Thiago T. Faioli]

Velho! Continua simples dessa forma...
Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Diego!
 Não sei se expliquei direito.
 Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão com
 a internet, subir as regras do iptables (que inclusive compartilha a
 conexão) e pronto!
 Nas estações (tanto faz Windows/Linux) bastava apontar o *Gateway* padrão
 e o *DNS primario* destas estações para o IP do Servidor e tudo
 funcionava. Não tinha que fazer nenhum redirectnão tinha que fazer
 nada!!!


 Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

 Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

 Se você vai simplesmente fazer um redirect do pedido, porque não
 configurar diretamente o DNS do Google (ou qualquer outro externo) nos
 máquinas locais?

 A ideia de usar uma máquina local como DNS não seria que ela fizesse um
 cache do DNS local que respondesse mais rapidamente às requisições do que
 ter que aguardar o pacote transitar até o servidor de DNS externo e voltar?
 (Lembrando que agora os DNS's do google não respondem mais da américa
 latina, agora é tudo nos EUA para nós, ou seja, não é o melhor em termos de
 desempenho).


 Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que fazer
 nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um redirecionamento,
 tudo que for para a porta 53 do ip 192.168.200.254 redireciona para o
 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu colocar,
 por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no DNS
 por exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com






 --
 
 Diego Rabatone Oliveira
 http://blog.diraol.eng.br
 diraol(arroba)diraol(ponto)eng(ponto)br
 Twitter: @diraol

Re: DNS (cache) no Jessie

[Vítor Meneguzzi Groterhorst]

Também pode interessar:
https://wiki.debian.org/Bind9
https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04

Se não me engano (não estou no Debian no momento para testar) o servidor
DNS usado é o Bind9. Estão aí dois links sobre ele, se quiser dar uma
olhada. O segundo é para Ubuntu mas creio que deva funcionar ok no Debian.

Em 6 de agosto de 2015 19:23, Vítor Meneguzzi Groterhorst 
vitor...@gmail.com escreveu:

 Você marcou a opção de instalar o servidor DNS durante a instalação (
 http://screenshots.debian.net/screenshot/tasksel)? Dé uma olhada na
 tasksel (equivalente a essa opção da instalação) do servidor DNS (
 https://wiki.debian.org/tasksel).


 @Rabatone
 Legal te ver por aqui, cara. Acabei de me inscrever, não sabia que você
 estava por aqui.

 Em 6 de agosto de 2015 19:02, Keppler jurgenkepp...@gmail.com escreveu:

 Não cara...pior que não




 Em 06-08-2015 18:43, Thiago T. Faioli escreveu:

 Não seria falta de rota no seu GW?
 Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com
 escreveu:

 Velho! Continua simples dessa forma...
 Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Diego!
 Não sei se expliquei direito.
 Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão
 com a internet, subir as regras do iptables (que inclusive compartilha a
 conexão) e pronto!
 Nas estações (tanto faz Windows/Linux) bastava apontar o *Gateway*
 padrão e o *DNS primario* destas estações para o IP do Servidor e tudo
 funcionava. Não tinha que fazer nenhum redirectnão tinha que fazer
 nada!!!


 Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

 Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

 Se você vai simplesmente fazer um redirect do pedido, porque não
 configurar diretamente o DNS do Google (ou qualquer outro externo) nos
 máquinas locais?

 A ideia de usar uma máquina local como DNS não seria que ela fizesse
 um cache do DNS local que respondesse mais rapidamente às requisições do
 que ter que aguardar o pacote transitar até o servidor de DNS externo e
 voltar? (Lembrando que agora os DNS's do google não respondem mais da
 américa latina, agora é tudo nos EUA para nós, ou seja, não é o melhor em
 termos de desempenho).


 Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que
 fazer nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um
 redirecionamento, tudo que for para a porta 53 do ip 192.168.200.254
 redireciona para o 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu
 colocar, por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, 
 no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no
 DNS por exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to
 debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com






 --
 
 Diego Rabatone Oliveira
 http://blog.diraol.eng.br
 diraol(arroba)diraol(ponto)eng(ponto)br
 Twitter: @diraol

Re: DNS (cache) no Jessie

[Vítor Meneguzzi Groterhorst]

Você marcou a opção de instalar o servidor DNS durante a instalação (
http://screenshots.debian.net/screenshot/tasksel)? Dé uma olhada na tasksel
(equivalente a essa opção da instalação) do servidor DNS (
https://wiki.debian.org/tasksel).


@Rabatone
Legal te ver por aqui, cara. Acabei de me inscrever, não sabia que você
estava por aqui.

Em 6 de agosto de 2015 19:02, Keppler jurgenkepp...@gmail.com escreveu:

 Não cara...pior que não




 Em 06-08-2015 18:43, Thiago T. Faioli escreveu:

 Não seria falta de rota no seu GW?
 Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com
 escreveu:

 Velho! Continua simples dessa forma...
 Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Diego!
 Não sei se expliquei direito.
 Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão
 com a internet, subir as regras do iptables (que inclusive compartilha a
 conexão) e pronto!
 Nas estações (tanto faz Windows/Linux) bastava apontar o *Gateway*
 padrão e o *DNS primario* destas estações para o IP do Servidor e tudo
 funcionava. Não tinha que fazer nenhum redirectnão tinha que fazer
 nada!!!


 Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

 Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

 Se você vai simplesmente fazer um redirect do pedido, porque não
 configurar diretamente o DNS do Google (ou qualquer outro externo) nos
 máquinas locais?

 A ideia de usar uma máquina local como DNS não seria que ela fizesse
 um cache do DNS local que respondesse mais rapidamente às requisições do
 que ter que aguardar o pacote transitar até o servidor de DNS externo e
 voltar? (Lembrando que agora os DNS's do google não respondem mais da
 américa latina, agora é tudo nos EUA para nós, ou seja, não é o melhor em
 termos de desempenho).


 Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que fazer
 nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um
 redirecionamento, tudo que for para a porta 53 do ip 192.168.200.254
 redireciona para o 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu
 colocar, por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no DNS
 por exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to
 debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com






 --
 
 Diego Rabatone Oliveira
 http://blog.diraol.eng.br
 diraol(arroba)diraol(ponto)eng(ponto)br
 Twitter: @diraol

Re: DNS (cache) no Jessie

[Dennis Gonçalves]

Amigo,

você tem dnsmasq instalado na sua maquina? Pode ser que estivesse vindo por
padrão na wheezy... mas isso não vou saber te informar.

Minha experiência é só com redes domésticas, mas até onde sei não adianta
apontar os pedidos de dns para o servidor local se este não estiver
configurado para processá-los. Isso pode ser feito, como o Marcos falou,
com regras de forward do iptables ou com um serviço de resolução local
rodando no servidor.

A segunda opção costuma ser implementada com dnsmasq, que é também um
servidor DHCP (mas pode ser configurado só a parte de DNS). Pelo que
relatou não penso que tenha necessidade de usar o bind, que é muito maior.

https://wiki.debian.org/HowTo/dnsmasq

Falou,
Dennis


Em 6 de agosto de 2015 19:37, Vítor Meneguzzi Groterhorst 
vitor...@gmail.com escreveu:

 Também pode interessar:
 https://wiki.debian.org/Bind9

 https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04

 Se não me engano (não estou no Debian no momento para testar) o servidor
 DNS usado é o Bind9. Estão aí dois links sobre ele, se quiser dar uma
 olhada. O segundo é para Ubuntu mas creio que deva funcionar ok no Debian.

 Em 6 de agosto de 2015 19:23, Vítor Meneguzzi Groterhorst 
 vitor...@gmail.com escreveu:

 Você marcou a opção de instalar o servidor DNS durante a instalação (
 http://screenshots.debian.net/screenshot/tasksel)? Dé uma olhada na
 tasksel (equivalente a essa opção da instalação) do servidor DNS (
 https://wiki.debian.org/tasksel).


 @Rabatone
 Legal te ver por aqui, cara. Acabei de me inscrever, não sabia que você
 estava por aqui.

 Em 6 de agosto de 2015 19:02, Keppler jurgenkepp...@gmail.com escreveu:

 Não cara...pior que não




 Em 06-08-2015 18:43, Thiago T. Faioli escreveu:

 Não seria falta de rota no seu GW?
 Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com
 escreveu:

 Velho! Continua simples dessa forma...
 Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Diego!
 Não sei se expliquei direito.
 Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão
 com a internet, subir as regras do iptables (que inclusive compartilha a
 conexão) e pronto!
 Nas estações (tanto faz Windows/Linux) bastava apontar o *Gateway*
 padrão e o *DNS primario* destas estações para o IP do Servidor e
 tudo funcionava. Não tinha que fazer nenhum redirectnão tinha que 
 fazer
 nada!!!


 Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

 Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

 Se você vai simplesmente fazer um redirect do pedido, porque não
 configurar diretamente o DNS do Google (ou qualquer outro externo) nos
 máquinas locais?

 A ideia de usar uma máquina local como DNS não seria que ela fizesse
 um cache do DNS local que respondesse mais rapidamente às requisições do
 que ter que aguardar o pacote transitar até o servidor de DNS externo e
 voltar? (Lembrando que agora os DNS's do google não respondem mais da
 américa latina, agora é tudo nos EUA para nós, ou seja, não é o melhor em
 termos de desempenho).


 Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que
 fazer nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um
 redirecionamento, tudo que for para a porta 53 do ip 192.168.200.254
 redireciona para o 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com
 escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu
 colocar, por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, 
 na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, 
 no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no
 DNS por exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to
 debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com






 --
 
 Diego Rabatone Oliveira
 http://blog.diraol.eng.br
 diraol(arroba)diraol(ponto)eng(ponto)br
 Twitter: @diraol








-- 




*JORNAL BRASIL DE FATOUma visão Popular do Brasil e do Mundo *
*assine! *http://www.brasildefato.com.br


*EDITORA EXPRESSÃO POPULARLivros bons, de boa qualidade e a preço de custo*
http://www.expressaopopular.com.br

Re: DNS (cache) no Jessie

[Ricardo César]

Pra fazer cache eu daria uma olhada no unbound, pelo que li parece ser melhor.

Enviado do Yahoo Mail no Android

De:Vítor Meneguzzi Groterhorst vitor...@gmail.com
Data:19:37 qui, 6 de ago de PM
Assunto:Re: DNS (cache) no Jessie

Também pode interessar:
https://wiki.debian.org/Bind9
https://www.digitalocean.com/community/tutorials/how-to-configure-bind-as-a-caching-or-forwarding-dns-server-on-ubuntu-14-04

Se não me engano (não estou no Debian no momento para testar) o servidor DNS 
usado é o Bind9. Estão aí dois links sobre ele, se quiser dar uma olhada. O 
segundo é para Ubuntu mas creio que deva funcionar ok no Debian.


Em 6 de agosto de 2015 19:23, Vítor Meneguzzi Groterhorst vitor...@gmail.com 
escreveu:

Você marcou a opção de instalar o servidor DNS durante a instalação 
(http://screenshots.debian.net/screenshot/tasksel)? Dé uma olhada na tasksel 
(equivalente a essa opção da instalação) do servidor DNS 
(https://wiki.debian.org/tasksel).


@Rabatone

Legal te ver por aqui, cara. Acabei de me inscrever, não sabia que você estava 
por aqui.


Em 6 de agosto de 2015 19:02, Keppler jurgenkepp...@gmail.com escreveu:

Não cara...pior que não





Em 06-08-2015 18:43, Thiago T. Faioli escreveu:

Não seria falta de rota no seu GW?

Em 06/08/2015 18:39, Thiago T. Faioli thiago.fai...@gmail.com escreveu:

Velho! Continua simples dessa forma...

Em 06/08/2015 11:38, Keppler jurgenkepp...@gmail.com escreveu:

Olá Diego!
Não sei se expliquei direito.
Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão com a 
internet, subir as regras do iptables (que inclusive compartilha a conexão) e 
pronto!
Nas estações (tanto faz Windows/Linux) bastava apontar o Gateway padrão e o DNS 
primario destas estações para o IP do Servidor e tudo funcionava. Não tinha que 
fazer nenhum redirectnão tinha que fazer nada!!!


Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

Se você vai simplesmente fazer um redirect do pedido, porque não configurar 
diretamente o DNS do Google (ou qualquer outro externo) nos máquinas locais?

A ideia de usar uma máquina local como DNS não seria que ela fizesse um cache 
do DNS local que respondesse mais rapidamente às requisições do que ter que 
aguardar o pacote transitar até o servidor de DNS externo e voltar? (Lembrando 
que agora os DNS's do google não respondem mais da américa latina, agora é tudo 
nos EUA para nós, ou seja, não é o melhor em termos de desempenho).


Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com escreveu:

Olá Marcos, obrigado por sua resposta!

Nossa, porque tudo isso?...antes era tão simples!...não tinha que fazer nada 
disso! 




Em 06-08-2015 11:15, Marcos Carraro escreveu:

Bom Dia,


Instala um servidor DNS Cache no proprio FW, ou faz um redirecionamento, tudo 
que for para a porta 53 do ip 192.168.200.254 redireciona para o 8.8.8.8


abraços


-- 

Att

Marcos Carraro

about.me/marcoscarraro


Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com escreveu:

Olá pessoal.
Até o Debian-7 sempre funcionou normal num servidor firewall eu colocar, por 
exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

No servidor tudo funciona normal, ou seja, se eu pingar o Google por exemplo 
ele resolve bonitinho o endereço.

Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações (Windows) 
elas não conseguem navegar (resolver os endereços), ou seja, na configuração de 
rede sempre coloco como GATEWAY e DNS o ip do servidor, no caso, 
192.168.200.254.

Então agora, para poder navegar, tenho que colocar nas estações no DNS por 
exemplo o ip do Google: 8.8.8.8

Aí sim elas navegam!

Como resolvo isso no Debian-8 ?

grato,
Jurgen


-- 
To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/55c36352.4000...@gmail.com






-- 


Diego Rabatone Oliveira
http://blog.diraol.eng.br
diraol(arroba)diraol(ponto)eng(ponto)br
Twitter: @diraol

Re: DNS (cache) no Jessie

[Marcos Carraro]

Bom Dia,

Instala um servidor DNS Cache no proprio FW, ou faz um redirecionamento,
tudo que for para a porta 53 do ip 192.168.200.254 redireciona para o
8.8.8.8

abraços

*--*
Att
Marcos Carraro
about.me/marcoscarraro

Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu colocar,
 por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no DNS por
 exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com

Re: DNS (cache) no Jessie

[Keppler]

Olá Marcos, obrigado por sua resposta!

Nossa, porque tudo isso?...antes era tão simples!...não tinha que fazer 
nada disso!



Em 06-08-2015 11:15, Marcos Carraro escreveu:

Bom Dia,

Instala um servidor DNS Cache no proprio FW, ou faz um 
redirecionamento, tudo que for para a porta 53 do ip 192.168.200.254 
redireciona para o 8.8.8.8


abraços

*--*
Att
Marcos Carraro
about.me/marcoscarraro http://about.me/marcoscarraro

Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com 
mailto:jurgenkepp...@gmail.com escreveu:


Olá pessoal.
Até o Debian-7 sempre funcionou normal num servidor firewall eu
colocar, por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

No servidor tudo funciona normal, ou seja, se eu pingar o Google
por exemplo ele resolve bonitinho o endereço.

Supondo que o IP do meu servidor seja 192.168.200.254,  nas
estações (Windows) elas não conseguem navegar (resolver os
endereços), ou seja, na configuração de rede sempre coloco como
GATEWAY e DNS o ip do servidor, no caso, 192.168.200.254.

Então agora, para poder navegar, tenho que colocar nas estações no
DNS por exemplo o ip do Google: 8.8.8.8

Aí sim elas navegam!

Como resolvo isso no Debian-8 ?

grato,
Jurgen


-- 
To UNSUBSCRIBE, email to

debian-user-portuguese-requ...@lists.debian.org
mailto:debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org mailto:listmas...@lists.debian.org
Archive: https://lists.debian.org/55c36352.4000...@gmail.com

Re: DNS (cache) no Jessie

[Diego Rabatone Oliveira]

Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

Se você vai simplesmente fazer um redirect do pedido, porque não
configurar diretamente o DNS do Google (ou qualquer outro externo) nos
máquinas locais?

A ideia de usar uma máquina local como DNS não seria que ela fizesse um
cache do DNS local que respondesse mais rapidamente às requisições do que
ter que aguardar o pacote transitar até o servidor de DNS externo e voltar?
(Lembrando que agora os DNS's do google não respondem mais da américa
latina, agora é tudo nos EUA para nós, ou seja, não é o melhor em termos de
desempenho).


Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com escreveu:

 Olá Marcos, obrigado por sua resposta!

 Nossa, porque tudo isso?...antes era tão simples!...não tinha que fazer
 nada disso!



 Em 06-08-2015 11:15, Marcos Carraro escreveu:

 Bom Dia,

 Instala um servidor DNS Cache no proprio FW, ou faz um redirecionamento,
 tudo que for para a porta 53 do ip 192.168.200.254 redireciona para o
 8.8.8.8

 abraços

 *--*
 Att
 Marcos Carraro
 about.me/marcoscarraro

 Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com escreveu:

 Olá pessoal.
 Até o Debian-7 sempre funcionou normal num servidor firewall eu colocar,
 por exemplo, no /etc/resolv.conf o DNS do Google: 8.8.8.8

 No servidor tudo funciona normal, ou seja, se eu pingar o Google por
 exemplo ele resolve bonitinho o endereço.

 Supondo que o IP do meu servidor seja 192.168.200.254,  nas estações
 (Windows) elas não conseguem navegar (resolver os endereços), ou seja, na
 configuração de rede sempre coloco como GATEWAY e DNS o ip do servidor, no
 caso, 192.168.200.254.

 Então agora, para poder navegar, tenho que colocar nas estações no DNS
 por exemplo o ip do Google: 8.8.8.8

 Aí sim elas navegam!

 Como resolvo isso no Debian-8 ?

 grato,
 Jurgen


 --
 To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: https://lists.debian.org/55c36352.4000...@gmail.com






-- 

Diego Rabatone Oliveira
http://blog.diraol.eng.br
diraol(arroba)diraol(ponto)eng(ponto)br
Twitter: @diraol

Re: DNS (cache) no Jessie

[Keppler]

Olá Diego!
Não sei se expliquei direito.
Mas até o Debian-7, bastava instalar o Servidor, configurar a conexão 
com a internet, subir as regras do iptables (que inclusive compartilha a 
conexão) e pronto!
Nas estações (tanto faz Windows/Linux) bastava apontar o _*Gateway*_ 
padrão e o *DNS primario* destas estações para o IP do Servidor e tudo 
funcionava. Não tinha que fazer nenhum redirectnão tinha que fazer 
nada!!!



Em 06-08-2015 11:33, Diego Rabatone Oliveira escreveu:

Não entendo muito do assunto, mas me surgiu a seguinte dúvida:

Se você vai simplesmente fazer um redirect do pedido, porque não 
configurar diretamente o DNS do Google (ou qualquer outro externo) nos 
máquinas locais?


A ideia de usar uma máquina local como DNS não seria que ela fizesse 
um cache do DNS local que respondesse mais rapidamente às requisições 
do que ter que aguardar o pacote transitar até o servidor de DNS 
externo e voltar? (Lembrando que agora os DNS's do google não 
respondem mais da américa latina, agora é tudo nos EUA para nós, ou 
seja, não é o melhor em termos de desempenho).



Em 6 de agosto de 2015 11:20, Keppler jurgenkepp...@gmail.com 
mailto:jurgenkepp...@gmail.com escreveu:


Olá Marcos, obrigado por sua resposta!

Nossa, porque tudo isso?...antes era tão simples!...não tinha que
fazer nada disso!



Em 06-08-2015 11:15, Marcos Carraro escreveu:

Bom Dia,

Instala um servidor DNS Cache no proprio FW, ou faz um
redirecionamento, tudo que for para a porta 53 do ip
192.168.200.254 redireciona para o 8.8.8.8

abraços

*--*
Att
Marcos Carraro
about.me/marcoscarraro http://about.me/marcoscarraro

Em 6 de agosto de 2015 10:38, Keppler jurgenkepp...@gmail.com
mailto:jurgenkepp...@gmail.com escreveu:

Olá pessoal.
Até o Debian-7 sempre funcionou normal num servidor firewall
eu colocar, por exemplo, no /etc/resolv.conf o DNS do
Google: 8.8.8.8

No servidor tudo funciona normal, ou seja, se eu pingar o
Google por exemplo ele resolve bonitinho o endereço.

Supondo que o IP do meu servidor seja 192.168.200.254,  nas
estações (Windows) elas não conseguem navegar (resolver os
endereços), ou seja, na configuração de rede sempre coloco
como GATEWAY e DNS o ip do servidor, no caso, 192.168.200.254.

Então agora, para poder navegar, tenho que colocar nas
estações no DNS por exemplo o ip do Google: 8.8.8.8

Aí sim elas navegam!

Como resolvo isso no Debian-8 ?

grato,
Jurgen


-- 
To UNSUBSCRIBE, email to

debian-user-portuguese-requ...@lists.debian.org
mailto:debian-user-portuguese-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org mailto:listmas...@lists.debian.org
Archive: https://lists.debian.org/55c36352.4000...@gmail.com







--

Diego Rabatone Oliveira
http://blog.diraol.eng.br http://blog.diraol.eng.br/
diraol(arroba)diraol(ponto)eng(ponto)br
Twitter: @diraol

Re: DNS primario baneado de AWS DNS?

[Camaleón]

El Mon, 11 May 2015 09:51:40 -0300, Mauro Antivero escribió:

 Estimados, luego de un inconveniente que tuvimos la semana pasada parece
 que los DNS de AWS (Amazon Web Services) han baneado a nuestro
 servidor DNS primario, por lo cual no podemos resolver numerosos
 dominios que tengan a AWS DNS como servidor autoritativo (que son
 muchos), salvo que pasemos a usar nuestro DNS secundario. El problema
 que ocasionó esto estaría resuelto, por lo que estamos viendo como hacer
 para anular dicho baneo, pero hasta ahora no he encontrado ninguna
 información de contacto ni nada por el estilo.

Pues ya les vale :-/

https://aws.amazon.com/es/contact-us/

 A continuación les paso la salida de dig usando nuestro DNS primario:
 
 dig ciudad.com @ip-dns-1rio
 
 ;  DiG 9.9.5-3ubuntu0.2-Ubuntu  ciudad.com @benito ;; global
 options: +cmd ;; connection timed out; no servers could be reached
 
 Si uso para la consulta a nuestro DNS secundario la respuesta que
 obtengo es la normal.
 
 Les agradecería mucho cualquier sugerencia que me puedan dar al respecto
 como para poder ir solucionando este inconveniente.

¿No podrías reenviar las peticiones desde el DNS primario al secundario? 
Seguramente hayan bloqueado la IP del servidor.

Saludos,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/pan.2015.05.11.14.03...@gmail.com

Re: DNS primario baneado de AWS DNS?

[Juan Francisco]

El 11/05/2015 a las 14:51, Mauro Antivero escribió:
Estimados, luego de un inconveniente que tuvimos la semana pasada 
parece que los DNS de AWS (Amazon Web Services) han baneado a 
nuestro servidor DNS primario, por lo cual no podemos resolver 
numerosos dominios que tengan a AWS DNS como servidor autoritativo 
(que son muchos), salvo que pasemos a usar nuestro DNS secundario. El 
problema que ocasionó esto estaría resuelto, por lo que estamos viendo 
como hacer para anular dicho baneo, pero hasta ahora no he encontrado 
ninguna información de contacto ni nada por el estilo.


A continuación les paso la salida de dig usando nuestro DNS primario:

dig ciudad.com @ip-dns-1rio

;  DiG 9.9.5-3ubuntu0.2-Ubuntu  ciudad.com @benito
;; global options: +cmd
;; connection timed out; no servers could be reached

Si uso para la consulta a nuestro DNS secundario la respuesta que 
obtengo es la normal.


Les agradecería mucho cualquier sugerencia que me puedan dar al 
respecto como para poder ir solucionando este inconveniente.


Saludos y muchas gracias,

Mauro.




Mas datos.

ip-dns-1rio no existe

que problemas has tenido. SPAM?

Cual es el DNS secundario? .


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5550abd3.50...@gmail.com

Re: DNS primario baneado de AWS DNS?

[Mauro Antivero]

El 11/05/15 a las 11:03, Camaleón escibió:

El Mon, 11 May 2015 09:51:40 -0300, Mauro Antivero escribió:


Estimados, luego de un inconveniente que tuvimos la semana pasada parece
que los DNS de AWS (Amazon Web Services) han baneado a nuestro
servidor DNS primario, por lo cual no podemos resolver numerosos
dominios que tengan a AWS DNS como servidor autoritativo (que son
muchos), salvo que pasemos a usar nuestro DNS secundario. El problema
que ocasionó esto estaría resuelto, por lo que estamos viendo como hacer
para anular dicho baneo, pero hasta ahora no he encontrado ninguna
información de contacto ni nada por el estilo.

Pues ya les vale :-/

https://aws.amazon.com/es/contact-us/
Por supuesto que ya visité esa página, pero fijate que el soporte que 
indican ahí no es el tipo de soporte que necesito yo. De todas formas, 
viendo que no encuentro ninguna otra alternativa voy a probar consultar 
a ver que me dicen.



A continuación les paso la salida de dig usando nuestro DNS primario:

dig ciudad.com @ip-dns-1rio

;  DiG 9.9.5-3ubuntu0.2-Ubuntu  ciudad.com @benito ;; global
options: +cmd ;; connection timed out; no servers could be reached

Si uso para la consulta a nuestro DNS secundario la respuesta que
obtengo es la normal.

Les agradecería mucho cualquier sugerencia que me puedan dar al respecto
como para poder ir solucionando este inconveniente.

¿No podrías reenviar las peticiones desde el DNS primario al secundario?
Seguramente hayan bloqueado la IP del servidor.
Si, se podría, pero quiero solucionar lo del DNS primario, ya que es lo 
que corresponde. Y si, lo que banearon es la IP de nuestro servidor 
primario :S


Saludos y muchas gracias, les comento después como me fue.

Mauro.


Saludos,




--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/5550c521.9050...@gmail.com

Re: DNS primario baneado de AWS DNS?

[Jose Maldonado]

El 11/05/15 a las 10:35, Mauro Antivero escribió:
 El 11/05/15 a las 11:03, Camaleón escibió:
 El Mon, 11 May 2015 09:51:40 -0300, Mauro Antivero escribió:

 Estimados, luego de un inconveniente que tuvimos la semana pasada parece
 que los DNS de AWS (Amazon Web Services) han baneado a nuestro
 servidor DNS primario, por lo cual no podemos resolver numerosos
 dominios que tengan a AWS DNS como servidor autoritativo (que son
 muchos), salvo que pasemos a usar nuestro DNS secundario. El problema
 que ocasionó esto estaría resuelto, por lo que estamos viendo como hacer
 para anular dicho baneo, pero hasta ahora no he encontrado ninguna
 información de contacto ni nada por el estilo.
 Pues ya les vale :-/

 https://aws.amazon.com/es/contact-us/
 Por supuesto que ya visité esa página, pero fijate que el soporte que
 indican ahí no es el tipo de soporte que necesito yo. De todas formas,
 viendo que no encuentro ninguna otra alternativa voy a probar consultar
 a ver que me dicen.

La idea es precisamente esa; llamar y preguntar porque clase de soporte
pueden ofrecerte en tu situación, ellos conocen su estructura de soporte
y posiblemente puedan ponerte en contacto con la persona adecuada.

Saludos.

-- 
Dios en su Cielo, todo bien en la Tierra




signature.asc
Description: OpenPGP digital signature

Re: dns

[Alejandro G Sánchez martínez]

El Jue 16 Oct 2014 09:24:33 Marcelino Osoria Pérez escribió:
 tengo el sgte problema con mi zona de dns, mi  isp me realizo la dekagacion
 de zona de la sgte forma:
 
 112/29 IN NS master.epscu.co.cu.
 113

No se se se una dekagaciòn , supongo que duces declaración o delegación.

y bueno ¿cual es el problema?


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1658199.GCDJNsxUtr@lurkan-desktop

Re: DNS

[Pascal Hambourg]

Christian Ottié a écrit :
 
 Je suis allé modifier la config DHCP de ma FreeBox (on peut mettre 5 ip 
 de DNS). J'avais, il y a longtemps, ajouté 4 DNS avant celui de ma 
 FreeBox, pensant être tranquille en cas de pb du coté de mon FAI.
 J'ai remplacé la première entrée par 8.8.8.8 (DNS Google - facile à 
 retenir) et là, ça marche avec Debian.
 Puis j'ai enlevé la première entrée ne laissant que les 4 suivantes, et 
 là encore ça marche.
 
 J'en déduis que Debian n'est pas capable de passer au DNS suivant en cas 
 de timeout du premier.

Si, puisque c'est une propriété du resolver de la libc.
Par contre la page de manuel de resolv.conf indique que seulement trois
NS au maximum sont pris en compte. Cela signifie que si les trois
premiers NS ne répondent pas, alors la résolution échoue. En supprimant
la première entrée, tu as peut-être permis au resolver d'interroger le
précédemment 4e devenu 3e NS qui répond.

Ça vaudrait le coup de tester individuellement chacun des NS que tu
avais configurés avec dig, host ou nslookup selon tes préférences.

Concernant Windows et Ubuntu, je ne sais pas comment ils fonctionnent.
Tu peux comparer le contenu de /etc/resolv.conf sous Debian et Ubuntu.

-- 
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: https://lists.debian.org/542e9c70.2070...@plouf.fr.eu.org

Re: DNS

[Sylvain Tgz]

Ok, la freebox fourni aux clients les adresses DHCP configurés. elle
ne fait pas relay.
Pour les DNS, si celui ci répond qu'il ne trouve pas l'adresse, c'est
tout de même une réponse, il n'essayera pas les autres DNS.



Si le problème réparait :
- ping le serveur DNS
- utilise dig @IPduserveurdns debian.org
- capture le flux via wireshark ou autre, cela permettra de pousser le
diagnostique.

(oups, je me suis loupé de destinataire pour mon premier message)

++
Tgz

Le 3 octobre 2014 16:50, Christian Ottié christian.ot...@laposte.net a écrit :
 Non, aucune configuration particulière sur les postes.
 Ils vont tous chercher l'ip du DNS dans la config DHCP de la FreeBox.
 Et là j'avais mis 4 ip de serveurs DNS 'publics'  et en 5e l'ip de la box.

 Le serveur DNS correspondant à la 1re ip de la liste est passé en timeout.

 Apparemment ça bloque Debian,
 Alors que LUbuntu et Seven sont passé outre et ont utilisé l'un des autres
 serveurs DNS de la liste.


 Le 03/10/2014 15:09, Sylvain Tgz a écrit :

 Hello,

 tous tes postes possède l'adresse IP de la box comme serveur DNS ?
 Tu n'a pas modifié les paramètres au niveau de tes postes ?

 Cdt,
 Tgz



 Le 3 octobre 2014 13:46, Christian Ottié christian.ot...@laposte.net a
 écrit :

 Bonjour,


 Il m'est arrivé un truc bizarre hier soir.

 Vers 21h, plus d'accès Internet depuis mon PC sous Wheezy.
 Depuis le PC de mon fils sous Windows 7, pas de pb.
 Depuis un autre PC que j'avais commencé à configurer sous Wheezy la
 semaine
 passée, idem, pas de connexion.
 Depuis un portable sous 7, ça marche.
 Depuis un netbook sous LUbuntu, ça marche,
 Depuis ma TV (Panasonic), pas de connexion.
 J'ai booté toutes mes machine sur une clé USB Debian Live, pas de
 connexion.

 Donc c'est un pb propre à Debian (et à ma TV) qui ne voit plus le DNS.
 Alors
 que pour Ubuntu et Windows 7, ça marche.
 Confirmé avec nslookup : timeout

 Et je suis allé me coucher (la nuit étant sensée porter conseil - et des
 fois que ça revienne tout seul...)

 Ce matin, pareil, pas d'Internet.
 Je suis allé modifier la config DHCP de ma FreeBox (on peut mettre 5 ip
 de
 DNS). J'avais, il y a longtemps, ajouté 4 DNS avant celui de ma FreeBox,
 pensant être tranquille en cas de pb du coté de mon FAI.
 J'ai remplacé la première entrée par 8.8.8.8 (DNS Google - facile à
 retenir)
 et là, ça marche avec Debian.
 Puis j'ai enlevé la première entrée ne laissant que les 4 suivantes, et
 là
 encore ça marche.

 J'en déduit que Debian n'est pas capable de passer au DNS suivant en cas
 de
 timeout du premier. Alors que Windows 7 et LUbuntu le font.

 Votre avis, bug ou pb de configuration ?


 Cordialement,
 Christian

 --
 Lisez la FAQ de la liste avant de poser une question :
 http://wiki.debian.org/fr/FrenchLists

 Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
 vers debian-user-french-requ...@lists.debian.org
 En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
 Archive: https://lists.debian.org/542e8cb2.40...@laposte.net



--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet unsubscribe
vers debian-user-french-requ...@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cadj1h1t_aucc4w0os-8ajsdnhwluxvei+k3c1tnlwdft1-k...@mail.gmail.com