Изпечатай

[laskov]

В мрежата 192.168.15.0/24 има домейн сървър, който знае имената на хостовете и IP адресите им. Домейнът е example.local
В мрежата имам пощенски сървър, на който работи bind. Имам конфигурирана зона

zone "15.168.192.in-addr.arpa" IN {
        type forward;
        forward only;
        forwarders {192.168.15.3; };
        };

и запитванията

dig -x 192.168.15.5

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> -x 192.168.15.5
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 37336
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; ANSWER SECTION:
5.15.168.192.in-addr.arpa. 1073 IN   PTR   sales.example.local.

;; AUTHORITY SECTION:
15.168.192.IN-ADDR.ARPA. 86400   IN   NS   .

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: вт апр 14 12:56:27 EEST 2020
;; MSG SIZE  rcvd: 126

получават отговора, който очаквам. Имам и зона

zone "example.local" IN {
        type forward;
        forwarders {192.168.15.3; };
        };

но отговорът не ми харесва:

dig sales.example.local

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-9.P2.el7 <<>> sales.example.local
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43131
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; AUTHORITY SECTION:
.         6339   IN   SOA   a.root-servers.net. nstld.verisign-grs.com. 2020041400 1800 900 604800 86400

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: вт апр 14 13:03:18 EEST 2020
;; MSG SIZE  rcvd: 124

Едно, че не получавам отговор, и второ, AUTHORITY секцията също не ми харесва.
Как да го оправя това нещо?

PS: Ако питам директно 15.3, получавам отговор.

[Naka]

Бaйн-да отдавна съм го забравил и винаги си е бил криптография за мен. Тъй че стрелям напосоки и е възможно да напиша големи глупости..но все пак да напиша на какво ми мирише......тъй че моля не ме бийте.

Ами в единят случай куерва локалният сървер...т.е. Authoritative сървера и всичко е ок. Ама когато се напише

dig sales.example.local

sales.example.local го третира като външен адрес...т.е. сървера ти работи като  Recursive като такъв който трябва да рови през мержата и затова почва да рови по стандартният ред от root сърверите наобратно докато стигне до домейна ти. затова първо ти връща 
6339   IN   SOA   a.root-servers.net. nstld.verisign-grs.com.


На кой точно локален адрес слуша твоят?
Накъде много отдавна тук имаше тема, че ако си си настроил за днс сървер (recursive)да ползваш твоят. например /etc/resolv.conf -> 192.168.15.3

и куернеш накъкъв адрес например sales.example.local. то той няма да почне да куерва И-т през роот серверите ами първо ще провери дали случайно той самият не е Authoritative за този адрес и ще върне първо него.
 

Ако сървера ти е 192.168.15.3

dig @192.168.15.3 sales.example.local

какво ще върне?

дай съдържанието на  /etc/resolv.conf

https://kb.isc.org/docs/aa-00817

[Acho]

Да, както Накта каза - да се укаже твърдо кой аджеба нейм-сървър да запитва командата dig. И понеже не разбрах на кое IP е запуснат байнд-а, примерно нещо такова :

dig @IP_na_tvoya_bind името_което_искаш

[laskov]

1.

dig @192.168.15.3 sales.example.local

какво ще върне?

Връща правилен отговор.
2.

cat /etc/resolv.conf
search example.com
nameserver 127.0.0.1
nameserver 212.39.90.43

В примерите ми по-горе се вижда, че отговарящият сървър е 127.0.0.1

PS1: Между другото, същата конфигурация, но на Slackware работи, а това е Centos 7

PS2: Обаче Centosът ми казва ей тези неща:

Apr 14 13:36:31 mailserver named[1818]:  validating example.local/SOA: got insecure response; parent indicates it should be secure
Apr 14 13:36:31 mailserver named[1818]: no valid RRSIG resolving 'sales.example.local/DS/IN': 192.168.15.3#53
Apr 14 13:36:31 mailserver named[1818]: insecurity proof failed resolving 'sales.example.local/A/IN': 192.168.15.3#53

PS3: Коментирането на
//      dnssec-enable yes;
//      dnssec-validation yes;
като че ли премахна съобщенията, но не решава проблема с липсата на отговор

[remotexx]

Пробва ли да им свериш часовниците
https://bugzilla.redhat.com/show_bug.cgi?id=1424719

Слак правят нещата както си е указано от разработчиците на съответното нещо (или поне възможно най-близко), а червникаквите ги правят както си знаят и затова често се получава омазване.

Пробва ли вместо да ги коментираш да ги сложиш на 'NO' (и двете опции)

https://bugzilla.redhat.com/show_bug.cgi?id=682482
явно им е стар проблем - и навремето (като се оакали подобно) решението им било

Ok, I was finally able to reproduce your issue. I sent a report to upstream if they consider this behavior as a bug or a feature.

Workaround is to disable DNSSEC validation in named.conf (dnssec-validation off;).

[laskov]

Пробва ли вместо да ги коментираш да ги сложиш на 'NO' (и двете опции)

Това оправя нещата.
Благодаря!

[Naka]

Нещо да добавя. Надявам се знаеш, (или си чувал) че има едно число serial  и всеки път когато правиш промени по някоя зона, него също трябва да го променяш всеки път. Иначе може да не се усети, че има промени по зоната. Няма значение какво е числото. Просто го увеличавш с 1 всеки път при промяна. Сега дали това е особеност на байнд-а или е изискване на ДНС стандарта не съм много наясно.....

cat /var/named/chroot/var/named/localdomain.zone
$TTL    86400
@               IN SOA  localhost root (
                                        42              ; serial (d. adams)
                                        3H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        1D )            ; minimum
                IN NS           localhost
localhost       IN A            127.0.0.1

https://www.networkworld.com/article/2767441/serial-numbers-in-zone-files--yours-and-named-s.html