Autoritativní DNS server Bind pro PTR

[tridster]

Dobrý den,

rád bych požádal o radu ohledně bind serveru. Je možné že jsem jen dosud nepochopil souvislosti, ale třeba mi to dojde po této diskuzi.

Mám dva autoritativní name servery,  oba mají bind 9.13. Nejsou ve vztahu master-slave, jsou oba master a každý se konfiguruje zvlášť, ale v zásadě je ten konfig stejný. Proč to tak je, bych teď nerad probíral.

Servery jsou veřejné a hostují zakoupené zóny. Od poskytovatele internetu mám i delegaci pro PTR, tudíž hostuji i PTR zónu pro moje veřejné adresy.

V bindu mám explicitně řečeno na obou serverech:

Kód: [Vybrat]

allow-query { any; };

Nicméně, v logu obou bind serverů vidím:

Kód: [Vybrat]

query REFUSED
na jakýkoli PTR dotaz, dokud nepovolím rekurzi:

Kód: [Vybrat]

recursion yes;
Je toto správné chování. Nebo mám prostě jen špatně nadefinovanou tu reverzní zónu? Spíš mi jde o tu úvahu. Případně konfig mohu zaslat taky.

Díky za jakoukoli reakci.

[Reklama]

[Milan Cagap]

Zdravim,

z mojich skusenosti autoritativny server pri dotaze hlada, ci mu existuje v zozname zon spravna zona.
Ak vidi, ze dotaz je na x.y.z.in-addr.arpa, tak hlada zonovy subor pre dany ip rozsah.
Ak je totaz na abc.domen.xyz, tak hlada zaznam v zone pre danu domenu.

Diretiva allow-query { any; };  postacuje na to, aby dotaz server spracoval.
recursion yes; - je pouzita, ak dany server okrem autoritativneho servra, robi aj rekurzor pre klientov.

Avsak tu treba este povolit z akych ip ma na dotazy odpovedat.

Kód: [Vybrat]

allow-recursion {
127.0.0.0/8;
192.168.0.0/16;
};

priklad zon pre localhost

Kód: [Vybrat]

zone "127.in-addr.arpa" {
          type master;
          file "/etc/bind/db.127";
};

zone "localhost" {
         type master;
         file "/etc/bind/db.local";
};

subor: db.127

Kód: [Vybrat]

;
; BIND reverse data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              1         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
1.0.0   IN      PTR     localhost.

subor: db.local

Kód: [Vybrat]

;
; BIND data file for local loopback interface
;
$TTL    604800
@       IN      SOA     localhost. root.localhost. (
                              2         ; Serial
                         604800         ; Refresh
                          86400         ; Retry
                        2419200         ; Expire
                         604800 )       ; Negative Cache TTL
;
@       IN      NS      localhost.
@       IN      A       127.0.0.1
@       IN      AAAA    ::1

Ak mate v logu hlasky refused pri dotazoch na PTR zaznam. Tak mozu byt, but z dotazov na rekurzor, alebo je zle definovana zona pre PTR subor. Treba si skontrolovat ci je spravne nazvana zona pre PTR.

IP rozsah 192.168.0.0/24 musi byt definovany pre PTR zonu ako "0.168.192.in-addr.arpa"

[tridster]

Díky moc za komentář. Problém je, že se jedná o veřejný rozsah, kdy samozřejmě, já nejsem vlastníkem celého Cčka ale mám jen část:

tzn v RIPE je pro ZZZ.YYY.XXX.0/24 uvedena zona XXX.YYY.ZZZ.in-addr.arpa je na NS providera. Provider nastavil delegaci pro:

Kód: [Vybrat]

128/27.XXX.YYY.ZZZ.in-addr.arpa nameserver ns01.mujserver.xz
128/27.XXX.YYY.ZZZ.in-addr.arpa nameserver ns02.mujserver.xz
A CNAME pro všechny moje přidělené adresy:

Kód: [Vybrat]

129.XXX.YYY.ZZZ.in-addr.arpa.  64322   CNAME   129.128/27.XXX.YYY.ZZZ.in-addr.arpa.
130.XXX.YYY.ZZZ.in-addr.arpa.  64322   CNAME   129.128/27.XXX.YYY.ZZZ.in-addr.arpa.
...
atd
následně já mám na obou serverech vytvořenou zonu:

Kód: [Vybrat]

128/27.XXX.YYY.ZZZ.in-addr.arpa
ve které už mám ty konkrétní IP adresy a k ním reverzní záznamy ve tvaru:

Kód: [Vybrat]

