Hallo Thomas, Danke für die schnelle Antwort.

-----Ursprüngliche Nachricht----- Von: Thomas Fankhauser [mailto:suseliste@digelec.ch] Gesendet: Dienstag, 10. Juli 2007 18:32 An: opensuse-de@opensuse.org Betreff: Re: named

Hallo Maximilian,

Maximilian Steinbauer wrote:

...

Hallo Linuxgemeinde,

Die Situation ist folgende (alles SuSE 10.1):

Ich hab einen Account bei dyndns z.B. mydomain.dyndns.org. Mein HW-Router meldet jeweils die aktuelle IP. Eingehende IMAP-Anfragen gehen auf meinen Mailserver. Alles funktioniert. Intern betreibe ich named (bind) als DNS-Server und hab mein internes Netz auch mydomain.dyndns.org genannt.

Wenn ich jetzt mein Notebook im eigenen Netz betreibe, gebe ich die IP meines Mailservers ein. Wenn ich außer Haus bin, muss ich auf mydomain.dyndns.org umkonfigurieren.

Das würde ich gerne vermeiden, aber als Serveradresse im eigenen Netz reicht mydomain.dyndns.org nicht, da der server halt server1.mydomain.dyndns.org heißt. Kennt einer eine Möglichkeit dem bind zu sagen, er soll bei der IP-Anfrage auf die domain (mydomain.dyndns.org) die IP des rechners server1.mydomain.dyndns.org zurückliefern?

Welchen Nameserver verwendet denn dein Notebook wenn du ausser Haust bist? Dyndns.org müsste ja mydomain.dyndns.org anders auflösen wenn du ausserhaus bist. Mein Notebook macht alles per dhcp!

Versuch doch mal einfach eine zone in DEINEM Bind einzurichten mydomain.dyndns.org der dir dann die interne ip zurückgibt. Ev. hast du erfolg. Da liegt ja das Problem. Außer Haus bekomme ich für mydomain.dyndns.org die Adresse des Routers, der die Anfrage per NAT weiterleitet. Im Haus ist es eine Anfrage auf die Domäne an sich und die liefert keine IP, da der spezifische Rechner (server.mydomain.dyndns.org) nicht angefragt wurde.

Ich bräucht nen dummy, der bei internen Anfragen, die er nicht kennt immer eine default IP liefert.

-- Gruss Thomas

...

Danke und Grüße

Max

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Falk Sauer schrieb:

Hi Maximilian

Am Dienstag, 10. Juli 2007 schrieb Maximilian Steinbauer:

...

Da liegt ja das Problem. Außer Haus bekomme ich für mydomain.dyndns.org die Adresse des Routers, der die Anfrage per NAT weiterleitet. Im Haus ist es eine Anfrage auf die Domäne an sich und die liefert keine IP, da der spezifische Rechner (server.mydomain.dyndns.org) nicht angefragt wurde.

...

Ich bräucht nen dummy, der bei internen Anfragen, die er nicht kennt immer eine default IP liefert.

und was spricht dagegen den internen Bind authoritativ für dyndns.org zu machen und darin dann mydomain als Rechner einzutragen? Es sei denn du willst noch irgendwas anderes aus dyndns.org erreichen, aber auch das lässt sich hinfummeln.

named.conf

... zone "dyndns.org" in { allow-transfer { any; }; file "master/dyndns.org"; type master; }; ...

master/dyndns.org

$ORIGIN . $TTL 12000 ; 200 minutes dyndns.org IN SOA mydomain.dyndns.org. hostmaster.dyndns.org. ( 7071002 ; serial 10800 ; refresh (3 hours) 900 ; retry (15 minutes) 604800 ; expire (1 week) 86400 ; minimum (1 day) ) NS mydomain.dyndns.org. MX 5 mydomain.dyndns.org. $ORIGIN dyndns.org. mydomain A 192.168.1.1

oder sowas in der Art.

Damit kannst du dann natürlich (falls du intern mit den server1.mydomain.dyndns.org sachen weiter machen willst) einen reverse lookup der mydomain.dyndns.org ausspuckt vergessen aber was solls, das klappt extern ja auch nicht.

Intern funktioniert es. man muss halt ales über den internen bind laufen lassen und nur einen forwarder konfigurieren. die zonedatei für den reverse muss auch angelegt werden. jetzt gehe ich joggen. ich kann später noch was dazu schreiben gruss jan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Maximilian Steinbauer schrieb:

Hallo Thomas,

Danke für die schnelle Antwort.

...

