The NSEC3 record contains the hash algorithm type 1 4c82sp2ag0m9hm9lfkb6d141t4qclui8.gmx.ch. 556 IN NSEC3 1 0 350 - 5AEHEF49CLPKJ5CHHRCND7VKKM7MKMJ4 CNAME RRSIG
So, it's only the NSEC3PARAM Hash Algorithm which confuses me. Daniel On 28.04.16 11:45, Daniel Stirnimann wrote: > 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 > -- SWITCH Daniel Stirnimann, SWITCH-CERT Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 15, direct +41 44 268 16 24 [email protected], http://www.switch.ch _______________________________________________ dane mailing list [email protected] https://www.ietf.org/mailman/listinfo/dane
