Dotaz: Delegace subdomény na jiný nameserver [BIND/NAMED]

[MMMMMMMMM]

Zdravím, řeším zapeklitou věc, se kterou si prozatím nějak nevím rady.

Mám doménu domena.cz, autoritativní NS (slouží i jako rekurzivní pro LAN) má IP adresu 10.0.0.1 (ns1.domena.cz). A já chci subdoménu test.domena.cz delegovat na jiný NS v síti, např. 10.0.0.2 (ns2.domena.cz), viz konfigurace v BINDu:

 zone "test.domena.cz" {
       type forward;
       forwarders { 10.0.0.2 };
 };

 zone "domena.cz" {
       type master;
       file "domena.cz";
 };

Pokud se zeptám NS 10.0.0.1 (ns1.domena.cz) na třeba www.domena.cz, dostanu správnou odpověď. Pokud se jej zeptám na www.test.domena.cz, odpověď nedostanu. Na netu jsem našel tohle "řešení" https://www.wizlab.it/code/delegate-sub-domain-to-another-nameserver.html, ale pokud do zóny domena.cz přidám na konec:

$ORIGIN test.domena.cz.
@               IN      NS      ns2.domena.cz.

Stejně k překladu nedojde. Setkal se prosím někdo s funkčním řešením pro BIND/NAMED? Nebo dělám něco špatně? NS 10.0.0.2 překládá název www.test.domena.cz na správnou IP, samotný název ns2.domena.cz překládá na IP 10.0.0.2.

---

---

Odpovědi

$ORIGIN test.domena.cz.
@               IN      NS      ns2.domena.cz.
ns2             IN      A       10.0.0.2

To s tím forwardováním jsme nepochopil.

[MMMMMMMMM]

V lokální síti pro skupinu počítačů je primární rekurzivní (kešující) nameserver 10.0.0.1, který současně slouží také jako autoritativní pro doménu domena.cz (dostupná v lokální síti), tj. přeloží doménu www.google.com, www.seznam.cz, ale taky www.domena.cz (zónový soubor "domena.cz").

Nyní vznikl v síti další nameserver (není to můj výmysl), který je autoritativní pro subdoménu test.domena.cz - tj. záznamy jako www.test.domena.cz, ftp.test.domena.cz, gopher.test.domena.cz, cokoliv.test.domena.cz, destíky záznamů.

Snažím se docílit toho, aby počítače v lokální síti při dotazu primárního rekurzivního nameserveru 10.0.0.1 dostaly odpověď i na dotazy typu *.test.domena.cz, tj. záznamy, o které se autoritativně nestará NS 10.0.0.1, ale NS 10.0.0.2.

Pokud se někdo zeptá nameserveru 10.0.0.2 na záznamy *.domena.cz, jsou požadavky přeposlány na 10.0.0.1, to funguje. Pokud se jej někdo zeptá na *.test.domena.cz, odpoví si na ně sám ze svého zónového souboru "test.domena.cz". Nameserver 10.0.0.1, ten zmiňovaný v úvodu, v současné chvíli *neumí* odpovědět na záznamy *.test.domena.cz - snažím se to rozjet, pokud to jde.

Na stroji 10.0.0.1 se o zónu test.doména.cz vůbec nestarej, kromě souboru se zónovým záznamem pro domena.cz, kam na konec připiš to, co jsem napsal. Na stroji 10.0.0.2 se postarej, aby se na záznamy, které nezná, dotazoval na 10.0.0.1 - ale to už asi máš.

Prostě tvůj stroj 10.0.0.1 teď sice ví, kde se má dotazovat na záznamy ze subdomény test.domena.cz, ale neví, jaký je A záznam pro ns2.domena.cz. Tak mu to tam připíšeš.

[MMMMMMMMM]

Tak tak, stroj 10.0.0.2 má jako nadřazený server 10.0.0.1, takže co nezná, přeposílá na něj, tedy dokáže bez problémů přeložit jak *.test.domena.cz, tak *.domena.cz.

