Hello I noticed that web.de uses a NSEC3 Hash Algorithm Type 8.
But 8 is not assigned: http://www.iana.org/assignments/dnssec-nsec3-parameters/dnssec-nsec3-parameters.xhtml#dnssec-nsec3-parameters-3 ; <<>> DiG 9.8.3-P1 <<>> web.de NSEC3PARAM +noall +answer ;; global options: +cmd web.de. 600 IN NSEC3PARAM 8 0 333 - ; <<>> DiG 9.8.3-P1 <<>> gmx.ch NSEC3PARAM +noall +answer ;; global options: +cmd gmx.ch. 600 IN NSEC3PARAM 8 0 350 - On a related note, I'm also confused why the browser plugin from https://www.dnssec-validator.cz/ does not recognize that gmx.ch is DNSSEC signed. It works for web.de though! Any idea? Daniel On 25.04.16 05:48, Viktor Dukhovni wrote: > On Fri, Apr 22, 2016 at 04:28:51PM +0000, Gumprich, Mario wrote: > >> We from Unitymedia has enabled DANE outbound a couple of month ago. > > Thanks for the update. > >> Today’s list of DANE inbound enabled domains / MX-IPs extracted from logs. >> mail.lux01.de[194.117.254.21] >> ... >> uhura.unitymedia.de[80.69.97.11] >> >> Pretty cool, the list grows from month to month. > > 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? > > Of the ~15k, 56 domains that have at some point in the last ~2 > years appeared in the Google email transparency report dataset. > Of these 30 are in the most recent report: > > gmx.at > conjur.com.br > registro.br > gmx.ch > gmx.com > mail.com > bayern.de > bund.de > gmx.de > jpberlin.de > lrz.de > posteo.de > ruhr-uni-bochum.de > tum.de > unitymedia.de > web.de > octopuce.fr > comcast.net > dd24.net > gmx.net > t-2.net > xs4all.net > xs4all.nl > debian.org > freebsd.org > gentoo.org > ietf.org > openssl.org > samba.org > torproject.org > > I'm still waiting for icann.org to show up on the list, and ideally > a few prominent ".edu" domains that have gone to all the trouble > of deploying DNSSEC, but have not yet published SMTP TLSA records. > The ones from Gmail's transparentcy report would be: > > berkeley.edu > fhsu.edu > iastate.edu > indiana.edu > iu.edu > iupui.edu > nau.edu > stanford.edu > temple.edu > ucdavis.edu > ucr.edu > uiowa.edu > umbc.edu > yale.edu > > None of these have made the leap as yet. It is possible, though > not very likely that some departments have, I only scan domains > directly delegated from public suffixes. > > A substantial outlier with problem TLSA records is ".br". The > registry/sole-registrar provides a web interface for adding TLSA > records, but no API for keeping them up to date. As a result, a > large fraction of ".br" domains with TLSA RRs have invalid records, > or related issues. Many don't promptly/ever act on email notices > (at least in English). It may be wise to not enable DANE for ".br" > domains. > > .BR TLSA records don't match reality: > > allispdv.com.br > bebidaliberada.com.br > giantit.com.br > idsys.com.br > lojabrum.com.br > netlig.com.br > prodnsbr.com.br > simplesestudio.com.br > solucoesglobais.com.br > ticketmt.com.br > twsolutions.net.br > > .BR DNSSEC lookup problems: > > bb.b.br > dpf.gov.br > pf.gov.br > justicaeleitoral.jus.br > tre-al.jus.br > tre-ce.jus.br > tre-ma.jus.br > tre-mg.jus.br > tre-ms.jus.br > tre-mt.jus.br > tre-pa.jus.br > tre-pb.jus.br > tre-pe.jus.br > tre-pi.jus.br > tre-pr.jus.br > tre-rn.jus.br > tre-rr.jus.br > tre-sp.jus.br > m3ganet.net.br > _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
