Re: Namensauflösung

[Paul Muster]

On 20.03.2012 17:31, Burkhard Ott wrote:

> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
> anderen Blatt.

Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.

Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
E-Mail-Versand mehr hin.


Danke & mfG Paul, fup2 de.comm.software.mailserver

[Tim Ritberg]

Am 20.03.2012 18:37, schrieb Paul Muster:
> On 20.03.2012 17:31, Burkhard Ott wrote:
>
>> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
>> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
>> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
>> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
>> anderen Blatt.
>
> Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
> wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.
>

rfc5321 Seite 18:
In the EHLO command, the host sending the command identifies itself;
the command may be interpreted as saying "Hello, I am <domain>" (and,
in the case of EHLO, "and I support service extension requests").


rfc2505 Seite 9:
Instead, the MTA MUST be able to authorize Mail Relay usage based on
a combination of:

o "RCPT To:" address (domain).
o SMTP_Caller FQDN hostname.
o SMTP_Caller IP address.



tim EOT

[Burkhard Ott]

On Tue, 20 Mar 2012 18:37:51 +0100, Paul Muster wrote:

> On 20.03.2012 17:31, Burkhard Ott wrote:
>
>> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
>> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
>> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
>> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
>> anderen Blatt.
>
> Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
> wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.

RFC 2812 4.1.1.1 und RFC 1123 (die ist etwas eindeutiger):

RFC 1123:

5.2.5
...

"The sender-SMTP MUST ensure that the <domain> parameter in a HELO
command is a valid principal host domain name for the client host. As a
result, the receiver-SMTP will not have to perform MX resolution on this
name in order to validate the HELO parameter."

So, asl Sender musst Du sicherstellen das der fqdn im helo/ehlo passt.
Das kann aber auch a.b.cc sein. (Doh! b.cc gibts ja wirklich, will sagen
das muss nur syntaktisch korrekt sein)

"The HELO receiver MAY verify that the HELO parameter really corresponds
to the IP address of the sender. However, the receiver MUST NOT refuse to
accept a message, even if the sender's HELO command fails verification."

Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen wenn
der nicht im DNS existiert.

> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
> und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
> E-Mail-Versand mehr hin.

Das ist zumindest in Europa so, in Nordamerika sieht das ganz anders aus.
Dennoch halte ich es fuer eine gute Methode email zu klassifizieren,
wenns auch etwas an den RFC vorbeigeht.
Nur das Du mich richtig verstehst, ich lehen diese Restriktionen
keinenfalls ab.

cheers

[Peter J. Holzer]

On 2012-03-20 18:46, Burkhard Ott <news...@derith.de> wrote:
> On Tue, 20 Mar 2012 18:37:51 +0100, Paul Muster wrote:
>> On 20.03.2012 17:31, Burkhard Ott wrote:
>>> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
>>> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
>>> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
>>> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
>>> anderen Blatt.
>>
>> Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
>> wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.
>
> RFC 2812 4.1.1.1 und RFC 1123 (die ist etwas eindeutiger):
>
> RFC 1123:
>
> 5.2.5
> ...
>
> "The sender-SMTP MUST ensure that the <domain> parameter in a HELO
> command is a valid principal host domain name for the client host. As a
> result, the receiver-SMTP will not have to perform MX resolution on this
> name in order to validate the HELO parameter."
>
> So, asl Sender musst Du sicherstellen das der fqdn im helo/ehlo passt.
> Das kann aber auch a.b.cc sein. (Doh! b.cc gibts ja wirklich, will sagen
> das muss nur syntaktisch korrekt sein)

Syntaktisch korrekt muss es sowieso sein, sonst kann der Server gleich
mit mit "501 Syntax error in parameters or arguments" antworten.

Aber ich interpretiere die Formulierung "a valid principal host domain
name for the client host" als "ein Name, der den Client-Host
identifiziert", nicht als "irgendein Name". Auch laut RFC 5321 ist der
Parameter "the fully-qualified domain name of the SMTP client" und nicht
irgendein Name (wenn der Name nicht bekannt ist, kann ersatzweise ein
Address-Literal verwendet werden, nicht aber irgendein Name).

> "The HELO receiver MAY verify that the HELO parameter really corresponds
> to the IP address of the sender. However, the receiver MUST NOT refuse to
> accept a message, even if the sender's HELO command fails verification."
>
> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen wenn
> der nicht im DNS existiert.

Ja. Wobei "local policy" natürlich der Trumpf ist, der alles schlägt.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Burkhard Ott]

On Tue, 20 Mar 2012 21:11:48 +0100, Peter J. Holzer wrote:

>>> Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
>>> wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.
>>
>> RFC 2812 4.1.1.1 und RFC 1123 (die ist etwas eindeutiger):
>>
>> RFC 1123:
>>
>> 5.2.5
>> ...
>>
>> "The sender-SMTP MUST ensure that the <domain> parameter in a HELO
>> command is a valid principal host domain name for the client host. As a
>> result, the receiver-SMTP will not have to perform MX resolution on
>> this name in order to validate the HELO parameter."
>>
>> So, asl Sender musst Du sicherstellen das der fqdn im helo/ehlo passt.
>> Das kann aber auch a.b.cc sein. (Doh! b.cc gibts ja wirklich, will
>> sagen das muss nur syntaktisch korrekt sein)
>
> Syntaktisch korrekt muss es sowieso sein, sonst kann der Server gleich
> mit mit "501 Syntax error in parameters or arguments" antworten.
>
> Aber ich interpretiere die Formulierung "a valid principal host domain
> name for the client host" als "ein Name, der den Client-Host
> identifiziert", nicht als "irgendein Name". Auch laut RFC 5321 ist der
> Parameter "the fully-qualified domain name of the SMTP client" und nicht
> irgendein Name (wenn der Name nicht bekannt ist, kann ersatzweise ein
> Address-Literal verwendet werden, nicht aber irgendein Name).

Wobei 'valid' nicht unbedingt bedeutet das Du den fqdn via DNS aufloesen
kannst.

>> "The HELO receiver MAY verify that the HELO parameter really
>> corresponds to the IP address of the sender. However, the receiver MUST
>> NOT refuse to accept a message, even if the sender's HELO command fails
>> verification."
>>
>> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen
>> wenn der nicht im DNS existiert.
>
> Ja. Wobei "local policy" natürlich der Trumpf ist, der alles schlägt.

Das hat aber nichts mit der RFC zu tuen, worauf der OP erst verwies.

cheers

[Juergen Ilse]

Hallo,

In de.comp.os.unix.linux.misc Paul Muster <exp-3...@news.muster.de1.cc> wrote:
> On 20.03.2012 17:31, Burkhard Ott wrote:
>> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
>> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
>> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
>> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
>> anderen Blatt.
> Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
> wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.

RFC821
----------------
HELLO (HELO)

This command is used to identify the sender-SMTP to the receiver-SMTP.
The argument field contains the host name of the sender-SMTP.
----------------

RFC2821
----------------
In the EHLO command the host sending the command identifies itself;

the command may be interpreted as saying "Hello, I am <domain>" (and,
in the case of EHLO, "and I support service extension requests").

----------------
(wie anders als durch seinen Hostnamen oder ggfs. seine IP-Adresse
sollte er sich denn identifizieren? Mit einem "rate mal wer hier ist"?).

RFC5321
----------------
o The domain name given in the EHLO command MUST be either a primary
host name (a domain name that resolves to an address RR) or, if
the host has no name, an address literal, as described in
Section 4.1.3 and discussed further in the EHLO discussion of
Section 4.1.4.
-----------------

Genuegt dir das oder moechtest du noch mehr Belege?

> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
> und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
> E-Mail-Versand mehr hin.

... weil alle Welt kaputtes RFC-widriges Zeug als Mailserver ins Netz
stellt (ja, auch viele grosse Mailprovider koennen so einen Bockmist
verzapfen ...). Deswegen muss man sich diesem Unfug aber noch nicht
unbedingt anschliessen ...

Tschuess,
Juergen Ilse (jue...@usenet-verwaltung.de)
--
Ein Domainname ist nur ein Name, nicht mehr und nicht weniger.
Wer mehr hineininterpretiert, hat das Domain-Name-System nicht
verstanden.

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Tue, 20 Mar 2012 18:37:51 +0100, Paul Muster wrote:
>
> "The HELO receiver MAY verify that the HELO parameter really corresponds
> to the IP address of the sender. However, the receiver MUST NOT refuse to
> accept a message, even if the sender's HELO command fails verification."
>
> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen wenn
> der nicht im DNS existiert.

Richtig.
Weil wir aufgrund eines fehlerhaften HELO nicht ablehnen dürfen werten wir
es überhaupt nicht aus.
Natürlich könnte man ein fehlerhaftes HELO für die Vergabe von SPAM-Punkten
verwenden. Wir machen das im Moment aber nicht.

>> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
>> und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
>> E-Mail-Versand mehr hin.
>
> Das ist zumindest in Europa so, in Nordamerika sieht das ganz anders aus.
> Dennoch halte ich es fuer eine gute Methode email zu klassifizieren,
> wenns auch etwas an den RFC vorbeigeht.

In RFC 1036 im Abschnitt 6.4 steht:
Inverse queries are an optional part of the DNS. Name servers are not
required to support any form of inverse queries. If a name server
receives an inverse query that it does not support, it returns an error
response with the "Not Implemented" error set in the header. While
inverse query support is optional, all name servers must be at least
able to return the error response.

Das bedeutet, dass Reverse-Mapping optional ist, aber der Server mit "Not
Implemented" antworten muss wenn er es nicht unterstützt.
Ich vermute, dass die wenigsten DNS-Server diesen Fehler zurückgeben.
Dann müssen sie das Reverse-Mapping unterstützen.
Reverse-Mapping wird damit praktisch zwingend (wenn meine Vermutung stimmt).

Claus-Dieter

[Burkhard Ott]

On Tue, 20 Mar 2012 21:52:41 +0100, Claus-Dieter Schulmann wrote:

> In RFC 1036 im Abschnitt 6.4 steht:
> Inverse queries are an optional part of the DNS. Name servers are not
> required to support any form of inverse queries. If a name server
> receives an inverse query that it does not support, it returns an error
> response with the "Not Implemented" error set in the header. While
> inverse query support is optional, all name servers must be at least
> able to return the error response.
>
> Das bedeutet, dass Reverse-Mapping optional ist, aber der Server mit
> "Not Implemented" antworten muss wenn er es nicht unterstützt. Ich
> vermute, dass die wenigsten DNS-Server diesen Fehler zurückgeben.

Und was machen die dann? Einfach nicht antworten, hast Du einen
spezifischen wo das nicht geht, alle die ich mal so auf die schnelle
getestet habe funktionieren. Kann aber durchaus sein das es da einige
gibt die etwas eigen reagieren.