Bohužel se mi nedaří ten příklad. Dával jsem na serveru 10.0.0.1 na konec zónového souboru "domena.cz" dle příkladu:

$ORIGIN test.domena.cz.
@               IN      NS      ns2.test.domena.cz.
ns2             IN      A       10.0.0.2

nebo

$ORIGIN test.domena.cz.
@               IN      NS      ns2
ns2             IN      A       10.0.0.2

nebo

$ORIGIN test.domena.cz.
@               IN      NS      ns2.domena.cz.

(ns2.domena.cz má IP 10.0.0.2, definice A záznamu je v zóně "domena.cz")

Ale ani v jednom případě se server 10.0.0.1 nedotazuje serveru 10.0.0.2 (sledováno přes tcpdump), pokud se jej někdo ptá na *.test.domena.cz. Pokud se dotazuju serveru 10.0.0.2 ručně, dostanu odpověď:

host www.test.domena.cz 10.0.0.2 => www.test.domena.cz has address 10.0.0.100

Pokud se dotazuju serveru 10.0.0.1 na www.test.domena.cz, je tu chyba:

host www.test.domena.cz => Host www.test.domena.cz not found: 3(NXDOMAIN)

Něco je někde špatně.

$ORIGIN domena.cz.
@     IN     SOA    dns.domena.cz.     root.domena.cz. (...)

             IN     NS     ns1.domena.cz.
             IN     A      10.0.0.1
ns1          IN     A      10.0.0.1

;-------------------------------------------
$ORIGIN test.domena.cz.
@            IN     NS     ns2.test.domena.cz.
ns2          IN     A      10.0.0.2

Hledej "glue record"

https://www.zytrax.com/books/dns/ch9/delegate.html

[j]

Mas v tom peknej hokej ...

Zjisti si, co to je a k cemu tzv GLUE. To je totiz jeden z duvodu, proc ti to nefunguje.

Pokud chces NS ve stejny domene pro jakou je ten NS autoritativni, tak MUSIS mit GLUE. Coz defakto znamena, ze na tom nadrazenym serverum MUSIS mit jak NS zaznamy, tak A/AAAA zaznamy pro ten NS.

Priklad:

test.domena.cz + ns.test.domena.cz => na dns serveru pro domena.cz (=ns.domena.cz) MUSI byt

ns.test.domena.cz IN A 1.2.3.4 test.domena.cz IN NS ns.test.domena.cz

Forward tam naopak vubec mit nemusis, to je uplne knicemu. Rekurzivni DNS se kupodivu sam a od prirody pta autoritativniho DNS pro danou (sub)domenu.

Tytez (vejs uvedeny) zaznamy podhopitelne MUSIS mit i na ns.test.domena.cz.

Pokud bys pouzil NS v jiny (znamy) domene, tak ti staci na nadrazenym DNS uvist jen NS pro subdomenu, protoze na IP adresy se uz je kde zeptat, ale protoze pouzivas NS v ty odkazovany subdomene, tak musis zaridit, aby ten nadrazenej server, kteryho se budou klenti (potazmo jejich DNSka) ptat, jim jaksi umel sdelit, nejen jak se ten dalsi NS jmenuje, ale taky kde bydli.

[j]

Chjo ...

Citelnejsi priklad:

ns.test.domena.cz IN A 1.2.3.4 
test.domena.cz IN NS ns.test.domena.cz 

[MMMMMMMMM]

Díky za příklad. Delegaci subdomény mám nastavenu dobře, ale problém je zřejmě s rekurzí, viz můj příspěvek níže.

Že sem tak smělej... A co mám napsáno v tom příspěvku, na kterej reaguješ?

[debian+]

Domeny wwww.test.domena.cz a test.domena.cz su dve rozdielne nezavisle. A sa vo svete iba DNS nastavuju zvlast.

