Fórum Root.cz
Hlavní témata => Server => Téma založeno: rooobertek 12. 01. 2017, 14:29:47
-
Ahojte, mám nastavený lokálny bind9 dns server pre resolvovanie lokálnych domén, napríklad *.lokal. Pomerne často sa mi stáva, že vo firefoxe refreshnem stránku na tej lokálnej doméne a výsledkom je chyba. Po ďalšom refreshi je opäť všetko v poriadku (niekedy je treba refreshovať aj viac krát).
Mám ubuntu 16.04. Sieť mám nastavenú tak, že primárne dns mám 127.0.0.1 a sekundárne 10.0.x.x.
/etc/bind/named.conf.local:
zone "lokal" {type master; file "/etc/bind/zones/local.txt";};
zone "lokal2" {type master; file "/etc/bind/zones/local.txt";};/etc/bind/named.conf.options:
options {
directory "/var/cache/bind";
dnssec-validation auto;
auth-nxdomain no; # conform to RFC1035
listen-on {
127.0.0.1;
};
listen-on-v6 { any; };
allow-transfer { none; };
forwarders {
10.0.x.x;
10.0.x.y;
};
forward only;
};Vo wiresharku to vyzeralo cca takto (nebolo jednoduché to odchytiť, keďže sa to stáva občasne):
(127.0.0.1) Standard query 0x1234 A abc.lokal
(10.0.x.x) Standard query 0x1235 A abc.lokal
(10.0.x.x) Standard query response 0x1235 No such name A abc.lokal SOA a.root-servers.net
(127.0.0.1) Standard query response 0x1234 No such name A abc.lokal SOA a.root-servers.netTo isté skúša aj s AAAA a celé sa to zopakuje niekoľko krát.
Niečo mi hovorí, že to bude súvisieť s IPv6, ale neviem to naisto a ani ako konkrétne. Skúsil som cez /etc/default/bind9 nastaviť ipv4 (OPTIONS="-4 -u bind"), ale je to ešte horšie.
V syslogu je niekoľko dnssec chýb napr. clients2.google.com, ale nič, čo by súviselo s mojím problémom.
Nejaké tipy?
-
S IPv6 to s největší pravděpodobností nesouvisí. Podle záznamu z wiresharku to vypadá, jako by v tu dobu BIND „zapomněl“, že existuje lokální zóna a hledal její obsah na Internetu.
-
No a jak vypada ten zonovej soubor? A co rika dig?
-
$TTL 86400 ; one day
@ IN SOA loc. hostmaster.loc. (
2014090102
28800
7200
864000
86400 )
NS 127.0.0.1
A 10.0.y.z
@ IN A 10.0.y.z
* IN A 10.0.y.z
Chybný dig sa mi zatiaľ nepodarilo získať. Kým sa k tomu dostanem, tak to znovu ide. Asi by som mohol nechať v intervale skúšať dig a pri inej odpovedi nahlásiť... Tu je správny dig:
$ dig abc.lokal
; <<>> DiG 9.10.3-P4-Ubuntu <<>> abc.lokal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41992
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;abc.lokal. IN A
;; ANSWER SECTION:
abc.lokal. 86400 IN A 10.0.y.z
;; AUTHORITY SECTION:
lokal. 86400 IN NS 127.0.0.1.lokal.
;; ADDITIONAL SECTION:
127.0.0.1.lokal. 86400 IN A 10.0.y.z
;; Query time: 0 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Jan 12 15:18:49 CET 2017
;; MSG SIZE rcvd: 94
-
tak už mám aj nesprávny dig:
$ dig abc.lokal
; <<>> DiG 9.10.3-P4-Ubuntu <<>> abc.lokal
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 43122
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;abc.lokal. IN A
;; AUTHORITY SECTION:
. 386 IN SOA a.root-servers.net. nstld.verisign-grs.com. 2017011200 1800 900 604800 86400
;; Query time: 0 msec
;; SERVER: 127.0.1.1#53(127.0.1.1)
;; WHEN: Thu Jan 12 15:27:23 CET 2017
;; MSG SIZE rcvd: 113
-
$TTL 86400 ; one day
@ IN SOA loc. hostmaster.loc. (
2014090102
28800
7200
864000
86400 )
NS 127.0.0.1
A 10.0.y.z
@ IN A 10.0.y.z
* IN A 10.0.y.z
Co to je to "loc." u SOA záznamu? Měl by tam být name server. A mít v datech domény NS záznam směřovaný na 127.0.0.1 není podle mě dobrý nápad pokud má stroj přístup i jinde než do sítě 127.0.0.0/8.
Dále vidím v konfiguraci poslouchání na kterékoli adrese IPv6, nestává se, že je DNS požádán o resolving ze sítě?
Co takhle podívat do logu, co se v tu chvíli dělo a proč si BIND myslí, že nemá ty lokální domény ve vlastní správě. Případně zapnout ukecanější log.
A proč je tam duplikovaný A záznam pro vlastní doménu?
-
loc je pôvodná doména, ktorú som chcel sprevádzkovať, zostalo to takto. Z iných zariadení sa na môj port 53 cez ipv4 nedostane nikto, bind počúva iba na 127.0.0.1, ipv6 som skúsil v tomto configu vypnúť, nepomohlo to.
V syslogu som nenašiel nič na konkrétny čas, mám tam nejaké podivné veci ako
kernel: [173300.899191] audit: type=1400 audit(1484207xyz.xyz:xyz): apparmor="DENIED" operation="mknod" profile="/usr/sbin/cupsd" name="/var/log/cups/access_log" pid=15387 comm="cupsd" requested_mask="c" denied_mask="c" fsuid=0 ouid=0Skúsim sa ešte pohrať s tými ipčkami a NS, možno pomôže. Ale príde mi to, že to je vec, ktorá by mala buď fungovať alebo nefungovať, a nie sa správať takto náhodne.
-
loc je pôvodná doména, ktorú som chcel sprevádzkovať, zostalo to takto.
Tak ještě jednou: Má tam být name server domény.
V syslogu som nenašiel nič na konkrétny čas, mám tam nejaké podivné veci ako
kernel: [173300.899191] audit: type=1400 audit(1484207xyz.xyz:xyz): apparmor="DENIED" operation="mknod" profile="/usr/sbin/cupsd" name="/var/log/cups/access_log" pid=15387 comm="cupsd" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
Zapněte si ukecanější nebo debug logování. Případně kategorizované logování např. dle: http://stackoverflow.com/questions/11153958/how-to-enable-named-bind-dns-full-logging
určitě se tam něco zajímavého objeví.
-
ja bych rekl, ze v tom zonefile nema byt byt NS zaznam IP adresou, ale hostname
-
velmi stara dokumentace, ale porad plati:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/3/html/Reference_Guide/s1-bind-zone.html
-
Sorry za vytiahnutie starej témy, len dodám, že po dlhom trápení s configmi, logmi a skúšaním som to vyriešil prechodom na dnsmasq a je po probléme.