> Dann
> müssen sie das Reverse-Mapping unterstützen. Reverse-Mapping wird damit
> praktisch zwingend (wenn meine Vermutung stimmt).

Noe.

cheers

[Burkhard Ott]

On Tue, 20 Mar 2012 20:45:09 +0000, Juergen Ilse wrote:

>> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
>> und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
>> E-Mail-Versand mehr hin.
>
> ... weil alle Welt kaputtes RFC-widriges Zeug als Mailserver ins Netz
> stellt (ja, auch viele grosse Mailprovider koennen so einen Bockmist
> verzapfen ...). Deswegen muss man sich diesem Unfug aber noch nicht
> unbedingt anschliessen ...

Naja, RFC widrig kann man es ja nun auch nicht nennen. Die haben es halt
etwas anders interpretiert,lol.

cheers

[Paul Muster]

On 20.03.2012 21:52, Claus-Dieter Schulmann wrote:

> Burkhard Ott wrote:

>> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen wenn
>> der nicht im DNS existiert.
>
> Richtig.
> Weil wir aufgrund eines fehlerhaften HELO nicht ablehnen dürfen werten wir
> es überhaupt nicht aus.

Ok, dann hatte ich das richtig verstanden und richtig in Erinnerung.


Danke & viele Grüße

Paul

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Tue, 20 Mar 2012 21:52:41 +0100, Claus-Dieter Schulmann wrote:
>
>> In RFC 1036 im Abschnitt 6.4 steht:
>> Inverse queries are an optional part of the DNS. Name servers are not
>> required to support any form of inverse queries. If a name server
>> receives an inverse query that it does not support, it returns an error
>> response with the "Not Implemented" error set in the header. While
>> inverse query support is optional, all name servers must be at least
>> able to return the error response.
>>
>> Das bedeutet, dass Reverse-Mapping optional ist, aber der Server mit
>> "Not Implemented" antworten muss wenn er es nicht unterstützt. Ich
>> vermute, dass die wenigsten DNS-Server diesen Fehler zurückgeben.
>
> Und was machen die dann? Einfach nicht antworten, hast Du einen
> spezifischen wo das nicht geht, alle die ich mal so auf die schnelle
> getestet habe funktionieren. Kann aber durchaus sein das es da einige
> gibt die etwas eigen reagieren.

Einfach nicht antworten wäre nach meiner Meinung falsch (sofern der
Nameserver aufgrund der Delegation zuständig ist).

Ich kenne keinen DNS-Server im Internet der Reverse-Mapping nicht
unterstützt.
Ich habe aber auch noch nie gezielt danach gesucht.
Alle Bind-DNS-Server und alle Windows-DNS-Server, die ich bisher gesehen
habe, haben Reverse-Mapping unterstützt.

In RFC 1035 im Abschnitt 4.1.1 steht wie dieser Fehler gemeldet wird: Es ist
eine 4 im RCODE-Feld.
Es ist jedenfalls leicht von "No such name" unterscheidbar welches mit einer
3 signalisiert wird.
Du kannst ja mal beim nächsten DNS, der Reverse-Mappings verweigert,
wireshark anwerfen.
Wenn eine 3 zurückgegeben wird legst Du dem zuständigen Admin einfach die
RFC 1035 auf den Tisch :-)

>> Dann
>> müssen sie das Reverse-Mapping unterstützen. Reverse-Mapping wird damit
>> praktisch zwingend (wenn meine Vermutung stimmt).
>
> Noe.

Das verstehe ich jetzt nicht.
-v please.

Claus-Dieter

[Burkhard Ott]

On Tue, 20 Mar 2012 22:30:27 +0100, Claus-Dieter Schulmann wrote:

>>> Das bedeutet, dass Reverse-Mapping optional ist, aber der Server mit
>>> "Not Implemented" antworten muss wenn er es nicht unterstützt. Ich
>>> vermute, dass die wenigsten DNS-Server diesen Fehler zurückgeben.
>>
>> Und was machen die dann? Einfach nicht antworten, hast Du einen
>> spezifischen wo das nicht geht, alle die ich mal so auf die schnelle
>> getestet habe funktionieren. Kann aber durchaus sein das es da einige
>> gibt die etwas eigen reagieren.
>
> Einfach nicht antworten wäre nach meiner Meinung falsch (sofern der
> Nameserver aufgrund der Delegation zuständig ist).

Genau. Wenn das Antwort packet nicht irgendwo verloren geht, bekommst Du
auch einen rcode.

> Ich kenne keinen DNS-Server im Internet der Reverse-Mapping nicht
> unterstützt.
> Ich habe aber auch noch nie gezielt danach gesucht. Alle Bind-DNS-Server
> und alle Windows-DNS-Server, die ich bisher gesehen habe, haben
> Reverse-Mapping unterstützt.

Wenn keine Zone mit PTR records vorhanden ist, bedeutet das nicht das
reverse mapping nicht unterstuetzt wird.

> In RFC 1035 im Abschnitt 4.1.1 steht wie dieser Fehler gemeldet wird: Es
> ist eine 4 im RCODE-Feld.
> Es ist jedenfalls leicht von "No such name" unterscheidbar welches mit
> einer 3 signalisiert wird.
> Du kannst ja mal beim nächsten DNS, der Reverse-Mappings verweigert,
> wireshark anwerfen.

Wie gesagt ich habe bisher keinen DNS gefunden der reverse mapping nicht
unterstuetzt, was nicht heisst das es die nicht gibt.

>
>>> Dann
>>> müssen sie das Reverse-Mapping unterstützen. Reverse-Mapping wird
>>> damit praktisch zwingend (wenn meine Vermutung stimmt).
>>
>> Noe.
>
> Das verstehe ich jetzt nicht.
> -v please.

Ich muesste da mal nachschauen, aber ein PTR record ist soweit ich weiss
optional. Wenn Du keinen anlegst, ist halt keiner da und der anfragende
Client bekommt eine Fehlermelding geliefert.

cheers

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Tue, 20 Mar 2012 22:30:27 +0100, Claus-Dieter Schulmann wrote:
>
> Genau. Wenn das Antwort packet nicht irgendwo verloren geht, bekommst Du
> auch einen rcode.

Ack.
Dann schickt der DNS-Client typischerweise eine weitere Anfrage.
Das wird notfalls sogar mehrfach wiederholt.

>> Ich kenne keinen DNS-Server im Internet der Reverse-Mapping nicht
>> unterstützt.
>> Ich habe aber auch noch nie gezielt danach gesucht. Alle Bind-DNS-Server
>> und alle Windows-DNS-Server, die ich bisher gesehen habe, haben
>> Reverse-Mapping unterstützt.
>
> Wenn keine Zone mit PTR records vorhanden ist, bedeutet das nicht das
> reverse mapping nicht unterstuetzt wird.

Ack.

>> In RFC 1035 im Abschnitt 4.1.1 steht wie dieser Fehler gemeldet wird: Es
>> ist eine 4 im RCODE-Feld.
>> Es ist jedenfalls leicht von "No such name" unterscheidbar welches mit
>> einer 3 signalisiert wird.
>> Du kannst ja mal beim nächsten DNS, der Reverse-Mappings verweigert,
>> wireshark anwerfen.
>
> Wie gesagt ich habe bisher keinen DNS gefunden der reverse mapping nicht
> unterstuetzt, was nicht heisst das es die nicht gibt.

So geht es mir auch.

>>>> Dann
>>>> müssen sie das Reverse-Mapping unterstützen. Reverse-Mapping wird
>>>> damit praktisch zwingend (wenn meine Vermutung stimmt).
>>>
>>> Noe.
>>
>> Das verstehe ich jetzt nicht.
>> -v please.
>
> Ich muesste da mal nachschauen, aber ein PTR record ist soweit ich weiss
> optional. Wenn Du keinen anlegst, ist halt keiner da und der anfragende
> Client bekommt eine Fehlermelding geliefert.

Wenn ich das richtig verstehe sind nicht die einzelnen PTR-Records optional
sondern die Implementation des Reverse-Mappings selber ist optional.

RFC 1034 (3.7.2): Implementation of this service is optional in a name
server ...

Das würde bedeuten: Der DNS-Server darf bei Reverse-Anfragen nicht mit dem
RCODE 3 antworten wenn es einen A-Record zu der IP-Adresse gibt.

Claus-Dieter

[Burkhard Ott]

On Tue, 20 Mar 2012 23:51:07 +0100, Claus-Dieter Schulmann wrote:

>> Ich muesste da mal nachschauen, aber ein PTR record ist soweit ich
>> weiss optional. Wenn Du keinen anlegst, ist halt keiner da und der
>> anfragende Client bekommt eine Fehlermelding geliefert.
>
> Wenn ich das richtig verstehe sind nicht die einzelnen PTR-Records
> optional sondern die Implementation des Reverse-Mappings selber ist
> optional.
>
> RFC 1034 (3.7.2): Implementation of this service is optional in a name
> server ...
>
> Das würde bedeuten: Der DNS-Server darf bei Reverse-Anfragen nicht mit
> dem RCODE 3 antworten wenn es einen A-Record zu der IP-Adresse gibt.

Wenn es einen PTR record gibt sollte der rcode 0 liefern (no error
condition), wenns nix gibt dann 3 (does not exist). Man kann u.a. am
rcode 5 (refused) sehen ob jemand nicht will das Du was siehst, e.g.
Juergens acl Implentation wuerde/sollte Dir diesen zurueckgeben.

http://www.ietf.org/rfc/rfc1035.txt erklaert das im Detail, falls Du
tieferegehende Informationen benoetigst.

cheers

[Juergen P. Meier]

Paul Muster <exp-3...@news.muster.de1.cc>:

> On 20.03.2012 17:31, Burkhard Ott wrote:
>
>> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
>> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
>> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
>> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
>> anderen Blatt.
>
> Für den _ersten Satz_ hätte ich gerne eine Quelle in einem RfC. Mir
> wurde nämlich - in de.comm.software.mailserver - etwas anderes gesagt.

IETF Standard 10, Paragraph 4.1.1.1, erster Abstaz, zweiter Satz.

> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
> und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
> E-Mail-Versand mehr hin.

Du hast den Satz nur nicht verstanden, genau das hat Burkhard naemlich
gesagt.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

[Juergen P. Meier]

Burkhard Ott <news...@derith.de>:

> Wobei 'valid' nicht unbedingt bedeutet das Du den fqdn via DNS aufloesen
> kannst.

Das ist Falsch. Richtig ist, dass "valid FQDN" im IETF Standard 13
genau definiert ist.

>>> "The HELO receiver MAY verify that the HELO parameter really
>>> corresponds to the IP address of the sender. However, the receiver MUST
>>> NOT refuse to accept a message, even if the sender's HELO command fails
>>> verification."
>>>
>>> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen
>>> wenn der nicht im DNS existiert.