NS zaznamy sluzia ze "ze pre dany NS zaznam vie prave tento DNS server IP-cku (nie ja)", takze jeho sa opytaj.

A nastuduj si: https://www.websupport.sk/support/kb-categories/dns-zaznamy/

[Filip Jirsák]

Máte na jednom DNS serveru autoritativní DNS server i DNS resolver. Doporučuje se to tak nedělat, mít to oddělené.

Vy potřebujete přidat do autoritativního serveru NS záznam delegující doménu test.domena.cz na ten druhý DNS server. Pokud název druhého DNS serveru bude v doméně test.domena.cz (např. ns.test.domena.cz), potřebujete přidat ještě tzv. GLUE záznam – IP adresa pro ns.test.domena.cz musí být uvedená i v té nadřazené zóně (jinak by vznikla smyčka – pro překlad ns.test.domena.cz byste potřeboval jmenný server pro test.domena.cz, jenže pro to potřebujete přeložit ns.test.domena.cz).

No a pak nastává ten problém s tím, že máte autoritativní server i resolver v jednom. Protože když se na test.domena.cz zeptáte toho vašeho serveru 10.0.0.1, ten se zaraduje, že doménu domena.cz zná a bude se snažit odpovídat sám (pochybuju, že by se Bind díval do té zóny a když zjistí, že je tam pro poddoménu delegace jinam, resolver by ji ignoroval). Takže v tom resolveru budete muset ještě nakonfigurovat, že se o doménu test.domena.cz nemá starat a má ji brát, jako by byla externí.

Ale pokud v síti opravdu důsledně používáte ten resolver 10.0.0.1 a nemáte na spoustě zařízení napevno nakonfigurováno, že autoritativní DNS pro domena.cz je 10.0.0.1, doporučil bych spíš to rozdělení. Na 10.0.0.1 nechat DNS resolver, a autoritativní DNS pro doménu domena.cz přesunout na jinou IP adresu, třeba 10.0.0.3. Může o být klidně stejný stroj, jenom bude mít 2 IP adresy a dvě instance Bindu.

[MMMMMMMMM]

Vypadá to, že problém je v tom, že server 10.0.0.1 je současně i rekurzivní a neumí si s tím poradit, viz Vaše zmínka o autoritativním NS a resolveru v jednom. Teď jsem si to otestoval. :-/

Pokud jako rekurzivní kešující NS pro klientský počítač v síti použiju jiný NS v síti a ten se ptá třeba na www.test.domena.cz autoritativního NS (10.0.0.1) pro zónu "domena.cz", následně je mu sděleno, že je tu autoritativní NS (10.0.0.2) pro zónu "test.domena.cz" a dotaz je poslán tam a vrácena korektní IP. To funguje. Pokud se klientský počítač ptá přímo NS 10.0.0.1 (je současně i rekurzivní pro klienty), vrací chybu NXDOMAIN.

Asi podobný model zatím nikdo neřešil...

[Filip Jirsák]

Samozřejmě že už to před vámi řešila spousta lidí. Jak jsem psal, nejlepší řešení je ten autoritativní server od resolveru oddělit. Pokud to z nějakého důvodu teď udělat nemůžete, je podle mne řešení nakonfigurovat v Bindu tu zónu test.domena.cz a nastavit na ní forward (to, co jste měl původně), a přidal bych tam forward only.

[MMMMMMMMM]

Tak bohužel i po přidání další zóny s parametrem forward only to nefunguje. Zřejmě budu muset jít cestou rozdělení autoritativního NS a rekurzivního resolveru.

 zone "test.domena.cz" {
       type forward;
       forward only;
       forwarders { 10.0.0.2; };
 };

Díky všem za nápady.

[Filip Jirsák]

To rozdělení autoritativního a rekurzivního resolveru bych vám doporučil, předejdete tím dalším problémům v budoucnosti, je to také bezpečnější.

