Bind reverse DNS beállítás

Linux-kezdő

Sziasztok!

Egy újabb problémával fordulok hozzátok. Sehogy nem sikerül beállítanom egy debian etch alatt a reverse dns-t. Látszólag működik, de gyakorlatban mégsem... Meg tudná valaki nézni ezt a szkriptet, hogy mi a franc baja lehet? Ugyanis a t-online mail szervere azt mondja, hogy nem jó a dns reverse. Köszi.

named.conf-ba a zónabeállítás:

zone "ip_cím_visszafele.in-addr.arpa" {
type master;
file "/etc/bind/db.ip_cím";
}

db.ip_cím fájl tartalma:

$TTL 604800
@ IN SOA domain_név. postmaster.domain_név. (
5 ; Serial
604800 ; Refresh
86400 ; Retry
2419200 ; Expire
604800 ) ; Negative Cache TTL
;
@ IN NS ns1.domain_név.
@ IN NS ns2.domain_név.

ip_cím IN PTR domain_név.

  • 4859 megtekintés

( x-daemon | 2008. 05. 16., p – 22:44 )

named.conf:

acl acl_update_key {
localhost;
key DHCP_UPDATER; // ha van dhcp update
};

zone "168.192.IN-ADDR.ARPA" {
type master;
file "168.192.IN-ADDR.ARPA";
allow-update { acl_update_key; };
};

/var/cache/bind/168.192.IN-ADDR.ARPA:

$ORIGIN .
$TTL 86400 ; 1 day
168.192.IN-ADDR.ARPA IN SOA ns1.domain.hu. hostmaster.domain.hu. (
2001198772 ; serial
28800 ; refresh (8 hours)
7200 ; retry (2 hours)
604800 ; expire (1 week)
86400 ; minimum (1 day)
)
NS ns1.domain.hu.
NS ns2.domain.hu.
$ORIGIN 0.168.192.IN-ADDR.ARPA.
0 PTR net.domain.hu.
255 PTR bcast.domain.hu.

Aha. Köszi. Csak a baj az, hogy nem segített ki. Arra időközben rájöttem, hogy a PTR rekordoknál is visszafele kell írni az ip címet.

Úgy már ha a linux alatt kiadom a "host ip_cím" parancsot, kiírja a domain nevet. De kifele ez még mindig nem működik.
Kell ennek valami speciális port, hogy működjön?

#netstat -plan | grep named
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN 12345/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 12345/named
udp 0 0 0.0.0.0:53 0.0.0.0:* 12345/named
udp 0 0 0.0.0.0:33484 0.0.0.0:* 12345/named
unix 3 [ ] STREAM CONNECTED 54321 12345/named

latszik-e, leginkabb az udp 0 0.0.0.0:53 ami kell

Nekem ez jön le:

tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 14663/named
tcp 0 0 ip_cím:53 0.0.0.0:* LISTEN 6339/named
tcp 0 0 127.0.0.1:53 0.0.0.0:* LISTEN 6339/named
tcp 0 0 127.0.0.1:953 0.0.0.0:* LISTEN 6339/named
tcp6 0 0 :::53 :::* LISTEN 14663/named
tcp6 0 0 ::1:953 :::* LISTEN 14663/named
tcp6 0 0 :::53 :::* LISTEN 6339/named
tcp6 0 0 ::1:953 :::* LISTEN 6339/named
udp 0 0 ip_cím:53 0.0.0.0:* 6339/named
udp 0 0 127.0.0.1:53 0.0.0.0:* 6339/named
udp 0 0 0.0.0.0:32934 0.0.0.0:* 14663/named
udp 0 0 0.0.0.0:32876 0.0.0.0:* 6339/named
udp6 0 0 :::53 :::* 6339/named
udp6 0 0 :::32935 :::* 14663/named
udp6 0 0 :::53 :::* 14663/named
udp6 0 0 :::32877 :::* 6339/named
unix 2 [ ] DGRAM 317278 14663/named
unix 2 [ ] DGRAM 300084 6339/named

( piedone | 2008. 05. 16., p – 23:12 )

Egyszerűen nem értem, hogy mi a franc lehet a baja.

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-05-16 21:17 UTC
Note: Host seems down. If it is really up, but blocking our ping probes, try -P0
Nmap finished: 1 IP address (0 hosts up) scanned in 2.035 seconds
root@test:/home/user# nmap -sU 91.120.30.177 -p53 -P0

Starting Nmap 4.11 ( http://www.insecure.org/nmap/ ) at 2008-05-16 21:17 UTC
Interesting ports on 91.120.30.177:
PORT STATE SERVICE
53/udp open|filtered domain

Nmap finished: 1 IP address (1 host up) scanned in 2.030 seconds

azon túl, hogy a post időpontjában tök más probléma volt a bind-el vagy a tűzfallal sokkal prózaibb a dolog bármily meglepő:

$ dig ns 177.30.120.91.in-addr.arpa

; <<>> DiG 9.3.4 <<>> ns 177.30.120.91.in-addr.arpa
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 10197
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;177.30.120.91.in-addr.arpa. IN NS

;; AUTHORITY SECTION:
120.91.in-addr.arpa. 8924 IN SOA nsauth.datanet.hu. postmaster.datanet.hu. 2008051706 28800 7200 604800 86400

a zóna nincs delegálva erre az ns-re, legegyszerübb ha írsz a datanet.hu hostmasternek és beállítják neked a reverse dns-t.

Attól függ mire érted, hogy "ettől még működnie kellene", maga a reverse dns-e a ennek az ip-nek csak akkor fog működni, ha a datanet csinál vele valamit. Két lehetősége van delegálja az ns-t, vagy beállítja maga. Ebben a formában a ripe ezt a zónát nem fogadná el, így a datanet visszadobná a labdát. Így a legegyszerübb és leggyorsabb, ha ők állítják be, vagy mielőtt delegálást kérne rá javítaná a zónát a ripe ajánlásnak megfelelően.

arra ertem hogy ha konkretan ettol a dns szervertol kerek le valamit, akkor neki valaszolnia kellene. az hogy erre a kerdesre csak o tudja a valaszt az egesz interneten az nem gond. ha o mar tud valaszolni utana lehet delegalni a zonat.
ennek a parancsnak jo eredmenyt kellene produkalni:
#host 91.120.30.177 91.120.30.177

arra 2-3 query-re válaszolt is amit lekérdeztem, szerintem az egyik előző kérdésedre pontatlan volt az eredeti válasz, mert ott kb nem ez az ns adta a "does not exist"-et hanem valamelyik másik (egyszerübben megfogalmazva: host 91.120.30.177 ;))

(amúgy a ttl-en,serial-on kicsit alakítani kéne ahhoz hogy ripe elfogadja a zónát, ha delegálásról lenne szó)

Ez az open|filtered egy érdekes eredmény. Az Nmap akkor szokott ilyet dobni, ha a port nyitva van ugyan, de a próbára nem kap vissza választ. Vagy azért, mert nem fut semmi, csak nyitott a port, vagy azért, mert a választ valami eldobja/lenyeli/szűri stb.

--------------------------------------------------------------
"Tegnap reggel addig röhögtünk a főnök viccén, míg ki nem derült, hogy az a napi feladat."