Re: Bind9 local DNS not forwarding query to public DNS

[Dan Ritter]

Muhammad Yousuf Khan wrote: 
> Need your experience advice, We have a BIND9 DNS server that operates both
> privately and publicly for the domain example xyz.com. I use the private
> DNS for certain secure nodes on our local network. I want all VPN users to
> be able to resolve these secure nodes using our local DNS, which is
> functioning correctly.
> 
> So I force assign all VPN user local DNS so that they can access the secure
> records and local DNS can forward their query to public DNS in case the
> record is not found in the zone file.
> 
>  locally everything is working just fine, the issue arises when a VPN user
> queries an A record that is on public. For example, if "secure.xyz.com" has
> a local entry in the zone file, it works as expected. However, when the
> entry is not present, I expect BIND to conditionally forward the query to a
> remote DNS server and resolve it for the VPN client. Unfortunately, this is
> not happening. BIND only searches for entries that are available in the
> local zone file and then times out. Here are my configuration files.
> 
> here is my bind config
> 
> 
>  options {
>  directory "/var/cache/bind";
>  recursion yes;   // Enable DNS recursion
>  allow-recursion { localhost; };

^ only localhost is allowed to do recursive queries. But you
want all your internal users to be allowed to do that.

>  allow-query { any; };   // Allow queries from any
> IP address
>  forwarders {
>   8.8.8.8;
>  };
>  dnssec-validation auto;
>  listen-on-v6 { any; };
>  };
> 
>   zone "xyz.com" {
>   type master;
>   file "/etc/bind/db.xyz.com";
>   forwarders {
>   8.8.8.8;
>   8.8.4.4;// Additional forwarder (optional)

^ you do not want forwarders here.

-dsr-

Re: Bind9 local DNS not forwarding query to public DNS

[Eduardo M KALINOWSKI]

On 12/03/2024 12:48, Muhammad Yousuf Khan wrote:

   Dear All,
Need your experience advice, We have a BIND9 DNS server that operates 
both privately and publicly for the domain example xyz.com 
. I use the private DNS for certain secure nodes on our 
local network. I want all VPN users to be able to resolve these secure 
nodes using our local DNS, which is functioning correctly.


So I force assign all VPN user local DNS so that they can access the 
secure records and local DNS can forward their query to public DNS in 
case the record is not found in the zone file.


  locally everything is working just fine, the issue arises when a VPN 
user queries an A record that is on public. For example, if 
"secure.xyz.com " has a local entry in the zone 
file, it works as expected. However, when the entry is not present, I 
expect BIND to conditionally forward the query to a remote DNS server 
and resolve it for the VPN client. Unfortunately, this is not happening. 
BIND only searches for entries that are available in the local zone file 
and then times out. Here are my configuration files.


here is my bind config


  options {
              directory "/var/cache/bind";
              recursion yes;                   // Enable DNS recursion
              allow-recursion { localhost; };


You're only allowing recursion from localhost. I guess you need to allow 
the internal VPN addresses here. Maybe that's the (commented) acl below, 
so try something like


allow-recursion { "trusted"; };

(Maybe the acl needs to be defined before it's used, I'm not sure.)


              //acl trusted {192.168.1.0/24; };


But remember to add localhost to the acl, so that local processes can 
also use the recursive server.



              querylog yes;
              allow-transfer { none; };       // Disable zone transfers by 
default
              allow-query { any; };           // Allow queries from any IP 
address
              forwarders {
                   8.8.8.8;
              };
              dnssec-validation auto;
              listen-on-v6 { any; };
      };

       zone "xyz.com" {
           type master;
           file "/etc/bind/db.xyz.com";
           forwarders {
               8.8.8.8;
               8.8.4.4;                    // Additional forwarder (optional)
           };
       };



Thanks,

Yousuf




--
pension:
A federally insured chain letter.

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

Re: bind9 and dns forward

[Michel Verdier]

Le 1 juin 2023 Bonno Bloksma a écrit :

>> If you get an answer it's a dnssec problem with the error message in your 
>> logs. If there is no answer it's another problem.
> Well, it seems I get an answer with the +cd option, and none without.

Yes. If I do :

# dig tio.nl A +dnssec +multiline

; <<>> DiG 9.18.12-1~bpo11+1-Debian <<>> tio.nl A +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15946
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: b5616e99dab9dfa201006479183bc71c1f369d50dcb2 (good)
;; QUESTION SECTION:
;tio.nl.IN A

;; ANSWER SECTION:
tio.nl. 3600 IN A 188.166.202.179
tio.nl. 3600 IN RRSIG A 8 2 3600 (
2023061500 2023052500 11454 tio.nl.
M3ZcaxHNXwnmZ5SQnvMcPsUDPLQLpyl0RO7azsSWoUTx
6CgENJbWQuMqHyiQlzxeSnzVbfFIlKdbsBACFylJUhsT
Mby5rp8ouOr8XOK2wC+qJvgYbl5SJwXePu0f1XgCxoAg
P5/6ZnnXpo4gidVtxfUB68Ed5T6yxo23o0eI5gE= )

I get external dns answer with a nice dnssec. Can you do :

dig @172.16.208.10 tio.nl A +dnssec +multiline

to see if your internal dns answer the same rrsig

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

@Tim,
If I use the dnssec-validation no; option then indeed it all works. Just tested 
it again to make sure.
And as a final solution to this problem I might accept it, but I would rather 
not.

@Michel,  
> I reread all our mails and I miss to ask you this one (as answers via 
> external dns masked the real problem) :
> dig tio.nl NS +cd

Ok, with /etc/resolv.conf pointing only to localhost and option 
dnssec-validation auto;

-
linbobo:/etc/bind# dig tio.nl NS +cd

; <<>> DiG 9.16.37-Debian <<>> tio.nl NS +cd
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8565
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f9edf2abbc6bb1b401006478e3bce0244f2a98d3724c (good)
;; QUESTION SECTION:
;tio.nl.IN  NS

;; ANSWER SECTION:
tio.nl. 3600IN  NS  amsstuddc-04.student.tio.nl.
[... snip ...]
tio.nl. 3600IN  NS  rtmstuddc-05.student.tio.nl.

;; Query time: 28 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 01 20:30:20 CEST 2023
;; MSG SIZE  rcvd: 568

linbobo:/etc/bind# dig tio.nl NS

; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57482
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: eeb3f3a1c2495cf501006478e3c58effeec3959e9ccc (good)
;; QUESTION SECTION:
;tio.nl.IN  NS

;; Query time: 188 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 01 20:30:29 CEST 2023
;; MSG SIZE  rcvd: 63

linbobo:/etc/bind#
-

> If you get an answer it's a dnssec problem with the error message in your 
> logs. If there is no answer it's another problem.
Well, it seems I get an answer with the +cd option, and none without.

[...]
> And it's definitely not the good solution but you could transfer the full 
> zone (or get a copy of the file) and serve it as master.
Nah, I do not want to do that. Too many updates on the internal zone, I would 
need to copy at least every 5 min. Also other reasons.

Bonno Bloksma

Re: bind9 and dns forward

[Michel Verdier]

Le 1 juin 2023 Bonno Bloksma a écrit :

> I can do that, but ... that is only for inbound traffic TO my dns server on 
> this network.
> That part is working without any problem. Changing that will not change 
> anything for the clients on this network.

You are right. I simply used to fix explicitely interfaces for
security and it's not the point here.

> My bind instance can reach the company dns server buy claims the response is 
> false/insecure
> Does that maybe mean that my bind gets a "normal" response from the company
> dns whereas the external dns at toplevel .nl. (being the parent zone) tells
> that any response from a tio.nl dns server should be a secure response. And
> therefore bind does not accept it?

I reread all our mails and I miss to ask you this one (as answers via
external dns masked the real problem) :

dig tio.nl NS +cd

If you get an answer it's a dnssec problem with the error message in your
logs. If there is no answer it's another problem.

> Where does bind store this info and can I overrule it?

I am not sure but I think bind only cache in memory.
And it's definitely not the good solution but you could transfert the
full zone (or get a copy of the file) and serve it as master.

RE: bind9 and dns forward

[Tim Woodall]

On Thu, 1 Jun 2023, Bonno Bloksma wrote:



My bind instance can reach the company dns server buy claims the response is 
false/insecure

Does that maybe mean that my bind gets a "normal" response from the company dns 
whereas the external dns at toplevel .nl. (being the parent zone) tells that any response 
from a tio.nl dns server should be a secure response. And therefore bind does not accept 
it?
Where does bind store this info and can I overrule it?



/etc/bind/named.conf.options:

dnssec-validation auto;

You'll have to check the docs but I think setting this to no or none (I
don't remember which) should mean that it doesn't complain.

But this is rather brute force. There may be a cleaner way to do it for
a single domain via trust anchors but it's not something I've tried to
do.

Tim.

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

>> linbobo:~# ss -nap | grep named
>> tcp LISTEN 0 10 [2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3]:53 [::]:*
>> users:(("named",pid=554,fd=78))
>> tcp LISTEN 0 10 [fe80::1e69:7aff:fe0c:65e3]%eno1:53 [::]:*
>> users:(("named",pid=554,fd=71))
>> tcp LISTEN 0 10 [fe80::33bc:2b:d928:991d]%tun0:53 [::]:*
>> users:(("named",pid=554,fd=94))

> You should not use fe80:: adresses on eno1 as you have an ipv6 2a02 on this 
> interface. 
I can do that, it is just default to listen on all local ip's. 
But that is also just inbound traffic as far as I know, that has nothing to do 
with what ip number bind itself uses to get info from other (company) dns 
servers.

> But you don't have real ipv6 on tun0. fe80:: is only assigned when there is 
> no adress assigned for an interface. 
Correct, the VPN tunnel is IPv4 only at this moment as the company network has 
only partial IPv6 set up and is not using it over the whole network yet.
I am only sure to reach all servers via IPv4, including the dns servers. Which 
is why I forward to the relevant ipv4 addresses.

> Usually fe80:: are local only and not routed. 
Correct

> And bind use ipv6 first. 
Yes, first, but not only. Also, there is no IPv6 address in the forward 
statements.

> So I suspect that your vpn block ipv6 from your tun0 fe80::. Check your vpn 
> configuration to setup a real ipv6 adress.
I cannot setup IPv6 on the VPN tunnel as the other side has no IPv6 address 
yet. Also there is no route to the dns servers on ipv6 yet.

> Meanwhile change /etc/bind/named.conf.options to select only your good ip
> 
> listen-on port 53 {
[]
>};

I can do that, but ... that is only for inbound traffic TO my dns server on 
this network.
That part is working without any problem. Changing that will not change 
anything for the clients on this network.


We are still left with the problem shown in the syslog:
-- 
Jun  1 09:25:45 linbobo named[554]: validating tio.nl/NS: got insecure 
response; parent indicates it should be secure 
Jun  1 09:25:45 linbobo named[554]: insecurity proof failed resolving 
'tio.nl/NS/IN': 172.16.128.40#53 
Jun  1 09:25:45 linbobo named[554]: validating tio.nl/NS: got insecure 
response; parent indicates it should be secure 
Jun  1 09:25:45 linbobo named[554]: insecurity proof failed resolving 
'tio.nl/NS/IN': 172.16.208.10#53 
--

My bind instance can reach the company dns server buy claims the response is 
false/insecure

Does that maybe mean that my bind gets a "normal" response from the company dns 
whereas the external dns at toplevel .nl. (being the parent zone) tells that 
any response from a tio.nl dns server should be a secure response. And 
therefore bind does not accept it?
Where does bind store this info and can I overrule it?

Bonno Bloksma

Re: bind9 and dns forward

[Michel Verdier]

Le 1 juin 2023 Bonno Bloksma a écrit :

> linbobo:~# ss -nap | grep named
> tcp LISTEN 0 10 [2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3]:53 [::]:*
> users:(("named",pid=554,fd=78))
> tcp LISTEN 0 10 [fe80::1e69:7aff:fe0c:65e3]%eno1:53 [::]:*
> users:(("named",pid=554,fd=71))
> tcp LISTEN 0 10 [fe80::33bc:2b:d928:991d]%tun0:53 [::]:*
> users:(("named",pid=554,fd=94))

You should not use fe80:: adresses on eno1 as you have an ipv6 2a02 on
this interface. But you don't have real ipv6 on tun0. fe80:: is only
assigned when there is no adress assigned for an interface. Usually fe80::
are local only and not routed. And bind use ipv6 first. So I suspect that
your vpn block ipv6 from your tun0 fe80::. Check your vpn configuration
to setup a real ipv6 adress.

Meanwhile change /etc/bind/named.conf.options to select only your good ip

listen-on port 53 {
127.0.0.1;
172.16.17.1;
172.16.1.138;
};
listen-on-v6 port 53 {
::1;
2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3;
# add here real ipv6 from vpn when setup
};

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

> resolv.conf must have only one search entry. And you don't want to resolv 
> with google directly. So you should have :

Ok, I have the google dns commented. Alhough Now I remember why I had the 
google dns in there. ;-)
For my machine to create the VPN it needs to know the ip number of the gateway. 
I fixed that for now with an entry in the /etc/hosts file. :-)

>> When booting if the internal bind is not up and running yet some services 
>> might need a resolver so I have 8.8.8.8 in there as well as a second dns 
>> entry.
> Ensure this in services ordering (systemd or initd). It's better and safer. 
> And I think it's better to get an error than a false result from bind.
Ok, I get it.

--
linbobo:~# rndc flush
linbobo:~# dig tio.nl NS

; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49974
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 52571ae710dcd2cc01006478463be41c8b3a2afd14a5 (good)
;; QUESTION SECTION:
;tio.nl.IN  NS

;; Query time: 244 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 01 09:18:19 CEST 2023
;; MSG SIZE  rcvd: 63

--

Hmm, no answer, that is weird.

--
linbobo:~# ss -nap | grep named
u_dgr UNCONN0  0   * 17532  
* 12035 users:(("named",pid=554,fd=3))  
   
u_str ESTAB 0  0   * 17082  
* 17525 
users:(("named",pid=554,fd=2),("named",pid=554,fd=1))   
   
udp   UNCONN0  0172.16.1.138:53 
  0.0.0.0:* users:(("named",pid=554,fd=83)) 
   
udp   UNCONN0  0172.16.1.138:53 
  0.0.0.0:* users:(("named",pid=554,fd=85)) 
   
udp   UNCONN0  0172.16.1.138:53 
  0.0.0.0:* users:(("named",pid=554,fd=84)) 
   
udp   UNCONN0  0172.16.1.138:53 
  0.0.0.0:* users:(("named",pid=554,fd=82)) 
   
udp   UNCONN0  0 172.16.17.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=49)) 
   
udp   UNCONN0  0 172.16.17.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=50)) 
   
udp   UNCONN0  0 172.16.17.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=51)) 
   
udp   UNCONN0  0 172.16.17.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=52)) 
   
udp   UNCONN0  0   127.0.0.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=39)) 
   
udp   UNCONN0  0   127.0.0.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=38)) 
   
udp   UNCONN0  0   127.0.0.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=40)) 
   
udp   UNCONN0  0   127.0.0.1:53 
  0.0.0.0:* users:(("named",pid=554,fd=37)) 
   
udp   UNCONN0  0   [::1]:53 
 [::]:* users:(("named",pid=554,fd=60)) 
   
udp   UNCONN0  0   [::1]:53 
 [::]:* users:(("named",pid=554,fd=58)) 
   
udp   UNCONN0  0   [::1]:53 
 [::]:* users:(("named",pid=554,fd=59)) 
   
udp   UNCONN0  0   [::1]:53 

Re: bind9 and dns forward

[Michel Verdier]

Le 19 mai 2023 Bonno Bloksma a écrit :

> Been a few busy week, that is why I only respond now, sory.

Same for me :/

> beheerdertio@linbobo:~$ cat /etc/resolv.conf
> domain bobo.xs4all.nl
> search bobo.xs4all.nl
> search tio.nl
> search staf.tio.nl
> search student.tio.nl
> nameserver 127.0.0.1
> nameserver 8.8.8.8

resolv.conf must have only one search entry. And you don't want to
resolv with google directly. So you should have :

domain bobo.xs4all.nl
search bobo.xs4all.nl tio.nl staf.tio.nl student.tio.nl
nameserver 127.0.0.1

> When booting if the internal bind is not up and running yet some services 
> might need a resolver so I have 8.8.8.8 in there as well as a second dns 
> entry.

Ensure this in services ordering (systemd or initd). It's better and
safer. And I think it's better to get an error than a false result from
bind.

> linbobo:~# dig tio.nl NS
>
> ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34517
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

This is the point : your local dns don't find tio.nl NS and then ask
somewhere else. 8.8.8.8 is in resolv.conf so you search tio.nl directly
on it and it gives you your provider name server.

Retry
 dig tio.nl NS
with a clean resolv.conf and also
 ss -nap | grep named

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

Been a few busy week, that is why I only respond now, sory.
Also as there is a lot of sensitive info in this mail, like a complete lost 
to domain controllers to be hacked, ;-) I am sending it direct. I will send a 
redacted version to the list

>> What does +cd do? I was unable to find it in the man page.
> it disable dnssec checks, was just in case of real dnssec problem

Aha, ok clear.

> can you give full /etc/resolv.conf
> from your result you should have 127.0.0.1 in it but just to be sure


beheerdertio@linbobo:~$ cat /etc/resolv.conf 
domain bobo.xs4all.nl
search bobo.xs4all.nl
search tio.nl
search staf.tio.nl
search student.tio.nl
nameserver 127.0.0.1
nameserver 8.8.8.8


When booting if the internal bind is not up and running yet some services might 
need a resolver so I have 8.8.8.8 in there as well as a second dns entry.

> and also :
> dig tio.nl NS
> dig @172.16.208.10 tio.nl NS


linbobo:~# dig tio.nl NS

; <<>> DiG 9.16.37-Debian <<>> tio.nl NS ;; global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34517 ;; flags: qr rd ra; 
QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: bfc026467d702f7d01006467377dffdb068b3e9c0a69 (good) ;; QUESTION 
SECTION:
;tio.nl.IN  NS

;; Query time: 32 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri May 19 10:46:53 CEST 2023
;; MSG SIZE  rcvd: 63

linbobo:~# dig @172.16.208.10 tio.nl NS

; <<>> DiG 9.16.37-Debian <<>> @172.16.208.10 tio.nl NS ; (1 server found) ;; 
global options: +cmd ;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13283 ;; flags: qr aa rd 
ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 19

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;tio.nl.IN  NS

;; ANSWER SECTION:
tio.nl. 3600IN  NS  hgltiodc-04.tio.nl.
[]
tio.nl. 3600IN  NS  amsstuddc-04.student.tio.nl.

;; ADDITIONAL SECTION:
hgltiodc-04.tio.nl. 3600IN  A   172.16.128.40
[...]
amsstuddc-04.student.tio.nl. 1200 INA   172.16.196.11

;; Query time: 20 msec
;; SERVER: 172.16.208.10#53(172.16.208.10) ;; WHEN: Fri May 19 10:48:07 CEST 
2023 ;; MSG SIZE  rcvd: 816



Bonno Bloksma

Re: bind9 and dns forward

[Michel Verdier]

Le 8 mai 2023 Bonno Bloksma a écrit :

> I also do not understand this difference when querying the internal dns 
> server directly.
> Why does the +trace +cd not show an answer but when I leave them out I get a
> correct answer. Is that because +trace forces it to start at the root which is
> irrelevant when trying to get an answer from an internal dns server?

yes

> What does +cd do? I was unable to find it in the man page.

it disable dnssec checks, was just in case of real dnssec problem

can you give full /etc/resolv.conf
from your result you should have 127.0.0.1 in it but just to be sure

and also :

dig tio.nl NS
dig @172.16.208.10 tio.nl NS

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

>> linbobo:/etc/bind# cat named.conf.local
> 
> You have only zone blocks in this file, right ?
Yes, 

> And you don't use views ?
I have no idea what they would do, but no. The word view is not in that file.

> Why does it first go to the public dns and then run into the dnssec problem? 
> There is a direct definition for the tio.nl zone in my config file. 

The public dns don't answer at all, so dnssec problem is only a consequence. 
The main problem seems to be the broken forwarding.
Do you restart or flush your bind before the queries ? I suppose you do but... 
:)

Just did a flush and then a query. It still seems to query the public dns and 
not (exclusively) forward the request.


linbobo:/etc/bind# dig einsccmdp-01.tio.nl +trace +cd

; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl +trace +cd
;; global options: +cmd
.   279702  IN  NS  c.root-servers.net.
.   279702  IN  NS  m.root-servers.net.
.   279702  IN  NS  k.root-servers.net.
.   279702  IN  NS  a.root-servers.net.
.   279702  IN  NS  b.root-servers.net.
.   279702  IN  NS  i.root-servers.net.
.   279702  IN  NS  e.root-servers.net.
.   279702  IN  NS  g.root-servers.net.
.   279702  IN  NS  d.root-servers.net.
.   279702  IN  NS  h.root-servers.net.
.   279702  IN  NS  j.root-servers.net.
.   279702  IN  NS  f.root-servers.net.
.   279702  IN  NS  l.root-servers.net.
.   279702  IN  RRSIG   NS 8 0 518400 2023051805 
2023050504 60955 . Yz1mgXTG4kStmPrjvxu3iQsekhdLfu3KeyZT26ebRPDeUnRUz/ajenhi 
jNj4FA6krNnCI1hfU0htq/10iADDnc35NTtGA6PodoTa8qf75l9UZ/Cc 
59FRaH7sEDgjXcvts0X2R85aHofogRRcp77ufoetwSS0KZRsbJ5vBbq2 
J4UIbKNHCZP0anl8+qmDmiMNy3VJYcUwePT6qDUBMe2fhktmU6w1RLSe 
3xGV1dIFONSdZJeQxsJkWBXa5HnBN1Vl8iw6eDKauJDw6LL41fd8XzSk 
CYfl79f92z2tVv5q3l1G8fN3C+KJ33J1Y/hivBSe2FmVuwRkbr1mddH0 4m4LLw==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

nl. 172800  IN  NS  ns1.dns.nl.
nl. 172800  IN  NS  ns3.dns.nl.
nl. 172800  IN  NS  ns4.dns.nl.
nl. 86400   IN  DS  34112 8 2 
3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22
nl. 86400   IN  RRSIG   DS 8 1 86400 2023052105 
2023050804 60955 . ORTn1H1ik3trq8VJQAVQ1nx4rrVZNEpoy9JZ/23pOjysRe9BWlXcCIK4 
9LO3olfaXGFMDMWT3RtlSO3XFc7gPw38y2yfSRN8LWMkY0LzmOoLNxLO 
owY9dqQDfrvZK++EsWWmen0db3u/G07/cVWgb3IO0W9OVioQqko6ryes 
S9rlwbZY7lrPcohjWbUQ/uKBnhyN9yQs0sU8b+v3EbIudSzAa2zz5Bep 
ZA/XcnP+I9KNHqOREEfAuUG8moCP3VYFwarIkAgQeg/pE/typQZuxHUS 
QYY6LEfUpZVVO6i0NAHmqRlOZe2LmIHPWO7FBjK6YZtxyLbNkjyWjjvr kf4bVg==
;; Received 573 bytes from 192.58.128.30#53(j.root-servers.net) in 92 ms

tio.nl. 3600IN  NS  ns3.argewebhosting.nl.
tio.nl. 3600IN  NS  ns1.argewebhosting.eu.
tio.nl. 3600IN  NS  ns2.argewebhosting.com.
tio.nl. 3600IN  DS  33829 8 2 
81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3
tio.nl. 3600IN  RRSIG   DS 8 2 3600 20230522040659 
20230508070836 50076 nl. 
kTSEJYjimMe4Kvdl6kc4gPF2OLn04nhuGDp4ppYbfxwPKZEzXb3GSY68 
3SPqHYTuOvwTeDnGQ1brG7l9N6EJRdgy9rG69/Irj1/aUZT27M5BBN3h 
r9y7dZQAfdZVDSy7zXUgAYy9AdOf+JeLhIeVhrbxD+NYBXaJOe9r3gtj F6s=
;; Received 408 bytes from 2620:10a:80ac::200#53(ns4.dns.nl) in 12 ms

