Hoggins! skrev den 2015-09-07 14:53:

Well, it seems to be a false alarm. My peer just issued a posttls-finger test with Postfix and the problem seems solved. Maybe there are other validators in the sea ?

you should just run postfix, not sendmail, hehe

Le 07/09/2015 15:04, Benny Pedersen a écrit :

...

Hey there !

I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr [1]), but I don't know what I need to change about that.

Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ?

posttls-finger smtp.hoggins.fr posttls-finger hoggins.fr

both shows here Verified

Thanks Benny ! Cheers!

Le 07/09/2015 18:02, Viktor Dukhovni a écrit :

...

...

I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that.

Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ? The MX host for a domain is required by DNS standards to not be a CNAME alias.

hoggins.fr. IN MX 1 smtp.hoggins.fr. smtp.hoggins.fr. CNAME mailer.hoggins.fr. mailer.hoggins.fr. A 5.196.52.52

The validator tries to be more strict than some MTAs, because there may be other MTAs for which CNAMEs in MX records are not valid. Change your MX hostname to "mailer.hoggins.fr" or make "smtp" be an "A" record with the same IP addresses as "mail", rather than an alias.

Once you do that, the mail server's TLSA records are fine:

smtp.hoggins.fr. IN CNAME mailer.hoggins.fr. ; NOERROR AD=1 mailer.hoggins.fr. IN NOTMX 0 smtp.hoggins.fr. ; NOERROR AD=1 _25._tcp.mailer.hoggins.fr. IN TLSA 3 1 2 05460499a59db40f0015caffef33eecb6e6121ee35afd87ee4daf88d3f9d0946a2af16db33ba3fb964d15b8a9018ec6b87e54a4aaa804cd31b20f62026d2314e ; passed

The alias may be exposing a minor bug in the web interface, which may be querying for success with "smtp.hoggins.fr", but the ultimate DANE verification is of "mailer.hoggins.fr".

Avoid aliases in email domain names and MX hosts.

Will do, thanks ! Hoggins!

Simson Garfinkel skrev den 2015-09-07 19:02:

http://ec2.simson.net/dane_check.cgi?host=hoggins.fr

It is much more verbose than the sys4.de tester.

just small fail it says try all ips, but it does not test ipv6 else it seems to do good job, thanks for shareing it http://ec2.simson.net/dane_check.cgi?host=fido.dk

I am in the process of adding ipv6 support.

On Sep 7, 2015, at 1:13 PM, Benny Pedersen wrote:

Simson Garfinkel skrev den 2015-09-07 19:02:

...

http://ec2.simson.net/dane_check.cgi?host=hoggins.fr It is much more verbose than the sys4.de tester.

just small fail it says try all ips, but it does not test ipv6

else it seems to do good job, thanks for shareing it

http://ec2.simson.net/dane_check.cgi?host=fido.dk

Jim, Thanks for giving my tester a try. I'm confused by your comment, though. I was pretty sure that SMTP commands were supposed to be followed by CRLF. Here's the quote from RFC 2821: 2.3.7 Lines SMTP commands and, unless altered by a service extension, message data, are transmitted in "lines". Lines consist of zero or more data characters terminated by the sequence ASCII character "CR" (hex value 0D) followed immediately by ASCII character "LF" (hex value 0A). This termination sequence is denoted as <CRLF> in this document. Conforming implementations MUST NOT recognize or generate any other character or character sequence as a line terminator. Limits MAY be imposed on line lengths by servers (see section 4.5.3). In addition, the appearance of "bare" "CR" or "LF" characters in text (i.e., either without the other) has a long history of causing problems in mail implementations and applications that use the mail system as a tool. SMTP client implementations MUST NOT transmit these characters except when they are intended as line terminators and then MUST, as indicated above, transmit them only as a <CRLF> sequence. https://www.ietf.org/rfc/rfc2821.txt https://www.ietf.org/rfc/rfc2821.txt Am I missing something?

On Sep 7, 2015, at 2:28 PM, Jim Popovitch wrote:

On Mon, Sep 7, 2015 at 1:02 PM, Simson Garfinkel wrote:

...

If you want to give my tester a try, you can try it at:

http://ec2.simson.net/dane_check.cgi?host=hoggins.fr

I appears that you are using "\r\n" in your smtp test commands. "\n" should be sufficient and won't cause logged errors on the systems you are testing.

-Jim P.

Hi, On Mon, Sep 07, 2015 at 02:56:50PM -0400, Jim Popovitch wrote:

I think the CRLF vs CR debate is older than the Emacs vs Vi debate. :-) Others can probably speak better as to which to use, I'll stand on the sidelines and share with you Wietse's feelings: :-)

There is nothing to stand aside here - the RFC is more than clear.

Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n

This has nothing to do with CR+NL (except that it shows up) but with, as the error message says, "improper command pipelining" - you're not supposed to send QUIT right away, but you're supposed to wait for the reply to HELO, and only *then* send the next command (here: QUIT). Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279

