Hallo Liste, heute mal folgendes Problem. Ich habe einen SuSE 8.0 mit BIND 9.2.1 hinter einer SuSEFirewall. Jetzt passiert folgendes eine nslookup/dig domain.tld Anfrage liefert alle Informationen zu den Hosts. Jedoch liefert ein Reverse Lookup auf diese Adresse rein garnichts. Was unter andrem den AOL Servern nicht ganz past. Der Port 53 sowie die Einstellungen in der FW sind alle korrekt gesetzt. Lokal auf dem Server funktioniert der Reverse Lookup. Vielleicht hat jemand von Euch eine Ahnung und kann mir etwas helfen? Gruß Alex
hallo alex,
der reverse lookup wird, wie bei einem A lookup, durch eine
kette von DNS ausgeführt.
dein DNS ist sicher nicht zuständig für eine PTR abfrage
aus dem internet (AOL).
ev. kannst du deinen rpovider dazu bringen, einen PTR
eintrag für deine (FIXE) IP zu erstellen.
ansonsten erhält dein DNS NIE eine anfrage für PTR
aus dem internet.
--
Gruss
Thomas
hoffentlich jetzt richtig :-(
----- Original Message -----
From: "Alexander Reuther"
Hallo Liste,
heute mal folgendes Problem. Ich habe einen SuSE 8.0 mit BIND 9.2.1 hinter einer SuSEFirewall. Jetzt passiert folgendes eine nslookup/dig domain.tld Anfrage liefert alle Informationen zu den Hosts. Jedoch liefert ein Reverse Lookup auf diese Adresse rein garnichts. Was unter andrem den AOL Servern nicht ganz past.
Der Port 53 sowie die Einstellungen in der FW sind alle korrekt gesetzt. Lokal auf dem Server funktioniert der Reverse Lookup.
Vielleicht hat jemand von Euch eine Ahnung und kann mir etwas helfen?
Gruß Alex
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
hallo alex,
der reverse lookup wird, wie bei einem A lookup, durch eine
kette von DNS ausgeführt.
dein DNS ist sicher nicht zuständig für eine PTR abfrage
aus dem internet (AOL).
ev. kannst du deinen rpovider dazu bringen, einen PTR
eintrag für deine (FIXE) IP zu erstellen.
ansonsten erhält dein DNS NIE eine anfrage für PTR
aus dem internet.
--
Gruss
Thomas
hoffentlich jetzt richtig :-(
----- Original Message -----
From: "Alexander Reuther"
Hallo Liste,
heute mal folgendes Problem. Ich habe einen SuSE 8.0 mit BIND 9.2.1 hinter einer SuSEFirewall. Jetzt passiert folgendes eine nslookup/dig domain.tld Anfrage liefert alle Informationen zu den Hosts. Jedoch liefert ein Reverse Lookup auf diese Adresse rein garnichts. Was unter andrem den AOL Servern nicht ganz past.
Der Port 53 sowie die Einstellungen in der FW sind alle korrekt gesetzt. Lokal auf dem Server funktioniert der Reverse Lookup.
Vielleicht hat jemand von Euch eine Ahnung und kann mir etwas helfen?
Gruß Alex
-- Um die Liste abzubestellen, schicken Sie eine Mail an: suse-linux-unsubscribe@suse.com Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: suse-linux-help@suse.com
Hier etwas mehr informationen
heute mal folgendes Problem. Ich habe einen SuSE 8.0 mit BIND 9.2.1 hinter einer SuSEFirewall. Jetzt passiert folgendes eine nslookup/dig domain.tld Anfrage liefert alle Informationen zu den Hosts. Jedoch liefert ein Reverse Lookup auf diese Adresse rein garnichts. Was unter andrem den AOL Servern nicht ganz past.
Der Port 53 sowie die Einstellungen in der FW sind alle korrekt gesetzt. Lokal auf dem Server funktioniert der Reverse Lookup.
Der Server ist verantwortlich für die öffentlichen Netze/IPs 62.26.xxx.xxx/30 und 62.26.xxx.xxx/28 der Server ist jeweils aus jedem Netz erreichbar. Die Konfiguration der /etc/named.conf: directory "/var/named"; listen-on port 53 { 62.26.xxx.xxx; 62.26.xxx.xxx; }; query-source address * port 53; transfer-source * port 53; notify-source * port 53; zone "domain1.tld" in { type master; file "tld.domain1.zone"; }; zone "domain2.tld" in { type master; file "tld.domain2.zone"; }; zone "xxx.26.62.in-addr.arpa" in { type master; file "62.26.xxx.zone"; }; [...] soweit alles okay. Der Fehler ist auch erst ab dem Zeitpunkt aufgetreten, an dem ein Secondary NS in Betrieb genommen wurde. Der aber nach geltenden Statuten in einem anderem Subnet steht. Komisch ist wie gesagt, dass sowohl, nslookup als auch dig saubere ergebnisse liefern, solgange man sie vom Server aus absetzt, allerdings bekommt man von ausserhalb nur eine Antwort, wenn man auf servname.domain1.tld 'gräbt'. Gruß Alex
*** Alexander Reuther (ml-suse-linux@xtxserve.com) schrieb heute in suse-linux:
Hier etwas mehr informationen [...] Der Server ist verantwortlich für die öffentlichen Netze/IPs 62.26.xxx.xxx/30 und 62.26.xxx.xxx/28
Also kein Class C oder ähnliches... Schonmal den RFC 2317 gelesen? Hat Dein Provider sowas aufgesetzt? Wenn nicht, dann hast Du die Antwort auf Dein "Problem"...
[...]
MfG Henning Hucke -- How many bits would a BitBlit blit if a BitBlit could blit bits? -- macanespie@waves.pas.ti.com in <1993Nov16.130625.1@waves.pas.ti.com>
Tach Henning, anbei der auszug aus der xxx.26.62.in-addr.arpa [...] $TTL 2D xxx.26.62.in-addr.arpa. IN SOA server1.domain1.tld. hostmaster.domain1.tld. ( 2004022601 3600 3600 604800 86400 ) IN NS server1.domain1.tld. IN NS server2.domain1.tld. IN NS server1.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server1.domain1.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server2.domain1.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server1.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server2.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server3.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server4.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server5.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server6.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server7.domain2.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server8.domain3.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server2.domain3.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server3.domain3.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server4.domain3.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server5.domain3.tld. xxx.xxx.26.62.in-addr.arpa. IN PTR server6.domain3.tld. [...]
Schonmal den RFC 2317 gelesen? Hat Dein Provider sowas aufgesetzt? Wenn nicht, dann hast Du die Antwort auf Dein "Problem"...
[...]
MfG Henning Hucke -- How many bits would a BitBlit blit if a BitBlit could blit bits? -- macanespie@waves.pas.ti.com in <1993Nov16.130625.1@waves.pas.ti.com>
*** Alexander Reuther (ml-suse-linux@xtxserve.com) schrieb heute in suse-linux:
Tach Henning,
anbei der auszug aus der xxx.26.62.in-addr.arpa
[...]
Ähmmmm... Du hast Dich aber schon mal mit dem Thema DNS, Bind und Zonen auseinandergesetzt!? Das alles ist unerheblich, solange Dein Provider keine Delegation einge- richtet hat, was ganz offensichtlich auch so der Fall ist. Schlimmer noch: Es scheint dort zwar eine entsprechende Zone aber keinen Inhalt in derselben zu geben...
[...]
Schonmal den RFC 2317 gelesen? Hat Dein Provider sowas aufgesetzt? Wenn nicht, dann hast Du die Antwort auf Dein "Problem"...
Die Antwort steht noch aus. Sigs zitiert man nicht. Danke. Ich finde es ein wenig affig, auf die gezeigte Art und Weise Daten verschleiern zu wollen. Ich habe in zwei Minuten herausgefunden, um welchen IP-Bereich es geht (und anderes). Security by obscurity *ist keine Sicherheit*! Also laß es sein und mach stattdessen Deine Systeme sicher! Gib stattdessen alle Daten mit, die der Fehlersuche hilfreich sind! MfG Henning Hucke -- Heute habe ich mal etwas probiert. Wie es ist, ohne Sex, Drogen und Computer auszukommen. Tja - es war die härteste Viertelstunde meines Lebens ;). Geklaut aber toll. (Uuups. Es ist schon wieder passiert :-})
Am Freitag, 27. Februar 2004 00:03 schrieb Henning Hucke:
Das alles ist unerheblich, solange Dein Provider keine Delegation einge- richtet hat, was ganz offensichtlich auch so der Fall ist. Schlimmer noch: Es scheint dort zwar eine entsprechende Zone aber keinen Inhalt in derselben zu geben...
Am besten mal bei Tiscali Business anrufen und fragen wo der Eintrag für die CIDR Reverse Delegation geblieben ist.
Ich finde es ein wenig affig, auf die gezeigte Art und Weise Daten verschleiern zu wollen. Ich habe in zwei Minuten herausgefunden, um welchen IP-Bereich es geht (und anderes). Security by obscurity *ist keine Sicherheit*! Also laß es sein und mach stattdessen Deine Systeme sicher! Gib stattdessen alle Daten mit, die der Fehlersuche hilfreich sind!
FULL ACK MfG Michael Hoffmann
On Thu, 26 Feb 2004, Alexander Reuther wrote:
Tach Henning,
anbei der auszug aus der xxx.26.62.in-addr.arpa [...]
Abgesehen von der Tatsache, dass Du Deinen named mit einer solchen Zone für einen Bereich für authorized erklärst, für den Du garnicht (vollständig) zuständig bist: Hat es denn nun geklappt? Hat der Provider (vermutlich) ebenfalls Mist gebaut? MG Henning Hucke -- "nobody is perfect." -- Nobody ;)
Am Dienstag, 2. März 2004 13:15 schrieb Henning Hucke:
On Thu, 26 Feb 2004, Alexander Reuther wrote:
Tach Henning,
anbei der auszug aus der xxx.26.62.in-addr.arpa [...]
Abgesehen von der Tatsache, dass Du Deinen named mit einer solchen Zone für einen Bereich für authorized erklärst, für den Du garnicht (vollständig) zuständig bist: Hat es denn nun geklappt? Hat der Provider (vermutlich) ebenfalls Mist gebaut?
Mein Provider hat das gleiche oder ein ähnliches Problem, die basteln noch am Reverseintrag (Ich schreibe seit einem Monat Tickets zu dem Thema). Im Moment sieht er so aus: 141.141-142.154.112.62.in-addr.arpa. Michael
*** Michael Hoffmann (linux@f-j-hoffmann.de) schrieb am Mar 3, 2004 in...:
[...]
((Bitte nicht mehr als 74 Zeichen in einer Zeile schreiben. Danke.))
Mein Provider hat das gleiche oder ein ähnliches Problem, die basteln noch am Reverseintrag (Ich schreibe seit einem Monat Tickets zu dem Thema). Im Moment sieht er so aus: 141.141-142.154.112.62.in-addr.arpa.
Ist doch in Ordnung, wenn Sie es richtig gemacht haben und Du die entsprechende Zone bei Dir aufgesetzt hast. Ich wundere mich nur, dass sie nur *zwei* IP-Adressen erteilt haben. Ich meine, dass es vom RIPE und sogar von DEnic Regeln gibt, dass nie weniger als acht Adressen ausgegeben werden sollen. MfG Henning Hucke -- Morgen war Gestern der Tag nach Heute.
Am Donnerstag, 4. März 2004 00:15 schrieb Henning Hucke:
Mein Provider hat das gleiche oder ein ähnliches Problem, die basteln noch am Reverseintrag (Ich schreibe seit einem Monat Tickets zu dem Thema). Im Moment sieht er so aus: 141.141-142.154.112.62.in-addr.arpa.
Ist doch in Ordnung, wenn Sie es richtig gemacht haben und Du die entsprechende Zone bei Dir aufgesetzt hast.
Die Zone ist bei mir eingetragen, aber die Anfragen kommen nicht bis zum Rootserver.
Ich wundere mich nur, dass sie nur *zwei* IP-Adressen erteilt haben. Ich meine, dass es vom RIPE und sogar von DEnic Regeln gibt, dass nie weniger als acht Adressen ausgegeben werden sollen.
Das ist nur ein Rootserver, mehr nicht, da reichen 2 IPs. :-) Michael
*** Michael Hoffmann (linux@f-j-hoffmann.de) schrieb heute in suse-linux:
[...] Die Zone ist bei mir eingetragen, aber die Anfragen kommen nicht bis zum Rootserver.
"Rootserver"? Ich denke nicht, dass Du einen root server betreibst... Du betreibst einen hidden primary server!?
[...] Das ist nur ein Rootserver, mehr nicht, da reichen 2 IPs. :-)
Du willst mir aber nicht erzählen, dass Du nichts anderes betreibst(?). Außerdem hat es in diesem Fall nicht viel mit den benötigten Adressen zu tun, vielmehr mit dem Verwaltungsaufwand. Aber ändern kann und sollte man es nachträglich eh nichtmehr. Also was solls. Bei solchen Sachen fällt mir immer nur einfach die Kinnlade runter und mein Kopf fängt an, sich von links nach rechts und wieder zurück zu bewegen... MfG Henning Hucke -- Zukunftstraechtiger Beruf? Geschichtenerzaehler! Damit kann man heute noch nicht das grosse Geld verdienen. Aber was denken Sie, werden Eltern ihnen in 20-30 Jahren bezahlen, damit ihre Kinder Ihnen an den Lippen haengen, wenn Sie Geschichten von Nashoernern, Schmetterlingen, Singvoegeln und Delphinen erzaehlen, "die einst die Erde bevoelkerten"!?
Am Donnerstag, 4. März 2004 20:27 schrieb Henning Hucke:
*** Michael Hoffmann (linux@f-j-hoffmann.de) schrieb heute in suse-linux:
[...] Die Zone ist bei mir eingetragen, aber die Anfragen kommen nicht bis zum Rootserver.
"Rootserver"? Ich denke nicht, dass Du einen root server betreibst...
Sicher doch, ich habe einen dedizierter Rootserver bei 1st-housing gemietet. :-)
Das ist nur ein Rootserver, mehr nicht, da reichen 2 IPs. :-)
Du willst mir aber nicht erzählen, dass Du nichts anderes betreibst(?). Außerdem hat es in diesem Fall nicht viel mit den benötigten Adressen zu tun, vielmehr mit dem Verwaltungsaufwand. Aber ändern kann und sollte man es nachträglich eh nichtmehr. Also was solls. Bei solchen Sachen fällt mir immer nur einfach die Kinnlade runter und mein Kopf fängt an, sich von links nach rechts und wieder zurück zu bewegen...
Jo, ich habe ein eigenes /30 :-) Die unterste IP ist Gateway und die oberste Broadcastadresse, dazwischen die zwei nutzbaren IPs. Das nenne ich eine effektive Aufteilung, nur 50% der IPs verschwendet. :-) Michael
participants (4)
-
Alexander Reuther -
Henning Hucke -
Michael Hoffmann -
Thomas Fankhauser