Auch das ist Falsch. Der Empfaenger *DARF* *IMMER* und *JEDE* E-Mail
aus Policy-Gruenden ablehnen - diese Freiheit gewaehrt der
SMTP-Standard jedem Empfaenger.

Der Empfaenger darf sogar aus Protokoll-Gruenden (Standardverletzung)
ablehnen, wenn der Hello-Parameter kein gueltiger (d.h. verifizierbarer*)
FQDN oder alternativ die IP-Addresse des Clients enthaelt, und muss
sich nicht auf seine Policy berufen.

>> Ja. Wobei "local policy" natürlich der Trumpf ist, der alles schlägt.
>
> Das hat aber nichts mit der RFC zu tuen, worauf der OP erst verwies.

Doch, aber bei ungueltigem Hello-Parameter kommt die Policy garnicht
erst ins Spiel, das ist naemlich schon eine gewoehnliche Verletzung des
Protokollstandards.

* Im Sinne von IETF Standard 13. Was du vermutlich verwechwelst ist
"valid FQDN" mit "loest auf einen IN A RR auf". Das ist aber dein
eigenes Misverstaendnis.

Ein FQDN /MUSS/ nicht auf einen A RR aufloesen, er DARF aber NICHT mit
NXDOMAIN terminieren. Es muss /mindesetens/ NOERROR (empty RR set) sein.

Im Mailverkehr kann man (local policy!) darueberhinaus Fordern, dass
der FQDN mindestens einen MX oder einen Address-Record hat.

[Juergen P. Meier]

begin 1 followup to Burkhard Ott <news...@derith.de>:

Tja, wenn man "MUST" mit "MUST NOT" fehlinterpretiert, dann ist halt
jede Vernunft verloren.

Mit solchen Spacken und Idioten will man andererseits nicht
Kommunizieren, dafuer gibt es aber zum Glueck die einschlaegigen RBLs
(rfc-ignorant etc.)

[Juergen Ilse]

Hallo,

Claus-Dieter Schulmann <claus-diete...@web.de> wrote:
> In RFC 1036 im Abschnitt 6.4 steht:

RFC1036 waere NNTP, da wird das nicht so drin stehen (ohne jetzt nachzusehen).

> Inverse queries are an optional part of the DNS. Name servers are not
> required to support any form of inverse queries. If a name server
> receives an inverse query that it does not support, it returns an error
> response with the "Not Implemented" error set in the header. While
> inverse query support is optional, all name servers must be at least
> able to return the error response.
> Das bedeutet, dass Reverse-Mapping optional ist, aber der Server mit "Not
> Implemented" antworten muss wenn er es nicht unterstützt.

Das sind Anforderungen an DNS-Server, nicht an DNS-Aufloesung (sprich
Existenz bestimmter Records).

> Ich vermute, dass die wenigsten DNS-Server diesen Fehler zurückgeben.
> Dann müssen sie das Reverse-Mapping unterstützen.

Im Zusammenhang mit eurer Mailpolicy spielt aber nicht die Unterstuetzung
von Reverse-Mapping durch DNS-Server eine Rolle, sondern die Existenz
bestimmter RRs im DNS. Das ist etwas anderes. Du bist hier IMHO bei der
voellig falschen Baustelle.

[Juergen Ilse]

Hallo,

Claus-Dieter Schulmann <claus-diete...@web.de> wrote:

> RFC 1034 (3.7.2): Implementation of this service is optional in a name
> server ...
> Das würde bedeuten: Der DNS-Server darf bei Reverse-Anfragen nicht mit dem
> RCODE 3 antworten wenn es einen A-Record zu der IP-Adresse gibt.

Anscheinend hast du das reverse-mapping im DNS nicht verstanden. Fuer das
Rverse-Mapping spielen A-Records *absolut* *gar* *keine* Rolle. Reverse-
Mapping laeuft ueber PTR-Records, typischerweise sind fuer Forwaertsauf-
loesung einer Domain und Rverse-aufloesung der zustaendigen IP-Adresse
noch nicht einmal unbedingt die selben DNS-Server zustaendig. Die Struktur
fuer Reverseaufloesung liegt (bei IPv4) unterhalb der Domain .in-addr-arpa,
dieser Baum, im DNS ist voellig unabhaengig wie ddie Teilbaume fuer die
TLDs unter denen die Forwaertsaufloesung liegt.

[Burkhard Ott]

On Wed, 21 Mar 2012 05:35:30 +0000, Juergen P. Meier wrote:

> Burkhard Ott <news...@derith.de>:
>> Wobei 'valid' nicht unbedingt bedeutet das Du den fqdn via DNS
>> aufloesen kannst.
>
> Das ist Falsch. Richtig ist, dass "valid FQDN" im IETF Standard 13 genau
> definiert ist.

Hast Du mal einen Link, konnte da auf die schnelle nix finden. Das
einzige was geschrieben wird ist das es kein localer name sein darf, was
man sicher als extern aufloesbar interpretieren koennte, so aber nicht
dahsteht.

>
>>>> "The HELO receiver MAY verify that the HELO parameter really
>>>> corresponds to the IP address of the sender. However, the receiver
>>>> MUST NOT refuse to accept a message, even if the sender's HELO
>>>> command fails verification."
>>>>
>>>> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen
>>>> wenn der nicht im DNS existiert.
>
> Auch das ist Falsch. Der Empfaenger *DARF* *IMMER* und *JEDE* E-Mail aus
> Policy-Gruenden ablehnen - diese Freiheit gewaehrt der SMTP-Standard
> jedem Empfaenger.

"... the receiver MUST NOT refuse to

accept a message, even if the sender's HELO command fails verification."

Ich verstehe das MUST als ein 'unbedingt muss' oder 'aufgrund dessen
[fqdn im helo/ehlo kann nicht validiert werden] darf man die mail nicht
ablehnen.

> Der Empfaenger darf sogar aus Protokoll-Gruenden (Standardverletzung)
> ablehnen, wenn der Hello-Parameter kein gueltiger (d.h.
> verifizierbarer*) FQDN oder alternativ die IP-Addresse des Clients
> enthaelt, und muss sich nicht auf seine Policy berufen.

Das steht ja auch in der RFC so drinn. e.g wenn man statt helo/ehlo
einfach huhu sendet ist das klar eine Standardverletzung, ergo logisch
das niemand das akzeptiert.

>>> Ja. Wobei "local policy" natürlich der Trumpf ist, der alles schlägt.
>>
>> Das hat aber nichts mit der RFC zu tuen, worauf der OP erst verwies.
>
> Doch, aber bei ungueltigem Hello-Parameter kommt die Policy garnicht
> erst ins Spiel, das ist naemlich schon eine gewoehnliche Verletzung des
> Protokollstandards.

Unguelting ist der dich erst wen man beispielsweise xxx-xxx-xxx-xx-xx als
fqdn sendet, wobei xx.yy.zz oder yy.zz valide sein sollte, oder?

> * Im Sinne von IETF Standard 13. Was du vermutlich verwechwelst ist
> "valid FQDN" mit "loest auf einen IN A RR auf". Das ist aber dein
> eigenes Misverstaendnis.
>
> Ein FQDN /MUSS/ nicht auf einen A RR aufloesen, er DARF aber NICHT mit
> NXDOMAIN terminieren. Es muss /mindesetens/ NOERROR (empty RR set) sein.

Wenn Du keine reverse zone angelegt hast muss er NXDOMAIN liefern.

> Im Mailverkehr kann man (local policy!) darueberhinaus Fordern, dass der
> FQDN mindestens einen MX oder einen Address-Record hat.

Das steht so auch nicht da.

cheers

[Burkhard Ott]

On Wed, 21 Mar 2012 05:45:35 +0000, Juergen P. Meier wrote:

> begin 1 followup to Burkhard Ott <news...@derith.de>:
>> On Tue, 20 Mar 2012 20:45:09 +0000, Juergen Ilse wrote:
>>
>>>> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen
>>>> forward- und reverse-Lookup nicht, kriegst du heutzutage keinen
>>>> zuverlässigen E-Mail-Versand mehr hin.
>>>
>>> ... weil alle Welt kaputtes RFC-widriges Zeug als Mailserver ins Netz
>>> stellt (ja, auch viele grosse Mailprovider koennen so einen Bockmist
>>> verzapfen ...). Deswegen muss man sich diesem Unfug aber noch nicht
>>> unbedingt anschliessen ...
>>
>> Naja, RFC widrig kann man es ja nun auch nicht nennen. Die haben es
>> halt etwas anders interpretiert,lol.
>
> Tja, wenn man "MUST" mit "MUST NOT" fehlinterpretiert, dann ist halt
> jede Vernunft verloren.
>
> Mit solchen Spacken und Idioten will man andererseits nicht
> Kommunizieren, dafuer gibt es aber zum Glueck die einschlaegigen RBLs
> (rfc-ignorant etc.)
>
> Juergen

Gar keine Frage, ich vermute Du hast den Sarkasmus gefunden. Aber mal ein
real life Beispiel, fuer RFC gibts keine Uebersetzungen, also nur english.
Wenn Du nun Systeme im english sparchingen Raum mit z.Bsp. europaeischen
vergleichst wirst Du festellen das die Systeme im nicht english
sprachigen Raum viel naeher an den RFC's sind als im english sprachigen.
Besonders Nord Amerika, ist hierfuer ein wirklich gutes Beispiel und das
gilt nicht nur fuer smtp server.
Keine Frage das die dort viel Humbug machen, das Problem ergibt sich erst
wenn Du mehr Beschwerden ueber 'nicht funktionierende' Systeme hast und
Du beginnst denen zu erklaeren "In Absatz 123 RFC 456 ist definiert...",
waste of time, glaub mir das.

cheers

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Claus-Dieter Schulmann <claus-diete...@web.de> wrote:
>> In RFC 1036 im Abschnitt 6.4 steht:
>
> RFC1036 waere NNTP, da wird das nicht so drin stehen (ohne jetzt
> nachzusehen).

Du hast recht: RFC 1035
Ich gehe davon aus, dass Du das aber trotzdem gefunden hast.
Google war ja nicht kaputt.

>> Inverse queries are an optional part of the DNS. Name servers are not
>> required to support any form of inverse queries. If a name server
>> receives an inverse query that it does not support, it returns an error
>> response with the "Not Implemented" error set in the header. While
>> inverse query support is optional, all name servers must be at least
>> able to return the error response.
>> Das bedeutet, dass Reverse-Mapping optional ist, aber der Server mit "Not
>> Implemented" antworten muss wenn er es nicht unterstützt.
>
> Das sind Anforderungen an DNS-Server, nicht an DNS-Aufloesung (sprich
> Existenz bestimmter Records).