On Mon, Sep 07, 2015 at 03:47:27PM -0400, Simson Garfinkel wrote:

Thanks. I've fixed the sequencing issue.

There may also be some DNSSEC issues. The DNS for the TLSA records of openssl.org is fine, modulo a minor inconsistency of NS RRs at the delegation from .org vs. the zone apex. http://dnsviz.net/d/_25._tcp.mta.openssl.org/dnssec/ And yet the validator claims the TLSA RRset is "bogus", reports failure: http://ec2.simson.net/dane_check.cgi?host=openssl.org BOGUS DNS CNAME lookup _25._tcp.mta.openssl.org. = wildcard._dane.openssl.org. Something's not quite right here... -- Viktor.

Viktor Dukhovni skrev den 2015-09-07 22:46:

All three are in fact fine. So the handling of TLSA CNAMEs seems to be broken.

+1 openssl.net and openssl.net is still same ssl/tls, skip restriction on subdomains then ? (include cname mx check or not) but if openssl.net and openssl.org make subdomain restriction ? cname to another tls/ssl is worst, where i think cname to same tls/ssl is still ok no ? i am just no expert yet

Viktor Dukhovni skrev den 2015-09-07 23:06:

All I can say about openssl.net is that this domain is not DNSSEC signed, so DANE is out of scope for openssl.net. In any case, it has neither MX records, nor A or AAAA records, so it receives no email.

i should have sayed example.org example.net, it was just a example, not a real problem

Thanks for the email. According to the report, the CNAME lookup of _25._tcp.open.nlnetlabs.nl is bogus. However it is not, so there is a problem with my CNAME chaser. I'll check it out.

On Sep 7, 2015, at 4:46 PM, Viktor Dukhovni wrote:

On Mon, Sep 07, 2015 at 08:10:38PM +0000, Viktor Dukhovni wrote:

...

And yet the validator claims the TLSA RRset is "bogus", reports failure:

http://ec2.simson.net/dane_check.cgi?host=openssl.org

BOGUS DNS CNAME lookup _25._tcp.mta.openssl.org. = wildcard._dane.openssl.org.

Something's not quite right here...

The issue seems to be systemic:

http://ec2.simson.net/dane_check.cgi?host=nlnetlabs.nl

BOGUS DNS CNAME lookup _25._tcp.nlnetlabs.nl = 3.1.1._dane-both.nlnetlabs.nl.

http://ec2.simson.net/dane_check.cgi?host=spodhuis.org

BOGUS DNS CNAME lookup _25._tcp.mx.spodhuis.org. = _globnix-tlsa.spodhuis.org.

http://ec2.simson.net/dane_check.cgi?host=wizmail.org

BOGUS DNS CNAME lookup _25._tcp.wizmail.org. = _cert301.wizmail.org.

All three are in fact fine. So the handling of TLSA CNAMEs seems to be broken.

-- Viktor.

On Mon, Sep 07, 2015 at 05:19:51PM -0400, Simson Garfinkel wrote:

The problem appears to with getdns... it's returning that CNAME lookups are bogus when in fact they are not.

Pity. In most cases however, you don't need to chase CNAMEs explicitly. Most validating resolvers (as shown by the example you included with the bug report) will automatically chase the CNAME for you. So when you ask for the TLSA records of _25._tcp.mta.openssl.org, you get a validated response with both the CNAME and the final answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30434 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;_25._tcp.mta.openssl.org. IN TLSA _25._tcp.mta.openssl.org. CNAME wildcard._dane.openssl.org. _25._tcp.mta.openssl.org. RRSIG CNAME 8 5 <...> wildcard._dane.openssl.org. TLSA 3 1 1 687C07FBE2491E7035D0567FA42A503E1F163312B310B47B7B64B911C93ECACA wildcard._dane.openssl.org. RRSIG TLSA 8 4 <...> So unless the resolver leaves you with a "dangling" CNAME (no answer for the RHS of the CNAME), you generally don't need to explicitly resolve CNAME RRs. So if you parse the getdns replies for TLSA looks with more care, you don't have to wait for the bug fix. You can "chase" the CNAME expansion within the provided initial reply without additional queries. -- Viktor.

On Mon, Sep 7, 2015 at 3:03 PM, Viktor Dukhovni wrote:

On Mon, Sep 07, 2015 at 02:56:50PM -0400, Jim Popovitch wrote:

...

...

https://www.ietf.org/rfc/rfc2821.txt

SMTP commands are <CRLF> terminated.

...

Sep 7 17:04:13 svr2 postfix/smtpd[17157]: improper command pipelining after HELO from ec2-52-7-167-73.compute-1.amazonaws.com[52.7.167.73]: HELO TEST\r\nQUIT\r\n

The problem is improper pipelining. After STARTTLS, the tester is supposed to send EHLO (not HELO) wait for a reply, and *then* send QUIT<CRLF> (and wait for a reply).

Ahh, thank you for the correction Viktor, Gert too. -Jim P.