Jen pro zajímavost, co znamená, že to nefunguje? Jakou odpověď server vrací? A pokusí se poslat požadavek dál, nebo odpovídá sám? Já jsem se bohužel (naštěstí s Bindem nikdy nepotkal, takže jak to nakonfigurovat správně nevím. Ale určitě to nebude výjimečný případ, takže by nemělo být těžké to vygooglit (akorát když jsem to zkoušel, vychází mi to pořád na tu konfiguraci, která vám nefunguje).

[j]

"je současně i rekurzivní a neumí si s tím poradit"

To samozrejme zadnej problem neni, naprosto bezne se to tak pouziva, Jirsaka neber vazne, je to negramotnej blb. 99% existujicich DNS serveru funguje prave presne v tomhle rezimu.

Jak uz sem psal vejs ZAPOMEN na to ze existujou nejaky forwardy. TO NANIC NEPOTREBUJES!!! Proste vsechny tyhle picoviny z konfigurace odstran. Nefunguje ti to prave a presne kvuli tomu. Forwardy se pouzivaji uplne jinak a slouzi k uplne necemu jinymu.

Jak myslis ze DNS vubec funguje?

Klient posle dotaz ... svymu DNS. Ten ten dotaz veme, a jde se podivat do fixniho seznamu korenovych NS. Vylosuje jednu z IPcek a zepta se, jaky DNS obsluhujou TLD cz trebas. Tak si najde NS pro prislusnou TLD, a tomu posle dalsi dotaz => v tld cz se trebas zepta na domena.cz. Prislusnej DNS mu odpovi, ze autoritativnim DNS pro domena.cz je cojavim, ns.domena.cz a ze ma ip 1.2.3.4. Nebo mu odpovi, ze je to ns.vopicka.cz. V tomhle pripade pokracuje dns tim, ze se zepta na vopicka cz ... a takhle to pokracuje.

Nasledne, kdyz uz konecne (v principu to muze znamenat i hromadu dotazu) vi IP, zepta toho dalsiho autoritativniho NS, trebas na unas.domena.cz ... a ten mu opet bud muze rovnou poslat nejaky to Acko nebo mu rekne, ze NS pro tuhle domenu je vyriduch.domena.cz ... a tudiz se opet pokracuje.

Presne tomu se rika ta rekurze. A pochopitelne sam k sobe se ten rekurzivni DNS chova uplne stejne jako k libovolnymu jinymu resolveru. Takze kdyz mu prijde dotaz na domenu, ktery je zaroven autoritativni DNS, tak to VI, a odpovida primo. Uplne stejne, jako kdyz se pri opakovanych dotazech pouziva cache.

[Filip Jirsák]

To samozrejme zadnej problem neni, naprosto bezne se to tak pouziva, Jirsaka neber vazne, je to negramotnej blb.

Od vás je to pochvala.

99% existujicich DNS serveru funguje prave presne v tomhle rezimu.

Zdroj toho čísla? Jinak bavíme se tady o tom, že je subdoména delegována na jiný server – pochybuju, že 99 % domén deleguje subdomény.

Výborné je, když u někoho, kdo provozuje DNS přesně v tomhle režimu, hostujete doménu, a pak ji převedete někam jinam. Protože ten DNS server si dál myslí, že je pro tu doménu autoritativní, a dál svým klientům vrací odpovědi ze své zóny, která už dávno neplatí. A vy pak musíte toho ISP extra žádat, jestli by byl tak laskav, a tu zónu ze svého serveru odstranil.

A pochopitelne sam k sobe se ten rekurzivni DNS chova uplne stejne jako k libovolnymu jinymu resolveru. Takze kdyz mu prijde dotaz na domenu, ktery je zaroven autoritativni DNS, tak to VI, a odpovida primo.

Hezky jste druhou větou popřel tu první. Správně je druhá věta. Rekurzvní DNS server se k zóně, kde je zároveň autoritativním serverem, nechová stejně. Právě proto, že si myslí, že ví, že je autoritativním serverem pro tu doménu, nikoho se na nic neptá a a vyřídí odpověď ze své zóny. Což je právě problém v případě, že dotyčný server v nadřazené doméně není veden jako autoritativní.

A právě v tom, že dotazy na „svou“ doménu vyřizuje ten kombinovaný DNS server jinak, je ten zádrhel. Protože on pro tu doménu test.domena.cz fakticky není autoritativním serverem, ale zároveň pro ni může posílat autoritativní odpovědi. Kdyby to tak nebylo, muselo by se v DNS postupovat přísně vždy jen o jeden stupeň v hierarchii dál – pro jméno 4. řádu byste musel nejprve oddelegovat příslušnou doménu 3. řádu. Takže pro adresu www.test.example.com byste musel speciálně vytvořit zónu test.example.com a tu explicitně delegovat na nějaký server. Jenže tak to není, v hierarchii DNS je možné přeskakovat, takže dotaz na www.test.example.com je možné klidně vyřídit ze zóny example.com a NS pro test.example.com vůbec nemusí existovat.

Pokud Bind odpovídá na dotaz ze subdomény k doméně, které je autoritativní, a příslušný záznam ve své zóně nenajde, musí se podívat, zda ta subdoména není někam oddelegovaná. Ale otázka je, co se stane, když ten záznam ve své zóně najde – já bych si tipnul, že jím odpoví a nebude ověřovat, zda ta subdoména náhodou není oddelegovaná jinam. A pak je také otázka, co se stane, když existuje záznam pro dané jméno, ale jiného typu. Jestli to bude brát tak, že dané jméno je pokryté vlastním zónovým souborem a není potřeba se ptát nikde jinde, nebo zda nezkusí, zda ta subdoména náhodou není oddelegovaná jinam.

A nebo je možné neřešit, jak jsou implementovány tyhle okrajové případy, a prostě oddělit rekurzivní a autoritativní server, protože to fakt nedělá dobrotu.

Nevím, co by na tom mělo nefungovat.

Stroj ns1 (10.10.0.183):

root@ns1:~# apt install bind9 dnsutils

Test:

root@ns1:~# dig @127.0.0.1 google.com. a

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 google.com. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17517
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: fd635b6e2a6616c9e7c8c88e5ebbfc7ef7b7ee59615773fd (good)
;; QUESTION SECTION:
;google.com.			IN	A

;; ANSWER SECTION:
google.com.		300	IN	A	216.58.201.78

;; AUTHORITY SECTION:
google.com.		172796	IN	NS	ns2.google.com.
google.com.		172796	IN	NS	ns4.google.com.
google.com.		172796	IN	NS	ns1.google.com.
google.com.		172796	IN	NS	ns3.google.com.

;; ADDITIONAL SECTION:
ns1.google.com.		172796	IN	A	216.239.32.10
ns2.google.com.		172796	IN	A	216.239.34.10
ns3.google.com.		172796	IN	A	216.239.36.10
ns4.google.com.		172796	IN	A	216.239.38.10
ns1.google.com.		172796	IN	AAAA	2001:4860:4802:32::a
ns2.google.com.		172796	IN	AAAA	2001:4860:4802:34::a
ns3.google.com.		172796	IN	AAAA	2001:4860:4802:36::a
ns4.google.com.		172796	IN	AAAA	2001:4860:4802:38::a

;; Query time: 3188 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; MSG SIZE  rcvd: 331

Úprava/vytvoření souborů /etc/bind/domena.cz.zone, /etc/bind/named.conf.zones, /etc/bind/named.conf.local

root@ns1:~# cat /etc/bind/domena.cz.zone 
$ORIGIN domena.cz.
$TTL 3600
@     IN     SOA    dns.domena.cz.     root.domena.cz. (
                    2020051301 ; serial
                    3600       ; refresh after 1 hour
                    1800       ; retry after 30 min
                    604800     ; expire after 1 week
                    3600 )     ; minimum TTL of 1 hour

             IN     NS     ns1.domena.cz.
             IN     MX     10     mx.domena.cz.
             IN     A       10.10.0.183
ns1          IN     A       10.10.0.183
mx           IN     A       10.10.0.183

raz          IN     A       10.10.0.1
dva          IN     A       10.10.0.2
tri          IN     A       10.10.0.3
;-------------------------------------------
$ORIGIN test.domena.cz.
@            IN     NS      ns2.test.domena.cz.
ns2          IN     A       10.10.0.159

root@ns1:~# cat /etc/bind/named.conf.zones 
zone "domena.cz" IN {
  type master;
  file "/etc/bind/domena.cz.zone";
  allow-update { none; };
};

root@ns1:~# cat /etc/bind/named.conf.local 
include "/etc/bind/named.conf.zones";

Test:

root@ns1:~# dig @127.0.0.1 ns1.domena.cz. a

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 ns1.domena.cz. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61970
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 74b995e627ea386dddd4a7bf5ebbffc3835b73d7f72a6ba4 (good)
;; QUESTION SECTION:
;ns1.domena.cz.			IN	A

;; ANSWER SECTION:
ns1.domena.cz.		3600	IN	A	10.10.0.183

;; AUTHORITY SECTION:
domena.cz.		3600	IN	NS	ns1.domena.cz.

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; MSG SIZE  rcvd: 100

Stroj ns2 (10.10.0.159):

Instalace stejná.

Úprava/vytvoření souborů /etc/bind/domena.cz.zone, /etc/bind/named.conf.zones, /etc/bind/named.conf.local

root@ns2:~# cat /etc/bind/test.domena.cz.zone 
$ORIGIN test.domena.cz.
$TTL 3600
@     IN     SOA    ns2.test.domena.cz.     root.domena.cz. (
                    2020051301 ; serial
                    3600       ; refresh after 1 hour
                    1800       ; retry after 30 min
                    604800     ; expire after 1 week
                    3600 )     ; minimum TTL of 1 hour

             IN     NS     ns2.test.domena.cz.
             IN     MX     10    mx.domena.cz.
             IN     A       10.10.0.159
ns2          IN     A       10.10.0.159

jedenact     IN     A       10.10.0.11
dvanact      IN     A       10.10.0.12
trinact      IN     A       10.10.0.13

root@ns2:~# cat /etc/bind/named.conf.zones
zone "test.domena.cz" IN {
  type master;
  file "/etc/bind/test.domena.cz.zone";
  allow-update { none; };
};

root@ns2:~# cat /etc/bind/named.conf.local
include "/etc/bind/named.conf.zones";

Test:

root@ns2:~# dig @127.0.0.1 test.domena.cz. ns

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @127.0.0.1 test.domena.cz. ns
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29523
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 935260d59b13992083aec8d45ebc04b68e9b4fd545d1e259 (good)
;; QUESTION SECTION:
;test.domena.cz.			IN	NS

;; ANSWER SECTION:
test.domena.cz.		3600	IN	NS	ns2.test.domena.cz.

;; ADDITIONAL SECTION:
ns2.test.domena.cz.	3600	IN	A	10.10.0.159

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)

