Bind9 + RFC2317 (BCP20) = Problem

[MaverrickTM]

Hallo zusammen,

ich hab hier ein etwas anspruchsvolleres Problem zu bieten, bei dem ich derzeit nicht wirklich mehr weiter komme.

Unser Provider wird demnächst (hoffentlich) die Reverselookup Zone, unseres IP-Netzes, an uns weiter delegieren. Diese Delegierung müssen wir ja irgendwie entgegen nehmen. Hierzu sagt ja das RFC2317 mehr als genug aus. Nur leider scheint es bei mir nicht zu funktionieren.

Bind Version: 9.5.1

Die rekusive Abfrage von extern ist verboten.

bei dem Subnetz handelt es sich um folgendes:

xxx.xxx.225.208/28

Die gleiche Config, eines 24er Subnetzes, funktioniert wunderbar. Es muss also an dem Teilsubnetz bzw. der Umsetzung des RFC2317 liegen. Die Frage ist warum Bind keine passende Antwort gibt bzw. was ich vergessen / übersehen habe. Wenn ich Bind erlaube nach extern cached informationen zu verteilen, dann antwortet er mir mit der Liste der root-server.

Ansonsten startet der Bind ordentlich und meldet das er sich zuständig für die Reverselookup Zone fühlt.

Eventuell kann mir jemand den entscheidenen Tipp geben, denn ich scheine den Wald vor lauter Bäumen nicht mehr zu sehen :upps

Entgegennahme der delegierung:

zone "208/28.225.xxx.xxx.in-addr.arpa" IN {

        type master;

        file "/etc/bind/external/master.xxx.xxx.225";

        allow-transfer { "dns_slaves_ext"; };

};

Zonefile:

$TTL    1h                              ; Zone TTL

@       IN      SOA     ns00.sld.tld.     hostmaster.sld.tld. (

                        2010060700      ; Serial

                        10m             ; Refresh

                        5m              ; Retry

                        30m             ; Expire

                        30m             ; Negative Caching TTL

)



;

; Nameserver der Domain (NS Records)

;


@     IN      NS      ns00.sld.tld.

@     IN      NS      ns01.sld.tld.



;

; Pointer Eintraege (PTR Records)

;


;208    IN      PTR     Netzname

;209    IN      PTR     <XXXXXX gateway>

210     IN      PTR     host.sld.tld.

;211    IN      PTR

;212    IN      PTR

213     IN      PTR     ns00.sld.tld.

214     IN      PTR     ns01.sld.tld.

;215    IN      PTR

;216    IN      PTR

;217    IN      PTR

;218    IN      PTR

;219    IN      PTR

;220    IN      PTR

;221    IN      PTR

;222    IN      PTR

;223    IN      PTR     Broadcast

nslookup:

Z:\>nslookup -querytype=ptr xxx.xxx.225.214 ns00.sld.tld.

Server:  UnKnown

Address:  xxx.xxx.225.213


*** 214.225.xxx.xxx.in-addr.arpa. wurde von UnKnown nicht gefunden: Query refused

dig:

[root@srv01 ~]# dig @ns00.sld.tld. ptr xxx.xxx.225.214


; <<>> DiG 9.3.6-P1-RedHat-9.3.6-4.P1.el5_4.2 <<>> @ns00.sld.tld. ptr xxx.xxx.225.214

; (1 server found)

;; global options:  printcmd

;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 5446

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0


;; QUESTION SECTION:

;xxx.xxx.225.214.                        IN      PTR


;; Query time: 21 msec

;; SERVER: xxx.xxx.225.213#53(xxx.xxx.225.213)

;; WHEN: Mon Jun  7 15:57:07 2010

;; MSG SIZE  rcvd: 32

logfile ns00:

Jun  7 15:44:22 ns00 named[10102]: client xxx.xxx.62.238#20409: view external: query (cache) '213.225.xxx.xxx.in-addr.arpa/PTR/IN' denied

Jun  7 15:44:22 ns00 named[10102]: client xxx.xxx.62.238#36190: view external: query (cache) '214.225.xxx.xxx.in-addr.arpa/PTR/IN' denied