-----Ursprüngliche Nachricht----- Von: Thomas Fankhauser [mailto:suseliste@digelec.ch] Gesendet: Dienstag, 10. Juli 2007 18:32 An: opensuse-de@opensuse.org Betreff: Re: named

...

Hallo Maximilian,

...

Maximilian Steinbauer wrote:

...

Hallo Linuxgemeinde,

...

...

Die Situation ist folgende (alles SuSE 10.1):

...

...

Ich hab einen Account bei dyndns z.B. mydomain.dyndns.org. Mein HW-Router meldet jeweils die aktuelle IP. Eingehende IMAP-Anfragen gehen auf meinen Mailserver. Alles funktioniert. Intern betreibe ich named (bind) als DNS-Server und hab mein internes Netz auch mydomain.dyndns.org genannt.

...

...

Wenn ich jetzt mein Notebook im eigenen Netz betreibe, gebe ich die IP meines Mailservers ein. Wenn ich außer Haus bin, muss ich auf mydomain.dyndns.org umkonfigurieren.

...

...

Das würde ich gerne vermeiden, aber als Serveradresse im eigenen Netz reicht mydomain.dyndns.org nicht, da der server halt server1.mydomain.dyndns.org heißt. Kennt einer eine Möglichkeit dem bind zu sagen, er soll bei der IP-Anfrage auf die domain (mydomain.dyndns.org) die IP des rechners server1.mydomain.dyndns.org zurückliefern? Welchen Nameserver verwendet denn dein Notebook wenn du ausser Haust bist? Dyndns.org müsste ja mydomain.dyndns.org anders auflösen wenn du ausserhaus bist. Mein Notebook macht alles per dhcp! Versuch doch mal einfach eine zone in DEINEM Bind einzurichten mydomain.dyndns.org der dir dann die interne ip zurückgibt. Ev. hast du erfolg. Da liegt ja das Problem. Außer Haus bekomme ich für mydomain.dyndns.org die Adresse des Routers, der die Anfrage per NAT weiterleitet. Im Haus ist es eine Anfrage auf die Domäne an sich und die liefert keine IP, da der spezifische Rechner (server.mydomain.dyndns.org) nicht angefragt wurde.

Ich bräucht nen dummy, der bei internen Anfragen, die er nicht kennt immer eine default IP liefert.

Mach ma' ein alias. IN CNAME -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Falk Sauer schrieb: Hi Falk

Am Dienstag, 10. Juli 2007 schrieb Jan Tiggy:

...

Mach ma' ein alias.

...

IN CNAME

da brauch ter aber auch eine zone in der der cname steht für die sein bind zuständig ist ...