Im Prinzip ja.
Ich schliesse aber daraus: Wenn eine IP-Adresse im DNS verzeichnet ist darf
der zuständige DNS-Server bei der Abfrage des PTR-Records nicht mit RCODE 3
antworten.

Claus-Dieter

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Claus-Dieter Schulmann <claus-diete...@web.de> wrote:
>> RFC 1034 (3.7.2): Implementation of this service is optional in a name
>> server ...
>> Das würde bedeuten: Der DNS-Server darf bei Reverse-Anfragen nicht mit
>> dem RCODE 3 antworten wenn es einen A-Record zu der IP-Adresse gibt.
>
> Anscheinend hast du das reverse-mapping im DNS nicht verstanden. Fuer das

Du irrst.

> Rverse-Mapping spielen A-Records *absolut* *gar* *keine* Rolle. Reverse-

Natürlich hängen A- und PTR-Records zusammen: Typischerweise sollten sie
konsistent sein, so dass ein Round-Trip (A -> PTR -> A) zum ursprünglichen
Ergebnis führt.
Auch wenn das so direkt vermutlich in keiner RFC steht.

> Mapping laeuft ueber PTR-Records, typischerweise sind fuer Forwaertsauf-
> loesung einer Domain und Rverse-aufloesung der zustaendigen IP-Adresse
> noch nicht einmal unbedingt die selben DNS-Server zustaendig. Die Struktur
> fuer Reverseaufloesung liegt (bei IPv4) unterhalb der Domain
> .in-addr-arpa, dieser Baum, im DNS ist voellig unabhaengig wie ddie
> Teilbaume fuer die TLDs unter denen die Forwaertsaufloesung liegt.

Warum erklärst Du DNS hier?
Das kann jeder selber bei O-Reilly nachlesen.
Manchmal ist weniger mehr.

Rechtschreibfehler im Usenet lassen mich normalerweise kalt.
Forwärts ist dann aber dann doch zuviel des Guten.

Claus-Dieter

[Burkhard Ott]

On Wed, 21 Mar 2012 19:55:24 +0100, Claus-Dieter Schulmann wrote:

> Ich schliesse aber daraus: Wenn eine IP-Adresse im DNS verzeichnet ist
> darf der zuständige DNS-Server bei der Abfrage des PTR-Records nicht mit
> RCODE 3 antworten.

Wenn der record existiert muesstest Du eine 0 zureuckbekommen.

[Paul Muster]

On 21.03.2012 06:30, Juergen P. Meier wrote:
> Paul Muster <exp-3...@news.muster.de1.cc>:
>> On 20.03.2012 17:31, Burkhard Ott wrote:
>>
>>> Eigentlich ist der fqdn der im helo/ehlo gesendet wird, der der
>>> existieren muss. Wenn kein RR fuer die Adresse da ist von der aus der
>>> connect aufgebaut wurde, ist das Wurst. So zumindest die offiziellen
>>> RFC's, das das in der Praxis anderes gehandelt wird steht auf einem
>>> anderen Blatt.

>> Der _zweite Satz_ ist durch die Wirklichkeit widerlegt. Passen forward-
>> und reverse-Lookup nicht, kriegst du heutzutage keinen zuverlässigen
>> E-Mail-Versand mehr hin.
>
> Du hast den Satz nur nicht verstanden, genau das hat Burkhard naemlich
> gesagt.

Achso. In meinem Umfeld bedeutet "es ist [wW]urscht", dass es egal,
irrelevant, unwichtig ist. Er meinte also, das sei schlecht, negativ,
ungünstig.


mfG Paul

[Paul Muster]

On 21.03.2012 16:37, Burkhard Ott wrote:

> "... the receiver MUST NOT refuse to
> accept a message, even if the sender's HELO command fails verification."
>
> Ich verstehe das MUST als ein 'unbedingt muss' oder 'aufgrund dessen
> [fqdn im helo/ehlo kann nicht validiert werden] darf man die mail nicht
> ablehnen.

Danke für das Herausarbeiten. :-)


Viele Grüße

Paul

[Juergen Ilse]

Hallo,

Mir ist auch nicht klar, was er mit "Wenn eine IP-Adresse im DNS verzeichnet
ist" meint: Ein A-Record, in dem die IP-Adresse vorkommt? Ein PTR-Record,
der zu dieser IP-Adresse gehoert? Moeglicherweise ein C-Name, der auf den
Namen eines anderen PTR-Records verweist (man denke an RFC2317)?
Und nein, das ist nicht alles das selbe, und aus der Existenz des einen
folgt nicht zwingend die Existenz des anderen ...

[Burkhard Ott]

On Thu, 22 Mar 2012 07:46:15 +0000, Juergen Ilse wrote:

> Hallo,
>
> Burkhard Ott <news...@derith.de> wrote:
>> On Wed, 21 Mar 2012 19:55:24 +0100, Claus-Dieter Schulmann wrote:
>>> Ich schliesse aber daraus: Wenn eine IP-Adresse im DNS verzeichnet ist
>>> darf der zuständige DNS-Server bei der Abfrage des PTR-Records nicht
>>> mit RCODE 3 antworten.
>> Wenn der record existiert muesstest Du eine 0 zureuckbekommen.
>
> Mir ist auch nicht klar, was er mit "Wenn eine IP-Adresse im DNS
> verzeichnet ist" meint: Ein A-Record, in dem die IP-Adresse vorkommt?
> Ein PTR-Record, der zu dieser IP-Adresse gehoert? Moeglicherweise ein
> C-Name, der auf den Namen eines anderen PTR-Records verweist (man denke
> an RFC2317)? Und nein, das ist nicht alles das selbe, und aus der
> Existenz des einen folgt nicht zwingend die Existenz des anderen ...

Oooch das ist einfach, sorry for the confusion.

Wenn Du eine Zone fuer eine Domain angelegt hast und dort einen A record
oder CNAME record etc. hast und ein Client fragt diesen record ab dann
sollte Dein rcode 0 sein. Gleiches gilt fuer die reverse zone. Wenn nun
aber keine reverse zone (x.x.x.x.in-addr.arpa) angelegt worden ist
(sinnvoll nur bei authoritativen DNS), dann sollte Dein rcode 3 sein und
nicht wie faelschlich angenommen 4.

Hoffe ich habe mich jetzt klarer ausgedrueckt.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:
> On Thu, 22 Mar 2012 07:46:15 +0000, Juergen Ilse wrote:
>> Burkhard Ott <news...@derith.de> wrote:
>>> On Wed, 21 Mar 2012 19:55:24 +0100, Claus-Dieter Schulmann wrote:
>>>> Ich schliesse aber daraus: Wenn eine IP-Adresse im DNS verzeichnet ist
>>>> darf der zuständige DNS-Server bei der Abfrage des PTR-Records nicht
>>>> mit RCODE 3 antworten.
>>> Wenn der record existiert muesstest Du eine 0 zureuckbekommen.
>> Mir ist auch nicht klar, was er mit "Wenn eine IP-Adresse im DNS
>> verzeichnet ist" meint: Ein A-Record, in dem die IP-Adresse vorkommt?
>> Ein PTR-Record, der zu dieser IP-Adresse gehoert? Moeglicherweise ein
>> C-Name, der auf den Namen eines anderen PTR-Records verweist (man denke
>> an RFC2317)? Und nein, das ist nicht alles das selbe, und aus der
>> Existenz des einen folgt nicht zwingend die Existenz des anderen ...
> Oooch das ist einfach, sorry for the confusion.

Den Teil den du mir hier erklaerst, gatte ich verstanden.

> Wenn Du eine Zone fuer eine Domain angelegt hast und dort einen A record
> oder CNAME record etc. hast und ein Client fragt diesen record ab dann
> sollte Dein rcode 0 sein. Gleiches gilt fuer die reverse zone. Wenn nun
> aber keine reverse zone (x.x.x.x.in-addr.arpa) angelegt worden ist
> (sinnvoll nur bei authoritativen DNS), dann sollte Dein rcode 3 sein und
> nicht wie faelschlich angenommen 4.

Was mir unklar geblieben ist, ist eher, was mit "wenn eine IP-Adresse
im DNS verzeichnet ist" gemeint ist (und die Formulierung kam nicht
von dir).

> Hoffe ich habe mich jetzt klarer ausgedrueckt.

Deine Formulierungen waren es nicht, deren Vedeutung mir unklar blieb.

[Burkhard Ott]

On Thu, 22 Mar 2012 19:02:32 +0000, Juergen Ilse wrote:

> Deine Formulierungen waren es nicht, deren Vedeutung mir unklar blieb.

Ooops, sorry da war ich dann auf dem Holzweg.

cheers

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Was mir unklar geblieben ist, ist eher, was mit "wenn eine IP-Adresse
> im DNS verzeichnet ist" gemeint ist (und die Formulierung kam nicht
> von dir).

Gemeint ist: Wenn eine IP-Adresse im DNS eingetragen wird ist es nach meiner
Meinung nicht ausreichend, nur einen A-Record einzutragen sondern es muss
mindestens auch ein PTR-Record eingetragen werden.

Claus-Dieter

[Burkhard Ott]

Wenn Du das muss mit kannst tauschts wirds richtig, PTR records sind
optional, also eine 'kann' Entscheidung. Auch wenn das huebscher
aussieht, du kannst niemanden dazu zwingen diese fuer sein Netz zu
setzten. Genauso wenn er mehrere PTR records zu einer IP hat, Du kannst
Dich darueber Aergern aber mehr auch nicht.

cheers

[Claus-Dieter Schulmann]

Nach STD0013 sind inverse queries optional.
Gleichzeitig fordert STD0013 aber auch, dass bei inverse queries der RCODE 4
(Not Implemented) zurückgegeben werden muss wenn man sich auf die
Optionalität beruft.

Wenn ich Dich richtig verstehe meinst Du: Die Eintragung von PTR-Records ist
optional. Das ist etwas ganz anderes. Damit macht die Erwähnung von "Not
Implemented" in STD0013 nämlich keinen Sinn.


Ich habe jetzt nochmal die entsprechenden Stellen aus STD0013 rausgesucht.
Der entscheidende Punkt ist jeweils die Erwähnung des RCODE 4 (Not
Implemented).
Bitte erkläre mir wie Du das verstehst.


1. Implementation of this service is optional in a name server, but all
name servers must at least be able to understand an inverse query
message and return a not-implemented error response.

Mit "this service" ist "inverse queries" gemeint.


2. If a name server receives an inverse query that it does not support, it

returns an error response with the "Not Implemented" error set in the
header. While inverse query support is optional, all name servers must be
at least able to return the error response.

Claus-Dieter

[Burkhard Ott]

On Thu, 22 Mar 2012 22:49:55 +0100, Claus-Dieter Schulmann wrote:

