Looking at your dig +sigchase
output, we can see that the KSK (SEP) DNSKEY
is:
ex-mailer.com. 86400 IN DNSKEY 257 3 8 AwEAAaer0hZ5wLS++AsZyIEea+hqFzH4VKCWtFrLIUIqPU368szAfq9q 58adbqXjbizWGVimZEhVgDdUbl+TI3hQQ8eppOpX5yPr49XNv3AP6IbT pUlXAEXUjb6DsTONKciWHxo8r0Es7KL/SJSWmd3aTqtMeIrxb2SSFRmH upy034CKgrniidBv2VVI1pGsvLIDn3HYWMHqUas81iDv8EJ6c1HYiVUf w+37kfFZtj4pUmFQwwZ5yfi8pECPwLV5QImsnT3QGV2sYGP0sDWgGpz+ Sbv3+fs2u1o5AzD5nB7FeTotSdl31J0BKNpOT3gIG3JvkCaRziqqkCnL 7p+5t4+1dqE=
We can also see that the DS
you found was:
ex-mailer.com. 85868 IN DS 30274 8 1 9D12E47AAB1817A5062590188B7FC849FB662CE3
However, if I check what the DS
should be for the above DNSKEY
I get:
$ echo "ex-mailer.com. 86400 IN DNSKEY 257 3 8 AwEAAaer0hZ5wLS++AsZyIEea+hqFzH4VKCWtFrLIUIqPU368szAfq9q 58adbqXjbizWGVimZEhVgDdUbl+TI3hQQ8eppOpX5yPr49XNv3AP6IbT pUlXAEXUjb6DsTONKciWHxo8r0Es7KL/SJSWmd3aTqtMeIrxb2SSFRmH upy034CKgrniidBv2VVI1pGsvLIDn3HYWMHqUas81iDv8EJ6c1HYiVUf w+37kfFZtj4pUmFQwwZ5yfi8pECPwLV5QImsnT3QGV2sYGP0sDWgGpz+ Sbv3+fs2u1o5AzD5nB7FeTotSdl31J0BKNpOT3gIG3JvkCaRziqqkCnL 7p+5t4+1dqE=" | dnssec-dsfromkey -1 -f - ex-mailer.com
ex-mailer.com. IN DS 47569 8 1 42665F3D9A532B16A8E5AD9564AF9936AC93F7A0
There's clearly a mismatch between the DS
you looked up and the KSK currently used.
For what it's worth, I get the correct DS
if I look it up myself:
$ dig @a.gtld-servers.net ex-mailer.com DS +norec +short
47569 8 1 42665F3D9A532B16A8E5AD9564AF9936AC93F7A0
It appears that the keys for ex-mailer.com
may have changed in some unplanned way (not rolled over in a controlled manner) which leaves validating resolver servers in a bad state until cached data expires.