Seems to be a typo and their signer (PowerDNS) correctly ignored it and used the correct value of 1.
Daniel On 28.04.16 12:11, Daniel Stirnimann wrote: > 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
