Estou lutando com um pequeno problema em nossa rede fechada. Criei novo DNS e DHCP e tudo funciona, exceto que o DNS se recusa a atualizar o arquivo com informações de encaminhamento enviadas do DHCP. Eu tentei várias alterações no dhcpd.conf, verifiquei e verifiquei os privilégios de arquivo e diretório e assim por diante. Desculpas para mostrar arquivos modificados e não os originais, os dados sensíveis foram alterados. O resultado desse problema pode ser visto em dois exemplos nslookup:
$ nslookup
> testname1
Server: 10.0.0.100
Address: 10.0.0.100#53
** server can't find testname1: REFUSED
> 10.0.0.101
Server: 10.0.0.100
Address: 10.0.0.100#53
101.0.0.1.in-addr.arpa name = testname1.example.com.
Como você pode ver, procurar o nome do cliente não funciona, mas pedir o endereço IP funciona. Isso acontece quando o PC cliente não é predefinido nos arquivos de zona direta e reversa e o DHCP deve enviar os dados. O arquivo reverso é atualizado, o arquivo de encaminhamento não é modificado. Quando o cliente solicita o endereço DHCP, isso acontece, de acordo com o registro named.run:
nov 07 08:51:41 localhost.localdomain dhcpd[2744]: DHCPREQUEST for 10.0.0.101 from 1a:2b:3c:4d:5e:6f via ens32
nov 07 08:51:41 localhost.localdomain dhcpd[2744]: DHCPACK on 10.0.0.101 to 1a:2b:3c:4d:5e:6f via ens32
nov 07 08:51:41 localhost.localdomain named[2549]: client 127.0.0.1#42022/key rndc-key: signer "rndc-key" approved
nov 07 08:51:41 localhost.localdomain named[2549]: client 127.0.0.1#42022/key rndc-key: updating zone '0.0.10.in-addr.arpa/IN': deleting rrset at '101.0.0.10.in-addr.arpa' PTR
nov 07 08:51:41 localhost.localdomain named[2549]: client 127.0.0.1#42022/key rndc-key: updating zone '0.0.10.in-addr.arpa/IN': adding an RR at '101.0.0.10.in-addr.arpa' PTR
nov 07 08:51:41 localhost.localdomain dhcpd[2744]: Added reverse map from 101.0.0.10.in-addr.arpa. to hostname1.example.com
nov 07 08:51:44 localhost.localdomain dhcpd[2744]: DHCPINFORM from 10.0.0.101 via ens32
nov 07 08:51:44 localhost.localdomain dhcpd[2744]: DHCPACK to 10.0.0.101 (1a:2b:3c:4d:5e:6f) via ens32
nov 07 08:51:44 localhost.localdomain named[2549]: client 10.0.0.101#54095: update 'example.com/IN' denied
nov 07 08:51:44 localhost.localdomain named[2549]: client 10.0.0.101#55624: update 'example.com/IN' denied
Se você olhar de perto quem está solicitando o que, você pode ver meu problema, a solicitação de atualização para 0.0.10.in-addr.arpa/IN é solicitada por 127.0.0.1, a solicitação de atualização para frente é feita por 10.0.0.101, em vez de 127.0.0.1. E, claro, a política de segurança no named.conf define que apenas alguém com chave DNSSEC pode atualizar as zonas.
dhcpd.conf
authoritative;
option domain-name "example.com";
option domain-name-servers ns1.example.com;
default-lease-time 72000;
max-lease-time 72000;
ddns-update-style interim;
ddns-updates on;
update-static-leases on;
ddns-domainname "example.com";
###allow client-updates;
###ignore client-updates;
###do-forward-updates; #if uncommented, this line crashes dhcpd at start, with strange errors reported in config file.
key "rndc-key" {
algorithm hmac-md5;
secret "secret-DNS-key";
};
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.110 10.0.0.120;
option broadcast-address 10.0.0.255;
option domain-name-servers 10.0.0.100;
option domain-name "example.com";
option routers 10.0.0.1;
}
zone example.com. {
primary localhost;
key rndc-key;
}
zone 0.0.10.in-addr.arpa. {
primary localhost;
key rndc-key;
}
host testname1 {
option host-name "testname1.example.com";
hardware ethernet 1a:2b:3c:4d:5e:6f;
fixed-address 10.0.0.101;
}
named.conf
options {
listen-on port 53 { 127.0.0.1; 10.0.0.100;}; #IP address of DNS server and localhost
# listen-on-v6 port 53 { ::1; };
directory "/var/named";
dump-file "/var/named/data/cache_dump.db";
statistics-file "/var/named/data/named_stats.txt";
memstatistics-file "/var/named/data/named_mem_stats.txt";
allow-query { localhost; 10.0.0.0/24;}; #which computers can ask
allow-transfer { localhost; }; #No backup DNS server yet
recursion no; #no connection to internet, to speed up requests for unknown names and domains.
dnssec-enable yes;
dnssec-validation yes;
/* Path to ISC DLV key */
bindkeys-file "/etc/named.iscdlv.key";
managed-keys-directory "/var/named/dynamic";
pid-file "/run/named/named.pid";
session-keyfile "/run/named/session.key";
/* forwarders { #nothing, so far
10.0.0.100
}
*/
};
logging {
channel default_debug {
file "data/named.run";
severity dynamic;
};
};
zone "." IN {
type hint;
file "named.ca";
};
include "/etc/named.rfc1912.zones";
include "/etc/named.root.key";
include "/etc/rndc.key";
zone "example.com." IN {
type master;
file "data/example.com";
allow-update {key rndc-key;};
# allow-update {127.0.0.1;10.0.0.0/24;};
};
zone "0.0.10.in-addr.arpa." IN {
type master;
file "data/0.0.10.in-addr.arpa";
allow-update {key rndc-key;};
# allow-update {127.0.0.1;10.0.0.0/24;};
};
ls -al / var / named / data
drwxrwx---. 2 named named 4096 7. nov 10.11 .
drwxrwx---. 7 named named 4096 7. nov 09.02 ..
-rw-r--r-- 1 named named 1810 7. nov 10.11 example.com
-rw-r--r--. 1 named named 2640 7. nov 09.58 example.com.jnl
-rw-r--r-- 1 named named 1494887 7. nov 10.34 named.run
-rw-r--r-- 1 named named 2353 7. nov 10.10 0.0.10.in-addr.arpa
-rw-r--r--. 1 named named 8010 7. nov 09.58 0.0.10.in-addr.arpa.jnl
arquivo de zona de encaminhamento, example.com
$TTL 604800 ; 1 week
example.com IN SOA ns1.example.com. admin.example.com. (
2016110411 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS ns1.example.com.
testname2 A 10.0.0.102
arquivo de zona reversa, 0.0.10.in-addr.arpa
$TTL 604800 ; 1 week
0.0.10.in-addr.arpa IN SOA ns1.example.com. admin.example.com. (
34 ; serial
604800 ; refresh (1 week)
86400 ; retry (1 day)
2419200 ; expire (4 weeks)
604800 ; minimum (1 week)
)
NS ns1.example.com.
102 PTR testname2.example.com.
Eu posso corrigir esse problema facilmente alterando o named.conf para permitir atualizações de 10.0.0.0/24 e sem chave - eu já testei que funciona - mas a segurança seria risível. Eu estou procurando uma resposta melhor. Por que a solicitação de arquivo reverso é processada a partir do localhost e do arquivo de encaminhamento a partir do IP do cliente e como corrigi-lo?
EDIT: adicionando resultados do teste "dig":
dig 10.0.0.101
; <<>> DiG 9.4.2-P2 <<>> 10.0.0.101
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 14648
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;10.0.0.101. IN A
;; Query time: 1 msec
;; SERVER: 10.0.0.100#53(10.0.0.100)
;; WHEN: Tue Nov 8 09:43:50 2016
;; MSG SIZE rcvd: 30
dig testname1
; <<>> DiG 9.4.2-P2 <<>> testname1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 60894
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;testname1. IN A
;; Query time: 1 msec
;; SERVER: 10.0.0.100#53(10.0.0.100)
;; WHEN: Tue Nov 8 09:44:07 2016
;; MSG SIZE rcvd: 23
dig testname1.example.com
; <<>> DiG 9.4.2-P2 <<>> testname1.example.com
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 40151
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available
;; QUESTION SECTION:
;testname1.example.com. IN A
;; AUTHORITY SECTION:
example.com. 604800 IN SOA ns1.example.com. admin.example.com. 2016110411 604800 86400 2419200 604800
;; Query time: 1 msec
;; SERVER: 10.0.0.100#53(10.0.0.100)
;; WHEN: Tue Nov 8 09:44:15 2016
;; MSG SIZE rcvd: 78