Re: [dane] [Uta] NEWSFLASH: DANE TLSA records published for web.de!

["Peter van Dijk" <[e-mail]>]

I’ve spoken to web.de/1und1 and they are aware of the weirdness they 
put in there. I trust they will rectify it soon.

Kind regards,
-- 
Peter van Dijk
PowerDNS.COM BV - https://www.powerdns.com/

On 28 Apr 2016, at 14:40, Daniel Stirnimann wrote:

> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dane
>>>
>>
>
> -- 
> SWITCH
> Daniel Stirnimann, SWITCH-CERT
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
> phone [phone], direct [phone]
> [e-mail], http://www.switch.ch
>
> _______________________________________________
> dane mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dane