Hi, could somebody pls check ns1.samba.org? (from list.samba.org) I get strange results here. smtp.samba.org is just fine. Thanks and regards. --eh. -- Dr. Erwin Hoffmann | www.fehcom.de PGP key-id: 20FD6E671A94DC1E PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
Hi, The MX records of samba.org and lists.samba.org seem a bit off: samba.org. 7200 IN MX 7 smtp.samba.org. samba.org. 7200 IN MX 9 ns1.samba.org. samba.org. 7200 IN MX 5 ns1.samba.org. lists.samba.org. 86400 IN MX 9 ns1.samba.org. lists.samba.org. 86400 IN MX 5 ns1.samba.org. lists.samba.org. 86400 IN MX 7 lists-mx.samba.org. smtp.samba.org. and lists-mx.samba.org. seems to be the only valid records, the ns1 entries can probably be deleted. gnutls-cli validates the TLSA records of smtp.samba.org. and lists-mx.samba.org.: - DANE: Certificate matches. Jelle On 6/13/24 11:16 PM, Erwin Hoffmann wrote:
Hi,
could somebody pls check
ns1.samba.org? (from list.samba.org)
I get strange results here.
smtp.samba.org
is just fine.
Thanks and regards. --eh.
On 13.06.24 23:16, Erwin Hoffmann wrote:
could somebody pls check
ns1.samba.org? (from list.samba.org)
I get strange results here.
smtp.samba.org
is just fine.
see https://en.wikipedia.org/wiki/Nolisting If you use "nolisting" and use DANE, you should make sure to have syntactically correct TLSA records for the nolisting MX hosts, which ideally don't match any other existing cert. This is what ns1.samba.org has: # host -t TLSA _25._tcp.ns1.samba.org _25._tcp.ns1.samba.org has TLSA record 3 0 1 00000000000000000000000000000000000000000000000000000000 00000000 Björn
Hi Börn, Am Freitag, dem 14.06.2024 um 00:00 +0200 schrieb Björn Jacke via dane- users:
On 13.06.24 23:16, Erwin Hoffmann wrote:
could somebody pls check
ns1.samba.org? (from list.samba.org)
I get strange results here.
smtp.samba.org
is just fine.
see https://en.wikipedia.org/wiki/Nolisting
If you use "nolisting" and use DANE, you should make sure to have syntactically correct TLSA records for the nolisting MX hosts, which ideally don't match any other existing cert. This is what ns1.samba.org has:
# host -t TLSA _25._tcp.ns1.samba.org _25._tcp.ns1.samba.org has TLSA record 3 0 1 00000000000000000000000000000000000000000000000000000000 00000000
could you point me to a RFC, where this is specified? I don't think that neither 'nolisting' nor publishing a 'nullified' TLSA recored is a good idea. And yes, I get: dnstlsa -v ns1.samba.org dnstlsa: info: checking for TLSA records: _25._tcp.ns1.samba.org Usage: [3], Selector: [0], Type: [1] 0000000000000000000000000000000000000000000000000000000000000000 Regards. --eh.
Björn
-- Dr. Erwin Hoffmann | www.fehcom.de PGP key-id: 20FD6E671A94DC1E PGP key-fingerprint: 8C6B 155B 0FDA 64F1 BCCE A6B9 20FD 6E67 1A94 DC1E
On Sat, Jun 15, 2024 at 09:28:37PM +0200, Erwin Hoffmann wrote:
If you use "nolisting" and use DANE, you should make sure to have syntactically correct TLSA records for the nolisting MX hosts, which ideally don't match any other existing cert. This is what ns1.samba.org has:
# host -t TLSA _25._tcp.ns1.samba.org _25._tcp.ns1.samba.org has TLSA record 3 0 1 00000000000000000000000000000000000000000000000000000000 00000000
could you point me to a RFC, where this is specified?
If one of a domain's MX hosts has no TLSA records, email to the domain is subject to active attacks even if all the primary and/or various other MX hosts do have TLSA records. An on-path attacker can block connections to all the protected MX hosts, and intercept the connection to the unprotected one. https://datatracker.ietf.org/doc/html/rfc7672#section-2.2.3 If the ultimate response is a "secure" TLSA RRset, then the candidate TLSA base domain will be the actual TLSA base domain, and the TLSA RRset will constitute the TLSA records for the destination. If none of the candidate TLSA base domains yield "secure" TLSA records, then the SMTP client is free to use pre-DANE opportunistic TLS (possibly even cleartext).
I don't think that neither 'nolisting' nor publishing a 'nullified' TLSA recored is a good idea.
Indeed "nolisting", though mostly harmless, and perhaps helpful to reduce abuse in some cases, is not a best practice. On the other hand, publishing a TLSA record matching nothing, even for inactive MX hosts is, in fact, required in order to avoid downgrade attacks. -- Viktor.
participants (4)
-
Björn Jacke -
Erwin Hoffmann -
Jelle -
Viktor Dukhovni