On Mon, 3 Jan 2022, Dan Mahoney wrote:
This is a problem when your local resolver is slaving the root zone, as a standard root
zone "type slave" will hand . NS out with the AA bit set, but will not set the
AD bit.
There's a feature in more recent versions of BIND (mirror zones) that may fix
this, but right now if you're following RFC7706, this check is lying to you.
That said, whomever put this in was good enough to put in a knob to disable it -- but
from the docs, it's unclear as to what happens: is dane simply ignored, or is this just a
warning that "hey, your dnssec may not be real, but we're still going to use it"
Also...the server I'm sending to has a legit signed cert that matches its
hostname, so the message I get is:
Trusted TLS connection established to prime.gushi.org[149.20.68.142]:25:
TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)
Whereas if pure DANE had been used, I think the wording there would be "Verified", not
Trusted. I'm guessing if there's a full cert path, that "wins"? Is TLSA still validated
at all in this case?
The TLSA record verification (or even the lookup) never gets logged, at least
at loglevel 2. This would be useful for admins to see how much traction DANE
is getting. Is there a logging knob that will enable this?
And again, dropping a header into the body of the mail message so that the admin on the
*receiving* server could see that their TLSA records are good for more than just getting
periodic "hey your record's broke" emails from Viktor :)
One more question: Does anyone know of a "reflector" like service that one
can use to test DANE validation, i.e. a site that one is allowed to send
test messages to, that *only* has DANE as the trust mech (so, say, a
self-signed cert?)
-Dan
--
--------Dan Mahoney--------
Techie, Sysadmin, WebGeek
Gushi on efnet/undernet IRC
FB: fb.com/DanielMahoneyIV
LI: linkedin.com/in/gushi
Site: http://www.gushi.org
---------------------------