A teď z jiného stroje.

user@jinde:~$ dig @10.10.0.183 raz.domena.cz. a

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @10.10.0.183 raz.domena.cz. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 28980
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: f8e9ee4c53f5dd11ddd80b515ebc0515d95957102a2c31e1 (good)
;; QUESTION SECTION:
;raz.domena.cz.			IN	A

;; ANSWER SECTION:
raz.domena.cz.		3600	IN	A	10.10.0.1

;; AUTHORITY SECTION:
domena.cz.		3600	IN	NS	ns1.domena.cz.

;; ADDITIONAL SECTION:
ns1.domena.cz.		3600	IN	A	10.10.0.183

;; Query time: 2 msec
;; SERVER: 10.10.0.183#53(10.10.0.183)
;; MSG SIZE  rcvd: 120


user@jinde:~$ dig @10.10.0.183 jedenact.test.domena.cz. a

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @10.10.0.183 jedenact.test.domena.cz. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56918
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 90a640f32a6000d66666db365ebc055733a6541a7d33bfe2 (good)
;; QUESTION SECTION:
;jedenact.test.domena.cz.	IN	A

;; ANSWER SECTION:
jedenact.test.domena.cz. 3240	IN	A	10.10.0.11

;; AUTHORITY SECTION:
test.domena.cz.		3600	IN	NS	ns2.test.domena.cz.