Schonmal vielen Dank für die Hinweise / Tipps

MfG Mav

Bearbeitet 7. Juni 2010 von MaverrickTM

[lordy]

Du hast die RFC zwar gelesen, aber nicht verstanden

Dein Nameserver kann die normale in-addr.arpa Notation nicht auflösen, da du ihn ja für eine Classless-Delegation konfiguriert hast. Du mußt ihn also eher nach soetwas fragen:

210.208/28.225.xxx.xxx.in-addr.arpa

Das müsste er auflösen können. Dein Provider setzt dann einen CNAME in 225.xxx.xxx.in-addr.arpa:

210 IN CNAME 210.208/28

was dann dafür sorgt, das die Welt deinen Nameserver fragt.

[MaverrickTM]

Danke für dein Post

definiere mal bitte "fragen" in deinem context. Ich verstehe leider nicht wie genau du das meinst.

MfG Mav

[MaverrickTM]

Sry wegen doppelpost. Kann oben nix editieren.

Du hast recht. Nu sehe ich es :upps

Nicht mein NS wird nach xxx.xxx.225.214 gefragt sondern der des Providers. :upps

Der besitzt nen CNAME-Record der auf unseren Nameserver verweisst und dort auf den PTR-Record 214 der Zone 208/28.xxx.xxx.in-addr.arpa. zeigt. Dieser enthält dann die entsprechende Information.

:upps

Danke für die Erleuchtung!

MfG Mav

[lupo49]

Dein Nameserver kann die normale in-addr.arpa Notation nicht auflösen, da du ihn ja für eine Classless-Delegation konfiguriert hast. Du mußt ihn also eher nach soetwas fragen:

210.208/28.225.xxx.xxx.in-addr.arpa

Kannst du das mit der Classless-Delegation in Verbindung mit Bind näher erläutern? Wie würde es ohne Classless-Delegation aussehen?

Sollte die Abfrage "nslookup -querytype=ptr xxx.xxx.225.214 ns00.sld.tld." nicht funktionieren, wenn direkt der NS gefragt wird?

Edit: Dadurch, dass durch die CNAME-Records die Anfrage innerhalb von Adressbereichen an unterschiedliche Nameserver delegiert werden können, wird es Classless genannt. Siehe Abschnitt 3 Motivation im o.g. RFC.

Bearbeitet 7. Juni 2010 von lupo49

[MaverrickTM]

Irgend ein Client wird den PTR eintrag zu xxx.xxx.255.214 abfragen. Jedoch tut er das nicht direkt bei dem dafür zuständigen NS sondern landet erst beim NS des Providers. Dieser hat nun das 24er Subnetz in mehrere aufgeteilt. Das heisst er erstellt mehrere Subdomains in der zone 255.xxx.xxx.-in-addr.arpa.

In meinem Fall wäre die Subdomain meiner reverselookup-zone:

208/28 in der Zone 255.xxx.xxx.in-addr.arpa.

Dort existieren dann CNAME einträge die abgefragt werden. Also 214.225.xxx.xxx.in-addr.arpa wäre einer dieser Einträge.

Dieser CNAME record zeigt dann auf 214.208/28.255.xxx.xxx.in-addr.arpa.

214.208/28.255.xxx.xxx.in-addr.arpa. ist dann der PTR-Record der auf ns00.sld.tld liegt und die antwort geben kann.

Ich hoffe ich konnte das ordentlich erklären. Ist nämlich nicht ganz einfach zu verstehen.

[EDIT]

Der Provider delegiert also nicht direkt das "Subnetz" an ns00.sld.tld weiter sondern er delegiert eine neue Subdomain (208/28) in der Zone (225.xxx.xxx.in-addr.arpa) an ns00.sld.tld und die eigentlichen PTR einträge des Providers werden mit CNAME einträge ausgetauscht die auf PTR Einträge der neuen Subdomain zeigen.

[/EDIT]

MfG Mav

Bearbeitet 7. Juni 2010 von MaverrickTM