> Burkhard Ott wrote:
>
>> On Thu, 22 Mar 2012 21:03:38 +0100, Claus-Dieter Schulmann wrote:
>>
>>> Juergen Ilse wrote:
>>>
>>>> Was mir unklar geblieben ist, ist eher, was mit "wenn eine IP-Adresse
>>>> im DNS verzeichnet ist" gemeint ist (und die Formulierung kam nicht
>>>> von dir).
>>>
>>> Gemeint ist: Wenn eine IP-Adresse im DNS eingetragen wird ist es nach
>>> meiner Meinung nicht ausreichend, nur einen A-Record einzutragen
>>> sondern es muss mindestens auch ein PTR-Record eingetragen werden.
>>
>> Wenn Du das muss mit kannst tauschts wirds richtig, PTR records sind
>> optional, also eine 'kann' Entscheidung. Auch wenn das huebscher
>> aussieht, du kannst niemanden dazu zwingen diese fuer sein Netz zu
>> setzten. Genauso wenn er mehrere PTR records zu einer IP hat, Du kannst
>> Dich darueber Aergern aber mehr auch nicht.
>
> Nach STD0013 sind inverse queries optional. Gleichzeitig fordert STD0013
> aber auch, dass bei inverse queries der RCODE 4 (Not Implemented)
> zurückgegeben werden muss wenn man sich auf die Optionalität beruft.

Nee, rcode 4 sendet man nur wenn ein 'Feature' nicht implentiert wurde,
wenn Dein DNS in der Lage ist diese Anfragen zu beantworten aber es gibt
keinen Zone Eintrag sendet Dir der DNS eine 3, wenn er versteht was Deine
query will (und das muss er) aber er das feature generell nicht
implentiert hat, bekommst Du eine 4.

> Wenn ich Dich richtig verstehe meinst Du: Die Eintragung von PTR-Records
> ist optional. Das ist etwas ganz anderes. Damit macht die Erwähnung von
> "Not Implemented" in STD0013 nämlich keinen Sinn.

Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion generell
nicht existiert aber in der DNS query 'verstanden' wurde, sendet der DNS
rcode 4.

>
> Ich habe jetzt nochmal die entsprechenden Stellen aus STD0013
> rausgesucht. Der entscheidende Punkt ist jeweils die Erwähnung des RCODE
> 4 (Not Implemented).
> Bitte erkläre mir wie Du das verstehst.

siehe oben.

>
> 1. Implementation of this service is optional in a name server, but all
> name servers must at least be able to understand an inverse query
> message and return a not-implemented error response.
>
> Mit "this service" ist "inverse queries" gemeint.

Es sind 2 unteschiedl. Schuhe, wenn der DNS weiss was Du willst aber
diese Funktion nicht unterstuetzt oder ob er die Funktion unterstuetzt
aber keinen Eintrag findet um Deine query zu beantworten.

>
> 2. If a name server receives an inverse query that it does not support,
> it returns an error response with the "Not Implemented" error set in the
> header. While inverse query support is optional, all name servers must
> be at least able to return the error response.

Jau, kurz gesagt er weiss was Du willst kanns aber nicht und das sagt er
Dir mit RCODE 4.

cheers

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Thu, 22 Mar 2012 22:49:55 +0100, Claus-Dieter Schulmann wrote:
>
> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion generell
> nicht existiert aber in der DNS query 'verstanden' wurde, sendet der DNS
> rcode 4.

Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).

Bei diesen weggelassenen PTR-Records würde Dein DNS-Server RCODE 3
zurückgeben.

Das widerspricht aber beiden zitierten Stellen aus STD0013 weil dort RCODE 4
gefordert ist.

Fazit: PTR-Records müssen eingetragen werden oder der DNS-Server muss RCODE
4 zurückgeben.
Da wir aber keinen DNS-Server kennen, der RCODE 4 zurückgibt bleibt nur eine
Möglichkeit: PTR-Records müssen eingetragen werden.

Claus-Dieter

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

Ausserdem liegt der zugehoerige PTR-Record oftmals nicht nur auf einem
anderen DNS-Server als der A-Record, sondern pftmals sogar bei einem ganz
anderen Provider ...

[Burkhard Ott]

On Thu, 22 Mar 2012 23:56:27 +0100, Claus-Dieter Schulmann wrote:

> Burkhard Ott wrote:
>
>> On Thu, 22 Mar 2012 22:49:55 +0100, Claus-Dieter Schulmann wrote:
>>
>> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion
>> generell nicht existiert aber in der DNS query 'verstanden' wurde,
>> sendet der DNS rcode 4.
>
> Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
> einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).
>
> Bei diesen weggelassenen PTR-Records würde Dein DNS-Server RCODE 3
> zurückgeben.
>
> Das widerspricht aber beiden zitierten Stellen aus STD0013 weil dort
> RCODE 4 gefordert ist.

Nochmal lesen, das steht da so nicht.

> Fazit: PTR-Records müssen eingetragen werden oder der DNS-Server muss
> RCODE 4 zurückgeben.
> Da wir aber keinen DNS-Server kennen, der RCODE 4 zurückgibt bleibt nur
> eine Möglichkeit: PTR-Records müssen eingetragen werden.

Falsch.

[Juergen Ilse]

Hallo,

Claus-Dieter Schulmann <claus-diete...@web.de> wrote:

> Burkhard Ott wrote:
>> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion generell
>> nicht existiert aber in der DNS query 'verstanden' wurde, sendet der DNS
>> rcode 4.
> Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
> einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).

Trotz mehrfacher Hinweise bist du noch immer an der voellig falschen
Baustelle. Der optionale Support fuer reverse-queries in DNS-Server
Implementierungen /das, worauf du hier herumreitest) hat *rein* *gar*
*nichts* damit zu tun, ob die Existenz von PTR-Records erforderlich
oder opzional ist. IIRC gibt es keinen RFC, der *zwingend* die Existenz
von PTR-Records vorschreibt. Wenn du der Meinung bist, die Nicht-Existenz
von PTR-Records sei ein RFC-Verstoss, solltest du das anhand von RFC-
Zitaten belegen koennen. Einen solchen Beleg habe ich von dir noch nicht
gelesen.

> Bei diesen weggelassenen PTR-Records würde Dein DNS-Server RCODE 3
> zurückgeben.
> Das widerspricht aber beiden zitierten Stellen aus STD0013 weil dort RCODE 4
> gefordert ist.

Falsch. RCODE 4 ist fuer den Fall vorgeschrieben, dass Reverse-Queries
vom DNS-Server nicht implementiert sind. Darueber, welche RCODES zulaessig
sind, wenn Reverse-Queries unterstuetzt werden, steht dort nichts.

> Fazit: PTR-Records müssen eingetragen werden oder der DNS-Server muss RCODE
> 4 zurückgeben.

Nein, deine Interpretation ist hier flacsh.

[Juergen P. Meier]

to Burkhard Ott <news...@derith.de>:

>>
>> Nach STD0013 sind inverse queries optional. Gleichzeitig fordert STD0013
>> aber auch, dass bei inverse queries der RCODE 4 (Not Implemented)
>> zurückgegeben werden muss wenn man sich auf die Optionalität beruft.
>
> Nee, rcode 4 sendet man nur wenn ein 'Feature' nicht implentiert wurde,

Korrekt. Und PTR ist ein Feature, das als ganzes Optional ist.

Falsch ist hingegen zu glauben, dass einzelne PTR Records optional
waeren, das ist ein leider weit verbreiteter Irrglaube.

> Jau, kurz gesagt er weiss was Du willst kanns aber nicht und das sagt er
> Dir mit RCODE 4.

Andernfalls muss er einen PTR RR liefern.

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Claus-Dieter Schulmann <claus-diete...@web.de> wrote:
>> Burkhard Ott wrote:
>>> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion
>>> generell nicht existiert aber in der DNS query 'verstanden' wurde,
>>> sendet der DNS rcode 4.
>> Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
>> einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).
>
> Trotz mehrfacher Hinweise bist du noch immer an der voellig falschen
> Baustelle. Der optionale Support fuer reverse-queries in DNS-Server
> Implementierungen /das, worauf du hier herumreitest) hat *rein* *gar*
> *nichts* damit zu tun, ob die Existenz von PTR-Records erforderlich
> oder opzional ist. IIRC gibt es keinen RFC, der *zwingend* die Existenz
> von PTR-Records vorschreibt. Wenn du der Meinung bist, die Nicht-Existenz

Soweit ich weiss gibt es auch keinen RFC, der *zwingend* die Existenz von
A-Records vorschreibt.
Wenn Du anderer Meinung bist solltest Du das anhand von RFC-Zitaten belegen
können.

> von PTR-Records sei ein RFC-Verstoss, solltest du das anhand von RFC-
> Zitaten belegen koennen. Einen solchen Beleg habe ich von dir noch nicht
> gelesen.

In STD0013 sind A-Records erklärt.
In STD0013 steht nirgends, dass A-Records eingetragen werden müssen.
In STD0013 steht nirgends, dass einzelne A-Records optional wären.
Daraus schliesse ich, dass einzelne A-Records nicht optional sind.
IP-Namen müssen deshalb als A-Records eingetragen werden.

Ich tausche jetzt A gegen PTR (und Namen gegen Adressen) aus:
In STD0013 sind PTR-Records erklärt.
In STD0013 steht nirgends, dass PTR-Records eingetragen werden müssen.
In STD0013 steht nirgends, dass einzelne PTR-Records optional wären.
Daraus schliesse ich, dass einzelne PTR-Records nicht optional sind.
IP-Adressen müssen deshalb als PTR-Records eingetragen werden.

Wenn Du anderer Meinung bist zeige mir bitte wo steht, dass einzelne PTR-
Records optional sind.

Claus-Dieter

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Thu, 22 Mar 2012 23:56:27 +0100, Claus-Dieter Schulmann wrote:
>
>> Burkhard Ott wrote:
>>
>>> On Thu, 22 Mar 2012 22:49:55 +0100, Claus-Dieter Schulmann wrote:
>>>
>>> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion
>>> generell nicht existiert aber in der DNS query 'verstanden' wurde,
>>> sendet der DNS rcode 4.
>>
>> Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
>> einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).
>>
>> Bei diesen weggelassenen PTR-Records würde Dein DNS-Server RCODE 3
>> zurückgeben.
>>
>> Das widerspricht aber beiden zitierten Stellen aus STD0013 weil dort
>> RCODE 4 gefordert ist.
>
> Nochmal lesen, das steht da so nicht.

Ich habe es nochmal gelesen, es steht in STD0013, nur nicht ganz direkt.
Auch in RFC 1912 sind PTR-Records erwähnt: For every IP address, there
should be a matching PTR record in the in-addr.arpa domain.
Solche RFCs wie 1912 dienen üblicherweise der Klarstellung.