;; ADDITIONAL SECTION:
ns2.test.domena.cz.	3233	IN	A	10.10.0.159

;; Query time: 4 msec
;; SERVER: 10.10.0.183#53(10.10.0.183)
;; MSG SIZE  rcvd: 130

user@jinde:~$ dig @10.10.0.159 dvanact.test.domena.cz. a

; <<>> DiG 9.11.5-P4-5.1-Debian <<>> @10.10.0.159 dvanact.test.domena.cz. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 51798
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 48b6313f8c5bf3016055b4c95ebc075def11fd912e0e1b01 (good)
;; QUESTION SECTION:
;dvanact.test.domena.cz.		IN	A

;; ANSWER SECTION:
dvanact.test.domena.cz.	3600	IN	A	10.10.0.12

;; AUTHORITY SECTION:
test.domena.cz.		3600	IN	NS	ns2.test.domena.cz.

;; ADDITIONAL SECTION:
ns2.test.domena.cz.	3600	IN	A	10.10.0.159

;; Query time: 3 msec
;; SERVER: 10.10.0.159#53(10.10.0.159)
;; MSG SIZE  rcvd: 129

[MMMMMMMMM]

Díky, že sis dal tu práci. Zkopíroval jsem nastavení a zónové soubory, jedinou změnu jsem provedl u IP adres podle skutečných serverů v síti. Bohužel to u mne nefunguje. :/ Až budu mít prostor, rozjedu si výchozí konfiguraci named.conf a zkusím to znovu. Pokud by to začalo fungovat, začnu přidávat parametry, co mám nastaveny v named.conf pro naši síť a uvidíme, zda zjistím, co za to může. Používám tu různé acl a views, mám tu i slave NS, ale to by snad nemělo mít vliv na to, jak tohle (ne)funguje. Jinak jde o standardní named v Centos 7.

