On Sun, Jan 31, 2021 at 07:15:05PM +0100, Patrick Proniewski wrote:
> fixed:
>
> $ telnet mail.patpro.net 25
> Trying 193.30.227.216...
> Connected to mail.patpro.net.
> Escape character is '^]'.
> 220-rack.patpro.net Do not say anything yet
You might also throw "ESMTP" in there:
220-hostname.example ESMTP ...
but more importantly, your DNSSEC implementation is FUBAR:
https://dnsviz.net/d/patpro.net/X0FcgA/dnssec/
Your domain is DNSSEC-signed with 4096-bit RSA keys for both the KSK and
ZSK! This sort of key size crypto porn is just asking for trouble. For
example, your TLSA RRset response:
https://dnsviz.net/d/_25._tcp.mail.patpro.net/YBcdDg/responses/
is 2446 bytes and requires UDP fragmentation!
UDP fragmentation and DNS don't play nicely together on the public
internet, and large UDP messages are all to often lost. The root zone
KSK is signed with a 2048 bit key, you get no additional security from
4096 bit RSA keys. This choice is especially odd with SHA-1 as the
signature algorithm, you'd want to at least use algorithm 8 or 10 which
use SHA-2.
If you want practical DNS security with RSA, use a 2048-bit KSK and a
1280-bit ZSK (with NSEC3 or, better yet, a 1536 bit key ZSK with NSEC).
Best practice is to actually use algorithm 13 with ECDSA P256 keys.
Algorithm rollovers in DNSSEC can be tricky, don't just "wing it", do it
by the book, unless short TTLs and a transient outage are your cup of
tea.
In addition to the absurd key sizes, you also have expired RRSIGs:
https://dnsviz.net/d/_25._tcp.mail.patpro.net/YBcdDg/dnssec/
on the "ns6.gandi.net" secondary server, which last successfully
got a signed AXFR some time before 2020-12-02.
The NODATA denial of existence response size for "_tcp" is 1287 bytes,
which may exceed IPv6 path MTUs:
https://dnsviz.net/d/_tcp.mail.patpro.net/YBcfYA/responses/
--
Viktor.