Zeige mir im Gegenzug doch einfach mal die Stelle wo steht, dass einzelne
PTR-Records optional sind.

Claus-Dieter

[Juergen Ilse]

Hallo,

Claus-Dieter Schulmann <claus-diete...@web.de> wrote:
> Burkhard Ott wrote:
>> On Thu, 22 Mar 2012 23:56:27 +0100, Claus-Dieter Schulmann wrote:
>>> Burkhard Ott wrote:
>>>> On Thu, 22 Mar 2012 22:49:55 +0100, Claus-Dieter Schulmann wrote:
>>>> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion
>>>> generell nicht existiert aber in der DNS query 'verstanden' wurde,
>>>> sendet der DNS rcode 4.
>>> Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
>>> einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).
>>> Bei diesen weggelassenen PTR-Records würde Dein DNS-Server RCODE 3
>>> zurückgeben.
>>> Das widerspricht aber beiden zitierten Stellen aus STD0013 weil dort
>>> RCODE 4 gefordert ist.
>> Nochmal lesen, das steht da so nicht.
> Ich habe es nochmal gelesen, es steht in STD0013, nur nicht ganz direkt.

Es steht dort gar nicht drin. Der dort behandeltze und von dir hier zitierte
Fall befasst sich *ausschliesslich* damit, was ein DNS-Server tun muss, wenn
er Reverse-Queries erhaelt aber diese nicht unterstuetzt. Fuer alle anderen
Faelle ist der von dir angesprochene Abschnitt nicht relevant.

> Auch in RFC 1912 sind PTR-Records erwähnt: For every IP address, there
> should be a matching PTR record in the in-addr.arpa domain.
> Solche RFCs wie 1912 dienen üblicherweise der Klarstellung.

Richtig, und Klrgestellt wird darin, dass man mit Problemen rechnen muss,
weil andere Systeme eben manche Situationen nicht RFC-gemaess abhandeln
und es deshalb zu Problemen kommen koennte. Daher die *Empfehlung* (nicht
etwa zwingende Forderung) Reverse-Eintraege zu haben. Allerdings suchst
du auch in RFC1912 vergeblich nach der Anforderung, dass der Name im
Reverse-Mapping zwingend der Name im forward-Mapping sein muss. Der Satz
"Make sure your PTR and A records match." koennte zwar als solcher Hinweis
betrachtet werden, er ist es aber nicht zwangslaeufig, da dieses "match"
an dieser Stelle nicht weiter erlaeutert wird. Insbesondere wird nicht
der (gar nicht so seltene) Fall behandelt, dass es fuer eine IP-Adresse
mehrere A-Records (mit unterschiedlichen Namen) gibt.

> Zeige mir im Gegenzug doch einfach mal die Stelle wo steht, dass einzelne
> PTR-Records optional sind.

Sie sind so lange als optional anzusehen, wie es keinen Beleg fuer die
zwingende Forderung nach Existenz des PTR-Records gibt. Die zwingende
Forderung hast du bishher noch nicht aufgezeigt. Wenn da also nicht mehr
kommt, muss man davon ausgehen, dass PTR-Records gemaess RFC optional sind.
(dass die Praxis teils anders aussieht, wurde bereits erlaeutert und an
der von dir zitierten stelle auch in RFC1912 erwaehnt).

[Juergen P. Meier]

Juergen Ilse <jue...@usenet-verwaltung.de>:

>> Zeige mir im Gegenzug doch einfach mal die Stelle wo steht, dass einzelne
>> PTR-Records optional sind.
>
> Sie sind so lange als optional anzusehen, wie es keinen Beleg fuer die
> zwingende Forderung nach Existenz des PTR-Records gibt. Die zwingende

Die Bedeutung von "should" in solchen RFCs wurde zwar erst spaeter
in eigenem RFC klargestellt, dies geschah aber u.A. auch um solchen
Misverstaendnissen vorzubeugen.

Richtig ist, dass PTRs weggelassen werden duerfen, wenn man dafuer
triftige Gruende hat. (z.B. wenn es keine eindeutige Zuordnung gibt).

Genauso richtig ist, dass man triftige Gruende haben muss, wenn man
wegen fehlender PTRs eine SMTP Kommunikation ablehnt. (z.B. wegen
Spam-Filterung).

[Burkhard Ott]

On Thu, 22 Mar 2012 23:31:45 +0000, Juergen Ilse wrote:

> Claus-Dieter Schulmann <claus-diete...@web.de> wrote:

>> Bei diesen weggelassenen PTR-Records würde Dein DNS-Server RCODE 3
>> zurückgeben.
>> Das widerspricht aber beiden zitierten Stellen aus STD0013 weil dort
>> RCODE 4 gefordert ist.
>
> Falsch. RCODE 4 ist fuer den Fall vorgeschrieben, dass Reverse-Queries
> vom DNS-Server nicht implementiert sind. Darueber, welche RCODES
> zulaessig sind, wenn Reverse-Queries unterstuetzt werden, steht dort
> nichts.

Die stehen im RFC 1035 Page 26, falls Du noch Interesse hast.

cheers

[Burkhard Ott]

On Fri, 23 Mar 2012 11:00:11 +0100, Claus-Dieter Schulmann wrote:

> Juergen Ilse wrote:
>
>> Claus-Dieter Schulmann <claus-diete...@web.de> wrote:
>>> Burkhard Ott wrote:
>>>> Jein, ich denke wir reden am Thema vorbei. Nur wenn die Funktion
>>>> generell nicht existiert aber in der DNS query 'verstanden' wurde,
>>>> sendet der DNS rcode 4.
>>> Du berufst Dich darauf, PTR-Records wären optional, d. h. Du dürftest
>>> einzelne PTR-Records weglassen (so habe ich Dich bisher verstanden).
>>
>> Trotz mehrfacher Hinweise bist du noch immer an der voellig falschen
>> Baustelle. Der optionale Support fuer reverse-queries in DNS-Server
>> Implementierungen /das, worauf du hier herumreitest) hat *rein* *gar*
>> *nichts* damit zu tun, ob die Existenz von PTR-Records erforderlich
>> oder opzional ist. IIRC gibt es keinen RFC, der *zwingend* die Existenz
>> von PTR-Records vorschreibt. Wenn du der Meinung bist, die
>> Nicht-Existenz
>
> Soweit ich weiss gibt es auch keinen RFC, der *zwingend* die Existenz
> von A-Records vorschreibt.
> Wenn Du anderer Meinung bist solltest Du das anhand von RFC-Zitaten
> belegen können.

Noe zwingen kann Dich auch keiner eine A record anzulegen, sicher niemand
kann Deinen Hostname via DNS aufloesen, aber manchmal will man das ja
auch nicht.

>> von PTR-Records sei ein RFC-Verstoss, solltest du das anhand von RFC-
>> Zitaten belegen koennen. Einen solchen Beleg habe ich von dir noch
>> nicht gelesen.
>
> In STD0013 sind A-Records erklärt.
> In STD0013 steht nirgends, dass A-Records eingetragen werden müssen. In
> STD0013 steht nirgends, dass einzelne A-Records optional wären. Daraus
> schliesse ich, dass einzelne A-Records nicht optional sind. IP-Namen
> müssen deshalb als A-Records eingetragen werden.

Wow wilde Logik, gibts ein Gesetz das genau aussagt das Du niemanden
mit .45 in den Kopf schiessen darfst? Deiner Logik nach wuerde das
bedeuten es ist erlaubt. (scnr)

> Ich tausche jetzt A gegen PTR (und Namen gegen Adressen) aus: In STD0013
> sind PTR-Records erklärt. In STD0013 steht nirgends, dass PTR-Records
> eingetragen werden müssen. In STD0013 steht nirgends, dass einzelne
> PTR-Records optional wären.

Wenn da kein MUST steht, bedeutet es das Du das machen kannst wie Du
froehlich bist, die Betonung steht auf 'kannst'. Wenn da steht 'should'n
heisst das, es waere schoen aber Du musst es nicht, also es ist optional.

> Daraus schliesse ich, dass einzelne
> PTR-Records nicht optional sind. IP-Adressen müssen deshalb als
> PTR-Records eingetragen werden.

Falsch.

> Wenn Du anderer Meinung bist zeige mir bitte wo steht, dass einzelne
> PTR- Records optional sind.

RFC 1035 vom November '87 ist da recht eindeutig.

cheers

[Burkhard Ott]

On Fri, 23 Mar 2012 11:00:32 +0100, Claus-Dieter Schulmann wrote:

> Ich habe es nochmal gelesen, es steht in STD0013, nur nicht ganz direkt.
> Auch in RFC 1912 sind PTR-Records erwähnt: For every IP address, there
> should be a matching PTR record in the in-addr.arpa domain. Solche RFCs
> wie 1912 dienen üblicherweise der Klarstellung.
>
> Zeige mir im Gegenzug doch einfach mal die Stelle wo steht, dass
> einzelne PTR-Records optional sind.

RFC 1035 ist der RFC welcher beschreibt wie man seinen DNS (server als
auch Client) zusammenstricken sollte, bisher habe ich auch noch keinen
DNS gesehen der die von Dir aufgefuehrten 'Schnitzer' hat.

cheers

[Burkhard Ott]

On Fri, 23 Mar 2012 10:54:27 +0000, Juergen Ilse wrote:

>> Zeige mir im Gegenzug doch einfach mal die Stelle wo steht, dass
>> einzelne PTR-Records optional sind.
>
> Sie sind so lange als optional anzusehen, wie es keinen Beleg fuer die
> zwingende Forderung nach Existenz des PTR-Records gibt. Die zwingende
> Forderung hast du bishher noch nicht aufgezeigt. Wenn da also nicht mehr
> kommt, muss man davon ausgehen, dass PTR-Records gemaess RFC optional
> sind. (dass die Praxis teils anders aussieht, wurde bereits erlaeutert
> und an der von dir zitierten stelle auch in RFC1912 erwaehnt).

RFC 1035 ist da sehr eindeutig, warum Claus-Dieter glaubt im Recht zu
sein obwohl die RFC's seine Aussagen widerlegen und obwohl mehr als eine
Person ihn (freundlich) auf seine falsche Interpretierung hingewiesen
hat, keine Ahnung.

cheers

[Burkhard Ott]

On Fri, 23 Mar 2012 05:34:37 +0000, Juergen P. Meier wrote:

> to Burkhard Ott <news...@derith.de>:
>>>
>>> Nach STD0013 sind inverse queries optional. Gleichzeitig fordert
>>> STD0013 aber auch, dass bei inverse queries der RCODE 4 (Not
>>> Implemented) zurückgegeben werden muss wenn man sich auf die
>>> Optionalität beruft.
>>
>> Nee, rcode 4 sendet man nur wenn ein 'Feature' nicht implentiert wurde,
>
> Korrekt. Und PTR ist ein Feature, das als ganzes Optional ist.
>
> Falsch ist hingegen zu glauben, dass einzelne PTR Records optional
> waeren, das ist ein leider weit verbreiteter Irrglaube.