tio.nl. 3600IN  SOA ns1.argewebhosting.eu. 
hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600
tio.nl. 3600IN  RRSIG   SOA 8 2 3600 2023051800 
2023042700 11454 tio.nl. 
JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A 
lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE 
JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0=
kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB 
KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk 
ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs 
+XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg=
oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB 
OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG
oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi 
Mpqu1Dw/NSuWgfYvhtfG5KFqlqyuH88pKJtt5mra6+c3NRi1F6yu4TYS 

Re: bind9 and dns forward

[Michel Verdier]

Le 5 mai 2023 Bonno Bloksma a écrit :

> linbobo:/etc/bind# cat named.conf.local

You have only zone blocks in this file, right ?
And you don't use views ?

> Why does it first go to the public dns and then run into the dnssec problem? 
> There is a direct definition for the tio.nl zone in my config file. 

The public dns don't answer at all, so dnssec problem is only a
consequence. The main problem seems to be the broken forwarding.
Do you restart or flush your bind before the queries ? I suppose you do
but... :)

Your tio.nl zone seems correct. Could you provide full
/etc/bind/named.conf.options and /etc/bind/named.conf ?

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

> In fact you don't resolv at all. Can you provide:

> dig einsccmdp-01.tio.nl +trace +cd
-
linbobo:~# dig einsccmdp-01.tio.nl +trace +cd

; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl +trace +cd
;; global options: +cmd
.   430791  IN  NS  i.root-servers.net.
.   430791  IN  NS  a.root-servers.net.
.   430791  IN  NS  c.root-servers.net.
.   430791  IN  NS  e.root-servers.net.
.   430791  IN  NS  b.root-servers.net.
.   430791  IN  NS  m.root-servers.net.
.   430791  IN  NS  k.root-servers.net.
.   430791  IN  NS  d.root-servers.net.
.   430791  IN  NS  j.root-servers.net.
.   430791  IN  NS  f.root-servers.net.
.   430791  IN  NS  l.root-servers.net.
.   430791  IN  NS  h.root-servers.net.
.   430791  IN  NS  g.root-servers.net.
.   430791  IN  RRSIG   NS 8 0 518400 2023051705 
2023050404 60955 . euvMHZqurPBykFmPr1OYrEWd3ZIP2l3skATDF8FxfGFfEZmBl/NIn+lu 
463u/qxl9F3NYoxN7ANmZyJFMoDhCVpRMEk9mRimctn9fj+6B1EiG02g 
vUiMKSBPrv/gWbZZcXobaE/F99WYV0xnWNWAKJqRO52YRXqvqltvcjNM 
FnreCFXRPLFKJ6jqortPA8XfDEUeyt2oFnNZFy9aVqBSGsIqT2gaqX++ 
6CXeemp5SSX1YHBxVVWnI6FWw7FjPBRNa485e0RmTi/0WdTTaYd2Eh5u 
Sfbpn4OzAgOkGJEU0J45Z4nO8j8M8PpRIW8xh7muW/pLUL6x3FsRsf2s scKr8w==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

nl. 172800  IN  NS  ns4.dns.nl.
nl. 172800  IN  NS  ns1.dns.nl.
nl. 172800  IN  NS  ns3.dns.nl.
nl. 86400   IN  DS  34112 8 2 
3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22
nl. 86400   IN  RRSIG   DS 8 1 86400 2023051805 
2023050504 60955 . n2RgQwHUOPq0Kfit0Fs3PJx+xiSsSeZqOtzw0oq5BU0CBhM6WN75Gw/T 
u+PIFd4NEFoS2T3Y+mGuQb7PfvGNOFHbRzp1rwHrgj5GzgS3nCih9jOF 
wPNytFVYhJ/RqfD80dMwShZAs2OxlVIfD7UYEjUs/ZC38PreGAoHedQI 
wp8lECv80cr+zFHtPHh5RiW1Clg4TDWmlzOsa8y9FOH3acTM+kFjnnaQ 
se2p0ZciZk8B7aNoxG468JQnQHHKRbxQgn8wxM0ttHKkpmwZHvL7bfhE 
CH+akGcz/g4TFQA88B9eHTe0AqcUcHsPhBmB/uySv3FAiO0myKsQwuC+ 8vORCg==
;; Received 605 bytes from 192.36.148.17#53(i.root-servers.net) in 0 ms

tio.nl. 3600IN  NS  ns1.argewebhosting.eu.
tio.nl. 3600IN  NS  ns2.argewebhosting.com.
tio.nl. 3600IN  NS  ns3.argewebhosting.nl.
tio.nl. 3600IN  DS  33829 8 2 
81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3
tio.nl. 3600IN  RRSIG   DS 8 2 3600 20230516084745 
20230501190734 50076 nl. 
HU8NwsPjKyakNkwXofrXCi6myG361X7PYkKbenuMz+idBTsOJxQDGmVp 
QAGsuI35V0zDKV4qhjCXH9DLfoPhktYMvQF1S87OrAVT8EKVMYOEbzmH 
e1KyXWXFIYoJnZxjL+peKL4KMKmlBn2ZbAZ2CjrEaCQU+JoQNK/rjL61 y+g=
;; Received 408 bytes from 2620:10a:80ac::200#53(ns4.dns.nl) in 12 ms

tio.nl. 3600IN  SOA ns1.argewebhosting.eu. 
hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600
tio.nl. 3600IN  RRSIG   SOA 8 2 3600 2023051800 
2023042700 11454 tio.nl. 
JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A 
lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE 
JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0=
kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB 
KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM
kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk 
ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs 
+XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg=
oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB 
OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG
oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi 
Mpqu1Dw/NSuWgfYvhtfG5KFqlqyuH88pKJtt5mra6+c3NRi1F6yu4TYS 
owv7naAaZy4Tv83zMcNYjivcM2wV4PCKX9nM1TQieRwB9nBx5+QnvUkX KvI=
o4n6i0v019dpao7abq7mfor6a1543t6g.tio.nl. 3600 IN NSEC3 1 0 1 AB 
OJI66FT00RG1TJD4KC30VNO3GBKRUU91 CNAME RRSIG
o4n6i0v019dpao7abq7mfor6a1543t6g.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 
2023051800 2023042700 11454 tio.nl. 
FGm7FofqjWiWd+9Bj7oNaLqraLyajz7rugO7N7ctd8ZKT14qcEfGkrgV 
zghw+Zpnda4Hb7aGomdsZ/XdiJorXRZRWQD5Qcirm1YEoZwAAbLyyJK0 
qfn3g8SRuVH51nVOOr7WfeZRMVXOlgYSrRnYGlsGQfg/y7or/1qrGnxM 8gM=
;; Received 1029 bytes from 
2a05:1500:702:0:1c00:eff:fe00:ce#53(ns1.argewebhosting.eu) in 8 ms

-
And just to make sure it 

Re: bind9 and dns forward

[Michel Verdier]

Le 2 mai 2023 Bonno Bloksma a écrit :

> linbobo:/etc/bind# cat named.conf.local
> ---
> []
> zone "tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "staf.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "student.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> }; 

> The problem is not that the company dns servers are not working, it is that 
> it somehow thinks the answers are not valid, not even for the top level 
> domain.

In fact you don't resolv at all. Can you provide:

dig einsccmdp-01.tio.nl +trace +cd
dig @172.16.208.10 einsccmdp-01.tio.nl
(this one to eliminate 172.16.208.10 beeing broken)

I don't understand why you define staf.tio.nl and student.tio.nl as
tio.nl is already on the same forwarders. I don't know if it's valid but
it seems useless. And your logs suggest a problem between staf.tio.nl and
tio.nl. Could you comment staf.tio.nl and student.tio.nl, restart bind
(or reload + flush) and try again above dig ?

RE: bind9 and dns forward

[Bonno Bloksma]

Hi,

Lots of info and log quotes. I hope you can find the "normal" text.

>> We use a different dns server(s) and zonefile for the external dns 
>> environment from what we use internally. Company dns is Windows server 2016 
>> incase that is relevant.
> 
> It's better to use dig (package bind9-dnsutils) to first eliminate problems 
> on other DNS. Give us:
> 
> dig @13.107.206.240 trafficmanager.net SOA dig @13.107.206.240 
> outlook.ha.office365.com IN dig @172.16.128.40 vijl.staf.tio.nl  dig 
> @172.16.128.10 vijl.staf.tio.nl 

Yes I also have dig.
About your 4 dig statements. Like I wrote the problem with office365 is not MY 
problem, that is a Microsoft problem.
And even though I have a working ipv6 environment at home I do not have a 
working ipv6 VPN tunnel to work, nor do we use ipv6 there internally. So here 
are the ipv4 results. As you can see there is a working dns server at those 2 
ip numbers.

--
linbobo:/etc/bind# dig @172.16.128.40 vijl.staf.tio.nl A

; <<>> DiG 9.16.37-Debian <<>> @172.16.128.40 vijl.staf.tio.nl A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61639
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vijl.staf.tio.nl.  IN  A

;; ANSWER SECTION:
vijl.staf.tio.nl.   1200IN  A   172.16.72.97

;; Query time: 8 msec
;; SERVER: 172.16.128.40#53(172.16.128.40)
;; WHEN: Tue May 02 11:20:52 CEST 2023
;; MSG SIZE  rcvd: 61

linbobo:/etc/bind# dig @172.16.208.10 vijl.staf.tio.nl A

; <<>> DiG 9.16.37-Debian <<>> @172.16.208.10 vijl.staf.tio.nl A
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12968
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;vijl.staf.tio.nl.  IN  A

;; ANSWER SECTION:
vijl.staf.tio.nl.   1200IN  A   172.16.72.97

;; Query time: 16 msec
;; SERVER: 172.16.208.10#53(172.16.208.10)
;; WHEN: Tue May 02 11:21:04 CEST 2023
;; MSG SIZE  rcvd: 61
--

But if I query my own bind server...

--
linbobo:~# dig vijl.staf.tio.nl

; <<>> DiG 9.16.37-Debian <<>> vijl.staf.tio.nl
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16945
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 63ecb9edc2f5036e01006450d2a73c1c133db0bfc629 (good)
;; QUESTION SECTION:
;vijl.staf.tio.nl.  IN  A

;; Query time: 12 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue May 02 11:06:47 CEST 2023
;; MSG SIZE  rcvd: 73

And from /var/log/syslog
May  2 11:06:32 linbobo named[574]: DNS format error from 172.16.128.40#53 
resolving vijl.staf.tio.nl/ for 127.0.0.1#56241: Name tio.nl (SOA) not 
subdomain of zone staf.tio.nl -- invalid response
May  2 11:06:32 linbobo named[574]: FORMERR resolving 
'vijl.staf.tio.nl//IN': 172.16.128.40#53
May  2 11:06:32 linbobo named[574]:   validating tio.nl/SOA: got insecure 
response; parent indicates it should be secure
May  2 11:06:32 linbobo named[574]: no valid RRSIG resolving 
'staf.tio.nl/DS/IN': 172.16.128.40#53
May  2 11:06:32 linbobo named[574]: DNS format error from 172.16.208.10#53 
resolving vijl.staf.tio.nl/ for 127.0.0.1#56241: Name tio.nl (SOA) not 
subdomain of zone staf.tio.nl -- invalid response
May  2 11:06:32 linbobo named[574]: FORMERR resolving 
'vijl.staf.tio.nl//IN': 172.16.208.10#53
May  2 11:06:32 linbobo named[574]:   validating tio.nl/SOA: got insecure 
response; parent indicates it should be secure
May  2 11:06:32 linbobo named[574]: no valid RRSIG resolving 
'staf.tio.nl/DS/IN': 172.16.208.10#53
May  2 11:06:32 linbobo named[574]: broken trust chain resolving 
'vijl.staf.tio.nl/A/IN': 172.16.128.40#53
May  2 11:06:35 linbobo named[574]:   validating tio.nl/SOA: got insecure 
response; parent indicates it should be secure
May  2 11:06:35 linbobo named[574]: no valid RRSIG resolving 
'student.tio.nl/DS/IN': 172.16.128.40#53
May  2 11:06:35 linbobo named[574]:   validating tio.nl/SOA: got insecure 
response; parent indicates it should be secure
May  2 11:06:35 linbobo named[574]: no valid RRSIG resolving 
'student.tio.nl/DS/IN': 172.16.208.10#53
May  2 11:06:35 linbobo named[574]: broken trust chain resolving 
'vijl.staf.tio.nl.student.tio.nl/A/IN': 172.16.128.40#53
May  2 11:06:35 linbobo named[574]: broken trust chain resolving 
'vijl.staf.tio.nl.student.tio.nl//IN': 172.16.128.40#53
May  2 11:06:47 linbobo named[574]: validating vijl.staf.tio.nl/A: bad cache 
hit (staf.tio.nl/DS)
May  2 11:06:47 linbobo named[574]: broken trust chain resolving 
'vijl.staf.tio.nl/A/IN': 172.16.128.40#53

Re: bind9 and dns forward

[Michel Verdier]

Le 28 avril 2023 Bonno Bloksma a écrit :

> We use a different dns server(s) and zonefile for the external dns 
> environment from what we use internally. Company dns is Windows server 2016 
> incase that is relevant.

It's better to use dig (package bind9-dnsutils) to first eliminate
problems on other DNS. Give us:

dig @13.107.206.240 trafficmanager.net SOA
dig @13.107.206.240 outlook.ha.office365.com IN
dig @172.16.128.40 vijl.staf.tio.nl 
dig @172.16.128.10 vijl.staf.tio.nl 

> Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53
> resolving staf.tio.nl/ for client 172.16.17.11#65033: Name tio.nl (SOA)
> not subdomain of zone staf.tio.nl -- invalid response

I suppose you reboot after your upgrade ?

Do you have defined somewhere on linbobo a zone staf.tio.nl ?
I guess not but do a grep just to be sure.

Re: bind9 slave sending notifies

[Tim Woodall]

On Thu, 24 Mar 2022, Jeremy Ardley wrote:


I'm using BIND 9.16.22-Debian (Extended Support Version) 

The problem is when I restart I see "sending notifies" in the log.

I have checked the configuration named.conf.local and named.conf.options and 
there is no 'allow-transfer' in the configuration.


example named.conf.local entry:

zone "lan" {
??? type slave;
??? file "db.lan";
??? masters { 192.0.2.1; };
??? allow-query {any;};
};

So is sending notifies with no-one to notify normal?

If not, how do I stop it?



I have:

allow-transfer { none; };
transfer-source-v6 2001:8b0:bfcd:***;
listen-on { 192.168.*.*/32; 192.168.*.*/32; };
listen-on-v6 { any; };
notify explicit;
}

in options. I don't see my slave sending any notifies.

Tim

Re: Bind9 et mise à jour DNS

[Migrec]

Le 26/05/2020 à 09:17, BERTRAND Joël a écrit :



RR at 'surf.homeg.lan' A 192.168.0.34
May 26 08:54:21 canoe kernel: [  164.300678] audit: type=1400
audit(1590476061.014:21): apparmor="DENIED" operation="mknod"
profile="/usr/sbin/named" name="/etc/bind/db.homeg.lan.jnl" pid=923
comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=105 ouid=105
May 26 08:54:21 canoe named[923]: /etc/bind/db.homeg.lan.jnl: create:
permission denied
May 26 08:54:21 canoe named[923]: client @0x7fb1a04bdb20
192.168.0.2#38965/key rndc-key: updating zone 'homeg.lan/IN': error:
journal open failed: unexpected error
May 26 08:54:21 canoe dhcpd[1303]: Forward map from surf.homeg.lan to
192.168.0.34 FAILED: SERVFAIL


/etc/bind/db.homeg.lan.jnl : je l'ai renommé en db.homeg.lan.jnl-SAUVE
et curieusement, la date de dernière mise à jour correspond à lka minute
près au dernier redémarrage de mon serveur.

