Fórum Root.cz
Hlavní témata => Server => Téma založeno: Rhinox 05. 11. 2022, 23:17:49
-
Tohle opravdu nechapu: bind mi vraci spatnou IP-adresu pro jednu domenu, a nechapu proc. Koukam na zonovej soubor, tam je vse jasne:
@ IN A <SPRAVNA_IP>
Pro jistotu sem vsechno znovu natahl do bind:
rndc reload
server reload successful
A kdyz pak skusim dotaz, dostanu nespravnou odpoved:
dig @localhost mojedomena.tld A
;; QUESTION SECTION:
;mojedomena.tld. IN A
;; ANSWER SECTION:
mojedomena.tld. 36000 IN A <JINA_IP>
Kde muze byt chyba?
-
Naslouchá na localhostu opravdu ten bind?
-
Ano, nasloucha (predpokladam, ze kdyby tam zadnej bind nenaslouchal, asi bych nedostal zadnou odpoved). Pres IP-adresu je to to same. Taky sem skusil vzdalene z jineho systemu...
-
A neni to dynamicka zona? Dnes to neni v bindu jen o statickem souboru, ale o dalsich srandach jako journaly. Mrkni, jestli okolo nemas soubory napr mojezona.jnl. Pokud je to dynamicka zona a je freeznuta, muzes menit co chces, bere to z toho freeznuteho stavu
-
Je to staticka zona, jen par zaznamu. Zadnej journal tam (/etc/bind) nevidim, resp. nevim kde jej mam hledat. Mam dva takove jednoduche zonove soubory, jinej jenom nazev domeny, "diff" nenajde zadnej rozdil. Jenze jedna zona funguje spravne, druha ne. Nechapu!
Mne to prijde, ze bind ma nekde nakou cache a bere z ni stare zaznamy, jen nechapu jak je mozne ze to prezije "rndc reload", dokonce i restart samotnyho demonu...
-
A když restartuješ démona, co je v logu? Není tam nějaká anomálie? Mělo by tam být info o nahraných zónách...
-
Ano, nasloucha (predpokladam, ze kdyby tam zadnej bind nenaslouchal, asi bych nedostal zadnou odpoved). Pres IP-adresu je to to same. Taky sem skusil vzdalene z jineho systemu...
Ne, kdyby tam nenaslouchal, může tam naslouchat něco jiného, třeba systemd-resolved, který vám může vracet adresu z veřejného internetu nebo nakešovaný záznam.
Které procesy naslouchají na jakém UDP portu zjistíte příkazem
ss -nlup
-
@ odkazuje na aktualne nastaveny $ORIGIN. Ukazte nam domenovy soubor od zacatku az po uvedeny zaznam + konfiguraci bindu pro tuto zonu + plny vypis digu vcetne plnych parametru. Problemu v konfiguraci muze byt cela rada (spatny origin, neplatna zona, nenactena zona - chybejici v konfiguraci, bind neposlouchajici na portu 53 na dotazovane IP, ...) a informaci mame malo.
-
zonovej soubor zacina:
; BIND data file for mydomain.tld
$TTL 3600
@ IN SOA myhost.mydomain.tld. root.mydomain.tld. (
2022110401
14400
3600
604800
86400 )
IN A <IP>
Nevim co by tam mohlo byt spatne, takhle to mam u vsech domen. Bind ma konfiguraci:
zone "mydomain.tld" {
type master;
file "db.mydomain.tld";
inline-signing yes;
auto-dnssec maintain;
key-directory "/etc/bind/keys";
allow-transfer { slavedns; };
};
Taky mi to pripada v poradku, a stejne jako u dalsich 5 domen. A vypis z dig-u:
dig @localhost mydomain.tld A
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> @localhost mydomain.tld A
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48015
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 5a746739be6907a52cda1be5636815bb2026567bf32814c9 (good)
;; QUESTION SECTION:
;mydomain.tld. IN A
;; ANSWER SECTION:
mydomain.tld. 36000 IN A <WrongIP>
;; AUTHORITY SECTION:
<jmenne servery, tady vsechno v poradku>
;; ADDITIONAL SECTION:
<prevod fqdn na IP pro jmenne servery, taky vsechno v poradku>
Naprosto stejne to mam jeste u jedne domeny, kde to funguje v poradku. Nechapu...
-
Jestli dobře vidím, máte tam defaultní TTL 3600 (a u záznamu samotného hodnota není), ale v odpovědi je 36000, takže bych se také přikláněl k názoru, že ta odpověď pochází buď z jiného serveru nebo z jiného zónového souboru. Pro začátek bych se asi zkusil stejným příkazem zeptat na SOA záznam, to by při troše štěstí mohlo něco napovědět.
-
dig @localhost mydomain.tld SOA
; <<>> DiG 9.11.5-P4-5.1+deb10u8-Debian <<>> @localhost mydomain.tld SOA
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42907
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 7
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: 31796cbe2095d84624c3c1b3636828500d40288c02ff132d (good)
;; QUESTION SECTION:
;mydomain.tld. IN SOA
;; ANSWER SECTION:
mydomain.tld. 36000 IN SOA myhost.mydomain.tld. root.mydomain.tld. 2022061645 14400 3600 604800 86400
Tohle byl asi dobrej tip, protoze tam vidim jinej serial! Jak je to mozne, a odkud se to vzalo?
-
Napadají mne z hlavy dvě věci, co bych vyzkoušel: (1) zkusit místo "localhost" explicitně dát 127.0.0.1 (nebo ::1), jeden nikdy neví; (2) podívat se do logu, BIND by měl při startu nebo reloadu zóny vypsat něco jako "... zone mk-sys.cz/IN: loaded serial 2015020901". V každém případě ta kulatá (a pořád stejná) hodnota TTL v odpovědi naznačuje, že odpověď pochází od někoho, kdo je (nebo se aspoň považuje za) autoritativní nameserver pro danou doménu, ne od nějakého zprostředkovatele.
-
Tohle byl asi dobrej tip, protoze tam vidim jinej serial! Jak je to mozne, a odkud se to vzalo?
No a už víte, kterého serveru se reálně dotazujete? Nebo pořád jen doufáte, že je to ten, kde děláte změny?
Dále, až budete vědět, že opravdu komunikujete s vaším serverem, bych zvýšil úroveň logování bindu. Při vysoké úrovni logování bude určitě vypisovat, odkud načítá zónové soubory, jaké na něj přicházejí požadavky i něco o tom, proč odpovídá tak, jak odpovídá.