Nein.

>> Jau, kurz gesagt er weiss was Du willst kanns aber nicht und das sagt
>> er Dir mit RCODE 4.
>
> Andernfalls muss er einen PTR RR liefern.

Nope, RFC 1034 Page 26 ist da sehr eindeutig.

cheers

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> On Fri, 23 Mar 2012 11:00:11 +0100, Claus-Dieter Schulmann wrote:

>> Soweit ich weiss gibt es auch keinen RFC, der *zwingend* die Existenz
>> von A-Records vorschreibt.
>> Wenn Du anderer Meinung bist solltest Du das anhand von RFC-Zitaten
>> belegen können.
>
> Noe zwingen kann Dich auch keiner eine A record anzulegen, sicher niemand
> kann Deinen Hostname via DNS aufloesen, aber manchmal will man das ja
> auch nicht.

Das hat aber nichts mit der Frage zu tun ob das Eintragen einzelner PTR-
Records nach STD0013 optional ist.

>> In STD0013 sind A-Records erklärt.
>> In STD0013 steht nirgends, dass A-Records eingetragen werden müssen. In
>> STD0013 steht nirgends, dass einzelne A-Records optional wären. Daraus
>> schliesse ich, dass einzelne A-Records nicht optional sind. IP-Namen
>> müssen deshalb als A-Records eingetragen werden.
>
> Wow wilde Logik, gibts ein Gesetz das genau aussagt das Du niemanden
> mit .45 in den Kopf schiessen darfst? Deiner Logik nach wuerde das
> bedeuten es ist erlaubt. (scnr)

Ich verstehe jetzt nicht was Du mit diesem Ausflug ins Strafrecht sagen
willst.
Vielleicht nur ausweichen?

> Wenn da kein MUST steht, bedeutet es das Du das machen kannst wie Du
> froehlich bist, die Betonung steht auf 'kannst'. Wenn da steht 'should'n
> heisst das, es waere schoen aber Du musst es nicht, also es ist optional.

Nö, das trifft es sicher nicht.
In RFC 2119 ist erklärt wie "SHOULD" zu verstehen ist: Es ist eine dringende
Empfehlung solange Du keinen triftigen Grund hast, Dich nicht daran zu
halten.
Originaler Wortlaut: the full implications must be understood and carefully
weighed before choosing a different course.

>> Daraus schliesse ich, dass einzelne
>> PTR-Records nicht optional sind. IP-Adressen müssen deshalb als
>> PTR-Records eingetragen werden.
>
> Falsch.

Hier ist Usenet: Bitte liefere eine Begründung für diese Behauptung.

>> Wenn Du anderer Meinung bist zeige mir bitte wo steht, dass einzelne
>> PTR- Records optional sind.
>
> RFC 1035 vom November '87 ist da recht eindeutig.

Zum wiederholten Mal bitte ich Dich, mir zu zeigen wo in RFC 1035 steht,
dass einzelne PTR-Records optional seien.

Claus-Dieter

[Claus-Dieter Schulmann]

Juergen Ilse wrote:

> Claus-Dieter Schulmann <claus-diete...@web.de> wrote:

>> Ich habe es nochmal gelesen, es steht in STD0013, nur nicht ganz direkt.
>
> Es steht dort gar nicht drin. Der dort behandeltze und von dir hier
> zitierte Fall befasst sich *ausschliesslich* damit, was ein DNS-Server tun
> muss, wenn er Reverse-Queries erhaelt aber diese nicht unterstuetzt. Fuer
> alle anderen Faelle ist der von dir angesprochene Abschnitt nicht
> relevant.

Richtig.
Dieser Satz ist für die üblichen DNS-Server irrelevant.
Damit sind alle Stellen in STD0013, wo PTR-Records im Zusammenhang mit dem
Wort "optional" erwähnt werden, irrelevant (wenn man von exotischen DNS-
Servern absieht).
Damit kommt meine Frage, die Du bisher nicht beantworten konntest, erneut:
Woraus leitest Du ab, einzelne PTR-Records seien optional?

>> Auch in RFC 1912 sind PTR-Records erwähnt: For every IP address, there
>> should be a matching PTR record in the in-addr.arpa domain.
>> Solche RFCs wie 1912 dienen üblicherweise der Klarstellung.
>
> Richtig, und Klrgestellt wird darin, dass man mit Problemen rechnen muss,
> weil andere Systeme eben manche Situationen nicht RFC-gemaess abhandeln
> und es deshalb zu Problemen kommen koennte. Daher die *Empfehlung* (nicht

Du hast "SHOULD" in RFC 2119 nachgelesen?
"Empfehlung" trifft es eher nicht.
"SHOULD" ist ein Muss solange Du keinen triftigen Grund hast, dieser
"Empfehlung" nicht zu folgen.
Das hat Jürgen P. M. aber auch schon geschrieben.

> etwa zwingende Forderung) Reverse-Eintraege zu haben. Allerdings suchst
> du auch in RFC1912 vergeblich nach der Anforderung, dass der Name im
> Reverse-Mapping zwingend der Name im forward-Mapping sein muss. Der Satz

Du weichst aus.
Im Moment geht es nicht um die Konsistenz mit A-Records sondern darum ob
einzelne PTR-Records optional sind.

> "Make sure your PTR and A records match." koennte zwar als solcher Hinweis
> betrachtet werden, er ist es aber nicht zwangslaeufig, da dieses "match"
> an dieser Stelle nicht weiter erlaeutert wird. Insbesondere wird nicht

Du begibst Dich hier auf das Niveau: Jedes Wort, das nicht genauestens in
einer RFC festgelegt ist akzeptierst Du nicht.
Auf diese Art kannst Du jede RFC in Frage stellen.
Ich war bisher der Meinung, dass Du sowas nicht nötig hättest.

> der (gar nicht so seltene) Fall behandelt, dass es fuer eine IP-Adresse
> mehrere A-Records (mit unterschiedlichen Namen) gibt.

Du weichst wieder aus.
Die Frage war: Sind einzelne PTR-Records optional?

>> Zeige mir im Gegenzug doch einfach mal die Stelle wo steht, dass einzelne
>> PTR-Records optional sind.
>
> Sie sind so lange als optional anzusehen, wie es keinen Beleg fuer die
> zwingende Forderung nach Existenz des PTR-Records gibt. Die zwingende

Andersrum wird ein Schuh draus.
Wenn in keinem einzigen Standard steht, dass sie optional seien, sind sie
eben *nicht* optional.

> Forderung hast du bishher noch nicht aufgezeigt. Wenn da also nicht mehr
> kommt, muss man davon ausgehen, dass PTR-Records gemaess RFC optional

Wie kommst Du auf die Idee, einzelne PTR-Records seien optional wenn es
nirgends steht?

> sind. (dass die Praxis teils anders aussieht, wurde bereits erlaeutert und
> an der von dir zitierten stelle auch in RFC1912 erwaehnt).

In STD0013 sind PTR-Records erklärt.
In STD0013 steht nirgends, dass einzelne PTR-Records optional seien.
Trotzdem beharrst Du auf dem Standpunkt sie seien optional.
Dann bist Du in der Beweispflicht.

Deshalb ein weiteres Mal: Bitte zeige die Stelle wo steht, dass einzelne
PTR-Records optional sind.

Claus-Dieter

[Burkhard Ott]

On Fri, 23 Mar 2012 18:40:41 +0100, Claus-Dieter Schulmann wrote:

> Burkhard Ott wrote:
>
>> On Fri, 23 Mar 2012 11:00:11 +0100, Claus-Dieter Schulmann wrote:
>
>>> Soweit ich weiss gibt es auch keinen RFC, der *zwingend* die Existenz
>>> von A-Records vorschreibt.
>>> Wenn Du anderer Meinung bist solltest Du das anhand von RFC-Zitaten
>>> belegen können.
>>
>> Noe zwingen kann Dich auch keiner eine A record anzulegen, sicher
>> niemand kann Deinen Hostname via DNS aufloesen, aber manchmal will man
>> das ja auch nicht.
>
> Das hat aber nichts mit der Frage zu tun ob das Eintragen einzelner PTR-
> Records nach STD0013 optional ist.

Du kannst lesen? Ich qoute mal ausser der Reihe, wenn Du in dem Satz
etwas ueber PTR records findest darfst Du dir 5 Mio. anlegen, ja.

>>> Soweit ich weiss gibt es auch keinen RFC, der *zwingend* die Existenz
>>> von A-Records vorschreibt.
>>> Wenn Du anderer Meinung bist solltest Du das anhand von RFC-Zitaten
>>> belegen können.

So wo steht das was von PTR records?

>>> In STD0013 sind A-Records erklärt.
>>> In STD0013 steht nirgends, dass A-Records eingetragen werden müssen.
>>> In STD0013 steht nirgends, dass einzelne A-Records optional wären.
>>> Daraus schliesse ich, dass einzelne A-Records nicht optional sind.
>>> IP-Namen müssen deshalb als A-Records eingetragen werden.
>>
>> Wow wilde Logik, gibts ein Gesetz das genau aussagt das Du niemanden
>> mit .45 in den Kopf schiessen darfst? Deiner Logik nach wuerde das
>> bedeuten es ist erlaubt. (scnr)
>
> Ich verstehe jetzt nicht was Du mit diesem Ausflug ins Strafrecht sagen
> willst.
> Vielleicht nur ausweichen?

Nein keinesfalls, es soll Dir Deinen Irrtum verdeutlichen. Nicht alles
was explizient verboten ist, ist automatisch erlaubt und umgekehrt.

>> Wenn da kein MUST steht, bedeutet es das Du das machen kannst wie Du
>> froehlich bist, die Betonung steht auf 'kannst'. Wenn da steht
>> 'should'n heisst das, es waere schoen aber Du musst es nicht, also es
>> ist optional.
>
> Nö, das trifft es sicher nicht.
> In RFC 2119 ist erklärt wie "SHOULD" zu verstehen ist: Es ist eine
> dringende Empfehlung solange Du keinen triftigen Grund hast, Dich nicht
> daran zu halten.

Und was ist ein triftiger Grund? Einer ware z.Bsp. will ich nicht ein
anderer mach ich nicht. Ausserdem steht das da ganz anders:

SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and

carefully weighed before choosing a different course.

Wie gesagt, es ist empfohlen aber Du kannst keinem mir der RFC auf den
Sack gehen weil er keine PTR records hat. Nebenbei wurde diese
Terminilogie in RFC 1035 und 1034 gar nicht verwendet. Ich denke mal
jetzt willst Du nur rumtrollen.