Avez-vous une idée ? J'avais déjà rencontré un problème similaire qui
s'était résolu en changeant une ligne de /etc/appamor.d/usr.sbin.named
- /etc/bind/** r,
+ /etc/bind/** rw,

La nouvelle ligne est toujours en place. Je ne sais plus trop ou chercher.

Ce problème me rappelle quelque chose. D'une part, les fichiers jnl
sont corrompus plus souvent qu'à leur tour, d'autre part, apparmor est
un truc qui cause plus de problèmes qu'il n'en résout. Pour ma part, je
m'en suis sorti en collant les fichiers rw dans /var/lib/bind et en
rajoutant un lien symbolique depuis /etc/bind.

Bonjour,
Du coup,  j'ai supprimé appamor et les fichiers journaux se créent 
correctement dans /etc/bind/ même si ce n'est pas l'endroit approprié me 
senble-t-il.

Merci pour la piste !

--
Migrec

Re: Bind9 et mise à jour DNS

[BERTRAND Joël]

Migrec a écrit :
> Bonjour,

Bonjour,

> Depuis le dernier redémarrage de mon serveur, j'ai un problème
> d'écriture des fichiers journaux de bind :
> May 26 08:54:20 canoe dhcpd[1303]: DHCPREQUEST for 192.168.0.34 from
> ac:fd:ce:c6:11:32 via enp2s0
> May 26 08:54:20 canoe dhcpd[1303]: DHCPACK on 192.168.0.34 to
> ac:fd:ce:c6:11:32 (surf) via enp2s0
> May 26 08:54:20 canoe named[923]: client @0x7fb1a00b90a0
> 192.168.0.2#41979/key rndc-key: updating zone 'homeg.lan/IN': update
> unsuccessful: surf.homeg.lan: 'name not in use' prerequisite not
> satisfied (YXDOMAIN)
> May 26 08:54:20 canoe named[923]: client @0x7fb1a04bdb20
> 192.168.0.2#38965/key rndc-key: signer "rndc-key" approved
> May 26 08:54:20 canoe named[923]: client @0x7fb1a04bdb20
> 192.168.0.2#38965/key rndc-key: updating zone 'homeg.lan/IN': deleting
> rrset at 'surf.homeg.lan' TXT
> May 26 08:54:20 canoe named[923]: client @0x7fb1a04bdb20
> 192.168.0.2#38965/key rndc-key: updating zone 'homeg.lan/IN': adding an
> RR at 'surf.homeg.lan' TXT "311a4dce09a52d221b64a0776507d60894"
> May 26 08:54:20 canoe named[923]: client @0x7fb1a04bdb20
> 192.168.0.2#38965/key rndc-key: updating zone 'homeg.lan/IN': deleting
> rrset at 'surf.homeg.lan' A
> May 26 08:54:20 canoe named[923]: client @0x7fb1a04bdb20
> 192.168.0.2#38965/key rndc-key: updating zone 'homeg.lan/IN': adding an
> RR at 'surf.homeg.lan' A 192.168.0.34
> May 26 08:54:21 canoe kernel: [  164.300678] audit: type=1400
> audit(1590476061.014:21): apparmor="DENIED" operation="mknod"
> profile="/usr/sbin/named" name="/etc/bind/db.homeg.lan.jnl" pid=923
> comm="isc-worker" requested_mask="c" denied_mask="c" fsuid=105 ouid=105
> May 26 08:54:21 canoe named[923]: /etc/bind/db.homeg.lan.jnl: create:
> permission denied
> May 26 08:54:21 canoe named[923]: client @0x7fb1a04bdb20
> 192.168.0.2#38965/key rndc-key: updating zone 'homeg.lan/IN': error:
> journal open failed: unexpected error
> May 26 08:54:21 canoe dhcpd[1303]: Forward map from surf.homeg.lan to
> 192.168.0.34 FAILED: SERVFAIL
> 
> 
> /etc/bind/db.homeg.lan.jnl : je l'ai renommé en db.homeg.lan.jnl-SAUVE
> et curieusement, la date de dernière mise à jour correspond à lka minute
> près au dernier redémarrage de mon serveur.
> 
> Avez-vous une idée ? J'avais déjà rencontré un problème similaire qui
> s'était résolu en changeant une ligne de /etc/appamor.d/usr.sbin.named
> - /etc/bind/** r,
> + /etc/bind/** rw,
> 
> La nouvelle ligne est toujours en place. Je ne sais plus trop ou chercher.

Ce problème me rappelle quelque chose. D'une part, les fichiers jnl
sont corrompus plus souvent qu'à leur tour, d'autre part, apparmor est
un truc qui cause plus de problèmes qu'il n'en résout. Pour ma part, je
m'en suis sorti en collant les fichiers rw dans /var/lib/bind et en
rajoutant un lien symbolique depuis /etc/bind.

Cordialement,

JKB

Re: Bind9 slave

[Christophe Maquaire]

Le jeudi 13 février 2020 à 08:24 +0100, BERTRAND Joël a écrit :
> NoSpam a écrit :
> > Le 12/02/2020 à 23:06, BERTRAND Joël a écrit :
> > > NoSpam a écrit :
> > > > >  Maintenant, ce que je ne saisis pas.
> > > > > 
> > > > > legendre# dig @8.8.8.8 systella.fr | grep systella
> > > > > ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
> > > > > ;systella.fr.   IN  A
> > > > > systella.fr.1741IN  SOA
> > > > > rayleigh.systella.fr.
> > > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400
> > > > > 
> > > > >  Ça semble normal (1741). Sur le slave :
> > > > > 
> > > > > legendre# dig @localhost systella.fr | grep systella
> > > > > ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
> > > > > ;systella.fr.   IN  A
> > > > > systella.fr.86400   IN  SOA
> > > > > rayleigh.systella.fr.
> > > > > bertrand.systella.fr. 2020021201 28800 7200 604800 86400
> > > > > 
> > > > > (tous les slaves tant qu'à faire) et le master, j'obtiens
> > > > > 86400.
> > > > Avec Debian9 et Debian10 en slave, je dois faire deux fois la
> > > > requête
> > > > dig: la 1ere fois comme toi j'obtiens le TTL défini dans le
> > > > master, la
> > > > seconde fois et celles d'après le TTL décrémenté. Si tu
> > > > utilises des
> > > > views dig n'affichera que les vues locales.
> > > Bon, j'obtiens toujours le même.
> > Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca
> > fonctionne
> 
>   Oui, sur 8.8.8.8, ça fonctionne.
> 
> > > Ce n'est pas grave. Ce qui l'est en
> > > revanche plus, c'est la non propagation sur le slave _sans
> > > enlever le
> > > fichier cache_.
> > 
> > Problème version BSD ?
> 
>   Pas sûr. Il y a deux slaves, l'un sur un NetBSD, l'autre chez
> Nerim.
> Même motif, même punition :
> 
> legendre# dig @noemie.nerim.net systella.fr | grep systella
> ; <<>> DiG 9.10.5-P1 <<>> @noemie.nerim.net systella.fr
> ;systella.fr.   IN  A
> systella.fr.86400   IN  SOA rayleigh.systella.fr.
> bertrand.systella.fr. 2020021201 28800 7200 604800 86400
> 
>   Je ne sais pas sous quel OS tourne noemie.nerim.net, mais les
> probabilités pour que ce serveur tourne sous un NetBSD me semblent
> assez
> faibles.
> 
>   Autre chose : noemie.nerim.net prend immédiatement en compte le
> serial
> et met à jour la zone. Je viens de tester en incrémentant le serial.
> Heureusement d'ailleurs, parce que ce serveur utilise aussi nsupdate
> pour mettre à jour un certificat letsencrypt *.systella.fr.
> 
>   Pour information, les versions de bind9 sont les suivantes :
> - master (Linux Debian/testing) : BIND 9.11.14-3-Debian (Extended
> Support Version)
> - slave1 (NetBSD 8.1) : BIND 9.10.5-P1 (Extended Support Version)
> - slave2 (chez Nerim) : version inconnue, je ne suis même pas sûr que
> ce
> soit un bind9.
> 
>   La seule différence entre les deux :
> - slave1 récupère la vue interne (slave1 est le DNS d'un site distant
> relié par VPN et n'est pas un DNC public) ;
> - slave2 récupère la vue externe (et est, lui, public).
> 
>   dig axfr @master fonctionne parfaitement (et il n'y a pas de
> problème
> réseau ou de MTU).
> 
>   Le système de vues fonctionne parfaitement. Lorsque la
> résolution des
> noms arrive depuis une interface LAN/VPN, bind retourne les adresses
> de
> la vue interne. Sinon, celles de la vue externe.
> 
>   Bref, tout ça n'est pas clair. Je comprendrais cette absence de
> propagation sur slave1 si la requête dig axfr depuis slave1 échouait
> ou
> s'il n'y avait pas de paquet de notification. Or dig axfr fonctionne
> et
> je vois le paquet de notification ainsi que sa réponse !
> 
>   Bien cordialement,
> 
>   JB
> 

Re: Bind9 slave

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 12/02/2020 à 23:06, BERTRAND Joël a écrit :
>> NoSpam a écrit :
  Maintenant, ce que je ne saisis pas.

 legendre# dig @8.8.8.8 systella.fr | grep systella
 ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
 ;systella.fr.   IN  A
 systella.fr.    1741    IN  SOA rayleigh.systella.fr.
 bertrand.systella.fr. 2020021201 28800 7200 604800 86400

  Ça semble normal (1741). Sur le slave :

 legendre# dig @localhost systella.fr | grep systella
 ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
 ;systella.fr.   IN  A
 systella.fr.    86400   IN  SOA rayleigh.systella.fr.
 bertrand.systella.fr. 2020021201 28800 7200 604800 86400

 (tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
>>> Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête
>>> dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la
>>> seconde fois et celles d'après le TTL décrémenté. Si tu utilises des
>>> views dig n'affichera que les vues locales.
>> Bon, j'obtiens toujours le même.
> Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca
> fonctionne

Oui, sur 8.8.8.8, ça fonctionne.

>> Ce n'est pas grave. Ce qui l'est en
>> revanche plus, c'est la non propagation sur le slave _sans enlever le
>> fichier cache_.
> 
> Problème version BSD ?

Pas sûr. Il y a deux slaves, l'un sur un NetBSD, l'autre chez Nerim.
Même motif, même punition :

legendre# dig @noemie.nerim.net systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @noemie.nerim.net systella.fr
;systella.fr.   IN  A
systella.fr.86400   IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

Je ne sais pas sous quel OS tourne noemie.nerim.net, mais les
probabilités pour que ce serveur tourne sous un NetBSD me semblent assez
faibles.

Autre chose : noemie.nerim.net prend immédiatement en compte le serial
et met à jour la zone. Je viens de tester en incrémentant le serial.
Heureusement d'ailleurs, parce que ce serveur utilise aussi nsupdate
pour mettre à jour un certificat letsencrypt *.systella.fr.

Pour information, les versions de bind9 sont les suivantes :
- master (Linux Debian/testing) : BIND 9.11.14-3-Debian (Extended
Support Version)
- slave1 (NetBSD 8.1) : BIND 9.10.5-P1 (Extended Support Version)
- slave2 (chez Nerim) : version inconnue, je ne suis même pas sûr que ce
soit un bind9.

La seule différence entre les deux :
- slave1 récupère la vue interne (slave1 est le DNS d'un site distant
relié par VPN et n'est pas un DNC public) ;
- slave2 récupère la vue externe (et est, lui, public).

dig axfr @master fonctionne parfaitement (et il n'y a pas de problème
réseau ou de MTU).

Le système de vues fonctionne parfaitement. Lorsque la résolution des
noms arrive depuis une interface LAN/VPN, bind retourne les adresses de
la vue interne. Sinon, celles de la vue externe.

Bref, tout ça n'est pas clair. Je comprendrais cette absence de
propagation sur slave1 si la requête dig axfr depuis slave1 échouait ou
s'il n'y avait pas de paquet de notification. Or dig axfr fonctionne et
je vois le paquet de notification ainsi que sa réponse !

Bien cordialement,

JB

Re: Bind9 slave

[NoSpam]

Le 12/02/2020 à 23:06, BERTRAND Joël a écrit :

NoSpam a écrit :

 Maintenant, ce que je ne saisis pas.

legendre# dig @8.8.8.8 systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
;systella.fr.   IN  A
systella.fr.    1741    IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

 Ça semble normal (1741). Sur le slave :

legendre# dig @localhost systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
;systella.fr.   IN  A
systella.fr.    86400   IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

(tous les slaves tant qu'à faire) et le master, j'obtiens 86400.

Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête
dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la
seconde fois et celles d'après le TTL décrémenté. Si tu utilises des
views dig n'affichera que les vues locales.

Bon, j'obtiens toujours le même.
Essaye avec dig @8.8.8.8 +nocmd +answer +ttlid a systella.fr ici ca 
fonctionne



Ce n'est pas grave. Ce qui l'est en
revanche plus, c'est la non propagation sur le slave _sans enlever le
fichier cache_.


Problème version BSD ?

--

Daniel

Re: Bind9 slave

[BERTRAND Joël]

NoSpam a écrit :
>> Maintenant, ce que je ne saisis pas.
>>
>> legendre# dig @8.8.8.8 systella.fr | grep systella
>> ; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
>> ;systella.fr.   IN  A
>> systella.fr.    1741    IN  SOA rayleigh.systella.fr.
>> bertrand.systella.fr. 2020021201 28800 7200 604800 86400
>>
>> Ça semble normal (1741). Sur le slave :
>>
>> legendre# dig @localhost systella.fr | grep systella
>> ; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
>> ;systella.fr.   IN  A
>> systella.fr.    86400   IN  SOA rayleigh.systella.fr.
>> bertrand.systella.fr. 2020021201 28800 7200 604800 86400
>>
>> (tous les slaves tant qu'à faire) et le master, j'obtiens 86400.
> 
> Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête
> dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la
> seconde fois et celles d'après le TTL décrémenté. Si tu utilises des
> views dig n'affichera que les vues locales.

Bon, j'obtiens toujours le même. Ce n'est pas grave. Ce qui l'est en
revanche plus, c'est la non propagation sur le slave _sans enlever le
fichier cache_.

Je suis sûr que ça fonctionnait précédemment.

JB

Re: Bind9 slave

[NoSpam]

Le 12/02/2020 à 19:28, BERTRAND Joël a écrit :

NoSpam a écrit :

Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :

[...]

  Dernière chose : il me semble qu'il existe une commande pour

obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une
idée ?

dig  et la seconde entrée, avant le A ou  est le TTL

 Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant
dans
le compteur local du DNS.

Le TTL affiché par dig est décrémenté ce qui pour moi est le tant
restant. J'ai bien compris ? ;)

Oui.

Maintenant, ce que je ne saisis pas.

legendre# dig @8.8.8.8 systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
;systella.fr.   IN  A
systella.fr.1741IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

Ça semble normal (1741). Sur le slave :

legendre# dig @localhost systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
;systella.fr.   IN  A
systella.fr.86400   IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

(tous les slaves tant qu'à faire) et le master, j'obtiens 86400.


Avec Debian9 et Debian10 en slave, je dois faire deux fois la requête 
dig: la 1ere fois comme toi j'obtiens le TTL défini dans le master, la 
seconde fois et celles d'après le TTL décrémenté. Si tu utilises des 
views dig n'affichera que les vues locales.


--
Daniel

Re: Bind9 slave

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :
>> [...]
>>>  Dernière chose : il me semble qu'il existe une commande pour
 obtenir le
 TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une
 idée ?
>>> dig  et la seconde entrée, avant le A ou  est le TTL
>> Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant
>> dans
>> le compteur local du DNS.
> 
> Le TTL affiché par dig est décrémenté ce qui pour moi est le tant
> restant. J'ai bien compris ? ;)

Oui.

Maintenant, ce que je ne saisis pas.

legendre# dig @8.8.8.8 systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @8.8.8.8 systella.fr
;systella.fr.   IN  A
systella.fr.1741IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

Ça semble normal (1741). Sur le slave :

legendre# dig @localhost systella.fr | grep systella
; <<>> DiG 9.10.5-P1 <<>> @localhost systella.fr
;systella.fr.   IN  A
systella.fr.86400   IN  SOA rayleigh.systella.fr.
bertrand.systella.fr. 2020021201 28800 7200 604800 86400

(tous les slaves tant qu'à faire) et le master, j'obtiens 86400.

JB

Re: Bind9 slave

[NoSpam]

Le 12/02/2020 à 18:33, BERTRAND Joël a écrit :

[...]

 Dernière chose : il me semble qu'il existe une commande pour

obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une
idée ?

dig  et la seconde entrée, avant le A ou  est le TTL

Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans
le compteur local du DNS.


Le TTL affiché par dig est décrémenté ce qui pour moi est le tant 
restant. J'ai bien compris ? ;)


--

Daniel

Re: Bind9 slave

[BERTRAND Joël]

NoSpam a écrit :
> 
> Le 12/02/2020 à 16:06, BERTRAND Joël a écrit :
>> Bonjour à tous,
> Bonjour
>>
>> Petit problème avec bind9. J'ai une configuration master/slave
>> avec le
>> master sous Debian/testing et le slave sous NetBSD 8.1. J'ai rajouté un
>> champ sur le master en modifiant le serial pour 2020021201 (auparavant
>> 2019xx). J'ai eu beau relancer les deux bind, je voyais passer les
>> paquets de notification, mais le slave n'était pas mis à jour.
>>
>> En virant le fichier cache sur le slave, la zone a finalement été
>> propagée.
>>
>> Or il me semblait qu'il suffisait que le serial soit supérieur sur le
>> maître pour que le slave se mettre immédiatement à jour lorsqu'il était
>> redémarré. Suis-je dans le vrai ?
> Tu as bien un notify pour la zone vers le slave?

Oui.

Root rayleigh:[/var/lib/bind] > tcpdump -i br0 -p port 53
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 262144 bytes
18:29:10.392473 IP rayleigh-udp.53522 > 192.168.1.2.domain: 47389 notify
[b2&3=0x2400] [1a] SOA? 10.168.192.in-addr.arpa. (101)
18:29:10.454588 IP 192.168.1.2.domain > rayleigh-udp.53522: 47389
notify*- 0/0/0 (41)

rayleigh-udp est l'adresse locale sur le VPN du master. 192.168.1.2 est
l'adresse du slave. Donc le redémarrage du master envoie bien une
notification au slave.

Naturellement, j'ai vérifié que les deux serial étaient bons.

> Dernière chose : il me semble qu'il existe une commande pour
>> obtenir le
>> TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une
>> idée ?
> 
> dig  et la seconde entrée, avant le A ou  est le TTL

Je me suis mal exprimé, ce qui m'intéresse, c'est le temps restant dans
le compteur local du DNS.

Cordialement,

JB

Re: Bind9 slave

[NoSpam]

Le 12/02/2020 à 16:06, BERTRAND Joël a écrit :

Bonjour à tous,

Bonjour


Petit problème avec bind9. J'ai une configuration master/slave avec le
master sous Debian/testing et le slave sous NetBSD 8.1. J'ai rajouté un
champ sur le master en modifiant le serial pour 2020021201 (auparavant
2019xx). J'ai eu beau relancer les deux bind, je voyais passer les
paquets de notification, mais le slave n'était pas mis à jour.

En virant le fichier cache sur le slave, la zone a finalement été 
propagée.

Or il me semblait qu'il suffisait que le serial soit supérieur sur le
maître pour que le slave se mettre immédiatement à jour lorsqu'il était
redémarré. Suis-je dans le vrai ?

Tu as bien un notify pour la zone vers le slave?


Dernière chose : il me semble qu'il existe une commande pour obtenir le
TTL courant sur un enregistrement mais ma mémoire me fait défaut. Une idée ?


dig  et la seconde entrée, avant le A ou  est le TTL

--

Daniel

Re: bind9 startup problems: /var/cache /bind

[Ross Boylan]

I tested my suspicion that bind9-resolvconf was somehow implicated in
the bind9 start problems by returning bind9-resolvconf to its
original, disabled, state and restarting the system.  Unfortunately,
it didn't help:
May 25 19:05:34 barley named[804]: /etc/bind/named.conf.options:2:
change directory to '/var/cache/bind' failed: file not found

But at least one theory has been eliminated.

I also reviewed permissions and ownership of /var/cache/bind and the
"directory" directive in named.conf.options for consistency with
Debian post-install scripts and packaged files.  There weren't any
differences.

Ross

Re: bind9 startup problems: /var/cache /bind

[Ross Boylan]

On Wed, May 22, 2019 at 2:47 PM Richard Hector  wrote:
>
> RequiresMountsFor=/absolute/path/of/mount
>
> .. to go in the unit file - or IIRC running:
>
> sudo systemctl edit bind9.service
>
> ... and putting in:
>
> ---8<
> [Unit]
> RequiresMountsFor=/var
> ---8<
>
> ... followed by:
> sudo systemctl daemon-reload
>
Thank you for the very clear instructions.  I wish README.Debian for
systemd said how you're supposed to handle /etc, since it's somewhat
non-standard.

I tried it.  Unfortunately, it didn't work.  After rebooting I still get
--
May 22 18:38:49 barley named[829]: loading configuration from
'/etc/bind/named.conf'
May 22 18:38:49 barley named[829]: /etc/bind/named.conf.options:2:
change directory to '/var/cache/bind' failed: file not found
May 22 18:38:49 barley named[829]: /etc/bind/named.conf.options:2:
parsing failed: file not found
May 22 18:38:49 barley named[829]: loading configuration: file not found
May 22 18:38:49 barley named[829]: exiting (due to fatal error)

Again, when I restart the service it succeeds.
As a check to see if my options took, systemctl show bind9 does have
the lines (leaving in some resolvconf stuff because of my suspicions):
-
Requires=sysinit.target -.mount var.mount system.slice
Wants=nss-lookup.target bind9-resolvconf.service
ConsistsOf=bind9-resolvconf.service
Before=bind9-resolvconf.service multi-user.target shutdown.target
nss-lookup.target
After=basic.target system.slice -.mount systemd-journald.socket
sysinit.target var.mount network.target
RequiresMountsFor=/var
---

Finally, ls -ld /var/cache/bind
drwxrwxr-x 2 root bind 4096 May 22 16:50 /var/cache/bind
The manual restart of bin began just before 18:50 local time.

Ross

Re: bind9 startup problems: /var/cache /bind

[Richard Hector]

On 23/05/19 9:08 AM, Ross Boylan wrote:
> /var is a separate file system, and like / it's encrypted, so it might
> take a bit of time to activate it.  Whether it's available when
> needed, I don't know, though the error suggests it might not be.
> Could systemd be launching services while some of the mounts (and the
> required decryption) are still to be done?
> 
> Is there some systemd way to ensure the file system is mounted before
> launching bind?  But I'd think if /var weren't available, bind
> wouldn't be the only one with a problem.

Well, I don't see anything in bind9.service to prevent it starting. I'm
not sure what the best dependency is ...

A bit of web searching finds:
https://unix.stackexchange.com/questions/246935/set-systemd-service-to-execute-after-fstab-mount

... which suggests:
RequiresMountsFor=/absolute/path/of/mount

.. to go in the unit file - or IIRC running:

sudo systemctl edit bind9.service

... and putting in:

---8<
[Unit]
RequiresMountsFor=/var
---8<

... followed by:
sudo systemctl daemon-reload

Not tested.

Cheers,
Richard



signature.asc
Description: OpenPGP digital signature

Re: bind9 startup problems: /var/cache /bind

[Ross Boylan]

/var is a separate file system, and like / it's encrypted, so it might
take a bit of time to activate it.  Whether it's available when
needed, I don't know, though the error suggests it might not be.
Could systemd be launching services while some of the mounts (and the
required decryption) are still to be done?

Is there some systemd way to ensure the file system is mounted before
launching bind?  But I'd think if /var weren't available, bind
wouldn't be the only one with a problem.

Ross

Re: bind9 startup problems: /var/cache /bind

[Richard Hector]

On 23/05/19 8:00 AM, Ross Boylan wrote:
> At system start, bind9 fails to start on a recently created buster
> system.  Some of the local bind is based on configuration from an
> earlier bind.  The logs show
> /etc/bind/named.conf.options:2: change directory to '/var/cache/bind'
> failed: file not found
> 
> But if I then start it manually via systemctl, it starts.  But then I
> need to fix up other services which were counting on working name
> resolution when they started.

Is /var/cache (or /var) a separate filesystem, that might not be mounted
in time at boot?

Richard



signature.asc
Description: OpenPGP digital signature

Re: Bind9 vragen

[Wouter Verhelst]

On Wed, Jul 18, 2018 at 11:10:44AM +0200, Paul van der Vlis wrote:
> Op 17-07-18 om 12:19 schreef Wouter Verhelst:
> > On Sun, Jul 15, 2018 at 01:38:50PM +0200, Paul van der Vlis wrote:
> 
> 
> 
> >> O, leuk. Hier in NL heb je wat vaker een vast IP-adres dan in België
> >> denk ik. Maar hier rukt het dynamische gebeuren ook op, ahum.
> > 
> > Not sure. Op Belgacom ADSL loopt veranderde het vroeger zowat elke 24
> > uur, "because we can"; geen idee of dat nog het geval is (Belgacom is
> > een bende incompetente idioten, dus daar ben ik geen klant van ;-)
> > 
> > Telenet heeft dat nooit gedaan; wijziging van IP-adres gebeurt daar in
> > principe enkel als je een MAC-adres verandert, of een machine meer dan
> > een paar minuten uitzet en iemand anders met je IP-adres gaan lopen is,
> > of als ze werken aan hun infrastructuur uitvoeren en daardoor de DHCP
> > cache gecleared wordt, of dat soort dingen.
> 
> Hier in NL heb je aardig wat providers waar je een vast IP krijgt.
> Alleen als je dienst veranderd (bijvoorbeeld als je van ADSL naar VDSL
> gaat) krijg je een ander IP.
> 
> > Als de nameserver niet te vertrouwen is, dan kan die inderdaad foutief
> > aangeven dat het DS record niet bestaat -- maar dan moet hij voor DNSSEC
> > ook een NSEC of NSEC3 record meegeven, met een RRSIG record daarvoor.
> > Dat eerste kan hij; maar dat tweede niet zonder de key van de parent
> > nameserver. Die heeft hij niet, dus kan je resolver zien dat er geen
> > RRSIG record is of dat de handtekening daarvan niet correct is, en
> > gewoon die nameserver overslaan; hetzij door naar de tweede nameserver
> > in zijn lijst met geconfigureerde nameservers te gaan, of door een root
> > query te doen en zelf een cache op te bouwen.
> 
> Hmm, ik begrijp het niet helemaal. Ben ook wat traag soms, ahum.
> 
> servfail.nl is een test-domein waar de dnssec validitatie niet in orde
> is.

All bets are off, dan. Als het domein niet valideert voor DNSSEC, dan
loopt alles fout, of het nu juiste of foute informatie is.

> Als ik dnssec-validation uit zet op ns2.sociotech.nl en dan doe:
> host servfail.nl ns2.sociotech.nl
> 
> Dan krijg ik keurig een IP-nummer terug (alleen IPv6 overigens).
> 
> Als ns2.sociotech.nl nu ook zou zeggen authoritatief te zijn voor
> servfail.nl dan kan hij een verkeerd IP-nummer teruggeven.
> Of vergis ik me?

Nee, dat klopt. Maar DNSSEC kan daar uiteraard ook niks aan doen.

> Wellicht moet ik iets omzetten op mijn laptop wat dnssec-validatie eist,
> en wat anders een waarschuwing geeft?
> 
> >> Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die
> >> gewoon niet aan DNSsec doet.
> > 
> > DNSSEC is normaal gezien transparant voor de nameserver. RRSIG, DS, en
> > DNSKEY records zijn ook gewoon records. Er is een manier om een
> > nameserver om records te vragen waar die nameserver zelf niet van op de
> > hoogte is.
> 
> Daar heb je gelijk.
> 
> > Een nameserver kan inderdaad DNSSEC blokkeren, en je firewall kan ook
> > alle DNS queries naar overal behalve die slechte nameserver blokkeren,
> > maar dat valt wel op.
> 
> Zou ik mijn firewall moeten instellen om DNS queries naar een bepaalde
> nameserver te blokkeren? Dan zou ik toch eerst al moeten weten dat die
> nameserver fout is?

Je begrijpt me verkeerd :-)

Als je in je voorgestelde koffiehuis zit, en de router van dat
koffiehuis firewallt alle DNS requests weg tenzij die naar de nameserver
die in het DHCP response zit, én die nameserver in het DHCP response
blokkeert requests naar DNSSEC-related RRs, dan kan een eindgebruiker
inderdaad geen DNSSEC doen. Maar dat valt dus wel op :-)

[...]
> > [1] met dien verstande dat NSEC3 hashing met een beetje GPU computing
> > redelijk snel te breken is.
> 
> Dat is volgens mij de reden dat het goed is om de ZSK key vaak te
> verwisselen. Maar de details ken ik niet.

Onder andere, ja. Maar er zijn nog andere redenen.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Bind9 vragen

[Paul van der Vlis]

Op 17-07-18 om 12:19 schreef Wouter Verhelst:
> On Sun, Jul 15, 2018 at 01:38:50PM +0200, Paul van der Vlis wrote:



>> O, leuk. Hier in NL heb je wat vaker een vast IP-adres dan in België
>> denk ik. Maar hier rukt het dynamische gebeuren ook op, ahum.
> 
> Not sure. Op Belgacom ADSL loopt veranderde het vroeger zowat elke 24
> uur, "because we can"; geen idee of dat nog het geval is (Belgacom is
> een bende incompetente idioten, dus daar ben ik geen klant van ;-)
> 
> Telenet heeft dat nooit gedaan; wijziging van IP-adres gebeurt daar in
> principe enkel als je een MAC-adres verandert, of een machine meer dan
> een paar minuten uitzet en iemand anders met je IP-adres gaan lopen is,
> of als ze werken aan hun infrastructuur uitvoeren en daardoor de DHCP
> cache gecleared wordt, of dat soort dingen.

Hier in NL heb je aardig wat providers waar je een vast IP krijgt.
Alleen als je dienst veranderd (bijvoorbeeld als je van ADSL naar VDSL
gaat) krijg je een ander IP.

> Als de nameserver niet te vertrouwen is, dan kan die inderdaad foutief
> aangeven dat het DS record niet bestaat -- maar dan moet hij voor DNSSEC
> ook een NSEC of NSEC3 record meegeven, met een RRSIG record daarvoor.
> Dat eerste kan hij; maar dat tweede niet zonder de key van de parent
> nameserver. Die heeft hij niet, dus kan je resolver zien dat er geen
> RRSIG record is of dat de handtekening daarvan niet correct is, en
> gewoon die nameserver overslaan; hetzij door naar de tweede nameserver
> in zijn lijst met geconfigureerde nameservers te gaan, of door een root
> query te doen en zelf een cache op te bouwen.

Hmm, ik begrijp het niet helemaal. Ben ook wat traag soms, ahum.

servfail.nl is een test-domein waar de dnssec validitatie niet in orde
is. Als ik dnssec-validation uit zet op ns2.sociotech.nl en dan doe:
host servfail.nl ns2.sociotech.nl

Dan krijg ik keurig een IP-nummer terug (alleen IPv6 overigens).

Als ns2.sociotech.nl nu ook zou zeggen authoritatief te zijn voor
servfail.nl dan kan hij een verkeerd IP-nummer teruggeven.
Of vergis ik me?

Wellicht moet ik iets omzetten op mijn laptop wat dnssec-validatie eist,
en wat anders een waarschuwing geeft?

>> Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die
>> gewoon niet aan DNSsec doet.
> 
> DNSSEC is normaal gezien transparant voor de nameserver. RRSIG, DS, en
> DNSKEY records zijn ook gewoon records. Er is een manier om een
> nameserver om records te vragen waar die nameserver zelf niet van op de
> hoogte is.

Daar heb je gelijk.

> Een nameserver kan inderdaad DNSSEC blokkeren, en je firewall kan ook
> alle DNS queries naar overal behalve die slechte nameserver blokkeren,
> maar dat valt wel op.

Zou ik mijn firewall moeten instellen om DNS queries naar een bepaalde
nameserver te blokkeren? Dan zou ik toch eerst al moeten weten dat die
nameserver fout is?

> Inderdaad. Ben gisteren ook toevallig overgestapt naar backports bind
> ;-)

Ik nu ook.

Bedankt voor je uitgebreide verhaal over NSEC3, ik ben de materie nog
aan het bestuderen.

> [1] met dien verstande dat NSEC3 hashing met een beetje GPU computing
> redelijk snel te breken is.

Dat is volgens mij de reden dat het goed is om de ZSK key vaak te
verwisselen. Maar de details ken ik niet.

Groeten,
Paul

-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: Bind9 vragen

[Wouter Verhelst]

On Sun, Jul 15, 2018 at 01:38:50PM +0200, Paul van der Vlis wrote:
> Hoi Wouter en anderen,
> 
> Op 15-07-18 om 12:29 schreef Wouter Verhelst:
> > Ik had me in bovenstaande paragraaf inderdaad vergist. De glue is voor
> > de KSK, niet voor de ZSK. De ZSK kan je automatisch laten vervangen, de
> > KSK niet (daarvoor moet je de glue idd updaten).
> 
> Ook dat kan tegenwoordig automatisch als er een eerste geldige key op
> staat, kan deze worden vervangen. Kijk eens naar RFC 7344 en 8078.

Interesting; dat wist ik nog niet.

> Zelf heb ik ook het uploaden van de eerste keer nu geautomatiseerd, met
> de API van de registrar (ik gebruik opendomainregistry.net, mensen die
> interesse hebben kunnen de scripts krijgen).
> 
> >>> Bovenstaande is een directe kopie uit mijn live configuratie van een
> >>> domein waarin een aantal klanten met dynamisch IP-adres zitten. Bij de
> >>> klant draait een cronjob die gewoon een wget doet naar een CGI-script;
> >>> dat script draait dan nsupdate met een speciale "cgi" key, wat de zone
> >>> aanpast. Werkt perfect: dynamische DNS-updates met DNSSEC-ondersteuning
> >>> :-)
> >>
> >> Is dat vergelijkbaar met dyndns?
> > 
> > Sortof. Alleen draai je het zelf en heeft dyndns geen DNSSEC, VZIW.
> 
> O, leuk. Hier in NL heb je wat vaker een vast IP-adres dan in België
> denk ik. Maar hier rukt het dynamische gebeuren ook op, ahum.

Not sure. Op Belgacom ADSL loopt veranderde het vroeger zowat elke 24
uur, "because we can"; geen idee of dat nog het geval is (Belgacom is
een bende incompetente idioten, dus daar ben ik geen klant van ;-)

Telenet heeft dat nooit gedaan; wijziging van IP-adres gebeurt daar in
principe enkel als je een MAC-adres verandert, of een machine meer dan
een paar minuten uitzet en iemand anders met je IP-adres gaan lopen is,
of als ze werken aan hun infrastructuur uitvoeren en daardoor de DHCP
cache gecleared wordt, of dat soort dingen.

[...]
> >> Hoe controleert een computer of een programma dat?
> > 
> > DNSSEC is alleen veilig als er een ononderbroken keten van DS en DNSKEY
> > records is van een trust anchor (meestal de root key) tot het domein.
> > Als er ergens een onderbreking is, dan kan een aanvaller inderdaad valse
> > antwoorden voor die onderbreking genereren en claimen dat er voor child
> > domeinen geen DNSSEC aanwezig is.
> > 
> > Als een parent domein een DS record heeft voor een child domein, dan
> > MOET dat child domein een overeenkomstige DNSKEY record hebben. Is dat
> > niet het geval, dan wordt het domein als ongeldig gezien en genegeerd.
> > Als er een ononderbroken keten van DS en DNSKEY records bestaat van het
> > trust anchor tot het domein, dan kan een aanvaller alleen de afwezigheid
> > van DNSSEC faken door eerst een private key te kraken.
> > 
> > (Als dat gebeurt, dan is er uiteraard een probleem ;-)
> 
> Maar hoe weet je dat de parent een DS record heeft? Dat vraag je neem ik
> aan aan de nameserver. Als die nameserver niet te vertrouwen is, dan
> werkt dit dus niet.

Als de nameserver niet te vertrouwen is, dan kan die inderdaad foutief
aangeven dat het DS record niet bestaat -- maar dan moet hij voor DNSSEC
ook een NSEC of NSEC3 record meegeven, met een RRSIG record daarvoor.
Dat eerste kan hij; maar dat tweede niet zonder de key van de parent
nameserver. Die heeft hij niet, dus kan je resolver zien dat er geen
RRSIG record is of dat de handtekening daarvan niet correct is, en
gewoon die nameserver overslaan; hetzij door naar de tweede nameserver
in zijn lijst met geconfigureerde nameservers te gaan, of door een root
query te doen en zelf een cache op te bouwen.

> Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die
> gewoon niet aan DNSsec doet.

DNSSEC is normaal gezien transparant voor de nameserver. RRSIG, DS, en
DNSKEY records zijn ook gewoon records. Er is een manier om een
nameserver om records te vragen waar die nameserver zelf niet van op de
hoogte is.

Een nameserver kan inderdaad DNSSEC blokkeren, en je firewall kan ook
alle DNS queries naar overal behalve die slechte nameserver blokkeren,
maar dat valt wel op.

> Denk bijvoorbeeld aan een situatie bij het koffietentje op de hoek. Je
> logt in op de wifi, en je krijgt via DHCP een nameserver toegewezen. Les
> uit bovenstaande is volgens mij dat dit niet OK is, ook niet met dnssec.

Toch wel.

> Ook een ISP zou je in principe verkeerde gegevens kunnen geven. Volgens
> mij heel simpel via "split DNS".

Niet met DNSSEC.

> Eigenlijk lijkt het mij daarom het beste qua security om op b.v. een
> laptop zelf een nameserver te draaien, dat heb je zelf in de hand.
> 
> Wat ook nog een security aspect is als ik me niet vergis, is dat de
> root-keys geheel in handen zijn van de Amerikanen. Het lijkt me dat ze
> de boel kunnen vervalsen.

Dat is inderdaad zo: wie de root key heeft kan foutieve NS, DS, en
DNSKEY records de wereld insturen. Daar kan niks aan gedaan worden, en
dat is inderdaad een probleem.

De veiligheid van DNSSEC is gebaseerd op het axioma 

Re: Bind9 vragen

[Paul van der Vlis]

Hoi Wouter en anderen,

Op 15-07-18 om 12:29 schreef Wouter Verhelst:
> Ik had me in bovenstaande paragraaf inderdaad vergist. De glue is voor
> de KSK, niet voor de ZSK. De ZSK kan je automatisch laten vervangen, de
> KSK niet (daarvoor moet je de glue idd updaten).

Ook dat kan tegenwoordig automatisch als er een eerste geldige key op
staat, kan deze worden vervangen. Kijk eens naar RFC 7344 en 8078.

Zelf heb ik ook het uploaden van de eerste keer nu geautomatiseerd, met
de API van de registrar (ik gebruik opendomainregistry.net, mensen die
interesse hebben kunnen de scripts krijgen).

>>> Bovenstaande is een directe kopie uit mijn live configuratie van een
>>> domein waarin een aantal klanten met dynamisch IP-adres zitten. Bij de
>>> klant draait een cronjob die gewoon een wget doet naar een CGI-script;
>>> dat script draait dan nsupdate met een speciale "cgi" key, wat de zone
>>> aanpast. Werkt perfect: dynamische DNS-updates met DNSSEC-ondersteuning
>>> :-)
>>
>> Is dat vergelijkbaar met dyndns?
> 
> Sortof. Alleen draai je het zelf en heeft dyndns geen DNSSEC, VZIW.

O, leuk. Hier in NL heb je wat vaker een vast IP-adres dan in België
denk ik. Maar hier rukt het dynamische gebeuren ook op, ahum.

 Het is mij nog niet helemaal duidelijk wat het "dsset" bestand nu
 precies doet.
>>>
>>> Dat heeft te maken met de glue van je DNSSEC, en is redelijk belangrijk.
>>>
>>> DNSSEC werkt als volgt:
>>>
>>> - In de root zone zit er een aantal DS records voor de naam "be" met
>>>   daarin de fingerprints van de KSKs van het domein "be"
>>> - In de "be" zone zitten er DNSKEY records voor die KSKs. Deze KSKs
>>>   tekenen de RRs van de DNSKEY records van de ZSKs.
>>> - De ZSKs van de "be" zone tekenen dan alle andere RRs in die zone,
>>>   inclusief het DS record voor "nixsys.be"
>>>
>>> Het zelfde verhaal wordt dan herhaald door "nixsys.be" dat DS records
>>> bevat voor "dyn-cust.nixsys.be", enzovoort.
>>>
>>> Het "dsset" bestand bevat simpelweg de DS records die je aan je parent
>>> zone moet doorgeven.
>>
>> Dat is inderdaad gebruikelijk, maar niet bij .nl domeinen. Daar moet je
>> namelijk je pubkey uploaden en de DS records genereren ze zelf.
> 
> Het parent domein heeft een DS-record nodig. Dat DS-record kan je
> inderdaad makkelijk genereren vanuit je pubkey (het is uiteindelijk
> gewoon een hash). Hoe het parent domein aan dat DS record geraakt, is
> minder belangrijk.
> 
> Als je zelf het parent domein beheert, dan kan je via dat dsset
> bestand--of via het bind-commando 'dnssec-dsfromkey'--het DS record zelf
> genereren. Dit is in jouw geval niet van toepassing.
> 
>> Dus vandaar mijn verwarring waarvoor dat dsset bestand nodig is.
>>
>> "Door uit die DNSKEY records zelf de DS records te genereren houdt SIDN
>> controle over het daarbij gebruikte hash-algoritme."
> 
> Juist.
> 
>> Wat ik nog niet helemaal begrijp is het volgende: stel iemand kan de
>> nameserver manipuleren of de antwoorden vervalsen, dat is toch iets waar
>> dnssec tegen zou moeten beveiligen.
> 
> Dat is de raison d'être van DNSSEC, ja.
> 
>> Maar dan kan hij toch ook antwoorden dat het domein geen dnssec heeft en
>> er dus ook niks te controleren valt.
> 
> Neen.
> 
>> Hoe controleert een computer of een programma dat?
> 
> DNSSEC is alleen veilig als er een ononderbroken keten van DS en DNSKEY
> records is van een trust anchor (meestal de root key) tot het domein.
> Als er ergens een onderbreking is, dan kan een aanvaller inderdaad valse
> antwoorden voor die onderbreking genereren en claimen dat er voor child
> domeinen geen DNSSEC aanwezig is.
> 
> Als een parent domein een DS record heeft voor een child domein, dan
> MOET dat child domein een overeenkomstige DNSKEY record hebben. Is dat
> niet het geval, dan wordt het domein als ongeldig gezien en genegeerd.
> Als er een ononderbroken keten van DS en DNSKEY records bestaat van het
> trust anchor tot het domein, dan kan een aanvaller alleen de afwezigheid
> van DNSSEC faken door eerst een private key te kraken.
> 
> (Als dat gebeurt, dan is er uiteraard een probleem ;-)

Maar hoe weet je dat de parent een DS record heeft? Dat vraag je neem ik
aan aan de nameserver. Als die nameserver niet te vertrouwen is, dan
werkt dit dus niet.

Ik bedacht me ook nog dat je ook nog een nameserver kunt neerzetten die
gewoon niet aan DNSsec doet.

Denk bijvoorbeeld aan een situatie bij het koffietentje op de hoek. Je
logt in op de wifi, en je krijgt via DHCP een nameserver toegewezen. Les
uit bovenstaande is volgens mij dat dit niet OK is, ook niet met dnssec.

Ook een ISP zou je in principe verkeerde gegevens kunnen geven. Volgens
mij heel simpel via "split DNS".

Eigenlijk lijkt het mij daarom het beste qua security om op b.v. een
laptop zelf een nameserver te draaien, dat heb je zelf in de hand.

Wat ook nog een security aspect is als ik me niet vergis, is dat de
root-keys geheel in handen zijn van de Amerikanen. Het lijkt me dat ze
de boel kunnen vervalsen. Volgens mij hebben de 

Re: Bind9 vragen

[Wouter Verhelst]

On Fri, Jul 13, 2018 at 09:24:44PM +0200, Paul van der Vlis wrote:
> Op 13-07-18 om 15:17 schreef Wouter Verhelst:
> > On Wed, Jun 27, 2018 at 02:04:37PM +0200, Paul van der Vlis wrote:
> > De échte manual van bind is de "Administrator's Reference Manual":
> > 
> > https://www.isc.org/downloads/bind/doc/
> > 
> > Daar staat ook een "BIND DNSSEC Guide", die je wil lezen.
> 
> Ik had de officiële documentatie ondertussen ook gevonden.
> Vreemd inderdaad dat ik daar in eerste instantie niet zocht, ik denk dan
> vaak dat dat meer naslag is dan iets leesbaars.

Heh, in dit geval niet echt :-)

> >> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
> >>
> >> Wat lijkt jullie een goede plek om keys en zones neer te zetten, zelf
> >> denk ik over /etc/bind/zones/ en /etc/bind/keys/ .
> > 
> > Dat is ook (ongeveer) wat ik doe.
> > 
> >> Voor de keys wil ik graag een aparte map, want ik overweeg ze ergens
> >> anders neer te zetten zodat ze offline zijn, maar wel te mounten.
> > 
> > Sure.
> > 
> >> Vernieuwen jullie de KSK en de ZSK regelmatig of niet?
> > 
> > Dat moet je doen voor de veiligheid.
> 
> Heb jij al bepaald hoe vaak je het gaat doen? En zet je ook harde
> einddatums in de keys? Op het moment heb ik geen einddatums in de keys,
> en ook niet in de RRSIG. Vooral dat laatste lijkt me fout.

KSK wordt aangeraden om jaarlijks te vernieuwen.

ZSK hangt af van de grootte van je domein. Eens per drie maand is
voldoende voor een gemiddeld domein.

> >> En wat voor strategie hebben jullie voor online of offline bewaren?
> > 
> > Persoonlijk doe ik dat laatste niet.
> 
> Op zich heb je die KSK key eigenlijk niet meer nodig, alleen als je een
> nieuwe ZSK key wilt maken, of hem wilt intrekken.

ACK.

> >> Hoe vaak vernieuwen jullie de RRSIG, als er geen wijzigingen zijn?
> > 
> > Dat kan je aan bind overlaten (en dat raad ik je heel erg aan):
> > 
> > zone "dyn-cust.nixsys.be" {
> > type master;
> > update-policy {
> > grant local-ddns zonesub any;
> > grant wou...@grep.be zonesub any;
> > grant cgi zonesub any;
> > };
> > allow-transfer { !notslaves; key latin; };
> > file "/etc/bind/zones/dyn-cust.nixsys.be";
> > key-directory "/etc/bind/keys";
> > auto-dnssec maintain;
> > };
> > 
> > De belangrijkste lijnen hierboven zijn die met "key-directory" en
> > "auto-dnssec". De eerste configureert waar je je keys dropt (die je van
> > tijd tot tijd moet genereren met "dnssec-keygen", waarbij je ook tijden
> > moet opgeven -- de manpage is daar redelijk duidelijk over). 
> 
> Ik neem aan tijden waarna ze verlopen? Wat voor tijden hou jij aan?

Zie boven :-)

> > BIND zal
> > die keys dan automatisch inladen, en de RRSIGs automatisch roteren. De
> > KSKs worden ook automatisch vervangen op basis van de tijden die je aan
> > dnssec-keygen meegegeven hebt. Alleen de glue van je ZSKs moet je nog
> > handmatig updaten (want daar heeft BIND geen toegang toe).
> 
> De ZSK wordt door de KSK ondertekend en daaruit haalt hij/zij zijn
> waarde. Ik neem dus aan dat je de KSK bedoeld met "glue"?

Ik had me in bovenstaande paragraaf inderdaad vergist. De glue is voor
de KSK, niet voor de ZSK. De ZSK kan je automatisch laten vervangen, de
KSK niet (daarvoor moet je de glue idd updaten).

> > Bovenstaande is een directe kopie uit mijn live configuratie van een
> > domein waarin een aantal klanten met dynamisch IP-adres zitten. Bij de
> > klant draait een cronjob die gewoon een wget doet naar een CGI-script;
> > dat script draait dan nsupdate met een speciale "cgi" key, wat de zone
> > aanpast. Werkt perfect: dynamische DNS-updates met DNSSEC-ondersteuning
> > :-)
> 
> Is dat vergelijkbaar met dyndns?

Sortof. Alleen draai je het zelf en heeft dyndns geen DNSSEC, VZIW.

> >> Het is mij nog niet helemaal duidelijk wat het "dsset" bestand nu
> >> precies doet.
> > 
> > Dat heeft te maken met de glue van je DNSSEC, en is redelijk belangrijk.
> > 
> > DNSSEC werkt als volgt:
> > 
> > - In de root zone zit er een aantal DS records voor de naam "be" met
> >   daarin de fingerprints van de KSKs van het domein "be"
> > - In de "be" zone zitten er DNSKEY records voor die KSKs. Deze KSKs
> >   tekenen de RRs van de DNSKEY records van de ZSKs.
> > - De ZSKs van de "be" zone tekenen dan alle andere RRs in die zone,
> >   inclusief het DS record voor "nixsys.be"
> > 
> > Het zelfde verhaal wordt dan herhaald door "nixsys.be" dat DS records
> > bevat voor "dyn-cust.nixsys.be", enzovoort.
> > 
> > Het "dsset" bestand bevat simpelweg de DS records die je aan je parent
> > zone moet doorgeven.
> 
> Dat is inderdaad gebruikelijk, maar niet bij .nl domeinen. Daar moet je
> namelijk je pubkey uploaden en de DS records genereren ze zelf.

Het parent domein heeft een DS-record nodig. Dat DS-record kan je
inderdaad makkelijk genereren vanuit je pubkey (het is uiteindelijk
gewoon een hash). Hoe het parent domein aan dat DS record geraakt, 

Re: Bind9 vragen

[Paul van der Vlis]

Hallo Wouter en anderen,

Bedankt voor je opmerkingen.
Ik zal na de tekst van Wouter reageren:

Op 13-07-18 om 15:17 schreef Wouter Verhelst:
> On Wed, Jun 27, 2018 at 02:04:37PM +0200, Paul van der Vlis wrote:
>> Hoi,
>>
>> Ik ben bezig met het implementeren van DNSsec en rndc op bind9 voor een
>> authoritatieve nameserver.
> 
> Jeuj.
> 
>> Rndc is een tool van bind om domeinen toe te voegen (eerder gebruikte ik
>> hiervoor eigen scriptjes).
> 
> Neen.
> 
> rndc is een tool om bind te beheren. Je kan daar inderdaad vanalles mee
> doen, zoals domeinen toevoegen, maar niet alleen dat.

Het kan inderdaad meer, maar tot nu toe gebruik ik het alleen voor het
toevoegen en verwijderen van domeinen.

>> Ik zie dat bind dingen opslaat in /var/cache/bind/ , bij een "cache"
>> denk ik aan een duplicatie van informatie, het origineel staat dan
>> ergens anders. Misschien is dat ook zo.
>>
>> De manuals die ik vind op internet over Bind zijn vaak oud of van
>> slechte kwaliteit. Degene die ik nog het beste vond is van Digital Ocean
>> en is van 2014. Wat me daar opvalt is dat ze bijvoorbeeld keys opslaan
>> in de root van /var/cache/bind/ , dat lijkt me een rare plek.
> 
> De échte manual van bind is de "Administrator's Reference Manual":
> 
> https://www.isc.org/downloads/bind/doc/
> 
> Daar staat ook een "BIND DNSSEC Guide", die je wil lezen.

Ik had de officiële documentatie ondertussen ook gevonden.
Vreemd inderdaad dat ik daar in eerste instantie niet zocht, ik denk dan
vaak dat dat meer naslag is dan iets leesbaars.

>> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
>>
>> Wat lijkt jullie een goede plek om keys en zones neer te zetten, zelf
>> denk ik over /etc/bind/zones/ en /etc/bind/keys/ .
> 
> Dat is ook (ongeveer) wat ik doe.
> 
>> Voor de keys wil ik graag een aparte map, want ik overweeg ze ergens
>> anders neer te zetten zodat ze offline zijn, maar wel te mounten.
> 
> Sure.
> 
>> Vernieuwen jullie de KSK en de ZSK regelmatig of niet?
> 
> Dat moet je doen voor de veiligheid.

Heb jij al bepaald hoe vaak je het gaat doen? En zet je ook harde
einddatums in de keys? Op het moment heb ik geen einddatums in de keys,
en ook niet in de RRSIG. Vooral dat laatste lijkt me fout.

>> En wat voor strategie hebben jullie voor online of offline bewaren?
> 
> Persoonlijk doe ik dat laatste niet.

Op zich heb je die KSK key eigenlijk niet meer nodig, alleen als je een
nieuwe ZSK key wilt maken, of hem wilt intrekken.

>> Hoe vaak vernieuwen jullie de RRSIG, als er geen wijzigingen zijn?
> 
> Dat kan je aan bind overlaten (en dat raad ik je heel erg aan):
> 
> zone "dyn-cust.nixsys.be" {
>   type master;
>   update-policy {
>   grant local-ddns zonesub any;
>   grant wou...@grep.be zonesub any;
>   grant cgi zonesub any;
>   };
>   allow-transfer { !notslaves; key latin; };
>   file "/etc/bind/zones/dyn-cust.nixsys.be";
>   key-directory "/etc/bind/keys";
>   auto-dnssec maintain;
> };
> 
> De belangrijkste lijnen hierboven zijn die met "key-directory" en
> "auto-dnssec". De eerste configureert waar je je keys dropt (die je van
> tijd tot tijd moet genereren met "dnssec-keygen", waarbij je ook tijden
> moet opgeven -- de manpage is daar redelijk duidelijk over). 

Ik neem aan tijden waarna ze verlopen? Wat voor tijden hou jij aan?

> BIND zal
> die keys dan automatisch inladen, en de RRSIGs automatisch roteren. De
> KSKs worden ook automatisch vervangen op basis van de tijden die je aan
> dnssec-keygen meegegeven hebt. Alleen de glue van je ZSKs moet je nog
> handmatig updaten (want daar heeft BIND geen toegang toe).

De ZSK wordt door de KSK ondertekend en daaruit haalt hij/zij zijn
waarde. Ik neem dus aan dat je de KSK bedoeld met "glue"?

> Bovenstaande is een directe kopie uit mijn live configuratie van een
> domein waarin een aantal klanten met dynamisch IP-adres zitten. Bij de
> klant draait een cronjob die gewoon een wget doet naar een CGI-script;
> dat script draait dan nsupdate met een speciale "cgi" key, wat de zone
> aanpast. Werkt perfect: dynamische DNS-updates met DNSSEC-ondersteuning
> :-)

Is dat vergelijkbaar met dyndns?

>> Het is mij nog niet helemaal duidelijk wat het "dsset" bestand nu
>> precies doet.
> 
> Dat heeft te maken met de glue van je DNSSEC, en is redelijk belangrijk.
> 
> DNSSEC werkt als volgt:
> 
> - In de root zone zit er een aantal DS records voor de naam "be" met
>   daarin de fingerprints van de KSKs van het domein "be"
> - In de "be" zone zitten er DNSKEY records voor die KSKs. Deze KSKs
>   tekenen de RRs van de DNSKEY records van de ZSKs.
> - De ZSKs van de "be" zone tekenen dan alle andere RRs in die zone,
>   inclusief het DS record voor "nixsys.be"
> 
> Het zelfde verhaal wordt dan herhaald door "nixsys.be" dat DS records
> bevat voor "dyn-cust.nixsys.be", enzovoort.
> 
> Het "dsset" bestand bevat simpelweg de DS records die je aan je parent
> zone 

Re: Bind9 vragen

[Wouter Verhelst]

On Wed, Jun 27, 2018 at 02:04:37PM +0200, Paul van der Vlis wrote:
> Hoi,
> 
> Ik ben bezig met het implementeren van DNSsec en rndc op bind9 voor een
> authoritatieve nameserver.

Jeuj.

> Rndc is een tool van bind om domeinen toe te voegen (eerder gebruikte ik
> hiervoor eigen scriptjes).

Neen.

rndc is een tool om bind te beheren. Je kan daar inderdaad vanalles mee
doen, zoals domeinen toevoegen, maar niet alleen dat.

> Ik zie dat bind dingen opslaat in /var/cache/bind/ , bij een "cache"
> denk ik aan een duplicatie van informatie, het origineel staat dan
> ergens anders. Misschien is dat ook zo.
> 
> De manuals die ik vind op internet over Bind zijn vaak oud of van
> slechte kwaliteit. Degene die ik nog het beste vond is van Digital Ocean
> en is van 2014. Wat me daar opvalt is dat ze bijvoorbeeld keys opslaan
> in de root van /var/cache/bind/ , dat lijkt me een rare plek.

De échte manual van bind is de "Administrator's Reference Manual":

https://www.isc.org/downloads/bind/doc/

Daar staat ook een "BIND DNSSEC Guide", die je wil lezen.

> https://www.digitalocean.com/community/tutorials/how-to-setup-dnssec-on-an-authoritative-bind-dns-server--2
> 
> Wat lijkt jullie een goede plek om keys en zones neer te zetten, zelf
> denk ik over /etc/bind/zones/ en /etc/bind/keys/ .

Dat is ook (ongeveer) wat ik doe.

> Voor de keys wil ik graag een aparte map, want ik overweeg ze ergens
> anders neer te zetten zodat ze offline zijn, maar wel te mounten.

Sure.

> Vernieuwen jullie de KSK en de ZSK regelmatig of niet?

Dat moet je doen voor de veiligheid.

> En wat voor strategie hebben jullie voor online of offline bewaren?

Persoonlijk doe ik dat laatste niet.

> Hoe vaak vernieuwen jullie de RRSIG, als er geen wijzigingen zijn?

Dat kan je aan bind overlaten (en dat raad ik je heel erg aan):

zone "dyn-cust.nixsys.be" {
type master;
update-policy {
grant local-ddns zonesub any;
grant wou...@grep.be zonesub any;
grant cgi zonesub any;
};
allow-transfer { !notslaves; key latin; };
file "/etc/bind/zones/dyn-cust.nixsys.be";
key-directory "/etc/bind/keys";
auto-dnssec maintain;
};

De belangrijkste lijnen hierboven zijn die met "key-directory" en
"auto-dnssec". De eerste configureert waar je je keys dropt (die je van
tijd tot tijd moet genereren met "dnssec-keygen", waarbij je ook tijden
moet opgeven -- de manpage is daar redelijk duidelijk over). BIND zal
die keys dan automatisch inladen, en de RRSIGs automatisch roteren. De
KSKs worden ook automatisch vervangen op basis van de tijden die je aan
dnssec-keygen meegegeven hebt. Alleen de glue van je ZSKs moet je nog
handmatig updaten (want daar heeft BIND geen toegang toe).

Bovenstaande is een directe kopie uit mijn live configuratie van een
domein waarin een aantal klanten met dynamisch IP-adres zitten. Bij de
klant draait een cronjob die gewoon een wget doet naar een CGI-script;
dat script draait dan nsupdate met een speciale "cgi" key, wat de zone
aanpast. Werkt perfect: dynamische DNS-updates met DNSSEC-ondersteuning
:-)

> Het is mij nog niet helemaal duidelijk wat het "dsset" bestand nu
> precies doet.

Dat heeft te maken met de glue van je DNSSEC, en is redelijk belangrijk.

DNSSEC werkt als volgt:

- In de root zone zit er een aantal DS records voor de naam "be" met
  daarin de fingerprints van de KSKs van het domein "be"
- In de "be" zone zitten er DNSKEY records voor die KSKs. Deze KSKs
  tekenen de RRs van de DNSKEY records van de ZSKs.
- De ZSKs van de "be" zone tekenen dan alle andere RRs in die zone,
  inclusief het DS record voor "nixsys.be"

Het zelfde verhaal wordt dan herhaald door "nixsys.be" dat DS records
bevat voor "dyn-cust.nixsys.be", enzovoort.

Het "dsset" bestand bevat simpelweg de DS records die je aan je parent
zone moet doorgeven.

> Ik ben overigens aan het testen met het domein sociotech.nl. Mocht
> iemand nog iets zien wat niet in orde is, dan hoor ik dat graag.

Daarvoor is dnsviz.net nuttig:

http://dnsviz.net/d/sociotech.nl/dnssec/

Je ZSK en KSK zijn dubbel zo lang als aangeraden. Dit gaat
performantie-issues veroorzaken, omdat de handtekening van je RRs
daardoor niet meer binnen één DNS-pakket past.

-- 
Could you people please use IRC like normal people?!?

  -- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
 Hacklab

Re: Bind9 vragen

[Paul van der Vlis]

Op 27-06-18 om 14:04 schreef Paul van der Vlis:

> De manuals die ik vind op internet over Bind zijn vaak oud of van
> slechte kwaliteit. Degene die ik nog het beste vond is van Digital Ocean
> en is van 2014. 

Ik kan iedereen dit aanraden:
https://www.sidn.nl/a/dnssec/dnssec-ondertekening-op-bind-named

Groeten,
Paul


-- 
Paul van der Vlis Linux systeembeheer Groningen
https://www.vandervlis.nl/

Re: BIND9 sous squeeze

[Pascal Hambourg]

Thanh Taduy a écrit :
 
 L'exemple est bon, sauf que dans ce cas ci, j'aurais à faire autant de
 fichier de zone que j'ai de sous domaine, n'est ce pas ?

Oui. C'est pour cela que j'ai suggéré dnsmasq à la place. A la base
c'est un simple proxy DNS qui relaie les requêtes vers un serveur DNS
récursif, mais il peut aussi répondre de lui-même pour les noms et
adresses définis dans /etc/hosts, sans devoir créer de zone.

Une autre solution, si tu as accès au contenu complet de la zone
publique originelle, consiste à créer une version locale de la zone en y
ajoutant les enregistrements privés. Il faudra bien sûr la mettre à jour
manuellement à chaque changement de la zone publique. Inutile de faire
des views si le serveur DNS local ne sert pas les requêtes externes.

Re: BIND9 sous squeeze

[Erwan David]

On Thu, Aug 13, 2015 at 10:28:04AM CEST, Pascal Hambourg 
pas...@plouf.fr.eu.org said:
 Thanh Taduy a écrit :
  
  L'exemple est bon, sauf que dans ce cas ci, j'aurais à faire autant de
  fichier de zone que j'ai de sous domaine, n'est ce pas ?
 
 Oui. C'est pour cela que j'ai suggéré dnsmasq à la place. A la base
 c'est un simple proxy DNS qui relaie les requêtes vers un serveur DNS
 récursif, mais il peut aussi répondre de lui-même pour les noms et
 adresses définis dans /etc/hosts, sans devoir créer de zone.
 
 Une autre solution, si tu as accès au contenu complet de la zone
 publique originelle, consiste à créer une version locale de la zone en y
 ajoutant les enregistrements privés. Il faudra bien sûr la mettre à jour
 manuellement à chaque changement de la zone publique. Inutile de faire
 des views si le serveur DNS local ne sert pas les requêtes externes.
 

unbound aussi sait transmettre à un autre résolveur, tout en répondant
pour quelques enregistrements définis localement.

Re: BIND9 sous squeeze

[Thanh Taduy]

Le 13 août 2015 11:54, Erwan David er...@rail.eu.org a écrit :

 On Thu, Aug 13, 2015 at 10:28:04AM CEST, Pascal Hambourg 
 pas...@plouf.fr.eu.org said:
  Thanh Taduy a écrit :
  
   L'exemple est bon, sauf que dans ce cas ci, j'aurais à faire autant de
   fichier de zone que j'ai de sous domaine, n'est ce pas ?
 
  Oui. C'est pour cela que j'ai suggéré dnsmasq à la place. A la base
  c'est un simple proxy DNS qui relaie les requêtes vers un serveur DNS
  récursif, mais il peut aussi répondre de lui-même pour les noms et
  adresses définis dans /etc/hosts, sans devoir créer de zone.
 
  Une autre solution, si tu as accès au contenu complet de la zone
  publique originelle, consiste à créer une version locale de la zone en y
  ajoutant les enregistrements privés. Il faudra bien sûr la mettre à jour
  manuellement à chaque changement de la zone publique. Inutile de faire
  des views si le serveur DNS local ne sert pas les requêtes externes.
 


Dans cette histoire, je n'ai malheureusement pas la main sur la zone
publique soit pour faire une modif, soit pour faire uen copie en locale.
C'est ça qui est malheureux.


 unbound aussi sait transmettre à un autre résolveur, tout en répondant
 pour quelques enregistrements définis localement.


Je vais de ce pas jeter un oeil et sur dnsmasq et sur unbound.
D'après ce que j'en tire de vos suggestions, c'est qu'il n'y a visiblement
pas de solution simple qu'on peut faire uniquement avec Bind et avec views.
Merci à tous de m'avoir éclairé sur ce sujet. Much appreciated - comme dit
souvent mon chef - :-)

Re: BIND9 sous squeeze

[François TOURDE]

Le 16659ième jour après Epoch,
thanh taduy écrivait:

 Bonjour Pascal,

 C'est exactement ce dont j'ai besoin : une zone qui peut passer la main à mon 
 FAI si un sous domaine n'est pas déclarée.
 Votre idée m'intéresse. N'étant pas un expert du DNS, pourriez-vous m'en dire 
 plus ?
 Pourriez-vous s'il vous plait me donner un exemple d'une zone locale ?

Bonjour.

À y regarder rapidement, je vois plusieurs solutions possible, et il y en a
sûrement d'autres:

1)

Créer sur le DNS local une entrée de type:

   prive   NS  tondnslocal.domaine.com.

ou peut-être même simplement une entrée de type SOA sur le domaine
'prive.domaine.com', afin qu'il soit autoritaire sur la zone
'privé.domaine.com', et définir pour l'ensemble des machines du réseau
local le résolveur comme étant tondnslocal.domaine.com

Tes machines privées devront être nommées dans ce sous-domaine (par
exemple machine1.prive.domaine.com).

Insérer dans le DNS un forwarding vers les DNS du FAI afin qu'il passe
la main sur les domaines dans lesquels il n'est pas autorité

2)

Gérer entièrement en local le domaine 'domaine.com' et utiliser des vues
pour différentier les réponses. Les requêtes externes au LAN ne
répondront pas sur les machines 'prive1.domaine.com' par exemple.

3)

S'en foutre complètement et insérer dans le DNS distant des entrées pour
les machines privées en répondant par des adresses du LAN. De toute
façon elles seront inaccessibles de l'extérieur si le LAN est du type
adresses privées

Re: BIND9 sous squeeze

[Thanh Taduy]

Pardon, vieille habitude de Répondre à tous :-(

Le 12 août 2015 21:06, Pascal Hambourg pas...@plouf.fr.eu.org a écrit :

 (Inutile d'envoyer une copie privée, je suis abonné à la liste)

 thanh.ta...@gmail.com a écrit :
 
  C'est exactement ce dont j'ai besoin : une zone qui peut passer la main
 à mon FAI si un sous domaine n'est pas déclarée.
  Votre idée m'intéresse. N'étant pas un expert du DNS, pourriez-vous m'en
 dire plus ?
  Pourriez-vous s'il vous plait me donner un exemple d'une zone locale ?

 Supposons le domaine principal example.com. Pour créer un zone pour un
 sous-domaine privé private1.example.com, on fait une déclaration de zone
 maître classique :

 zone private1.example.com {
 type master ;
 file /path/to/private1.example.com.db ;
 }

 Exemple de contenu du fichier de zone /path/to/private1.example.com.db
 (en fait le fichier de zone ne peut pas être générique puisque l'adresse
 IP de l'enregistrement A est différente...) :

 @   IN  SOA ton.serveur.dns. ton.email. (
 2015081200 ; serial (version)
 6H ; refresh period (6 hours)
 1H ; retry interval (1 hour)
 2W ; expire time (2 weeks)
 1H ; default ttl (1 hour)
 )
 IN  NS  ton.serveur.dns.
 IN  A   192.0.2.47 ; adresse de private1.example.com

 Mais je me demande s'il ne serait pas possible de faire plus simple avec
 un proxy DNS comme dnsmasq à la place de bind9.



L'exemple est bon, sauf que dans ce cas ci, j'aurais à faire autant de
fichier de zone que j'ai de sous domaine, n'est ce pas ?


  Envoyé de mon iPhone

 Est-ce un excuse pour justifier le top-posting et les lignes trop longues ?


Non, juste simplement que j'ai lu ta réponse dans les transports. C'est un
problème qui m'intéresse et que je souhaite connaitre la solution.

Re: BIND9 sous squeeze

[Pascal Hambourg]

Christophe a écrit :

 Ma question est, comment dois-je écrire mon fichier name.conf ainsi que
 mon fichier de zone de telle manière à ce que si quelqu'un du LAN essaie
 d'atteindre un serveur Privé, le DNS interne lui résolvera le nom en
 local, et si l'entrée n'est pas dans cette zone locale, le DNS
 transférera cette requête vers le DNS de mon FAI.
 
 Dans bind9, ca s'appelle des views .

Les vues ou views, c'est fait pour qu'un serveur DNS autoritaire serve
- par exemple - deux versions différentes d'une zone selon l'origine des
requêtes. Mais dans le cas présent, sauf erreur d'interprétation de ma
part, ce n'est pas ce qui est demandé. Si j'ai bien compris, le serveur
DNS local ne doit faire autorité que pour les noms privés de la zone et
récursif pour le reste de la zone, sans dupliquer la partie publique de
la zone. A ma connaissance, ce n'est pas possible : un serveur fait
autorité pour une zone entière ou pas du tout. Le seul moyen que je
vois, c'est de créer une zone fille locale pour et de même nom que
chaque nom privé. On peut utiliser le même fichier de zone générique
pour toutes les zones filles, seul le nom de la zone changeant.

Re: BIND9 sous squeeze

[thanh . taduy]

Bonjour Pascal,

C'est exactement ce dont j'ai besoin : une zone qui peut passer la main à mon 
FAI si un sous domaine n'est pas déclarée.
Votre idée m'intéresse. N'étant pas un expert du DNS, pourriez-vous m'en dire 
plus ?
Pourriez-vous s'il vous plait me donner un exemple d'une zone locale ?

Je vous remercie de votre aide,
Bien à vous
Thanh

Envoyé de mon iPhone

 Le 12 août 2015 à 13:54, Pascal Hambourg pas...@plouf.fr.eu.org a écrit :
 
 Christophe a écrit :
 
 Ma question est, comment dois-je écrire mon fichier name.conf ainsi que
 mon fichier de zone de telle manière à ce que si quelqu'un du LAN essaie
 d'atteindre un serveur Privé, le DNS interne lui résolvera le nom en
 local, et si l'entrée n'est pas dans cette zone locale, le DNS
 transférera cette requête vers le DNS de mon FAI.
 
 Dans bind9, ca s'appelle des views .
 
 Les vues ou views, c'est fait pour qu'un serveur DNS autoritaire serve
 - par exemple - deux versions différentes d'une zone selon l'origine des
 requêtes. Mais dans le cas présent, sauf erreur d'interprétation de ma
 part, ce n'est pas ce qui est demandé. Si j'ai bien compris, le serveur
 DNS local ne doit faire autorité que pour les noms privés de la zone et
 récursif pour le reste de la zone, sans dupliquer la partie publique de
 la zone. A ma connaissance, ce n'est pas possible : un serveur fait
 autorité pour une zone entière ou pas du tout. Le seul moyen que je
 vois, c'est de créer une zone fille locale pour et de même nom que
 chaque nom privé. On peut utiliser le même fichier de zone générique
 pour toutes les zones filles, seul le nom de la zone changeant.
 

Re: BIND9 sous squeeze

[Pascal Hambourg]

(Inutile d'envoyer une copie privée, je suis abonné à la liste)

thanh.ta...@gmail.com a écrit :
 
 C'est exactement ce dont j'ai besoin : une zone qui peut passer la main à mon 
 FAI si un sous domaine n'est pas déclarée.
 Votre idée m'intéresse. N'étant pas un expert du DNS, pourriez-vous m'en dire 
 plus ?
 Pourriez-vous s'il vous plait me donner un exemple d'une zone locale ?

Supposons le domaine principal example.com. Pour créer un zone pour un
sous-domaine privé private1.example.com, on fait une déclaration de zone
maître classique :

zone private1.example.com {
type master ;
file /path/to/private1.example.com.db ;
}

Exemple de contenu du fichier de zone /path/to/private1.example.com.db
(en fait le fichier de zone ne peut pas être générique puisque l'adresse
IP de l'enregistrement A est différente...) :

@   IN  SOA ton.serveur.dns. ton.email. (
2015081200 ; serial (version)
6H ; refresh period (6 hours)
1H ; retry interval (1 hour)
2W ; expire time (2 weeks)
1H ; default ttl (1 hour)
)
IN  NS  ton.serveur.dns.
IN  A   192.0.2.47 ; adresse de private1.example.com

Mais je me demande s'il ne serait pas possible de faire plus simple avec
un proxy DNS comme dnsmasq à la place de bind9.

 Envoyé de mon iPhone

Est-ce un excuse pour justifier le top-posting et les lignes trop longues ?

Re: BIND9 sous squeeze

[Christophe]

Hello,

Le 09/08/2015 17:19, Thanh Taduy a écrit :

Bonjour à tous,

Je me remets à vos connaissances sur les problèmes concernant BIND, car
je pense que ce sera un jeu d'enfant pour vous.
Je suis sous Debian squeeze et j'essaie de faire la chose suivante :
J'ai un domaine qui s'appelle admettons domaine.com
http://domaine.com, ce domaine possède un certain nombre d'entrées A
qui s'appellent admettons Public1, Public2,
C'est entrées sont connues publiquement, joignables de n'importe tout,
et elles sont déclarées sur un DNS externe au LAN.

Je voudrais maintenant rajouter des entrées qui seront privées (Privé1,
Privé2, ...). Ces entrées seront déclarées sur un DNS du LAN en interne.
La zone qui est déclarée sur mon DNS privé est par conséquent
domaine.com http://domaine.com.

Ma question est, comment dois-je écrire mon fichier name.conf ainsi que
mon fichier de zone de telle manière à ce que si quelqu'un du LAN essaie
d'atteindre un serveur Privé, le DNS interne lui résolvera le nom en
local, et si l'entrée n'est pas dans cette zone locale, le DNS
transférera cette requête vers le DNS de mon FAI.

Je vous remercie par avance de toute les suggestions que vous pouvez me
faire.
Bon dimanche
Thanh



Dans bind9, ca s’appelle des views .

Il te faut définir un fichier de zone par emplacement (alias plage 
d'adresse IPv4 ou IPv6) qui requête le DNS :


et dans la configuration de bind (simple exemple) :

view net0 {
match-clients { 192.168.0.0/24; };
recursion yes;

zone domaine.com {
type master;
file /etc/bind/zones/db.net0.domaine.com;
};
};

view net1 {
match-clients { 192.168.1.0/24; };
recursion yes;

zone domaine.com {
type master;
file /etc/bind/zones/db.net1.domaine.com;
};
};



En espérant que cela aide.

@+
Christophe.

--
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/55c7a5d4.6080...@stuxnet.org

Re: BIND9 sous squeeze

[gnafou]

je crois que tu as juste la récursivité à activer.  ( allow-recursion ) 
F. 


 Le Dimanche 9 août 2015 17h19, Thanh Taduy thanh.ta...@gmail.com a écrit 
:
   

 Bonjour à tous,
Je me remets à vos connaissances sur les problèmes concernant BIND, car je 
pense que ce sera un jeu d'enfant pour vous.Je suis sous Debian squeeze et 
j'essaie de faire la chose suivante :J'ai un domaine qui s'appelle admettons 
domaine.com, ce domaine possède un certain nombre d'entrées A qui s'appellent 
admettons Public1, Public2,C'est entrées sont connues publiquement, 
joignables de n'importe tout, et elles sont déclarées sur un DNS externe au LAN.
Je voudrais maintenant rajouter des entrées qui seront privées (Privé1, Privé2, 
...). Ces entrées seront déclarées sur un DNS du LAN en interne. La zone qui 
est déclarée sur mon DNS privé est par conséquent domaine.com.
Ma question est, comment dois-je écrire mon fichier name.conf ainsi que mon 
fichier de zone de telle manière à ce que si quelqu'un du LAN essaie 
d'atteindre un serveur Privé, le DNS interne lui résolvera le nom en local, et 
si l'entrée n'est pas dans cette zone locale, le DNS transférera cette requête 
vers le DNS de mon FAI.
Je vous remercie par avance de toute les suggestions que vous pouvez me 
faire.Bon dimancheThanh

  

Re: bind9 needs sometimes a restart after resume from suspend

[Karl E. Jorgensen]

Hi

On Sun, Nov 30, 2014 at 03:26:29PM +0100, Rainer Dorsch wrote:
 On Sunday 30 November 2014 11:59:16 Karl E. Jorgensen wrote:
  Hi
  
  On Sun, Nov 30, 2014 at 12:26:36PM +0100, Rainer Dorsch wrote:
   Hi Pascal,
   
   On Sunday 30 November 2014 11:15:41 Pascal Hambourg wrote:
Hello,

Rainer Dorsch a écrit :
 I run bind9 locally and noticed that bind9 sometimes needs a restart
 after
 suspend.

Why ? Not running, not resolving, errors... ?
   
   bind9 does not respond.
   
   See e.g. the dig command from my previous post
   
   blackbox:~# dig heise.de
   ^Cblackbox:~#
  
  That was well hidden :-)
  
  Any related messages in /var/log/daemon.log ?
 
 Indeed there are a number of entries in there, these are the entries right 
 after restart:
 
 Nov 30 10:10:49 blackbox named[24198]: clients-per-query decreased to 12
 Nov 30 10:10:50 blackbox console-kit-daemon[2055]: WARNING: Error waiting for 
 native console 56 activation: Resource temporarily unavailable 
 Nov 30 10:10:50 blackbox named[24198]: validating @0xb3f5c0d0: . NS: got 
 insecure response; parent indicates it should be secure
 Nov 30 10:10:50 blackbox named[24198]: error (insecurity proof failed) 
 resolving './NS/IN': 192.168.178.1#53
 Nov 30 10:10:50 blackbox named[24198]: error (network unreachable) resolving 
 './NS/IN': 2001:503:c27::2:30#53
 Nov 30 10:10:50 blackbox named[24198]: managed-keys-zone: No DNSKEY RRSIGs 
 found for '.': success
 Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
 signature found
[snipped more of the same]

These messages dont look abnormal - in fact they seem to indicate
proper operation.

 
 But after restart when bind9 is working, I still see similar entries:
 
 Nov 30 15:19:40 blackbox named[2322]: validating @0xb4072230: . NS: got 
 insecure response; parent indicates it should be secure
 Nov 30 15:19:40 blackbox named[2322]: error (insecurity proof failed) 
 resolving './NS/IN': 192.168.178.1#53
[similar messages snipped]

Going back to your original symptom: bind not responding... It looks
like bind is at least *alive*.

I wonder... What exactly does bind not responding mean? any command
that reproduces that would be handy.

As this is happening in relation to suspend/resume, this would imply
that network interfaces go down and up too. So perhaps bind is failing
to detect the re-arrival of network interfaces?

The output of a command like sudo netstat -nlp | grep bind while
bind is not responding would be instructive. And then compare/contrast
with the scenario of a working bind...

Hope this helps 
-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141202130714.GA32322@hawking

Re: bind9 needs sometimes a restart after resume from suspend

[Bob Proulx]

Karl E. Jorgensen wrote:
 I wonder... What exactly does bind not responding mean? any command
 that reproduces that would be handy.

 As this is happening in relation to suspend/resume, this would imply
 that network interfaces go down and up too. So perhaps bind is failing
 to detect the re-arrival of network interfaces?

 The output of a command like sudo netstat -nlp | grep bind while
 bind is not responding would be instructive. And then compare/contrast
 with the scenario of a working bind...

I think that is a good debugging direction.  For reasons I haven't
looked into BIND will bind to specific addresses.  There is always
127.0.0.1:53.  Plus there will be one for each interface.

Try:

  $ netstat -na | awk '$NF==LISTEN/:53/'

With this example output from a system.

  tcp0  0 192.168.2.34:53 0.0.0.0:*   LISTEN
  tcp0  0 127.0.0.1:530.0.0.0:*   LISTEN
  tcp6   0  0 :::53684:::*LISTEN
  tcp6   0  0 :::53   :::*LISTEN

It may be that something is dropping the network offline and the
suspend-resume is simply cycling the network off and on again and
restoring the network connection.  Maybe the root cause isn't BIND but
rather that the network has gone offline.

  $ ip addr show | awk '$1==inet'
inet 127.0.0.1/8 scope host lo
inet 192.168.2.34/24 brd 192.168.230.255 scope global br0

I would also want to know what is in /etc/resolv.conf to know if it is
configured for the local nameserver.  And also what hosts entry is
listed in /etc/nsswitch.conf to see how it is configured.

  $ grep nameserver /etc/resolv.conf
  nameserver 127.0.0.1

  $ grep hosts /etc/nsswitch.conf
  hosts:  files dns

Lastly this *shouldn't* be related to any DNS lookups but the contents
of /etc/hosts is the files part in the above.  It is possible that
contents of /etc/hosts might be confusing the issue of thinking bind
isn't working properly.  Shouldn't be since it apparently works after
a suspend-resume but mentioning it here for completeness anyway.

Bob


signature.asc
Description: Digital signature

Re: bind9 needs sometimes a restart after resume from suspend

[Pascal Hambourg]

Hello,

Rainer Dorsch a écrit :
 
 I run bind9 locally and noticed that bind9 sometimes needs a restart after 
 suspend.

Why ? Not running, not resolving, errors... ?


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547aee4d.7090...@plouf.fr.eu.org

Re: bind9 needs sometimes a restart after resume from suspend

[Rainer Dorsch]

Hi Pascal,

On Sunday 30 November 2014 11:15:41 Pascal Hambourg wrote:
 Hello,
 
 Rainer Dorsch a écrit :
  I run bind9 locally and noticed that bind9 sometimes needs a restart after
  suspend.
 
 Why ? Not running, not resolving, errors... ?

bind9 does not respond.

See e.g. the dig command from my previous post

blackbox:~# dig heise.de
^Cblackbox:~#

Thanks,
Rainer

-- 
Rainer Dorsch
http://bokomoko.de/


--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4217716.oQpynmt4IH@blackbox

Re: bind9 needs sometimes a restart after resume from suspend

[Karl E. Jorgensen]

Hi

On Sun, Nov 30, 2014 at 12:26:36PM +0100, Rainer Dorsch wrote:
 Hi Pascal,
 
 On Sunday 30 November 2014 11:15:41 Pascal Hambourg wrote:
  Hello,
  
  Rainer Dorsch a écrit :
   I run bind9 locally and noticed that bind9 sometimes needs a restart after
   suspend.
  
  Why ? Not running, not resolving, errors... ?
 
 bind9 does not respond.
 
 See e.g. the dig command from my previous post
 
 blackbox:~# dig heise.de
 ^Cblackbox:~#

That was well hidden :-)

Any related messages in /var/log/daemon.log ?

-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141130115916.GA22567@hawking

Re: bind9 needs sometimes a restart after resume from suspend

[Andrew McGlashan]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 30/11/2014 8:42 PM, Rainer Dorsch wrote:
 blackbox:/etc/bind# cat /etc/systemd/system/bind9-resume.service

So ... buggy systemd bites yet again; and *some* [too many] people still
don't understand why we don't want this on our Debian (or other) systems.

A.

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (MingW32)

iF4EAREIAAYFAlR7BzoACgkQqBZry7fv4vtyFgEA2lxjJ5tJpX8n+owMTM73Rcwy
w0WCbqupjDduwbRWV+YBAJ//SFY0D2dB33XZQnmSmHjjf9IfZda6jyEqNB2ONw9d
=E/GT
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/547b073d.3080...@affinityvision.com.au

Re: bind9 needs sometimes a restart after resume from suspend

[Martin Read]

On 30/11/14 12:02, Andrew McGlashan wrote:

On 30/11/2014 8:42 PM, Rainer Dorsch wrote:

blackbox:/etc/bind# cat /etc/systemd/system/bind9-resume.service


So ... buggy systemd bites yet again;


This is *BIND* we're talking about; even if I was opposed to systemd, I 
probably wouldn't go jumping to the conclusion that this is necessarily 
a bug in systemd.



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: https://lists.debian.org/547b18d8.1080...@zen.co.uk

Re: bind9 needs sometimes a restart after resume from suspend

[Rainer Dorsch]

On Sunday 30 November 2014 11:59:16 Karl E. Jorgensen wrote:
 Hi
 
 On Sun, Nov 30, 2014 at 12:26:36PM +0100, Rainer Dorsch wrote:
  Hi Pascal,
  
  On Sunday 30 November 2014 11:15:41 Pascal Hambourg wrote:
   Hello,
   
   Rainer Dorsch a écrit :
I run bind9 locally and noticed that bind9 sometimes needs a restart
after
suspend.
   
   Why ? Not running, not resolving, errors... ?
  
  bind9 does not respond.
  
  See e.g. the dig command from my previous post
  
  blackbox:~# dig heise.de
  ^Cblackbox:~#
 
 That was well hidden :-)
 
 Any related messages in /var/log/daemon.log ?

Indeed there are a number of entries in there, these are the entries right 
after restart:

Nov 30 10:10:49 blackbox named[24198]: clients-per-query decreased to 12
Nov 30 10:10:50 blackbox console-kit-daemon[2055]: WARNING: Error waiting for 
native console 56 activation: Resource temporarily unavailable 
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3f5c0d0: . NS: got 
insecure response; parent indicates it should be secure
Nov 30 10:10:50 blackbox named[24198]: error (insecurity proof failed) 
resolving './NS/IN': 192.168.178.1#53
Nov 30 10:10:50 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:503:c27::2:30#53
Nov 30 10:10:50 blackbox named[24198]: managed-keys-zone: No DNSKEY RRSIGs 
found for '.': success
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 199.7.91.13#53
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 199.7.83.42#53
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.36.148.17#53
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.5.5.241#53
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 198.41.0.4#53
Nov 30 10:10:50 blackbox colord: device removed: sysfs-(null)
Nov 30 10:10:50 blackbox colord: device removed: sysfs-(null)
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 193.0.14.129#53
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 202.12.27.33#53
Nov 30 10:10:50 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:50 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.33.4.12#53
Nov 30 10:10:50 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:500:1::803f:235#53
Nov 30 10:10:50 blackbox colord: device removed: sysfs-asus-Nexus_7
Nov 30 10:10:51 blackbox named[24198]: error (chase DS servers) resolving 
'com/DS/IN': 192.168.178.1#53
Nov 30 10:10:51 blackbox named[24198]: validating @0xb3f40ff0: . NS: no valid 
signature found
Nov 30 10:10:51 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.112.36.4#53
Nov 30 10:10:51 blackbox named[24198]: validating @0xb3f40ff0: . NS: no valid 
signature found
Nov 30 10:10:51 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.228.79.201#53
Nov 30 10:10:51 blackbox named[24198]: validating @0xb3a00018: . NS: no valid 
signature found
Nov 30 10:10:51 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.203.230.10#53
Nov 30 10:10:51 blackbox named[24198]: validating @0xb3f40ff0: . NS: no valid 
signature found
Nov 30 10:10:51 blackbox named[24198]: error (no valid RRSIG) resolving 
'./NS/IN': 192.58.128.30#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:500:2d::d#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:500:3::42#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:7fe::53#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:500:2f::f#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:503:ba3e::2:30#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:7fd::1#53
Nov 30 10:10:51 blackbox named[24198]: error (network unreachable) resolving 
'./NS/IN': 2001:dc3::35#53
Nov 30 10:10:51 blackbox named[24198]: error (no valid RRSIG) resolving 
'arpa/DS/IN': 192.168.178.1#53
Nov 30 10:10:51 blackbox 

Re: BIND9 Dynamic Update Zones

[Pascal Hambourg]

Roman Gelfand a écrit :
 When I try run nsupdate -d -L 9 nsu.tmp, where nsu.tmp is
 
 update add cmm3.workdom.com 3600 A 192.168.10.8
 show
 send
 
 Dynamic zone file
 
 include /etc/bind/zones.rfc1918;
 
 zone workdom.com  IN  {
  type master;
  file dyn.workdom.com.zone;
  allow-transfer { any; };
  allow-query { any; };
  allow-update { 127.0.0.1; };
 };
 
 The send command response is REFUSED.  I am not sure why.

The zone definition allows updates only from 127.0.0.1. However :

 Sending update to 192.168.3.42#53

Even if nsupdate runs on the server itself, DNS query packets sent to
192.168.3.42 have the same source address 192.168.3.42 by default, not
127.0.0.1. No need to mention that if nsupdate is running on a different
host, the source address cannot be 127.0.0.1.

If nslookup runs on a different host, add its address to the
allow-update option in the zone definition.

If nslookup runs on the server itself, you have several options :
- add 192.168.3.42 to the allow-update option in the zone definition
- add -l (localhost only mode) to the nsupdate command line
- add server 127.0.0.1 into nsu.tmp to force the server address
- add local 127.0.0.1 into nsu.tmp to force the source address

Cf. the manpage for more details.


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/546d13aa.1090...@plouf.fr.eu.org

Re: Bind9

[Gustavo S. de Lima]

Em 2014-10-19 18:56, Paulo escreveu:

Pessoal,

Sempre me perco na instalação do BIND.


Sim, configurar DNS perto de DHCP, Samba, etc, é mais complexo.


Consegui configurar o encaminhamento
Mas não consigo configurar uma zona


Você pode usar o comando named-checkzone para conferir se as zonas 
estão configuradas corretamente.


Mesmo seguindo vários tutoriais a zona não pinga e não consigo dar 
host para ela


Poderia colar o arquivo named.conf.local e named.conf.options para 
analisarmos a configuração?




É uma máquina de testes, coloquei o nome de teste.dom.local no
/etc/hosts e no /etc/hostname


Se possível, colar a saída destes também.


Teria que ser um nome válido na Internet ?
Não tenho IP válido, estou usando uma conexão tipo Home


Não, o DNS atua para a sua rede local.


Se alguém tiver alguma dica, agradeço

Desde já agradeço.


Disponha



Paulo


--
 

Gustavo


--
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/a8d4c7c35e48abb84b20d4ffe1e8d...@logicus.com.br

Re: bind9

[Joe]

On Fri, 1 Nov 2013 10:58:50 +0530
Arun Khan knu...@gmail.com wrote:

 On Fri, Nov 1, 2013 at 10:40 AM, Roman Gelfand rgelfa...@gmail.com
 wrote:
  My workstations' ips are assigned by dhcp server on firewall.  The
  bind9 is running on debian 7 box.  Is there a way to automatically
  update forward and reverse zones?
 
 
 For known MAC addresses I usually assign 'fixed' ip addresses  + the
 hostname given by a DNS server (bind9).
 
 ISC dhcp + bind9 can be configured to work in sync for dynamic
 updates.  I don't know about the reverse zones.
 

Yes, reverse as well, as can the 2003 MS DNS and DHCP servers. BIND can
update between different machines, using a shared key for
authentication, I'm not sure if MS servers can.

Unfortunately, small routers generally can't do this kind of thing, and
sometimes not even add arbitrary DHCP parameters, so it is normally
recommended that in an AD domain, both DNS and DHCP are handled by one
of the directory servers. Clearly this hasn't happened here, and is
probably not possible to organise.

If an MS server can't find its workstations in DNS, it will use
broadcasts to locate them. This would probably need a fair bit of
scripting on Linux, maybe a mix of nmap and arp, as well as being able
to authenticate to BIND. Possibly just writing to /etc/hosts might be
enough for a small-scale application. I'm not aware of anything
ready-made, but I only dabble occasionally in network infrastructure,
and there might well be something that does this already.

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131101101707.7dd3c...@jretrading.com

Re: bind9

[Karl E. Jorgensen]

Hi

On Fri, Nov 01, 2013 at 01:10:33AM -0400, Roman Gelfand wrote:
 My workstations' ips are assigned by dhcp server on firewall.  The
 bind9 is running on debian 7 box.  Is there a way to automatically
 update forward and reverse zones?

In this configuration: probably not.

Having the name server on a debian box is obviously sensible (this is
a Debian list after all!), but since DHCP is done by the firewall
there is no way the name server can be updated by that.  Unless you
want to resort to sort of automated network traffic analysis ... But
let's not go there...

But does the firewall HAVE to run DHCP?  If it is possible to turn
that off, then you can run a DHCP server on the debian box, and use
the normal DHCP - DNS updates for both forward and reverse zones...


-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131101231918.GA19544@hawking

Re: bind9

[Arun Khan]

On Fri, Nov 1, 2013 at 10:40 AM, Roman Gelfand rgelfa...@gmail.com wrote:
 My workstations' ips are assigned by dhcp server on firewall.  The
 bind9 is running on debian 7 box.  Is there a way to automatically
 update forward and reverse zones?


For known MAC addresses I usually assign 'fixed' ip addresses  + the
hostname given by a DNS server (bind9).

ISC dhcp + bind9 can be configured to work in sync for dynamic
updates.  I don't know about the reverse zones.

-- Arun Khan


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CAHhM8gAwT9+j=L29j_Ar5VO90daR3iyBb=knazldf+3szy+...@mail.gmail.com

Re: bind9

[pch0317]

I found in /var/log/daemon.log that not all zone are in view brackets. I 
solve the problem.

Thanks

On 10/03/2013 08:41 PM, Karl E. Jorgensen wrote:

Hi

On Thu, Oct 03, 2013 at 07:28:46PM +0200, Pawe?? Ch. wrote:

Hi list

I install bind9 server on debian (https://wiki.debian.org/Bind9). When I add
named.conf.log entries bind9 can't start. Before adding log entries bind work
correctly.

Without more information, diagnostics is guesswork at best

What error message do you get in /var/log/daemon.log?

Regards



--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Archive: http://lists.debian.org/524ede82.3050...@gmal.com

Re: bind9

[Karl E. Jorgensen]

Hi

On Thu, Oct 03, 2013 at 07:28:46PM +0200, Pawe?? Ch. wrote:
 Hi list
 
 I install bind9 server on debian (https://wiki.debian.org/Bind9). When I add
 named.conf.log entries bind9 can't start. Before adding log entries bind work
 correctly.

Without more information, diagnostics is guesswork at best

What error message do you get in /var/log/daemon.log?

Regards
-- 
Karl E. Jorgensen


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20131003184109.GB16986@hawking

Re: bind9, openswan crashes wheezy VPS

[Gregory Nowak]

On Tue, Aug 13, 2013 at 01:37:32PM -0600, Bob Proulx wrote:
 I will be curious to hear what you find out about your problem.
 System crashes are always especially difficult for me to debug.
 

I'm closing this issue with my VPS provider, so wanted to follow up
here as well. My VPS provider changed the network interface from
virtio_net to e1000. Once we made that change, the VPS stopped
crashing, but querying local bind9 for www.debian.org. for example, and
running openswan as responder now produces a kernel panic. The VPS
itself stays up, but I'm forced to do a hard shutdown, and boot it up
again. So, I opened a bug against what was at that time the latest
debian kernel:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=719668

It may still be the latest kernel for all I know, but I went back to
the stock 3.2.0 kernel that comes with squeeze. The one good news is
that before kernels 3.4.56 and older caused the VPS to crash at times
during boot if bind9 was started while the eth0 interface was up. This
doesn't happen anymore under the stock wheezy 3.2.0 at least, since
the switch to e1000. I can stop/start bind9 as much as I want now
while eth0 is up without a system crash, or kernel panic.

Yes, I could be migrated to a host with a newer KVM/QEMU version. This
however isn't automated, and would incur a labor charge as a
result. Since I've found workarounds (below), and since the migration
doesn't guarantee a resolution to this, I decided to leave things as
they are. 

I decided to not use my local bind9 for queries in /etc/resolv.conf
for now. I may try pdns-server one day to see how it does as far as
the crash/kernel panic. I also got openvpn going with my laptop able
to have a publicly routed IP address through my VPS. I would like to
thank Zenaan here for nudging me in the right direction to get this
going. I also want to apologize to Zenaan and the list if it seemed
like I was nitpicking during our exchange. That was not my intent. I
just wanted to make sure I understood what Zenaan was getting at. I
also want to thank Bob for his response to my initial post in this
thread.

If there is further news on this issue, it will likely take place in
the kernel bug ticket I gave above. If I do manage to find a solution
where openswan/bind are fully operational in my VPS on the same host,
I will post it here if it doesn't end up in the debian bug tracker.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130821235834.ga10...@gregn.net

Re: bind9, openswan crashes wheezy VPS

[Gregory Nowak]

On Mon, Aug 12, 2013 at 08:33:14PM -0600, Bob Proulx wrote:
 I don't know but for example DNS will start off with a UDP query.  But
 if the response is too large for a single UDP packet then it will
 change to a TCP connection for the larger data exchange.  So let's say
 that UDP always works okay and it is only something about TCP that is
 problematic.  Then you could definitely find issues with some domain
 names and not others if those problematic ones used TCP due to a
 larger amount of data.  Such as if some have many more records than
 others.
 
 You might compare the sizes of the returned data in a dns query and
 see if there is a correlation.  'dig' should give you that
 information.  But I am not saying that is the problem.  Just saying
 that there will be differences in how the lookups are handled.

Interesting you mention that. I've transferred stuff over ftp/http/ssh
up/down with no problem. On the other hand, as you point out, bind9
uses udp for queries initially, and openswan uses udp as well. I went
ahead and contacted my VPS provider's support, since there doesn't
seem to be much more I can do here on my own. So, we'll see what
finally fixes things. I'll post back here when that happens to close
this out. One more thing I forgot to mention here is that back when
bind9 was causing the machine to crash at boot, I brought down the
eth0 interface, and was able to stop/start bind9 as much as I wanted
without problems. So, it could very well be something with the
virtio_net module. Will be interesting to see what solves this.

 
 BTW...  What do you have in /etc/nsswitch.conf?  Hope it just says
 files dns there.
 
   $ grep hosts /etc/nsswitch.conf
   hosts:  files dns
 

I didn't touch that, so it is whatever wheezy installed by
default. Yes, when I run grep like you show above, I get back exactly
what you did. It has other lines in there, so the whole file doesn't
just say 

hosts:  files dns

all by itself. So, I assume you're asking if that one line just says
hosts:  files dns, not that the entire file consists of that,
and only that. If that is the intended question, the answer is
yes. Thanks again for your help Bob.

Greg


-- 
web site: http://www.gregn..net
gpg public key: http://www.gregn..net/pubkey.asc
skype: gregn1
(authorization required, add me to your contacts list first)

--
Free domains: http://www.eu.org/ or mail dns-mana...@eu.org


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130813071759.ga7...@gregn.net

Re: bind9, openswan crashes wheezy VPS

[Bob Proulx]

Gregory Nowak wrote:
 Bob Proulx wrote:
 without problems. So, it could very well be something with the
 virtio_net module. Will be interesting to see what solves this.

Good luck!

  BTW...  What do you have in /etc/nsswitch.conf?  Hope it just says
  files dns there.
  
$ grep hosts /etc/nsswitch.conf
hosts:  files dns
 
 I didn't touch that, so it is whatever wheezy installed by
 default.

Well, there is by default and then there is depending upon what other
packages have also been installed.  For example libnss-mdns adds
avahi mdns stuff there and that causes me problems.

 Yes, when I run grep like you show above, I get back exactly
 what you did. It has other lines in there, so the whole file doesn't
 just say 
 
 hosts:  files dns

That is normal and good.

 all by itself. So, I assume you're asking if that one line just says
 hosts:  files dns, not that the entire file consists of that,
 and only that. If that is the intended question, the answer is
 yes.

That was exactly what I was asking.  There are other configurable
services in that file.  But I was only asking about the hosts lookup
network service.

 Thanks again for your help Bob.

I will be curious to hear what you find out about your problem.
System crashes are always especially difficult for me to debug.

Bob


signature.asc
Description: Digital signature

Re: bind9, openswan crashes wheezy VPS

[Bob Proulx]

Gregory Nowak wrote:
 I have a VPS running a fresh install of wheezy, installed by me from
 scratch (including kernel). Everything seems to be running fine,
 except for bind9 and openswan which literally crash the vps as
 explained below.

I don't know anything about why you are having system crashes.  But no
one else responded and so I decided to jump in.

I run a handful of VMs full time and let me assure you that they are
stable and reliable and don't crash.  Your crashes are not
intrinsically part of the Linux kernel, Debian, or anything else.
They are something unique to your environment.  And they should not be
happening.

 I'll start with bind9, since I have more info there. It's setup as a
 name server authoritative for two zones. Querying both zones works fine
 from localhost and the internet over ipv4, and ipv6. The problem comes
 up when I try to use bind9 to resolve other domains from
 localhost. When resolving certain domains, the vps literally
 crashes. I have to send it a boot request, and it boots up again

Very bizarre!  I can't guess as to any reason why.  But I can't
believe the problem is related to bind code itself.  It is simply a
user space program the same as any other.  The problem is in the
kernel.

 When using the stock wheezy kernel, the machine would sometimes crash
 during boot right after printing starting bind9, before the ok that
 comes after. This was true especially if starting named without the -4
 flag to disable ipv6. There were also random crashes every couple of
 days or so when I wasn't logged into the machine watching for
 them. All this seems to have gone away after I upgraded to
 linux 3.9 from wheezy-backports, and just the query crashes remain.

I have no idea.  However if the kernel is crashing then the problem is
in the kernel or kernel+kernel-drivers which are also part of the
kernel.  All else are just symptoms of the disease.

 I know someone who is with the same VPS provider and runs fedora 16 in
 his VPS. I have a shell account on his system, and have been able to
 verify for myself by using dig that it's possible to query all the
 domains I listed above using his local bind9 on his machine with no
 crashes. As far as I can tell (lspci, /proc/cpuinfo), his vps is
 configured exactly like mine as far as hardware, except for RAM and HD
 capacity. That's all the info I have on the bind9 problem.

I would contact your VPS provider support.  If you are paying for the
service and it isn't working then you should get help to get it going.

 As far as openswan, it's setup with one connection, configured as
 ...
 The machine crashes when I try to initiate a connection from a win7
 client. Nothing gets written to the logs here, so the output below is

Again, very bizarre.  But openswan won't be the problem either.  This
is just another symptom of the kernel problem.

 That's all the info I have on the openswan issue. This vps is of
 course running lots more than just bind9 and openswan. Apache,
 proftpd, postfix, spamassassin, clamav, opendkim, just to name a
 few. All of those appear to be running without problems.

Since all of your crashes appear to be network related I imagine the
problem is in the kernel network driver stack somewhere.

 As far as the vps itself, it is based on KVM/QEMU with one cpu, and
 one gig of RAM. The network card uses the virtio_net module, and the
 HD shows up as /dev/vda (I assume using the virtio_blk module, which
 is also automatically loaded).

Seems reasonable to me.  I have several that are similar.  All run fine.

 Based on the login banner I get when using out of band access, the
 host seems to be running openbsd. I'm not sure if the machine
 providing the out of band account and the host my vps is running on
 are actually one and the same though. According to /proc/cpu, the
 KVM/QEMU version seems to be 0.9.1.

That seems to be quite an old version of qemu.

  Squeeze 6 - 0.12.5
  Wheezy 7 - 1.1.2
  Unstable - 1.5.0
  Experimental - 1.6.0~rc0

Part of me says that if it worked reliably way back when 0.9.1 was
current then it should still be working reliably today.  But another
part worries that the Linux 3.9 that you are running is tickling some
bug in the qemu 0.9.1 and that upgrading to something more recent will
probably fix it.  Because your problem seems pretty severe and so it
would almost certainly be a bug that would have already been fixed.

 Any help in at least figuring out what is causing this, if not
 actually having a fully functional bind9 and openswan is much
 appreciated. If more info is necessary, I'll see what I can do.

To me it feels like an interaction between your very new Linux
kernel version 3.9 and your quite old qemu version 0.9.1.  I would try
the *oldest* stock Debian kernel you can find that still supports your
libc and other libs and see if that fixes things.  (At some point your
old kernel won't support the newer userland.  I don't know where the
compatibility lines are drawn though.)

I 

Re: bind9, openswan crashes wheezy VPS

[Gregory Nowak]

On Mon, Aug 12, 2013 at 02:44:35PM -0600, Bob Proulx wrote:
 I don't know anything about why you are having system crashes.  But no
 one else responded and so I decided to jump in.

Thank you for doing so. I actually went ahead and opened bugs against
openswan and bind9 after getting no responses here in almost 24
hours. I was somewhat reluctant to do that, but if nobody here seems
to have ideas on how to farther troubleshoot this, I figured the people
who build those packages and are probably more familiar with how said
package works than general
users, would have ideas on how to proceed.

 
 I run a handful of VMs full time and let me assure you that they are
 stable and reliable and don't crash.  Your crashes are not
 intrinsically part of the Linux kernel, Debian, or anything else.
 They are something unique to your environment.  And they should not be
 happening.

Yes, but I figured that if at least one of these programs works fine
on fedora 16 in the same type of environment, then there must be
something with how wheezy interacts with that environment which is
causing this. So, while it is fair to say the problem is unique to my
environment, I also think it's fair, and more precise to say that it's
something having to do with how wheezy specifically interacts with
that environment.

 
 Very bizarre!  I can't guess as to any reason why.  But I can't
 believe the problem is related to bind code itself.  It is simply a
 user space program the same as any other.  The problem is in the
 kernel.

Yes, that occurred to me as well. However, given that only two packages
are doing this so far out of a bunch of them, I thought it would be
better and more obvious to focus on those first, until I can actually
trace the problem to the kernel itself.

 I would contact your VPS provider support.  If you are paying for the
 service and it isn't working then you should get help to get it going.

Yes, I plan to do that, once I've verified as much as possible the
problem isn't exclusively on my end of things. Perhaps I've reached
that point already.

 Since all of your crashes appear to be network related I imagine the
 problem is in the kernel network driver stack somewhere.

I've thought of that as well, especially since research indicates that
the virtio_net module has had problems in the past. In fact, the most
recent batch of these seems to have been fixed earlier this month in
linux 3.4.56 (more on that below). On the other hand, if it's
something in the network stack, why am I for example able to query my
VPS provider's servers for the same domains without crashes? If it's
in the network stack, then I think it's reasonable to conclude I'd be
seeing crashes regardless of what name servers I queried for those
domains. Right?

 To me it feels like an interaction between your very new Linux
 kernel version 3.9 and your quite old qemu version 0.9.1.  I would try
 the *oldest* stock Debian kernel you can find that still supports your
 libc and other libs and see if that fixes things.  (At some point your
 old kernel won't support the newer userland.  I don't know where the
 compatibility lines are drawn though.)

I actually did do something along the same lines. I tried linux 3.10
from unstable, and then my own build of linux 3.10.5. Same results as
with 3.9 from wheezy-backports. I then tried my own builds of 3.4.56,
3.0.89, and 2.6.32 from squeeze. My builds were done using the sources
from kernel.org. I was really hoping that 3.4.56 would be the magic
fix, because of the virtio_net fixes I mentioned above that went into
it. Everything from 3.4.56 down behaved the same way as 3.2.0 in
wheezy (I.E. crashes during boot when starting bind9, and crashes on
resolving the domains that make it crash). The exception was 2.6.32
from squeeze which crashed the machine when I attempted to query my
local bind for even the domains that work on higher kernels. So, I
didn't go lower than that.

There is one thing that's been bothering me on and off through all
this, which I forgot to mention in my original post. The fedora
machine with the same VPS provider. I noticed there is no
virtio_ring.ko module, it simply doesn't exist on that machine. All
the kernels I tried have virtio_ring built as module, and I couldn't
find a .config option to disable it anywhere when I was doing my build
of 3.10.5. I did a bit of research, but couldn't find a clear answer
on what exactly virtio_ring does. I keep wondering on and off what would happen 
if I
could find a way to black list it in the initrd image. Would all this
suddenly go away, or would I end up with an unbootable system, because
virtio_blk couldn't load with virtio_ring black listed. I would prefer not to 
risk the second
alternative, so it would be best if I can simply find a debian kernel,
or build my own without virtio_ring altogether.

 
 I would get your VPS support involved.  If there are no other ideas
 then I would have them move you to a host with a newer qemu 1.x
 installed.  

Re: bind9, openswan crashes wheezy VPS

[Bob Proulx]

Gregory Nowak wrote:
 On the other hand, if it's something in the network stack, why am I
 for example able to query my VPS provider's servers for the same
 domains without crashes? If it's in the network stack, then I think
 it's reasonable to conclude I'd be seeing crashes regardless of what
 name servers I queried for those domains. Right?

I don't know but for example DNS will start off with a UDP query.  But
if the response is too large for a single UDP packet then it will
change to a TCP connection for the larger data exchange.  So let's say
that UDP always works okay and it is only something about TCP that is
problematic.  Then you could definitely find issues with some domain
names and not others if those problematic ones used TCP due to a
larger amount of data.  Such as if some have many more records than
others.

You might compare the sizes of the returned data in a dns query and
see if there is a correlation.  'dig' should give you that
information.  But I am not saying that is the problem.  Just saying
that there will be differences in how the lookups are handled.

BTW...  What do you have in /etc/nsswitch.conf?  Hope it just says
files dns there.

  $ grep hosts /etc/nsswitch.conf
  hosts:  files dns

Bob


signature.asc
Description: Digital signature

Re: bind9 squeeze/oldstable

[george cox]

I found named-checkconf search-engining, and this found my bind syntax error, 
yeah!

Is there anything I can do about the logging issue? I was thinking of doing a 
dist-upgrade to wheezy on my server, but could the logging issue remain after 
the upgrade? Maybe I should just do a fresh install of wheezy instead? Any 
advice? Far as I know that messages and syslog not containing info (filesystem 
not full BTW) is the only problem.
- Original Message -
From: george cox
Sent: 05/18/13 07:25 AM
To: debian-user@lists.debian.org
Subject: bind9 squeeze/oldstable

I haven't had a chance to upgrade this system yet.

I needed to update my bind configuration and now it will not start. In the past 
bind would write errors to the syslog (or messages file, i forget which), but 
it isn't doing so. Is there another way to get the error messages? All the info 
I get is a failed when trying to restart the daemon, but no clue as to what 
is causing the problem.

I noticed my syslog and messages files are totally empty, Going back a few 
version numbers there was always useful info there, but not any more. Is there 
a way to increase the level of logging?

Re: bind9 squeeze/oldstable

[Joe]

On Sat, 18 May 2013 07:57:08 -0400
george cox gc...@mail.com wrote:

 I found named-checkconf search-engining, and this found my bind
 syntax error, yeah!
 
 Is there anything I can do about the logging issue? I was thinking of
 doing a dist-upgrade to wheezy on my server, but could the logging
 issue remain after the upgrade? Maybe I should just do a fresh
 install of wheezy instead? Any advice? Far as I know that messages
 and syslog not containing info (filesystem not full BTW) is the only
 problem.

No experience here, but my feeling is that a server upgrade should be
approached in a state of great peace of mind, not in an attempt to
solve a problem. I wouldn't attempt it without getting the old system
running perfectly first. Especially logging.

Bind should also be logging as 'named' to daemon.log, by the way. But
the default logging seems oriented towards problems with name serving
rather than problems in bind itself. I've found Google/guesswork to be
more useful than the logs with bind.

But syslog should contain much more, cron and iptables at least should
leave logs here. If it is empty, I would start looking at syslogd,
bearing in mind there is more than one possible version, though they
should all log to the same place.

-- 
Joe


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20130518133104.3be97...@jretrading.com

Re: bind9 squeeze/oldstable

[george cox]

I checked debug and it was empty too. I'll take a look at syslogd, I can't 
think of ever touching its config though.
I think that is sound advice about the upgrade. My thinking was perhaps debian 
in general or various package maintainers had decided to reduce the amount of 
message logging, but I think you are right saying that something has broken 
with syslog. My laptop is a fresh wheezy/stable and it has lots of useful stuff 
adding to the logs. I know the syslog issue has been that way for a long time 
on the system in question. I've had some issues in the past and noticed the 
logs were empty then too. Thanks.
- Original Message -
From: Joe
Sent: 05/18/13 08:31 AM
To: debian-user@lists.debian.org
Subject: Re: bind9 squeeze/oldstable

On Sat, 18 May 2013 07:57:08 -0400 george cox gc...@mail.com wrote:  I 
found named-checkconf search-engining, and this found my bind  syntax error, 
yeah!   Is there anything I can do about the logging issue? I was thinking of 
 doing a dist-upgrade to wheezy on my server, but could the logging  issue 
remain after the upgrade? Maybe I should just do a fresh  install of wheezy 
instead? Any advice? Far as I know that messages  and syslog not containing 
info (filesystem not full BTW) is the only  problem. No experience here, but 
my feeling is that a server upgrade should be approached in a state of great 
peace of mind, not in an attempt to solve a problem. I wouldn't attempt it 
without getting the old system running perfectly first. Especially logging. 
Bind should also be logging as 'named' to daemon.log, by the way. But the 
default logging seems oriented towards problems with name serving rather than 
problems in bind itself. I've found Google/guesswork to be more use
 ful than the logs with bind. But syslog should contain much more, cron and 
iptables at least should leave logs here. If it is empty, I would start looking 
at syslogd, bearing in mind there is more than one possible version, though 
they should all log to the same place. -- Joe -- To UNSUBSCRIBE, email to 
debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? 
Contact listmas...@lists.debian.org Archive: 
http://lists.debian.org/20130518133104.3be97...@jretrading.com

Re: Bind9 para cache caindo....[Resolvido]

[d4n1]

Normal cara, somos humanos ;)

Mas que bom que você persistiu e conseguiu achar a falha. É isso ai

Em 20 de fevereiro de 2013 17:53, Keppler jurgenkepp...@gmail.comescreveu:

  Boa tarde Fábio!
 Obrigado pelo retorno, mas descobri o erro aqui!
 Na verdade era uma regra no Firewall que estava bloqueando a porta 53 para
 a rede interna!...resumindo...caquinha minha!
 Nossa!..que febre me deu isso aqui!

 Mas mesmo assim, obrigado pelo retorno!

 abraço,
 Jurgen


 Em 20-02-2013 08:17, Fábio Rabelo escreveu:

 Bom dia ...

 Faltam muitas informações para que seja possível tirar alguma conclusão !

 O Sr. verificou se aparece alguma msg no log ?

 Qdo para de funcionar, a msg de erro nas estações é de falha na resolução
 de nomes, ou de time-out ??


 Fábio Rabelo



 Em 19 de fevereiro de 2013 23:19, Keppler jurgenkepp...@gmail.comescreveu:

 Olá pessoal, mas uma vez eu aqui!

 No título do e-mail eu usei a frase cache caindo, mas não sei se é este
 extamente o termo.

 Seguinte, estou configurando um servidor para ser um Gateway (Firewall +
 Squid).

 Pretendo usar o bind9 só pra cache, ou seja, só pra resolver os nomes sem
 ter que depender de outros servidores DNS como Telefonica, UOL, Google, etc.
 Para isto instalei o bind9 e no coloquei no meu /etc/resolv.conf o
 seguinte: nameserver 127.0.0.1

 Quando eu booto a máquina a resolução de nomes funciona por algum
 período e depois cai. Nem mesmo eu fazendo /etc/init.d/bind9 restart
 volta a funcionar.
 Então, para poder navegar novamente eu tenho que colocar no
 /etc/resolv.conf qualquer outro servidor DNS (por exemplo: nameserver
 8.8.8.8).

 Alguém sabe o q acontece?

 O gozado é que instalei para ser o servidor aqui do escritório o mesmo
 Debian Squeeze. Pelo que me lembro, fiz os mesmos procedimentos para a
 instalação e nele funciona perfeitamente se eu colocar no
 /etc/resolv.conf como nameserver nameserver 127.0.0.1.

 Está faltando alguma coisa?

 att,
 Jurgen


 --
 To UNSUBSCRIBE, email to debian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: http://lists.debian.org/512432b4.7000...@gmail.com







-- 
Daniel Melo d4n1 :

Re: Bind9 para cache caindo....

[Fábio Rabelo]

Bom dia ...

Faltam muitas informações para que seja possível tirar alguma conclusão !

O Sr. verificou se aparece alguma msg no log ?

Qdo para de funcionar, a msg de erro nas estações é de falha na resolução
de nomes, ou de time-out ??


Fábio Rabelo



Em 19 de fevereiro de 2013 23:19, Keppler jurgenkepp...@gmail.comescreveu:

 Olá pessoal, mas uma vez eu aqui!

 No título do e-mail eu usei a frase cache caindo, mas não sei se é este
 extamente o termo.

 Seguinte, estou configurando um servidor para ser um Gateway (Firewall +
 Squid).

 Pretendo usar o bind9 só pra cache, ou seja, só pra resolver os nomes sem
 ter que depender de outros servidores DNS como Telefonica, UOL, Google, etc.
 Para isto instalei o bind9 e no coloquei no meu /etc/resolv.conf o
 seguinte: nameserver 127.0.0.1

 Quando eu booto a máquina a resolução de nomes funciona por algum
 período e depois cai. Nem mesmo eu fazendo /etc/init.d/bind9 restart
 volta a funcionar.
 Então, para poder navegar novamente eu tenho que colocar no
 /etc/resolv.conf qualquer outro servidor DNS (por exemplo: nameserver
 8.8.8.8).

 Alguém sabe o q acontece?

 O gozado é que instalei para ser o servidor aqui do escritório o mesmo
 Debian Squeeze. Pelo que me lembro, fiz os mesmos procedimentos para a
 instalação e nele funciona perfeitamente se eu colocar no
 /etc/resolv.conf como nameserver nameserver 127.0.0.1.

 Está faltando alguma coisa?

 att,
 Jurgen


 --
 To UNSUBSCRIBE, email to 
 debian-user-portuguese-**requ...@lists.debian.orgdebian-user-portuguese-requ...@lists.debian.org
 with a subject of unsubscribe. Trouble? Contact
 listmas...@lists.debian.org
 Archive: 
 http://lists.debian.org/**512432b4.7000...@gmail.comhttp://lists.debian.org/512432b4.7000...@gmail.com

Re: Bind9 para cache caindo....[Resolvido]

[Keppler]

Boa tarde Fábio!
Obrigado pelo retorno, mas descobri o erro aqui!
Na verdade era uma regra no Firewall que estava bloqueando a porta 53 
para a rede interna!...resumindo...caquinha minha!

Nossa!..que febre me deu isso aqui!

Mas mesmo assim, obrigado pelo retorno!

abraço,
Jurgen


Em 20-02-2013 08:17, Fábio Rabelo escreveu:

Bom dia ...

Faltam muitas informações para que seja possível tirar alguma conclusão !

O Sr. verificou se aparece alguma msg no log ?

Qdo para de funcionar, a msg de erro nas estações é de falha na 
resolução de nomes, ou de time-out ??



Fábio Rabelo



Em 19 de fevereiro de 2013 23:19, Keppler jurgenkepp...@gmail.com 
mailto:jurgenkepp...@gmail.com escreveu:


Olá pessoal, mas uma vez eu aqui!

No título do e-mail eu usei a frase cache caindo, mas não sei se
é este extamente o termo.

Seguinte, estou configurando um servidor para ser um Gateway
(Firewall + Squid).

Pretendo usar o bind9 só pra cache, ou seja, só pra resolver os
nomes sem ter que depender de outros servidores DNS como
Telefonica, UOL, Google, etc.
Para isto instalei o bind9 e no coloquei no meu /etc/resolv.conf
o seguinte: nameserver 127.0.0.1

Quando eu booto a máquina a resolução de nomes funciona por
algum período e depois cai. Nem mesmo eu fazendo
/etc/init.d/bind9 restart volta a funcionar.
Então, para poder navegar novamente eu tenho que colocar no
/etc/resolv.conf qualquer outro servidor DNS (por exemplo:
nameserver 8.8.8.8).

Alguém sabe o q acontece?

O gozado é que instalei para ser o servidor aqui do escritório o
mesmo Debian Squeeze. Pelo que me lembro, fiz os mesmos
procedimentos para a instalação e nele funciona perfeitamente se
eu colocar no /etc/resolv.conf como nameserver nameserver
127.0.0.1.

Está faltando alguma coisa?

att,
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: http://lists.debian.org/512432b4.7000...@gmail.com

Re: Bind9 - help - wildcard priority fail.

[Camaleón]

On Mon, 27 Aug 2012 20:47:08 +0200, Ja wrote:

 Hi,

Hi, but please, no html posts, thanks :-)
  
 I'm having problem with newest Bind9 (9.7.3). In version 9.6-ESV-R1 it
 works fine. The problem is that wildcard records are taking priority to
 more specific ones.

(...)

 When I ask Bind 9.6, it says:
  
 jajko.pl, NAME: s1.serv.pl, and this is fine! But bind 9.7.3 says
 s2.serv.pl ... why and how do I fix it?

How are you querying your DNS servers? 

Send the exact command and what's the output you get in both cases.

Anyway, I would avoid using wildcards for DNS registries.

Also, check this for some hints:

Will a wildcard CNAME take precedence over a named CNAME record?
http://serverfault.com/questions/117671/will-a-wildcard-cname-take-precedence-over-a-named-cname-record

Greetings,

-- 
Camaleón


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/k1imvi$ik9$1...@ger.gmane.org

Re: Bind9 : masquage du numéro de version

[Alain Vaugham]

Le Wed, 11 Apr 2012 18:47:41 +0200,
Stephane Bortzmeyer steph...@sources.org a écrit :

 On Wed, Apr 11, 2012 at 01:30:49AM +0200,
  Alain Vaugham al...@vaugham.com wrote 
  a message of 202 lines which said:
 
  Pour masquer la version 
 
 Cela ne sert à rien

C'est ce que je me disais car :

1)
j'ai l'impression qu'il y a peu de versions Bind en service. 
Donc ce ne doit pas être très long de trouver la bonne.

2)
Comme Apache est très locace quand à la version Debian sur laquelle il tourne,
ce n'est pas difficile de prévoir la version du Bind9 qui vient avec à moins
qu'on ait volontairement installé une autre version et qu'on ait pris beaucoup
de précautions pour masquer ce qui est masquable par ailleurs.

3)
Même avec une version masquée, un dig @ip CH TXT version.bind retoure
cette info dès sa première ligne :
;  DiG 9.7.3  @ip..


Merci de t'être intéressé à ma requête.



-- 
Alain Vaugham
Clef GPG : 0xD26D18BC

--
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: http://lists.debian.org/20120412134944.3eb5d150@mach07.localdomain

Re: Bind9 : masquage du numéro de version

[Pierre-Arnaud]

Le 12/04/2012 13:49, Alain Vaugham a écrit :

2)
Comme Apache est très locace quand à la version Debian sur laquelle il tourne,
ce n'est pas difficile de prévoir la version du Bind9 qui vient avec à moins
qu'on ait volontairement installé une autre version et qu'on ait pris beaucoup
de précautions pour masquer ce qui est masquable par ailleurs.


La plupart du temps, les serveurs de noms faisant autorité sur une zone 
donnée ne tournent pas sur les mêmes systèmes que d'éventuels serveurs 
apache pointés par les hôtes de la zone en question (à part dans le cas 
de micro infrastructures style auto-hébergement).


Et puis y'a pas que http et debian dans la vie ;p


3)
Même avec une version masquée, un dig @ip CH TXT version.bind retoure
cette info dès sa première ligne :
;  DiG 9.7.3  @ip..


C'est la version du dig installé sur la machine depuis laquelle tu fais 
le test, pas celle du serveur de noms.


P.-A.

--
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: http://lists.debian.org/4f86c83c.6040...@lemurien.org

Re: Bind9 : masquage du numéro de version

[Pierre-Arnaud]

Le 11/04/2012 01:30, Alain Vaugham a écrit :

version pipo;


Ca ne m'a pas l'air mal.


Résultat : la version est inchangée :
# named-checkconf -v
9.7.3


Tu ne fais pas le bon test.
named-checkconf est un outil local qui te donnera toujours la véritable 
version de bind.


Essaie plutôt ceci: dig @localhost CH TXT version.bind

Tu devrais voir la chaîne que tu as spécifiée dans named.conf.options. 
C'est cette information de version qui est accessible au reste du monde, 
pas la valeur retournée par named-checkconf.


P.-A.

--
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: http://lists.debian.org/4f853654.2030...@lemurien.org

Re: Bind9 : masquage du numéro de version [Résolu]

[Alain Vaugham]

Le Wed, 11 Apr 2012 09:44:20 +0200,
Pierre-Arnaud debian-user-fre...@lemurien.org a écrit :

 Le 11/04/2012 01:30, Alain Vaugham a écrit :
  version pipo;
 
 Ca ne m'a pas l'air mal.
 
  Résultat : la version est inchangée :
  # named-checkconf -v
  9.7.3
 
 Tu ne fais pas le bon test.
 named-checkconf est un outil local qui te donnera toujours la véritable 
 version de bind.
 
 Essaie plutôt ceci: dig @localhost CH TXT version.bind
 
 Tu devrais voir la chaîne que tu as spécifiée dans named.conf.options. 
 C'est cette information de version qui est accessible au reste du monde, 
 pas la valeur retournée par named-checkconf.

Pour l'instant il n'est pas encore ouvert au reste du monde.
J'ai tout compris.

Merci.



-- 
Alain Vaugham
Clef GPG : 0xD26D18BC

--
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: http://lists.debian.org/2012041207.466eb93c@mach07.localdomain

Re: Bind9 : masquage du numéro de version

[Stephane Bortzmeyer]

On Wed, Apr 11, 2012 at 01:30:49AM +0200,
 Alain Vaugham al...@vaugham.com wrote 
 a message of 202 lines which said:

 Pour masquer la version 

Cela ne sert à rien mais cela permet de faire des choses amusantes :

http://www.bortzmeyer.org/versions-serveurs-dns.html

-- 
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: http://lists.debian.org/20120411164741.ga7...@sources.org

Re: Bind9 (9.7.4)

[Chris Brennan]

On Tue, Nov 8, 2011 at 3:01 PM, Pascal Hambourg pas...@plouf.fr.eu.org wrote:

Hello,

 Chris Brennan a écrit :
 
  I was discussing a bind issue that I am experiencing w/ an acquaintance
 on
  IRC this afternoon and he informed me that bind was updated to cover a
  latent bug in the DNS message processing code that could allow certain
  UPDATE requests to crash named.
 
  I'm currently running Bind 9.7.3, which as far as I can tell is the
 latest
  available on the stable squeeze repos.

 AFAICS, this vulnerability has been fixed in Debian Squeeze, see
 http://www.debian.org/security/2011/dsa-2272


OK, So my copy of bind is correctly up to date. That doesn't explain then
why
I am getting random deaths of bind, multiple times a day. It doesn't log
anything, which is the odd part, and it fails to restart without human
intervention
(cron isn't catching it for some reason, but that's not the bigger problem.)

 --
 Chris Brennan
 A: Yes.
 Q: Are you sure?
 A: Because it reverses the logical flow of conversation.
 Q: Why is top posting frowned upon?
 http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/
 GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8  9E4A EECD 9A84 D5B2 0C0C)

Re: Bind9 (9.7.4)

[Pascal Hambourg]

Hello,

Chris Brennan a écrit :
 
 I was discussing a bind issue that I am experiencing w/ an acquaintance on
 IRC this afternoon and he informed me that bind was updated to cover a 
 latent bug in the DNS message processing code that could allow certain 
 UPDATE requests to crash named.
 
 I'm currently running Bind 9.7.3, which as far as I can tell is the latest
 available on the stable squeeze repos.

AFAICS, this vulnerability has been fixed in Debian Squeeze, see
http://www.debian.org/security/2011/dsa-2272


-- 
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org 
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4eb98a84.6060...@plouf.fr.eu.org

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Diego Sanchez]

El 8 de octubre de 2011 11:46, Flako subfo...@gmail.com escribió:

   Hola
   Tengo una duda conceptual de  bind y zonas inversas.
   Configure la zonas principal y inversa para mi dominio, donde estan
 anda bien. pero como que no encuentro documentacion de como hacer que
 la zona inversa se actualice automaticamente desde los datos de la
 principal, esto es posible? bind tiene un parametro?
   Realmente toy pensado en hacer un script que lea la zona inversa y
 genere el archivo inverso..

   Ustedes que hacen normalmente?  editar los dos archivos?


   Saludos.



Buscando algo totalmente fuera de este topic, me encontre con este site:
http://www.softpanorama.org/DNS/Tools/zone_generators.shtml#Generation_of_zones_from_hosts_file
Cito:

Reverse Zones Generation

mkrdns http://www.mkrdns.org/ -- Program to automatically generate reverse
DNS zone files (PTR records) Dec 03rd 1998, 10:34 stable: 1.4 - devel: none
license: GPL

mkdnstabhttp://fresh.t-systems-sfr.com/unix/src/misc/dns/mkdnstab-0.6b.tar.gz/
DNS
Table generator in Perl Jul 10th 1999, 00:28 stable: 0.3 - devel: none
license: OpenSource

Updatehosts ftp://ftp.tic.com/pub/updatehosts/updatehosts-1.0.0.tar.gz -- is
a system for automatically managing and generating DNS zone files using flat
relational tables. Some of the features of updatehosts includes:

   - Automatic generation of DNS zone files including *.in-addr.arpa zones
   for an unlimited number of DNS zones.
   - Automatic generation of BIND V4 or V8 bootstrap files with support for
   most BIND options.
   - Automatic serial number generation in DNS zone files. Automatic
   generation of the DHCP bootstrap file.
   - Limited support for DNS updates when using DHCP dynamic addressing.
   - Generation of static hosts files from the same set of information used
   for DNS zone file generation
   - Flexible input file syntax which allows additional information such as
   contact names, etc to be kept with all DNS information. This information can
   be added without impacting DNS zone file generation.
   - Tools which allow a set of administrators to manage the the nameserver
   configuration without requiring root access.
   - Conversion utilities to convert existing DNS zone files or static host
   tables into the updatehosts input file format.
   - Flexible postprocessing hooks which allow site specific command to be
   run after the file generation is completed.
   - General purpose tool for reading flat ASCII files as database
   relations.
   - Maintenance of input files under SCCS or RCS control as a user option.T
   - A mailing list (updateho...@tic.com) has been set up. to subscribe send
   request to majord...@tic.com.


Este script+algo de bash, deberia poder ser una solucion :)


-- 
Diego - Yo no soy paranoico! (pero que me siguen, me siguen) |
http://about.me/diegors/bio

Vivo gracias al SL, pero los talibanes, merecen un wipe

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[AngelD]

Sat, 8 Oct 2011, Flako:


  Hola
  Tengo una duda conceptual de bind y zonas inversas.
  Configure la zonas principal y inversa para mi dominio, donde estan 
anda bien. pero como que no encuentro documentacion de como hacer que la 
zona inversa se actualice automaticamente desde los datos de la 
principal, esto es posible? bind tiene un parametro?
  Realmente toy pensado en hacer un script que lea la zona inversa y 
genere el archivo inverso..


  Ustedes que hacen normalmente?  editar los dos archivos?


	Si utilizo Bind, edito los doa archivos. Si utilizo [1]maradns, 
recurro a las directivas FQDN4 y FQDN6 que realizan el registro directo e 
inverso de una sola tacada.


 [1]http://www.maradns.org
 [2]http://www.maradns.org/tutorial/man.csv2.html

--
Saludos --- Angel


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/alpine.DEB.2.00.1110121022080.25904@x61

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Flako]

   Gracias a todos..
   Ya confirme q no hay opcion en bind :)
   Saludos.


-- 
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CADqxbRSWuNUL5426T2ZrdtJh66fzc=fq3uknhmozobykwfl...@mail.gmail.com

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Marc Olive]

On Monday 10 October 2011 07:30:28 julio wrote:
 El sáb, 08-10-2011 a las 11:46 -0300, Flako escribió:
 Ustedes que hacen normalmente?  editar los dos archivos?
 
 Yo si, edito ambos archivos.

Yo tambien, tampoco cuesta tanto.

 Un saludo
 
 JulHer

-- 

Marc Olivé
Blau Advisors

marc.ol...@blauadvisors.com

C/ Molí de Guasch, 10 baixos 1a,
43440 L’Espluga de Francolí (Tarragona)
Tel. +34 977 870 702
Tel i Fax. + 34 977 870 507

www.blauadvisors.com


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/201110111047.34259.marc.ol...@blauadvisors.com

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Camaleón]

El Mon, 10 Oct 2011 14:56:09 -0300, Flako escribió:

 De: Camaleón [mailto:noela...@gmail.com]

 ¿Por qué no explicas con un ejemplo práctico que es lo que quieres
 hacer, o dicho de otro modo, qué es lo que te gustaría que pasara
 automáticamente y qué configuración usas actualmente?

 No me queda clara tu pregunta y Google tampoco encuentra ninguna
 referencia a casos prácticos sobre la actualización automática de zonas
 inversas salvo que uses una configuración de dns dinámico (busca por
 dynamic updates en Bind9 para ver qué tipo de cambios permite
 actualizar).



  Hola
  Donde digo:   Realmente toy pensado en hacer un script que lea
 la zona inversa y  genere el archivo inverso.., imaginen que dice
   Realmente toy pensado en hacer un script que lea la zona directa y
 genere el archivo de la zona  inversa..   :)

Pues adelante, me ha parecido ver uno por la web hecho en perl :-)

 intento explicar mejor...
 Como ya saben en bind las zona de domino son archivos planos, uno
 edita dichos archivos para modificar los registros.,

Supongo que no sólo en bind sino en el resto de servidores dns. Tienes 
entornos gráficos para gestionarlo (webmin creo que dispone de un módulo) 
pero vaya, al final todos terminan por hacer lo mismo.

http://doxfer.webmin.com/Webmin/BINDDNSServer#Adding_and_editing_records

Ahh, mira, parece que webmin sí contempla esa opción o al menos, 
parcialmente:

***
The field Update reverse? only appears when adding an Address record. It 
controls the automatic creation of a corresponding record in a reverse 
zone which associates the hostname with the IP address. Naturally, this 
can only be done if the IP that you enter is in a network that your 
system is the primary reverse DNS server for. This keeps the forward and 
reverse zones synchronized, which can be very useful. If Yes is selected, 
a reverse address record will be added as long as one does not already 
exist in the reverse zone for the same IP address. Often many hostnames 
will have the same IP, such as those use for name-based virtual hosting. 
In cases like these, you don't want to change the reverse mapping if one 
already exists. The Yes (and replace existing) option works the same as 
Yes, but if a reverse record for the IP address already exists it will be 
updated with the new hostname. This can be useful if you know there is an 
existing record that you want to replace. If No is selected, no reverse 
address will be created even if it is possible. 
***

 Si tienes que cambiar la  ip a un host, tienes que ir  a cambiar
 los registros  asociados a la zona directa e indirecta, que son dos
 archivos diferentes, yo lo que quiero es que cuando se modifique el
 registro de la zona directa, automáticamente se modifique el registro
 prt de la zona indirecta.

Ya... lo ideal sería que se creara el registro automáticamente, ¿verdad? 
es decir, al crear una zona, que el asistente de configuración te 
preguntara si deseas crear una zona inversa... y que las actualizaciones 
se gestionaran igual. Pues ahora que lo dices, no sé si el dpkg-
reconfigure es capaz de hacer esto, pero no estaría nada mal aunque 
tampoco es un cambio que tenga que hacer (al menos yo) todos los días :-)

  Esto lo vengo haciendo a mano y me pregunto si se puede hacer
 automático, si hay algún parámetro de bind que lo haga, no he logrado
 encontrar nada en la web,
  La configuración Bind  es estandar, sin actualización automática,

(...)

Okay, pues entonces no, no conozco ningún parámetro disponible desde 
bind9.

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: http://lists.debian.org/pan.2011.10.11.10.52...@gmail.com

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Cristian Mitchell]

El día 11 de octubre de 2011 07:52, Camaleón noela...@gmail.com escribió:
 El Mon, 10 Oct 2011 14:56:09 -0300, Flako escribió:

 De: Camaleón [mailto:noela...@gmail.com]

 ¿Por qué no explicas con un ejemplo práctico que es lo que quieres
 hacer, o dicho de otro modo, qué es lo que te gustaría que pasara
 automáticamente y qué configuración usas actualmente?

 No me queda clara tu pregunta y Google tampoco encuentra ninguna
 referencia a casos prácticos sobre la actualización automática de zonas
 inversas salvo que uses una configuración de dns dinámico (busca por
 dynamic updates en Bind9 para ver qué tipo de cambios permite
 actualizar).



  Hola
      Donde digo:   Realmente toy pensado en hacer un script que lea
 la zona inversa y  genere el archivo inverso..    , imaginen que dice
   Realmente toy pensado en hacer un script que lea la zona directa y
 genere el archivo de la zona  inversa..   :)

 Pues adelante, me ha parecido ver uno por la web hecho en perl :-)

     intento explicar mejor...
     Como ya saben en bind las zona de domino son archivos planos, uno
 edita dichos archivos para modificar los registros.,

 Supongo que no sólo en bind sino en el resto de servidores dns. Tienes
 entornos gráficos para gestionarlo (webmin creo que dispone de un módulo)
 pero vaya, al final todos terminan por hacer lo mismo.

 http://doxfer.webmin.com/Webmin/BINDDNSServer#Adding_and_editing_records

 Ahh, mira, parece que webmin sí contempla esa opción o al menos,
 parcialmente:

 ***
 The field Update reverse? only appears when adding an Address record. It
 controls the automatic creation of a corresponding record in a reverse
 zone which associates the hostname with the IP address. Naturally, this
 can only be done if the IP that you enter is in a network that your
 system is the primary reverse DNS server for. This keeps the forward and
 reverse zones synchronized, which can be very useful. If Yes is selected,
 a reverse address record will be added as long as one does not already
 exist in the reverse zone for the same IP address. Often many hostnames
 will have the same IP, such as those use for name-based virtual hosting.
 In cases like these, you don't want to change the reverse mapping if one
 already exists. The Yes (and replace existing) option works the same as
 Yes, but if a reverse record for the IP address already exists it will be
 updated with the new hostname. This can be useful if you know there is an
 existing record that you want to replace. If No is selected, no reverse
 address will be created even if it is possible.
 ***

     Si tienes que cambiar la  ip a un host, tienes que ir  a cambiar
 los registros  asociados a la zona directa e indirecta, que son dos
 archivos diferentes, yo lo que quiero es que cuando se modifique el
 registro de la zona directa, automáticamente se modifique el registro
 prt de la zona indirecta.

 Ya... lo ideal sería que se creara el registro automáticamente, ¿verdad?
 es decir, al crear una zona, que el asistente de configuración te
 preguntara si deseas crear una zona inversa... y que las actualizaciones
 se gestionaran igual. Pues ahora que lo dices, no sé si el dpkg-
 reconfigure es capaz de hacer esto, pero no estaría nada mal aunque
 tampoco es un cambio que tenga que hacer (al menos yo) todos los días :-)

      Esto lo vengo haciendo a mano y me pregunto si se puede hacer
 automático, si hay algún parámetro de bind que lo haga, no he logrado
 encontrar nada en la web,
      La configuración Bind  es estandar, sin actualización automática,

 (...)

 Okay, pues entonces no, no conozco ningún parámetro disponible desde
 bind9.

 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: http://lists.debian.org/pan.2011.10.11.10.52...@gmail.com




Con las erramientas estandar de bind no se puede.
por que los archivos de configuracion son archivos planos, sin
interaccion entre ellos

podes probar algunos de los configuradores graficos o web (ej: webmin)

lo que no te garantizo que lo hagan bien,
personalmente tube varios problemas con los que probe

saludos
-- 
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/CALvB54atnKP8SQtdLQBJXwLhnRu53mVE=fhez8yknva95vb...@mail.gmail.com

RE: bind9 actualizar la zona inversa automaticamente desde la directa

[Mauricio Erazo Mejía]

-Mensaje original-
De: Cristian Mitchell [mailto:mitchell6...@gmail.com] 
Enviado el: martes, 11 de octubre de 2011 10:17 a.m.
Para: debian-user-spanish@lists.debian.org
Asunto: Re: bind9 actualizar la zona inversa automaticamente desde la
directa

El día 11 de octubre de 2011 07:52, Camaleón noela...@gmail.com escribió:
 El Mon, 10 Oct 2011 14:56:09 -0300, Flako escribió:

 De: Camaleón [mailto:noela...@gmail.com]

 ¿Por qué no explicas con un ejemplo práctico que es lo que quieres 
 hacer, o dicho de otro modo, qué es lo que te gustaría que pasara 
 automáticamente y qué configuración usas actualmente?

 No me queda clara tu pregunta y Google tampoco encuentra ninguna 
 referencia a casos prácticos sobre la actualización automática de 
 zonas inversas salvo que uses una configuración de dns dinámico 
 (busca por dynamic updates en Bind9 para ver qué tipo de cambios 
 permite actualizar).



  Hola
      Donde digo:   Realmente toy pensado en hacer un script que lea 
 la zona inversa y  genere el archivo inverso..    , imaginen que 
 dice
   Realmente toy pensado en hacer un script que lea la zona directa y 
 genere el archivo de la zona  inversa..   :)

 Pues adelante, me ha parecido ver uno por la web hecho en perl :-)

     intento explicar mejor...
     Como ya saben en bind las zona de domino son archivos planos, uno 
 edita dichos archivos para modificar los registros.,

 Supongo que no sólo en bind sino en el resto de servidores dns. Tienes 
 entornos gráficos para gestionarlo (webmin creo que dispone de un 
 módulo) pero vaya, al final todos terminan por hacer lo mismo.

 http://doxfer.webmin.com/Webmin/BINDDNSServer#Adding_and_editing_recor
 ds

 Ahh, mira, parece que webmin sí contempla esa opción o al menos,
 parcialmente:

 ***
 The field Update reverse? only appears when adding an Address record. 
 It controls the automatic creation of a corresponding record in a 
 reverse zone which associates the hostname with the IP address. 
 Naturally, this can only be done if the IP that you enter is in a 
 network that your system is the primary reverse DNS server for. This 
 keeps the forward and reverse zones synchronized, which can be very 
 useful. If Yes is selected, a reverse address record will be added as 
 long as one does not already exist in the reverse zone for the same IP 
 address. Often many hostnames will have the same IP, such as those use for
name-based virtual hosting.
 In cases like these, you don't want to change the reverse mapping if 
 one already exists. The Yes (and replace existing) option works the 
 same as Yes, but if a reverse record for the IP address already exists 
 it will be updated with the new hostname. This can be useful if you 
 know there is an existing record that you want to replace. If No is 
 selected, no reverse address will be created even if it is possible.
 ***

     Si tienes que cambiar la  ip a un host, tienes que ir  a cambiar 
 los registros  asociados a la zona directa e indirecta, que son dos 
 archivos diferentes, yo lo que quiero es que cuando se modifique el 
 registro de la zona directa, automáticamente se modifique el registro 
 prt de la zona indirecta.

 Ya... lo ideal sería que se creara el registro automáticamente, ¿verdad?
 es decir, al crear una zona, que el asistente de configuración te 
 preguntara si deseas crear una zona inversa... y que las 
 actualizaciones se gestionaran igual. Pues ahora que lo dices, no sé 
 si el dpkg- reconfigure es capaz de hacer esto, pero no estaría nada 
 mal aunque tampoco es un cambio que tenga que hacer (al menos yo) 
 todos los días :-)

      Esto lo vengo haciendo a mano y me pregunto si se puede hacer 
 automático, si hay algún parámetro de bind que lo haga, no he logrado 
 encontrar nada en la web,
      La configuración Bind  es estandar, sin actualización 
 automática,

 (...)

 Okay, pues entonces no, no conozco ningún parámetro disponible desde 
 bind9.

 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: http://lists.debian.org/pan.2011.10.11.10.52...@gmail.com




Con las erramientas estandar de bind no se puede.
por que los archivos de configuracion son archivos planos, sin interaccion
entre ellos

podes probar algunos de los configuradores graficos o web (ej: webmin)

lo que no te garantizo que lo hagan bien, personalmente tube varios
problemas con los que probe

saludos
--
MrIX
Linux user number 412793.
http://counter.li.org/

las grandes obras,
las sueñan los santos locos,
las realizan los luchadores natos,
las aprovechan los felices cuerdo,
y las critican los inútiles crónicos,


--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact
listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALvB54atnKP8SQtdLQBJXwLhnRu53mVE=ez8YkNVa95Vbs9Q@ma
il.gmail.com

Te recomiendo

RE: bind9 actualizar la zona inversa automaticamente desde la directa

[Mauricio Erazo Mejía]

-Mensaje original-
De: Camaleón [mailto:noela...@gmail.com] 
Enviado el: domingo, 09 de octubre de 2011 07:25 a.m.
Para: debian-user-spanish@lists.debian.org
Asunto: Re: bind9 actualizar la zona inversa automaticamente desde la directa

El Sat, 08 Oct 2011 11:46:51 -0300, Flako escribió:

Tengo una duda conceptual de  bind y zonas inversas. Configure la
zonas principal y inversa para mi dominio, donde estan anda bien. 
 pero como que no encuentro documentacion de como hacer que la zona 
 inversa se actualice automaticamente desde los datos de la principal, 
 esto es posible? bind tiene un parametro?
Realmente toy pensado en hacer un script que lea la zona inversa y 
 genere el archivo inverso..
 
Ustedes que hacen normalmente?  editar los dos archivos?

¿Por qué no explicas con un ejemplo práctico que es lo que quieres hacer, o 
dicho de otro modo, qué es lo que te gustaría que pasara automáticamente y qué 
configuración usas actualmente?

No me queda clara tu pregunta y Google tampoco encuentra ninguna referencia a 
casos prácticos sobre la actualización automática de zonas inversas salvo que 
uses una configuración de dns dinámico (busca por dynamic updates en Bind9 
para ver qué tipo de cambios permite actualizar).

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: http://lists.debian.org/pan.2011.10.09.12.25...@gmail.com

Cordial saludo.

No entiendo muy bien tu pregunta, pero te puedo recomendar mucho la siguiente 
página, tienen excelentes ejemplos y ayudas.

http://www.zytrax.com/books/dns/

buena suerte.

Mauricio E.





--
To UNSUBSCRIBE, email to debian-user-spanish-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/!!AAAYAKiQOuQAQcZAjY/biazc2iPCgAAAEBOSbI2gpNFHlih+22GOMPYBAA==@gmail.com

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Flako]

 De: Camaleón [mailto:noela...@gmail.com]

 ¿Por qué no explicas con un ejemplo práctico que es lo que quieres hacer, o 
 dicho de otro modo, qué es lo que te gustaría que pasara automáticamente y 
 qué configuración usas actualmente?

 No me queda clara tu pregunta y Google tampoco encuentra ninguna referencia a 
 casos prácticos sobre la actualización automática de zonas inversas salvo que 
 uses una configuración de dns dinámico (busca por dynamic updates en Bind9 
 para ver qué tipo de cambios permite actualizar).

 Saludos,


 Hola
 Donde digo:   Realmente toy pensado en hacer un script que lea
la zona inversa y  genere el archivo inverso.., imaginen que dice
  Realmente toy pensado en hacer un script que lea la zona directa y
genere el archivo de la zona  inversa..   :)



intento explicar mejor...
Como ya saben en bind las zona de domino son archivos planos, uno
edita dichos archivos para modificar los registros.,
Si tienes que cambiar la  ip a un host, tienes que ir  a cambiar
los registros  asociados a la zona directa e indirecta, que son dos
archivos diferentes, yo lo que quiero es que cuando se modifique el
registro de la zona directa, automáticamente se modifique el registro
prt de la zona indirecta.
 Esto lo vengo haciendo a mano y me pregunto si se puede hacer
automático, si hay algún parámetro de bind que lo haga, no he logrado
encontrar nada en la web,
 La configuración Bind  es estandar, sin actualización automática,


Julio:  mm, y bueno, me pondré hacer un script.. uno de estos días...


 Saludos.


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

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[Camaleón]

El Sat, 08 Oct 2011 11:46:51 -0300, Flako escribió:

Tengo una duda conceptual de  bind y zonas inversas. Configure la
zonas principal y inversa para mi dominio, donde estan
 anda bien. pero como que no encuentro documentacion de como hacer que la
 zona inversa se actualice automaticamente desde los datos de la
 principal, esto es posible? bind tiene un parametro?
Realmente toy pensado en hacer un script que lea la zona inversa y
 genere el archivo inverso..
 
Ustedes que hacen normalmente?  editar los dos archivos?

¿Por qué no explicas con un ejemplo práctico que es lo que quieres hacer, 
o dicho de otro modo, qué es lo que te gustaría que pasara 
automáticamente y qué configuración usas actualmente?

No me queda clara tu pregunta y Google tampoco encuentra ninguna 
referencia a casos prácticos sobre la actualización automática de zonas 
inversas salvo que uses una configuración de dns dinámico (busca por 
dynamic updates en Bind9 para ver qué tipo de cambios permite 
actualizar).

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: http://lists.debian.org/pan.2011.10.09.12.25...@gmail.com

Re: bind9 actualizar la zona inversa automaticamente desde la directa

[julio]

El sáb, 08-10-2011 a las 11:46 -0300, Flako escribió:
 no encuentro documentacion de como hacer que
 la zona inversa se actualice automaticamente desde los datos de la
 principal, esto es posible? bind tiene un parametro?


Que yo sepa, no.

Ustedes que hacen normalmente?  editar los dos archivos? 

Yo si, edito ambos archivos.

Un saludo

JulHer



signature.asc
Description: This is a digitally signed message part

Re: BIND9 o DNSmasq???

[Julio]

El mar, 28-06-2011 a las 10:18 -0430, skorky duarte escribió:
 Poseo un dominio (midominio.com) con un revendedor tipo godaddy
 (cdmon.net) el cual redirecciono para mi ip de dsl
 donde tengo un debian como servidor esperandolo para hacer todo lo que
 deseo. 

Jo, que suerte...

 el problema es cuando deseo crear subdominios
 y que cada uno de ellos vaya a un equipo distinto dentro de mi red
 lan:
 
 
 midoiminio.com-192.168.1.1
 soporte.midominio.com  -   192.168.100.1
 inventario.midominio.com - 192.168.200.1
 

Hasta donde yo se eso lo puedes hacer con los virtualhost del apache.

 
 *Nota:* Con bind9 se que se pueden crear zonas y redirigir cada uno de
 esos subdominos a la ip que deseo dentro de mi lan pero lo he
 intentado y desde la wan sigo viendo los subdominios apuntando a la
 misma ip que coloque en el cdmon, y ya he colocado los virtual host
 del apache.

lógicamente... la resolución de nombres no la hace tu bind, ¿no...? por
lo que yo entiendo la hace tu proveedor, y por eso tu bind ni se entera.
 
 Con dnsmasq anteriormente se estaba haciendo en una maquina ubuntu
 server
 (todo lo aqui planteado) solo que se migro a debian squeeze con bind9
 para
 separar las funciones de dhcp del dns (se instalo por el dhcp el
 isc-dhcp-server) e instalar un nuevo equipo.

Apache seguro que es capaz de servir tus tres subdominios y muchos mas,
pero si quieres que vayas a sitios diferentes puedes echar un ojo al
módulo rewrite del apache, quizás te sirva.

 Gracias de antemano por la ayuda que puedan prestar

De nada, para eso estamos.

Un saludo

JulHer

P.D. Se que este correo va a llegar tarde, pero estoy sin Internet
esperando que me arreglen un desaguisado y seguro que alguien ya te
habrá puesto en la pista correcta.


signature.asc
Description: Esta parte del mensaje está firmada	digitalmente