Will ich doch meinen. Wie sonst kann er das machen?? Also die Ausgangssituation war doch: "Ich hab einen Account bei dyndns z.B. mydomain.dyndns.org. Mein HW-Router meldet jeweils die aktuelle IP. Eingehende IMAP-Anfragen gehen auf meinen Mailserver. Alles funktioniert. Intern betreibe ich named (bind) als DNS-Server und hab mein internes Netz auch mydomain.dyndns.org genannt. Wenn ich jetzt mein Notebook im eigenen Netz betreibe, gebe ich die IP meines Mailservers ein. Wenn ich außer Haus bin, muss ich auf mydomain.dyndns.org umkonfigurieren. Das würde ich gerne vermeiden, aber als Serveradresse im eigenen Netz reicht mydomain.dyndns.org nicht, da der server halt server1.mydomain.dyndns.org heißt. Kennt einer eine Möglichkeit dem bind zu sagen, er soll bei der IP-Anfrage auf die domain (mydomain.dyndns.org) die IP des rechners server1.mydomain.dyndns.org zurückliefern?" Diesem Problem bin ich so begegnet: hostname: server domain: blabla.selfip.com (damit ich noch andere *.selfip.com erreichen kann) IP: 192.168.14.113 (fix) Dann in Bind, eine Zone erstellt: $TTL 2d @ IN SOA server.blabla.selfip.com. root.server.blabla.selfip.com. ( 2007031901 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum blabla.selfip.com. IN NS ns.blabla.selfip.com. blabla.selfip.com. IN MX 10 mail.blabla.selfip.com. ns.blabla.selfip.com. IN A 192.168.14.113 blabla.selfip.com. IN A 192.168.14.113 server.blabla.selfip.com. IN A 192.168.14.113 mail.blabla.selfip.com. IN A 192.168.14.113 mail. IN CNAME mail.blabla.selfip.com. www.blabla.selfip.com. IN CNAME blabla.selfip.com. ftp.blabla.selfip.com. IN CNAME blabla.selfip.com. webserver. IN CNAME blabla.selfip.com. ftp. IN CNAME blabla.selfip.com. www. IN CNAME blabla.selfip.com. server. IN CNAME server.blabla.selfip.com. Dann noch ein reverse (sonst hatte ich probleme mit Postfix oder irgendeinem seiner Filter. Ich kann mich nicht mehr erinnern.) $TTL 86400 @ IN SOA blabla.selfip.com. ( 2007031901 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum IN NS blabla.selfip.com. 2 IN PTR blabla.selfip.com. 2 IN PTR server.blabla.selfip.com. ....und das Imap- TLS-Zertifikat für blabla.selfip.com erstellt. Schließlich intern geht alles über den bind. Danach via Forward über den Router. Dieser wiederum bekommt die DNS via DHCP. Bei mir funktioniert es sowohl extern als auch intern. Dennoch, wenn man es anders machen kann, dann lerne ich gerne dazu. Das habe ich mir so nur in einer halben Stunden zusammen gefummelt. Es geht mit Sicherheit besser. Gruß Jan PS: Ich will auch nicht behaupten, dass ich das ganze so richtig zu ende verstanden habe. ;( PS: Komplizierter wird es, wenn man mehrere Dyndns-Domains auf einer Kiste betreiben möchte, aber es ist auch sonderlich schwierig. Bei mir laufen zur Zeit 5 DynDNS-Domains. Alle mit Apache (vhosts), Postfix (vdomains), FTP, MySQL etc. Last but not least: Das Yast-Setup-Script für Bind produziert bei mir einen Fehler (suse 10.2) im Bereich key "rndc-key" der /etc/named.conf, so dass ich die entsprechenden Zeilen manuell editieren muss. Grausam. Nicht das Editieren, sondern das Nicht-Funktionieren. g'nite. -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Falk Sauer wrote:

Hi Jan

Am Mittwoch, 11. Juli 2007 schrieb Jan Tiggy:

...

Dann noch ein reverse (sonst hatte ich probleme mit Postfix oder irgendeinem seiner Filter. Ich kann mich nicht mehr erinnern.)

kann man abstellen, postfix macht keinen lookup wenn der Eintrag in eckigen klammern steht.

Nein, die Klammern um einen Host-/Domain-Namen unterdrücken nur die MX-Auflösung dieses Namens, nicht aber den PTR-Lookup für den Reverse-DNS-Eintrag. Wenn kein Reverse-DNS existiert, steht der Server im Log von Postfix als "unknown".

was gibt dir hier host, dig und nslookup aus? 2 unterschiedliche _reverse_ Antworten werden afair nicht von allen Programmen sauber verarbeitet.

Postfix wertet nur den ersten Eintrag auf, den der Nameserver schickt. Falls das nicht mit dem Forward-DNS übereinstimmt, wird der Rest der Einträge nicht ausgewertet und der Server ist "unknown" bzw. wird als der Reverse-DNS-Eintrag geloggt.

Aaaaaber extern bekommst du reverse immer sowas wie dip-dialin* aber _nie_ dein blabla.selfip.com. Das heißt aber auch das ein setting was sich auf einen zum forward passenden reverse verlässt und darauf besteht, extern immer auf die Schnauze fallen muß.

Sage niemals nie: japantest.homelinux.com (^-^) Präzise gesagt, man muss den Verwalter der entsprechenden PTR-Zone dazu bringen, den Eintrag entsprechend vorzunehmen.

ps: dem ganzen Elend entgeht man ziemlich zuverlässig mit openvpn, dann reicht einfach _ein_ Eintrag mydomain.dyndns.org und der ganze Rest wird im eigenen privaten Adressraum erledigt. Auch hat man dann kein Problem sicherzustellen das man irgendwo mit der eigenen dns konfig möglicherweise Bereiche von dyndns.org verdeckt. Und für port 80 braucht man den ganzen Schnickschnack auch nicht, das kann man ja parallel betreiben wenns unbedingt sein muß.

Für extern angebotene Dienste wie Web- und Mailserver ist dies leider keine Lösung. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Falk Sauer wrote:

Hi Sandy,

Am Mittwoch, 11. Juli 2007 schrieb Sandy Drobic:

...

Falk Sauer wrote:

...

Am Mittwoch, 11. Juli 2007 schrieb Jan Tiggy: kann man abstellen, postfix macht keinen lookup wenn der Eintrag in eckigen klammern steht. Nein, die Klammern um einen Host-/Domain-Namen unterdrücken nur die MX-Auflösung dieses Namens, nicht aber den PTR-Lookup für den Reverse-DNS-Eintrag. Wenn kein Reverse-DNS existiert, steht der Server im Log von Postfix als "unknown".

was aber nicht zwingend (je nach Konfig) zu einem Abbruch führen muß, ein MX-Lookup der nicht zum gewünschten Ergebnis führt dagegen schon. MX Pointer sind bei dynodns Hostern außerdem idr. kostenpflichtig.

Ha?!? Wovon redest du eigentlich? Nochmal zusammengefasst: Wenn man an einer dynamischen Leitung hängt, bekommt man in der Regel nicht den den DynDNS-Namen als Reverse-DNS-Eintrag gesetzt. Als Folge davon wird der Host (wenn er nicht ohnehin wegen der dynamischen IP direkt abgewiesen wird) vom empfangenden Server als "unknown" geführt, bzw. bei vorhandenem PTR als der Reverse DNS-Name. Dieser Lookup kann nicht über die Klammern unterdrückt werden. Die Klammern um einen Hostnamen sind nur für die Unterdrückung der MX-Auflösung des Namens beim Versenden von Mails. Der erste Absatz ist die Sicht des empfangenden Servers, dem eine Mail geschickt wird. Der zweite Absatz hier ist die Sicht des eigenen sendenden Servers. Nebenbei ist das Setzen des MX bei DynDNS (andere habe ich noch nicht probiert) nicht kostenpflichtig. Was genau meinst du jetzt mit "nicht zwingend (je nach Konfig) zu einem Abbruch führen muß"? Redest du hier von dem eigenen sendenden Server oder dem anderen Remote Server?

...

...

Aaaaaber extern bekommst du reverse immer sowas wie dip-dialin* aber _nie_ dein blabla.selfip.com. Das heißt aber auch das ein setting was sich auf einen zum forward passenden reverse verlässt und darauf besteht, extern immer auf die Schnauze fallen muß. Sage niemals nie: japantest.homelinux.com (^-^)

Präzise gesagt, man muss den Verwalter der entsprechenden PTR-Zone dazu bringen, den Eintrag entsprechend vorzunehmen.

Reverse PTRs können aber praktisch nur die Eigentümer der IPs setzen, und das sind in D nunmal überwiegend die Ts, Arcors, freenets und wie sie alle heißen. ich sehe grade vor meinem geistigen Auge wie du an der Ecke mit den MAn des pinkfarbenen T darüber verhandelst. ;-) Das ließe sich als quotenstarke Soap verkaufen. Wohl dem der einen dialin Provider seines Vertrauens hat, der arme Rest ist hier auf _eigene feste_ IPs angewiesen und braucht kein dyndns.

Ich denke nicht, dass man bei einer Dialin-Adresse einen selbst gewählten Reverse-Eintrag bekommt. Ich hatte mal angefragt, ob dies mit Aufpreis vielleicht gehen würde, war jedoch nicht erfolgreich. Na ja, jetzt bin ich an einer statischen IP und kann die Einträge setzen. Und da ich nun schon seit Jahren meinen Hostnamen einsetze, ist dieser eben auch auf der statischen Adresse eingetragen.

...

...

ps: dem ganzen Elend entgeht man ziemlich zuverlässig mit openvpn, dann reicht einfach _ein_ Eintrag mydomain.dyndns.org und der ganze Rest wird im eigenen privaten Adressraum erledigt. Auch hat man dann kein Problem sicherzustellen das man irgendwo mit der eigenen dns konfig möglicherweise Bereiche von dyndns.org verdeckt. Und für port 80 braucht man den ganzen Schnickschnack auch nicht, das kann man ja parallel betreiben wenns unbedingt sein muß. Für extern angebotene Dienste wie Web- und Mailserver ist dies leider keine Lösung.

Vielleicht hab ich mich hier nicht präzise genug ausgedrückt, ich schrub ja das man für port 80 die Dienste - extern only - am vpn vorbei bereitstellen kann. Das funktioniert selbstverständlich auch mit den anderen Diensten, dafür reicht auch nahezu immer der eine von dyndns bereitgestellte hostname, zumindest solange man alles was intern passieren soll einfach intern belässt (über vpn). Die Struktur - insbesondere der firewall - ist damit imho einfach viel übersichtlicher und leichter zu warten.

Das kommt ganz auf den Einsatzzweck an. Für mich ist VPN eben nur die Erweiterung des Intranets, Für die Verbindung zum Internet ist dies eher eine Komplikation. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Falk Sauer schrieb:

ja wenn du aber intern und extern auf die gleiche konfig setzt und darum ging es ja letztendlich muss beides für den Client zum gleichen Ergebnis führen damit es geht. Das mit dem MX bekommt man hin, dh. das der Client vom DNS gesagt bekommt wo sein smtp-Server mit dem Port 25 auf ihn wartet. -->1

Bei meinen Laptops wird sowohl im Internet als auch im Intranet Thunderbird mit der Konfiguration 'force TLS' auf bla.selfip.com (also dyndns.org) eingesetzt. Das Zertifikat wurde für bla.selfip.com erstellt. Benutzerdaten werden via Login/Pass abgefragt. Saslauthd ist am werken. Als Imap-Server ist die bla.selfip.com in dem Thunderbird eingetragen. Das Versenden gehen die Mails über Postfix mit der weiterleitung über den Relayserver von ish.de Auf dem Server läuft Postfix mit Cyrus-imap. Die Einstellungen für den Server lauten: HOST: server DOMAIN: bla.selfip.com Interne Auflösung: nslookup bla.selfip.com Server: 192.168.1.103 Address: 192.168.1.103#53 Name: bla.selfip.com Address: 192.168.1.103 nslookup 192.168.1.103 Server: 192.168.1.103 Address: 192.168.1.103#53 103.1.168.192.in-addr.arpa name = bla.selfip.com. 103.1.168.192.in-addr.arpa name = server.bla.selfip.com.1.168.192.in-addr.arpa. 103.1.168.192.in-addr.arpa name = ftp.bla.selfip.com.1.168.192.in-addr.arpa. 103.1.168.192.in-addr.arpa name = www.bla.selfip.com.1.168.192.in-addr.arpa. 103.1.168.192.in-addr.arpa name = mail.bla.selfip.com.1.168.192.in-addr.arpa. Externe Auflösung: nslookup bla.selfip.com Name: bla.selfip.com Address: 62.143.x.x nslookup 62.143.x.x Name: x.x.1511H-CUD12K-01.ish.de Address: 62.143.x.x Ich kann sowohl extern als auch intern auf den Server in beide Richtungen zugreifen, ohne die Konfiguration der Email-Clients ändern zu müssen.

Das sehen aber nicht alle so, als ich mich vor 2-3 Jahren nach einem Dyndns umgeschaut habe wollten die meisten für einen MX-Eintrag Geld, und ich würde jetzt fast wetten das dyndns.org da auch dabei war.

MX-Eintrag ist bei dyndns.org 100%-ig für Lau, ebenfalls die Wildcards. Thx Jan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Sandy Drobic schrieb:

Beim Mailserver fragt er nach 192.168.1.103 mit "bla.selfip.com", das reicht. Für den Rest wie ftp und www brauchst du nur CNAMEs in den Forward-Zonen für bla.selfip.com.

Kannst du mir das ein bisschen naeher erlaeutern? Ein 'www. IN CNAME bla.selfip.com' will bind nicht annehmen. Also er macht dies schon aber meckert im Log, dass der Befehlt zu kurz war oder so. Ausserdem sagte jemand, dass man keine

Ich würde da eher die restlichen Clients des internen Netzwerkes auch eintragen, damit diese mit Namen im Log deines Servers erscheinen.

Ich habe alle Cleints von Anfang an drin. Hab sie nur nicht hier augelistet.

...

Externe Auflösung:

nslookup bla.selfip.com

Name: bla.selfip.com Address: 62.143.x.x

nslookup 62.143.x.x

Name: x.x.1511H-CUD12K-01.ish.de Address: 62.143.x.x

Ich kann sowohl extern als auch intern auf den Server in beide Richtungen zugreifen, ohne die Konfiguration der Email-Clients ändern zu müssen.

Ja, da sehe ich auch kein Problem. Leider scheint der Relayserver von Ish manchmal stark belastet zu sein, denn die Auslieferung von Mails dauerte teilweise etliche Stunden. :-(

-- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig schrieb:

der Punkt hat eine besondere Bedeutung im DNS. Mach den hinter www mal weg.

Stimmt. Das gilt nur für die FQDN oder?

Man darf keine CNAMEs neben andere Eintraege legen. Aber der Vorschlag, bzw. dein Eintrag oben ist ok. Du darfst dann aber nirgends noch einen "www IN ... Eintrag" machen.

Ok, wenn ich dich richtig verstanden habe müsste das Folgende stimmen? Oder sollen die ww und ftp einträge aus der reverse auch raus? bla.zone $TTL 2d @ IN SOA server.bla.selfip.com. root.server.bla.selfip.com. ( 2007031901 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum bla.selfip.com. IN NS ns.bla.selfip.com. bla.selfip.com. IN MX 10 mail.bla.selfip.com. @ IN A 192.168.1.103 ns.bla.selfip.com. IN A 192.168.1.103 bla.selfip.com. IN A 192.168.1.103 server.bla.selfip.com. IN A 192.168.1.103 mail.bla.selfip.com. IN A 192.168.1.103 fritz.bla.selfip.com. IN A 192.168.1.1 dbox2.bla.selfip.com. IN A 192.168.1.102 voyager.bla.selfip.com. IN A 192.168.1.101 voyager2.bla.selfip.com. IN A 192.168.1.100 www IN CNAME bla.selfip.com ftp IN CNAME bla.selfip.com und hier die reverse: $TTL 2d @ IN SOA bla.selfip.com. root.bla.selfip.com. ( 2007031901 ; Serial 10800 ; Refresh 3600 ; Retry 604800 ; Expire 86400 ) ; Minimum IN NS bla.selfip.com. 103 IN PTR bla.selfip.com. 103 IN PTR server.bla.selfip.com 103 IN PTR mail.bla.selfip.com 103 IN PTR www.bla.selfip.com 103 IN PTR ftp.bla.selfip.com 1 IN PTR fritz.bla.selfip.com 102 IN PTR dbox2.bla.selfip.com 101 IN PTR voyager.bla.selfip.com 100 IN PTR voyager2.bla.selfip.co -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig schrieb:

Kennste named-checkzone?

Bis jetzt noch nicht, aber ich schaue mir es mal an. Danke für die Erläuterung zu Toplevel-Domain. Wieder was gelernt. MfG Jan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Falk Sauer wrote:

Hi Sandy,

Am Do 12.Juli 2007 20:13:35 schrieb Sandy Drobic:

...

Ha?!? Wovon redest du eigentlich?

Nochmal zusammengefasst: Wenn man an einer dynamischen Leitung hängt, bekommt man in der Regel nicht den den DynDNS-Namen als Reverse-DNS-Eintrag gesetzt. Als Folge davon wird der Host (wenn er nicht ohnehin wegen der dynamischen IP direkt abgewiesen wird) vom empfangenden Server als "unknown" geführt, bzw. bei vorhandenem PTR als der Reverse DNS-Name.

jepp

...

Dieser Lookup kann nicht über die Klammern unterdrückt werden. Die Klammern um einen Hostnamen sind nur für die Unterdrückung der MX-Auflösung des Namens beim Versenden von Mails.

ja wenn du aber intern und extern auf die gleiche konfig setzt und darum ging es ja letztendlich muss beides für den Client zum gleichen Ergebnis führen damit es geht. Das mit dem MX bekommt man hin, dh. das der Client vom DNS gesagt bekommt wo sein smtp-Server mit dem Port 25 auf ihn wartet. -->1

Beim Client sieht es erheblich einfacher aus: er braucht keine Rückwärts-Auflösung. Ihm reicht es, wenn der Hostname auf einen IP-Adresse aufgelöst werden kann oder die IP direkt angegeben wird. Dabei muss dies nicht zum selben Ergebnis führen, sondern nur zum gleichen Server zeigen. Der interne Client kann hier die interne IP verwenden, der externe muss natürlich über die externe IP gehen. Die Namensauflösung des smtp-Clients muss also nicht das gleiche Ergebnis bringen. Viele Wege führen nach Rom bzw. zum Relayserver.

...

Der erste Absatz ist die Sicht des empfangenden Servers, dem eine Mail geschickt wird. Der zweite Absatz hier ist die Sicht des eigenen sendenden Servers.

Nebenbei ist das Setzen des MX bei DynDNS (andere habe ich noch nicht probiert) nicht kostenpflichtig.

Das sehen aber nicht alle so, als ich mich vor 2-3 Jahren nach einem Dyndns umgeschaut habe wollten die meisten für einen MX-Eintrag Geld, und ich würde jetzt fast wetten das dyndns.org da auch dabei war.

Jetzt jedenfalls nicht mehr, vermutlich auch, weil einige Admins statt in Kenntnis der RFCs nach dem Sitz ihrer Hosen administrieren.

...

Was genau meinst du jetzt mit "nicht zwingend (je nach Konfig) zu einem Abbruch führen muß"?

1) wenn du überprüfst ob der reverse zu dem übermittelten Namen passt, und er passt nicht wird der Sender abgewiesen. Wenn man das nicht macht geht es. So wie du oben schon geschrieben hast. Dieses Problem bekommt man aber nicht in den Griff wenn man auf dem eigenen per dialin angeschlossenen Server auf den reverse Eintrag testet wenn der eigene Client daher kommt. Denn dann stimmt dessen reverse maximal von innen aber nie von außen - wenn sich der client jeweils als der gleiche Rechner identifiziert.

Was passiert, wenn dein Server (der an der dynamischen IP hängt), eine Mail an einen anderen Server verschickt? Diese Schritte laufen ab: - Dein Server verbindet sich mit dem externen Server. Dieser löst die IP deines Rechners auf und überprüft, ob der Reverse-DNS-Eintrag zurück auf die IP zeigt. Bei Ish ist dies der Fall. Dein Server wird geloggt als xxxxx.xxxx.ish.de. - Jetzt kommt das HELO/EHLO-Kommando, das dein Server absetzt. Dieses ist der Hostname bla.self-ip.org oder was auch immer. Jetzt prüft der externe Server, ob dieser den RFCs genügt: FQDN, muss existieren. Alles klar, der Hostname existiert im DNS. KEIN RFC verlangt, dass der sendende Server seinen eigenen Hostnamen für das HELO verwenden muss! Diesem Aberglauben hängen nur die Admins mit den zu knappen Hosen an. - Als nächstes kommt nun Envelope-Sender/-Recipient, auch diese müssen FQDN sein und die Domain muss existieren. Auch müssen dies gültige Adressen sein. Address-verify kommt jedoch in Verruf, da einige Server so stark durch die Adressproben von anderen Servern belastet wurden, dass einige Admins diese Adressproben schon als Teil der Spambelastung sehen und die entsprechenden Server auf die eigene Blacklist setzen. Danach kommt nur noch die eigentliche Mail. Der Server an der dynamischen IP wird also in diesem Fall nicht als "unknown" geloggt, sondern als xxx.ish.de. Das eigentliche Problem ist, dass die IP in einem Bereich liegt, welcher als Dialin ausgewiesen ist und deshalb durch den Gebrauch der entsprechenden Blacklists abgewiesen wird. Anders sieht es aus, wenn für die IP gar kein Reverse DNS eingerichtet ist, der Eintrag ungültig ist, oder dieser Eintrag auf eine andere IP zeigt. Dann wird der Client vom empfangenden Server als "unknown" geführt.

...

Na ja, jetzt bin ich an einer statischen IP und kann die Einträge setzen. Und da ich nun schon seit Jahren meinen Hostnamen einsetze, ist dieser eben auch auf der statischen Adresse eingetragen.

ich hatte mal einen isdn dialin Provider mit ner statischen Adresse, das war klasse, lang ists her. Sowas könnte ich zwar wieder per vpn haben aber meine Leitung daheim gibt einen sinnvollen Betrieb leider nicht her, wenn ich das mal machen sollte dann nur bei einem Hoster.

Wenn Kosten ein kritischer Punkt sind, dann sollte man einen virtuellen Server mit offizieller IP mieten und diesen als Mailserver verwenden. Der interne Server ist dann der Backend-Server. Wichtig ist dann nur, dass der Relayserver alle gültigen Adressen kennt und ungültige direkt abweisen kann.

völlig richtig - es sei denn man bekommt vor Ort keine bezahlbare statische Adresse, aber ging es dem OP nicht ursprünglich lediglich darum mit dem möglichst gleichen setting bei sich daheim auf den Server zu kommen?

Ja, bis die Diskussion ausgeufert ist zur Mailannahme etc. (^-^) Wie ich oben geschrieben habe, ist es für den Client nur wichtig, dass er den Hostnamen auflösen kann auf die IP-Adresse. Dies muss jedoch nicht die gleiche IP sein wie die externe. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig wrote:

On Mon, Jul 16, 2007 at 01:23:13PM +0200, Sandy Drobic wrote:

...

KEIN RFC verlangt, dass der sendende Server seinen eigenen Hostnamen für das HELO verwenden muss! Diesem Aberglauben hängen nur die Admins mit den zu knappen Hosen an.

Du liest RFC2821 4.1.1.1 dann aber mit einer interessanten Auslegungsweise.

Ein Rechner, der tatsaechlich keine gueltige HELO/EHLO Argumente finden kann, sollte nich mit einem SMTP MTA, sondern seinem lokalen MSA sprechen.

Moooment! "ungültig" und "nicht der eigene Hostname" ist nicht das gleiche, da hast du leider falsch gequotet. Der Satz davor hat genau dies erklärt, deshalb hier noch einmal: - Jetzt kommt das HELO/EHLO-Kommando, das dein Server absetzt. Dieses ist der Hostname bla.self-ip.org oder was auch immer. Jetzt prüft der externe Server, ob dieser den RFCs genügt: FQDN, muss existieren. Alles klar, der Hostname existiert im DNS. Diese kann ich verwenden (und empfehle sie auch anderen zum Testen: - reject_non_fqdn_helo_hostname - reject_invalid_helo_hostname Diese hier kann ich nicht verwenden (zuviele false positives): - reject_unknown_helo_hostname (helo wie exchange.local) Auch die letzte Bedingung ist eigentlich RFC-Pflicht, aber es gibt zuviele schlecht gewartete Server. Keiner dieser Checks verlangt, dass forward dns = reverse dns = helo gelten muss. Auch der RFC 2821 sagt nur, dass das HELO-Kommando den Client identifizieren soll und es ein gültiger Hostname sein muss. So darf der Server mail.example.com sich durchaus als example.com melden, vorausgesetzt, example.com hat einen A-Eintrag im DNS.

Ich bin jedenfalls froh eine ganze Menge unnuetzes Zeug allein dadurch loszuwerden das die HELO Angaben ueberprueft werden.

Da kann ich dir nur recht geben. allein durch die HELO-Checks wird schon ein beträchtlicher Anteil von Spam/Viren abgeblockt. Nur sollte man aufpassen, das man nicht den Sinn eines Mailservers aus den Augen verliert. Wenn die Anwender ständig fragen, ob eine Mail durchgekommen ist oder eine Mail blockiert wurde, deutet das auf ein intransparentes System hin. Wichtigste Aufgabe ist es immer noch, die erwünschten Mails anzunehmen, weniger hohe Priorität ist es (zumindest bei mir), die unerwünschten Mails abzuweisen. Besser, eine Spammail kommt durch als das eine erwünschte Mail abgewiesen wird. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org

Peter Wiersig wrote:

On Mon, Jul 16, 2007 at 02:59:35PM +0200, Sandy Drobic wrote:

...

Peter Wiersig wrote:

...

On Mon, Jul 16, 2007 at 01:23:13PM +0200, Sandy Drobic wrote:

...

KEIN RFC verlangt, dass der sendende Server seinen eigenen Hostnamen für das HELO verwenden muss! Diesem Aberglauben hängen nur die Admins mit den zu knappen Hosen an. Du liest RFC2821 4.1.1.1 dann aber mit einer interessanten Auslegungsweise.

Ein Rechner, der tatsaechlich keine gueltige HELO/EHLO Argumente finden kann, sollte nich mit einem SMTP MTA, sondern seinem lokalen MSA sprechen. Moooment! "ungültig" und "nicht der eigene Hostname" ist nicht das gleiche, da hast du leider falsch gequotet. Der Satz davor hat genau dies erklärt, deshalb hier noch einmal:

- Jetzt kommt das HELO/EHLO-Kommando, das dein Server absetzt. Dieses ist der Hostname bla.self-ip.org oder was auch immer. Jetzt prüft der externe Server, ob dieser den RFCs genügt: FQDN, muss existieren. Alles klar, der Hostname existiert im DNS.

Nein, das genuegt mir nicht: Wenn ein von extern initiierter SMTP-Client behauptet aus meiner Domain zu stammen, wird der abgewiesen - obwohl der Hostname im DNS nachschlagbar ist.

Das kannst du auch ohne schlechtes Gewissen, ich mache dies auch und betrachte dies als einen sicheren Check. Dies ist jedoch nicht von den RFCs so vorgegeben, sondern Teil deiner eigenen Policy, die du manuell konfigurieren musstest. RFC-konform ist ein helo, welches einen Hostnamen angibt, der nicht auf sich selbst zurückweist. Das Spammer gerne testen, ob sie mit dem HELO deines Servers/Domain ohne weitere Checks durchkommen, ist klar. Aber hier ging es nicht um Spamabwehr, sondern um die RFC-Konformität.

Mir ist schon klar, das ich nicht 100% sicher sein kann, ob die uebermittelte Domain zur verbundenen IP passt, aber ein Argument wie 'localhost' kann ich ohne schlechtes Gewissen abweisen. Das RFC konforme Verhalten eines Clients waere ja schliesslich seine IP-Adresse als literal zu uebermitteln.

"localhost" wird schon durch reject_non_fqdn_helo_hostname abgewiesen, kein weiterer Check notwendig. Ich bin hier auch etwas weitergegangen und blocke auch "localhost.localdomain". Es stimmt, die RFCs sagen, dass ein Addressliteral (IP-Adresse in eckigen Klammern) zu akzeptieren sei. Wobei ich inzwischen skeptisch bin, ob dies noch Sinn macht. Ich habe nur sehr wenige Situationen gesehen, wo dies notwendig war. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org