129   IN   PTR web1.mujserver.cz.
Nicméně dokud nezapnu rekurzi, tak ten server neresolvuje, ale je autoritativní tak hádám, že vlastně i díky té delegaci by měl být jediný, kdo je schopný odpovědět.

Otázka tedy je, jestli je ta delegace správně a jestli v případě té delegace musí být povolena rekurze, ačkoli nechápu proč, nebo prostě ten bind neakceptuje tento zápis, ale to bych zase očekával, že zhavaruje již při restartu služby..

[McFly]

Chtělo by to víc informací o konfiguraci BINDu...

[tridster]

Dobrý den,

konfigurace v named.conf:

Kód: [Vybrat]

options {
        listen-on port 53 { any; };
        listen-on-v6 { any; };
        auth-nxdomain no;
        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";
        dnssec-validation auto;
        allow-transfer { none; };
        allow-query { any; };
};

include "/etc/rndc.key";
include "/etc/named.zones";

controls {
        inet 127.0.0.1 allow { localhost; } keys { "rndc-key"; };
};

statistics-channels {
          inet 10.180.47.104 port 8081 allow { any; };
};

logging {
        channel default_debug {
                file "data/named.run";
                severity dynamic;
        };

        channel dns_log {
                file "/var/log/dns.log";
                severity dynamic;
                print-category yes;
                print-severity yes;
                print-time yes;
        };

        channel queries_log {
                file "/var/log/queries.log";
                severity dynamic;
                print-category yes;
                print-severity yes;
                print-time yes;
        };

        channel security_file {
                file "/var/log/security.log";
                severity dynamic;
                print-time yes;
        };
        channel resolver_file {
                file "/var/log/resolver.log";
                severity dynamic;
                print-time yes;
        };

        category queries  { queries_log; };
        category default  { dns_log; };
        category security { security_file; };
        category resolver { resolver_file; };

};


v named.zones:

Kód: [Vybrat]

zone "128/27.XXX.YYY.ZZZ.in-addr.arpa"  {
  type master;
  file "db.XXX.YYY.ZZZ.in-addr.arpa";
  allow-update { none; };
};

a zone file:

Kód: [Vybrat]

$TTL            600
@               IN      SOA     ns01.mujserver.xz. root.mujserver.xz. ( 2022062001 8H 2H 2W 1D )
@               IN      NS      ns01.mujserver.xz.
@               IN      NS      ns02.mujserver.xz.

129             IN      PTR     web1.mujserver.xz.

[Reklama]

[McFly]

Nemohl by to být tento případ?
https://arstechnica.com/civis/viewtopic.php?t=45878

Kdyby byla zóna definována jako zone "XXX.YYY.ZZZ.in-addr.arpa", mělo by to fungovat, ne?

[messagebus]

Jediny PTR dotaz, ktery v takove konfiguraci ma projit je dotaz na 129.128/27.XXX.YYY.ZZZ.in-addr.arpa. apod. Rikate tedy, ze neprochazi ani tento dotaz?

PTR dotaz primo na 129.XXX.YYY.ZZZ.in-addr.arpa. samozrejme nuti bind k rekurzi.

[Milan Cagap]

Pokial je vacsi rozsah ako /24, tak zona pre ptr sa da zapisat aj ako som uviedol priklad s local hostom.

Cize skratit na YYY.ZZZ.in-addr.arpa.  alebo kludne aj na ZZZ.in-addr.arpa.

a v zonovom subore davat tu cas ip, ktora nie je uvedena v zone in-addr.arpa.

Priklad: rozsah je 192.168.0.0/16, tak zona bude uvedena ako "168.192.in-addr.arpa"

a v samotnom zonovom subore bude zapisana ip 192.168.129.128 ako

Kód: [Vybrat]

128.129             IN      PTR     web1.mujserver.xz.

alebo, ak je zona "192.in-addr.arpa", tak v zonovom subore treba zapisat

Kód: [Vybrat]

128.129.168             IN      PTR     web1.mujserver.xz.

Kedze dns server nevie pracovat s rozsahom mensim ako /24 a ani nepotrebuje...
U vacsieho sa to riesi bud rozdelenim zon na /24 segmenti alebo skratenim addr zaznamu v zone.

[tridster]

Děkuji všem za reakci.

Vskutku pokud tu zonu zkratim z:

Kód: [Vybrat]

128/27.XXX.YYY.ZZZ.in-addr.arpana:

Kód: [Vybrat]

XXX.YYY.ZZZ.in-addr.arpaTak to vážně chodí. Nevím proč mne vlastně takové banální řešení nenapadlo hned. Měl jsem nevím proč za to, že ten zápis zóny musí být stejný jako je v té delegaci u providera.