user@moje:~$ dig @10.0.0.1 jedenact.test.domena.cz. a

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.2 <<>> @10.0.0.1 jedenact.test.domena.cz. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22252
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jedenact.test.domena.cz.       IN      A

;; Query time: 22 msec
;; SERVER: 10.0.0.1#53(10.0.0.1)
;; WHEN: St kvě 13 18:13:18 CEST 2020
;; MSG SIZE  rcvd: 52

user@moje:~$ dig @10.0.0.2 jedenact.test.domena.cz. a

; <<>> DiG 9.11.4-P2-RedHat-9.11.4-16.P2.el7_8.2 <<>> @10.0.0.2 jedenact.test.domena.cz. a
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23945
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;jedenact.test.domena.cz.       IN      A

;; ANSWER SECTION:
jedenact.test.domena.cz. 3600   IN      A       10.10.0.11

;; AUTHORITY SECTION:
test.domena.cz.         3600    IN      NS      ns2.test.domena.cz.

;; ADDITIONAL SECTION:
ns2.test.domena.cz.     3600    IN      A       10.0.0.2

;; Query time: 1 msec
;; SERVER: 10.0.0.2#53(10.0.0.2)
;; WHEN: St kvě 13 18:13:26 CEST 2020
;; MSG SIZE  rcvd: 102

[Filip Jirsák]

Bohužel to u mne nefunguje.

Důležité je zjistit, co přesně nefunguje. Zkoušel váš poslat dotaz na 10.0.0.2? Nebo rovnou odpovídal sám? A pokud sám, byla to odpověď z cache nebo ze zóny?