On 2026-02-07 at 10:33:36 UTC-0500 (Sat, 7 Feb 2026 16:33:36 +0100)
Dmitriy Alekseev via Postfix-users <[email protected]>
is rumored to have said:
UA TLD support dnssec?;)
It seems so...
$ dig +dnssec ua. DS
; <<>> DiG 9.20.18 <<>> +dnssec ua. DS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57286
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: e73dd8ccd9f95cd50100000069875be1f190edc4365aeee2 (good)
;; QUESTION SECTION:
;ua. IN DS
;; ANSWER SECTION:
ua. 86400 IN DS 51024 13 4
61195CABB323F940314D1BBEC97F4EBA54D2D7BA49AA244948C8C298
44E43A42293EE100841009FBFE85F1AB7CEFFACF
ua. 86400 IN DS 51024 13 2
1BDCA65B3BA927EFB64909637C10ADF90763EA7AB5D0AC1597C66CD6 C6CAEB6C
ua. 86400 IN RRSIG DS 8 1 86400 20260220050000 20260207040000 21831 .
JrFdhJjc9L9scB4L6RKcJrZgQhryuT0l6NaZbNfuXi3uGAxAAd+VNBNm
SdUWNJpLk96EGMJZElZKyw29brg2XXt2PoLmX1DQ0Wnl5P3PHMT3IYZw
nHkREgXBB/DgSdC7Cp5KL/xOLtXUF0TH4x2+p7zm3vmfeMiM/lOQ3ch7
VqjKxTUj8C/FpHKjJDmOFYC0Bh/2MafuxLQMBV8ztaHW5RVhOFNIRLya
Da+P9JYIW2AiOpBfBPrDRWMCmOg5qhjlAHG9OVi+cAqSWeBw7ZsE0f7X
dH7mXWuY5eNzsmzVVANGskGwK/jbuWbXicfe7SYlcqCoILRF2O1cmt4y pPdm1A==
;; Query time: 3 msec
;; SERVER: 192.168.254.17#53(192.168.254.17) (UDP)
;; WHEN: Sat Feb 07 10:36:01 EST 2026
;; MSG SIZE rcvd: 458
--
*Best Regards,*
Dmitriy Alekseev
DevOps Engineer
On Sat, 7 Feb 2026, 15:20 Viktor Dukhovni via Postfix-users, <
[email protected]> wrote:
On Sat, Feb 07, 2026 at 03:02:46PM +0100, Dmitriy Alekseev via
Postfix-users wrote:
but due to low level of dnssec spreading (as some tlds still fail to
add ability for it, as well as domain owners not interested in
enabling it even when they can).
Lack of TLD support is largely a thing of the past, all gTLDs and all
the major ccTLDs support DNSSEC, the only exceptions are a minority
(77
out of 248) of less technically sophisticated ccTLDs:
ae al ao aq as ba bb bo bs cd cf cg ck cu cv cw dj do eg fk gb gf
gh gm
gp gq gt gu hm im iq jm jo kh km kn kp mh mk mo mp mq mt mv mw mz
ne ng
ni np nr om pa pf pk pn ps qa sd sl sm so st sv sy sz tc td tg tj
tk to
va vg vi ye zw
and a handful (15 out of 61) of their related IDNA domains:
xn--d1alf xn--fzc2c9e2c xn--j1amh xn--lgbbat1ad8j xn--mgb9awbf
xn--mgba3a4f16a xn--mgbaam7a8h xn--mgbc0a9azcg xn--mgbpl2fh
xn--mgbtx2b
xn--mix891f xn--node xn--ogbpf8fl xn--wgbl6a xn--ygbi2ammx
And keeping DNS zones correctly signed is also mostly a thing of the
past, since the current generation of authoritative servers fully
automate zone resigning, and even key rotation, if you set up a key
rotation policy (with just a bit of care to not choose a policy that
performs key rotation even if the matching DS records don't show up
int
he parent zone).
Don't need to forget about complexity in operation on dns changes on
cert rotation or requirements to reuse same private key to not
rotate
tlsa I think it not get supported in other protocols and just CA
trust
is used.
There are robust tools to automate TLSA cert rotation and also
occasional key rollover, the knowledge to use them has sadly not yet
reached some the adopters. Too many HOWTO guides are giving rather
incomplete advice...
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
--
Bill Cole
_______________________________________________
Postfix-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