Děkuji ještě jednou všem.

[messagebus]

A funguje to urcite i pro PTR dotazy na jine DNS servery?

[_mbily]

RFC 2317

[tridster]

Update je takový, že tu změnu jsem byl nakonec nucen revertovat. Pokud jsem se doptal explicitně mého namesereru, tak odpověděl, respektive, občas odpověděl, ale občas jsem měl timeout, ačkoli v logu jsem vždy viděl, že dotaz dorazil.

Nicméně na prostý dotaz bez specifikace name serveru, už jsem žádnout odpověď nedostal.

Čili, jsem zony zpět přejmenoval a opět povolil rekurzi, abych alespoň fungoval.

Díky za to RFC, přečtu si jej v klidu o víkendu.

[messagebus]

Nebylo by lepsi postovat nejake vypisy a logy? (Ale pokud jste sem prisel na kus reci, tak jen tak dal)

Co vam vypise tenhle dotaz s vypnutou rekurzi a konfiguraci uvedenou na zacatku vlakna?

Kód: [Vybrat]

dig @vas.dns.server -t ptr 129.128/27.XXX.YYY.ZZZ.in-addr.arpa.

[jvb]

Nebylo by lepsi postovat nejake vypisy a logy? (Ale pokud jste sem prisel na kus reci, tak jen tak dal)

Co vam vypise tenhle dotaz s vypnutou rekurzi a konfiguraci uvedenou na zacatku vlakna?

Kód: [Vybrat]

dig @vas.dns.server -t ptr 129.128/27.XXX.YYY.ZZZ.in-addr.arpa.

Ahoj, presne jak pise kolega vyse. Tema jsem proletel trochu v rychlosti, ale podle me jsi to mel nastavene zcela spravne, jen ses neumel na konci toho sveho NS zeptat a nutil jsi ho dotazem k rekurzi.

Priklad jak jsem kdysi davno resil to stejne:

named.conf

Kód: [Vybrat]

zone "152/29.208.165.193.in-addr.arpa" in {
        type master;
        file "masters/rev/193.165.208.152-29.rev.db";
};

193.165.208.152-29.rev.db

Kód: [Vybrat]

$ORIGIN 152/29.208.165.193.in-addr.arpa.
@ IN SOA ... snip ....

158 PTR mail.uniscomp.cz.






Takhle se zeptas sveho ns

Kód: [Vybrat]

dig PTR 158.152/29.208.165.193.in-addr.arpa @ns1.uniscomp.cz

; <<>> DiG 9.18.3 <<>> PTR 158.152/29.208.165.193.in-addr.arpa @ns1.uniscomp.cz
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62887
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: a5720edb79b6cb530f5fe01362b5a28b13877b82eaba53f8 (good)
;; QUESTION SECTION:
;158.152/29.208.165.193.in-addr.arpa. IN PTR

;; ANSWER SECTION:
158.152/29.208.165.193.in-addr.arpa. 86400 IN PTR mail.uniscomp.cz.

;; AUTHORITY SECTION:
152/29.208.165.193.in-addr.arpa. 86400 IN NS ns2.uniscomp.cz.
152/29.208.165.193.in-addr.arpa. 86400 IN NS ns1.uniscomp.cz.
152/29.208.165.193.in-addr.arpa. 86400 IN NS ns3.uniscomp.cz.

;; ADDITIONAL SECTION:
ns1.uniscomp.cz. 60 IN A 193.165.209.171
ns2.uniscomp.cz. 60 IN A 193.165.209.172
ns3.uniscomp.cz. 60 IN A 95.129.102.24

;; Query time: 6 msec
;; SERVER: 193.165.209.171#53(ns1.uniscomp.cz) (UDP)
;; WHEN: Fri Jun 24 13:39:55 CEST 2022
;; MSG SIZE  rcvd: 224



Kód: [Vybrat]

$ dig 158.208.165.193.in-addr.arpa. @1.1 PTR

; <<>> DiG 9.18.4 <<>> 158.208.165.193.in-addr.arpa. @1.1 PTR
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 60062
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;158.208.165.193.in-addr.arpa. IN PTR

;; ANSWER SECTION:
158.208.165.193.in-addr.arpa. 28800 IN CNAME 158.152/29.208.165.193.in-addr.arpa.
158.152/29.208.165.193.in-addr.arpa. 86400 IN PTR mail.uniscomp.cz.

;; Query time: 40 msec
;; SERVER: 1.0.0.1#53(1.1) (UDP)
;; WHEN: Fri Jun 24 13:44:06 CEST 2022
;; MSG SIZE  rcvd: 112