Viktor Dukhovni wrote: > > Do you ever run into any of the domains whose TLSA records are > incorrect, or whose DNS servers fail authenticated denial of > existence? In other words, is there any mail you bounce because > of DANE that you might otherwise have delivered? > > Today's stats are: > > ~280000 DNSSEC domains that could have an MX host with TLSA RRs. > 15097 domains with valid TLSA RRs > 245 of those have 1+ MX hosts sans TLSA RRs (partial deployment) > 227 domains with DNSSEC problems when doing TLSA lookups > 56 domains with TLSA records that don't match the cert > > Given that the problem domans are rather few, perhaps you've never > run into them?
doing DNSSEC verification is not exactly easy, more like sufficiently close to the "beware of the leopard" in THHGTTG for practical matters. None of the regular Linux distro builds of the "dig" tool from the bind package seem to have the necessary code compiled into the binaries. After download bind source and compiling dig myself (which requires some non-intuitive wrangling with the build tool), I see the following DNSSEC outputs: $ bin/dig/dig +sigchase +trusted-key=./root.keys www.ietf.org. | tail -2 ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS $ bin/dig/dig +sigchase +trusted-key=./root.keys datatracker.ietf.org. | tail -2 ;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS $ bin/dig/dig +sigchase +trusted-key=./root.keys tools.ietf.org. | tail -2 ;; RRSIG is missing for continue validation: FAILED and the latter failure is something that I don't understand. If the IETF can not get DNSSEC right, who should? -Martin _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