> Originaler Wortlaut: the full implications must be understood and
> carefully weighed before choosing a different course.
>
>>> Daraus schliesse ich, dass einzelne
>>> PTR-Records nicht optional sind. IP-Adressen müssen deshalb als
>>> PTR-Records eingetragen werden.
>>
>> Falsch.

Ich habe Dir nun mehrfach den RFC 1035 page 26 als Literatur
vorgeschlagen, mein Verdacht das Du einTroll bist erhaertet sich.

> Hier ist Usenet: Bitte liefere eine Begründung für diese Behauptung.

Genau, deshalb lies die RFC 1035 und versuche zu verstehen, alles andere
ist keine Diskussionsgrundlage mehr und ich werde Dir nicht mehr
antworten.

cheers

[Claus-Dieter Schulmann]

Burkhard Ott wrote:

> Du kannst lesen? Ich qoute mal ausser der Reihe, wenn Du in dem Satz

Beleidigung deinerseits -> EOD von mir

> Ich habe Dir nun mehrfach den RFC 1035 page 26 als Literatur
> vorgeschlagen, mein Verdacht das Du einTroll bist erhaertet sich.

Beleidigung deinerseits -> EOD von mir

Claus-Dieter

[Burkhard Ott]

Der letzte Versuch:

RFC1912:


...For every IP address, there

should be a matching PTR record in the in-addr.arpa domain.

"should be" Du kannst wenn Du willst aber Du musst nicht.

Wenn Du PTR records hast:

.. PTR records must point back to a valid A record, not a alias defined
by a CNAME.

must= es ist vorgeschrieben das diese auf einen valide A record
aufloesbar sind kein canonical name.

Noch eindeutiger gehts nun wirklich nicht.

cheers

[Juergen Ilse]

Hallo,

Burkhard Ott <news...@derith.de> wrote:

> On Fri, 23 Mar 2012 11:00:11 +0100, Claus-Dieter Schulmann wrote:
>> Ich tausche jetzt A gegen PTR (und Namen gegen Adressen) aus: In STD0013
>> sind PTR-Records erklärt. In STD0013 steht nirgends, dass PTR-Records
>> eingetragen werden müssen. In STD0013 steht nirgends, dass einzelne
>> PTR-Records optional wären.
> Wenn da kein MUST steht, bedeutet es das Du das machen kannst wie Du
> froehlich bist, die Betonung steht auf 'kannst'. Wenn da steht 'should'n
> heisst das, es waere schoen aber Du musst es nicht, also es ist optional.

"Should" in RFCs heisst schon mehr als "kann man mchen oder auch nicht".
Es bedeutet eher "man sollte sich daran halten, wenn man nicht Gruende
dafuer hat es nicht zu tun *und* genau weiss was man tut". RFC weisst
auf genau einen solchen Fall hin: Weil Diensteanbieter manchmal (teils
auch entgegen RFC-Empfehlungen oder Vorschriften) auf der Existenz von
PTR bestehen oder die Zusammenarbeit verweigern, wird empfohlen, dieser
Forderung nachzugeben, auch wenn die DNS-RFCs das eigentlich nicht er-
fordern ...
Das wird in RFC1912 dementsprechend empfohlen, genau wie empfohlen wird,
fuer eine einzige IP-Adresse nicht mehrere PTR-Records anzulegen, obwohl
sich das dann (z.B. bei Existenz mehrerer A-Records die auf die selbe IP
verweisen) praktisch nicht mehr unter Einhaltung aller Empfehlungen aus
RFC1912 nicht mehr realisieren laesst ... Entsprechend sollte man RFC1912
dann auch betrachten: man hat eben oft genug gute Gruende sich nicht
daran zu halten (waehrebd es bei sehr vielen anderen RFCs keine guten
Gruende gibt, sich nicht an ein darin enthaltenes "Should" zu halten).

>> Daraus schliesse ich, dass einzelne PTR-Records nicht optional sind.

Dieser Schluss ist IMHO trotzdem flacsh ...

[Burkhard Ott]

On Fri, 23 Mar 2012 19:45:07 +0000, Juergen Ilse wrote:

> "Should" in RFCs heisst schon mehr als "kann man mchen oder auch nicht".
> Es bedeutet eher "man sollte sich daran halten, wenn man nicht Gruende
> dafuer hat es nicht zu tun *und* genau weiss was man tut". RFC weisst
> auf genau einen solchen Fall hin: Weil Diensteanbieter manchmal (teils
> auch entgegen RFC-Empfehlungen oder Vorschriften) auf der Existenz von
> PTR bestehen oder die Zusammenarbeit verweigern, wird empfohlen, dieser
> Forderung nachzugeben, auch wenn die DNS-RFCs das eigentlich nicht er-
> fordern ...

Du kannst das schoener ausdruecken als ich, im Prinzip sagts aber das
gleiche. Man kann nicht drauf bestehen, daruf filtern kann man zwar (war
ja das Ursprungs Thema) nur muss man sich nicht wundern wenn man
Beschwerden erhaelt.

cheers

[Peter J. Holzer]

On 2012-03-21 05:35, Juergen P. Meier <nospa...@jors.net> wrote:
> Burkhard Ott <news...@derith.de>:
>> Wobei 'valid' nicht unbedingt bedeutet das Du den fqdn via DNS aufloesen
>> kannst.
>
> Das ist Falsch. Richtig ist, dass "valid FQDN" im IETF Standard 13
> genau definiert ist.

Möglich (auch wenn ich die Stelle auf die Schnelle nicht finde), aber
für die Interpretation von RFC 5321 weitgehend irrelevant. Konsens in
der Working Group ist, dass nur lokal auflösbare Namen (z.B. irgendwas
wie mail13.intranet.example.org, wobei die Zone intranet.example.org
nicht global sichtbar ist) für den Namen im EHLO zulässig sind. Das ist
auch die übliche Begründung dafür, dass es dem Server verboten ist, die
Mail auf Grund einer fehlgeschlagenenen Validierung abzulehnen.


>>>> "The HELO receiver MAY verify that the HELO parameter really
>>>> corresponds to the IP address of the sender. However, the receiver MUST
>>>> NOT refuse to accept a message, even if the sender's HELO command fails
>>>> verification."
>>>>
>>>> Als Empfaenger darfst Du den fqdn gerne pruefen aber nicht ablehnen
>>>> wenn der nicht im DNS existiert.
>
> Auch das ist Falsch. Der Empfaenger *DARF* *IMMER* und *JEDE* E-Mail
> aus Policy-Gruenden ablehnen - diese Freiheit gewaehrt der
> SMTP-Standard jedem Empfaenger.

Richtig.


> Der Empfaenger darf sogar aus Protokoll-Gruenden (Standardverletzung)
> ablehnen, wenn der Hello-Parameter kein gueltiger (d.h. verifizierbarer*)
> FQDN oder alternativ die IP-Addresse des Clients enthaelt, und muss
> sich nicht auf seine Policy berufen.

Falsch. Dieser Fall ist explizit ausgeschlossen:

An SMTP server MAY verify that the domain name argument in the EHLO
command actually corresponds to the IP address of the client.
However, if the verification fails, the server MUST NOT refuse to
accept a message on that basis.
-- RFC 5321, 4.1.4. Order of Commands

Aber da Local Policy trotzdem greift, darf man doch wieder ablehnen.

Also: Protokollverletzung, also darf man ablehnen. Aber nicht in diesem
Fall, weil es für diese spezifische Verletzung eine Regelung gibt. Aber
aus Policy-Gründen darf man immer, also darf man doch.

Ja, das ist ein Krampf :-(.

hp


--
_ | Peter J. Holzer | Deprecating human carelessness and
|_|_) | Sysadmin WSR | ignorance has no successful track record.
| | | h...@hjp.at |
__/ | http://www.hjp.at/ | -- Bill Code on as...@irtf.org

[Peter J. Holzer]

Das ist ein Fehlschluss. Wenn zu einem Domainnamen keine IP-Adresse
gehört, warum solltest Du dort einen A-Record eintragen müssen?

Einen A-Record brauchst Du genau denn, wenn Du ein (global sichtbares)
Mapping von einem Domainnamen zu einer IP-Adresse haben willst. Dann
musst Du einen A-Record eintragen, aber nicht deshalb, weil es
vorgeschrieben ist, sondern deshalb, weil das Mapping sonst einfach
nicht existiert.

> Ich tausche jetzt A gegen PTR (und Namen gegen Adressen) aus:
> In STD0013 sind PTR-Records erklärt.
> In STD0013 steht nirgends, dass PTR-Records eingetragen werden müssen.
> In STD0013 steht nirgends, dass einzelne PTR-Records optional wären.
> Daraus schliesse ich, dass einzelne PTR-Records nicht optional sind.
> IP-Adressen müssen deshalb als PTR-Records eingetragen werden.

Gleiche Situation; Einen PTR-Records brauchst Du genau dann, wenn Du ein
Mapping von einer IP-Adresse zu einem Domainnamen willst. In dem Fall muss
ein PTR-Record da sein, aber wieder nicht, weil das so vorgeschrieben
ist, sondern weil man nur abrufen kann, was auch im DNS eingetreagen
ist.

Wenn Du kein Mapping von IP-Adresse zu Domainname willst, brauchst Du
auch keinen PTR-Record.

RFC 1035 verliert kein Wort darüber, wann man ein solles Mapping wollen
sollte. Es mag sein, dass die Autoren angenommen haben, dass man das für
jeder verwendete IP-Adresse will, oder es kann sein, dass sie dem
Betreiber eines Hosts zugetraut haben, das selbst zu entscheiden.

In RFC 1912 (9 Jahre später, Status: Informational) wird dann dringend
angeraten, zu jedem A-Record einen "matching" PTR-Record anzulegen (Im
Gegensatz zu Jürgen Ilse sehe ich nur eine mögliche Interpretation des
Worts "matching" in diesem Kontext). Das ist eine Empfehlung, die aus
der Praxis kommt (insbesondere FTP-Server waren damals sehr häufig so
konfiguriert, dass sie anonymous access nur von IP-Adressen zugelassen
haben, bei denen der IP -> FQDN -> IP Roundtrip funktioniert hat), und
der für MTAs wohl auch gilt, aber in etlichen anderen Fällen nicht mehr:
Wenn Du z.B. namensbasierte virtuelle Webserver betreibst, und 200
Domainnamen auf die gleiche IP-Adresse auflösen, dann willst Du ganz
sicher nicht 200 PTR-Records für diese IP-Adresse.

[Peter J. Holzer]

Was soll diese Seite mit PTR-Records zu tun haben? Da geht es um das
Header-Format. Relevant sind die Seiten 22 und 23.