- dane-users - list.sys4.de

Please take care when deploying Let's Encrypt certificates...
by Viktor Dukhovni 20 Nov '15

20 Nov '15

If you've published DANE TLSA records for your current certificate chain, and are considering switch to Let's Encrypt issued certificates, please do not forget: https://dane.sys4.de/common_mistakes#3 https://tools.ietf.org/html/rfc7671#section-8.1 I've seen more than one of the early adopters of LE certificates neglect to update their TLSA records (a few TTLs) *before* deploying the new LE certificate chain. -- Viktor.

2 2

Re: Deployment news (comcast.net publishes TLSA RRs)
by Viktor Dukhovni 16 Nov '15

16 Nov '15

On Mon, Nov 16, 2015 at 09:41:57AM -0600, Mark Felder wrote: > > My ongoing survey has now found 9389 working DANE domains. Most > > of these are served by a few domain hosting providers: > > > > 5230 udmedia.de > > 955 nederhost.net > > 354 transip.email > > 47 mediaweb-it.net > > 45 mailbox.org > > 36 gr-webdesign.de > > 32 core-networks.de > > 32 wk-serv.net > > 30 set-hosting.de > > 30 dotplex.de > > > > Your numbers seem much higher than Verisign's. I wonder what Verisign's > secspider is missing? > > http://secspider.verisignlabs.com/stats.html They are counting zones with TLSA records. I'm counting domains whose MX hosts have TLSA records. Those 5230 domains for udmedia.de all resolve to MX hosts in just 1 zone. My dataset has 1265 MX hosts in 1185 zones, but the number of *domains* with SMTP DANE TLS is 9513. -- Viktor.

1 0

DANE broken @ addons.mozilla.org?
by Andreas Pothe 27 Oct '15

27 Oct '15

Hi, can you confirm that addons.mozilla.org has a broken DANE entry? The DNSSEC Validator plugin in Firefox says "no DNSSEC at addons.mozilla.org" but "invalid DNSSEC signature". CU Andreas

3 6

DANE SMTP and OPS drafts now RFCs!
by Viktor Dukhovni 15 Oct '15

15 Oct '15

After a 2 and a half year process, the DANE SMTP and DANE OPS drafts are now published IETF RFCs: https://tools.ietf.org/html/rfc7671 ----------------------------------- The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance This document clarifies and updates the DNS-Based Authentication of Named Entities (DANE) TLSA specification (RFC 6698), based on subsequent implementation experience. It also contains guidance for implementers, operators, and protocol developers who want to use DANE records. https://tools.ietf.org/html/rfc7672 ----------------------------------- SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) This memo describes a downgrade-resistant protocol for SMTP transport security between Message Transfer Agents (MTAs), based on the DNS- Based Authentication of Named Entities (DANE) TLSA DNS record. Adoption of this protocol enables an incremental transition of the Internet email backbone to one using encrypted and authenticated Transport Layer Security (TLS). It is now time to shift my attention back to implementation in TLS libraries. The community can help by promoting adoption, and making sure that your deployment stays valid at all times. Please pay close attention to: https://dane.sys4.de/common_mistakes#3 https://dane.sys4.de/common_mistakes#8 https://tools.ietf.org/html/rfc7671#section-8.1 https://tools.ietf.org/html/rfc7671#section-8.4 https://tools.ietf.org/html/rfc7672#section-3.1.1 https://tools.ietf.org/html/rfc7672#section-3.1.2 https://tools.ietf.org/html/rfc7672#section-3.1.3 Just in case you overlooked something, please always retest your domain's TLSA records after deploying fresh certificates and/or private keys. https://dane.sys4.de -- Viktor.

3 2

DNSSEC / BIND breakage
by Wolfgang Rosenauer 01 Oct '15

01 Oct '15

Hi, one of my DNSSEC/DANE secured domains started breaking as of today and I do not fully understand why. Probably bright people here can point me to the correct resolution? I'm using bind and its auto-dnssec maintain; inline-signing yes; Also I'm not aware that my KSK and ZSK keys have any expiration date but today DNSSEC started to fail apparently because my RRSIG signatures are said to be expired. Actually my first idea is that the automatic maintenance in bind failed for some reason. So I deleted the journal and signed zone files and started over by signing the zone from scratch. This at least improved the situation a little bit according to http://dnsviz.net/d/rosenauer.org/dnssec/ But still it seems to be broken and I'm lost currently to understand what is wrong. Thanks for any pointers, Wolfgang

3 3

Subtle DNS problems to avoid...
by Viktor Dukhovni 27 Sep '15

27 Sep '15

Some of the domains I've tested exhibit sporadic TLSA record DNS lookup errors, with some of the domain's nameservers working fine, and others not so well. DANE mail to these sites gets through eventually, but perhaps with some delay. You can see some of the problems at the URLs below: http://dnsviz.net/d/_25._tcp.mx.edpescelsa.com.br/dnssec/ http://dnsviz.net/d/_25._tcp.smtp1.gencat.cat/dnssec/ http://dnsviz.net/d/_25._tcp.mail.edsi-tech.com/dnssec/ http://dnsviz.net/d/_25._tcp.mail.intersatafrica.com/dnssec/ http://dnsviz.net/d/_25._tcp.mailserver.planetvampire.com/dnssec/ http://dnsviz.net/d/_25._tcp.mailhost.bncr.fi.cr/dnssec/ http://dnsviz.net/d/_25._tcp.www.linuxdays.cz/dnssec/ http://dnsviz.net/d/_25._tcp.smtp.richland.edu/dnssec/ http://dnsviz.net/d/_25._tcp.mta0.core.aeschi.eu/dnssec/ http://dnsviz.net/d/_25._tcp.exceed-it.eu/dnssec/ http://dnsviz.net/d/_25._tcp.smtpedge2.uspto.gov/dnssec/ http://dnsviz.net/d/_25._tcp.mx2.dnet.net.id/dnssec/ http://dnsviz.net/d/_25._tcp.dmg2.dtic.mil/dnssec/ http://dnsviz.net/d/_25._tcp.mailproxy.cnic.navy.mil/dnssec/ http://dnsviz.net/d/_25._tcp.transport.hub210.net/dnssec/ http://dnsviz.net/d/_25._tcp.mx1.kurty.net/dnssec/ http://dnsviz.net/d/_25._tcp.mail.zwei.net/dnssec/ http://dnsviz.net/d/_25._tcp.mailfilter.webguru.nl/dnssec/ http://dnsviz.net/d/_25._tcp.rejo.zenger.nl/dnssec/ http://dnsviz.net/d/_25._tcp.smtpin1.stgraber.org/dnssec/ http://dnsviz.net/d/_25._tcp.charybda.torinthiel.pl/dnssec/ http://dnsviz.net/d/_25._tcp.brownsugar.se/dnssec/ http://dnsviz.net/d/_25._tcp.mailgw01.harnosand.se/dnssec/ http://dnsviz.net/d/_25._tcp.em01.jhwbg.se/dnssec/ http://dnsviz.net/d/_25._tcp.manc.se/dnssec/ http://dnsviz.net/d/_25._tcp.nllplus.se/dnssec/ http://dnsviz.net/d/_25._tcp.rafel.se/dnssec/ Problems include: * Warnings about glue NS records differing from authoritative NS records (some of the "extra" nameservers don't support DNSSEC, refuse service, ...). * Warnings about likely UDP fragmentation problems (no response unless EDNS0 payload is reduced). * Some nameservers reachable only via TCP * Some nameservers refusing service for the domain * Some nameservers not returning NSEC or NSEC3 records with denial of existence. * Some nameservers returning the wrong or partial NSEC3 records, failing to take into account intermediate domains between the zone apex and the qname. * Some nameservers returning nonsense NSEC records * Expired RRSIGs on a subset of the nameservers. * NODATA instead of NXDOMAIN for a subset of the nameservers. * NSEC records with no RRSIG for a subset of the nameservers. Bottom line, please check your DNS from time to time. Even if mail is getting through, and DANE tests report success, there may be some latent problems. And if anyone on this list owns the above domains, or knows the responsible parties, please correct your DNS or reach out to your contacts. -- Viktor.

1 0

Change in dane.sys4.de x509 cert ahead
by Patrick Ben Koetter 09 Sep '15

09 Sep '15

Benny Petersen noted today that dane.sys4.de is still using a SHA1 x509 cert for the website. We will need to revocate that certificate in order to get a new, SHA2 certificate. During that time and until the new certificate will be in place you may receive a warning when your browser connects to https://dane.sys4.de. If you use a browser plugin to DANE validate https://dane.sys4.de you will probably also receive a warning. This will go away once the new fingerprint has been distributed via DNS. Don't be alarmed while we replace the certificate. p@rick -- [*] sys4 AG https://sys4.de, +49 (89) 30 90 46 64 Franziskanerstraße 15, 81669 München Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263 Vorstand: Patrick Ben Koetter, Marc Schiffbauer Aufsichtsratsvorsitzender: Florian Kirstein

2 3

Validating an SMTP server
by Hoggins! 08 Sep '15

08 Sep '15

Hey there ! I'm trying to validate my DANE records against my SMTP server, but I'm facing something that I cannot understand, because I believe I'm lacking some details about the validation failure : I'm trying to validate smtp.hoggins.fr. It gives me an error on the validator (https://dane.sys4.de/smtp/smtp.hoggins.fr), but I don't know what I need to change about that. Is there a way to be more verbose about the validation failure ? Maybe some client-side checking I can do manually ? Thanks. Hoggins!

6 27

Kudos to udmedia.de
by Viktor Dukhovni 28 Jul '15

28 Jul '15

It has come to my attention that many udmedia.de hosted domains are now provisioned with DNSSEC and when email is also hosted, the associated udmedia.de MX hosts have DANE TLSA records. This means that domains hosted for DNS and email by udmedia are automatically DANE-enabled. Out of the ~1600 DANE SMTP domains in my survey, somewhere between 50 and 100 are hosted by udmedia (a rescan of previously tested, but not recently re-tested domains is in progress and the final count is still an estimate). Thanks udmedia.de, I hope to see more hosting providers follow their lead. -- Viktor.

4 5

TLSA Validation Failed
by Abdelmeniem Tharwat 28 Jul '15

28 Jul '15

Dears , Hope you are doing well , I tried to deploy DANE at my testing environment and do the following :- 1) Create self-signed certificate "IDN domain name". 2) Get the TLSA hash from self-signed certificate file. 3) Add the TLSA record to zone file. And when I try to execute dig @8.8.8.8<mailto:dig@8.8.8.8> _443._tcp.xn----ymcadjpj1at5o.xn--wgbh1c +dnssec TLSA , I got the TLSA record that Is identical to the hash from crt file. The TLSA validator said that :- [cid:image008.jpg@01D0BDC0.1A30F150] , any advice !!! Thnx All the Best, Abdalmonem Tharwat Galila Deputy Manager, Dot Masr Registry, Operation Sector. [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: https://fbcdn-sphotos-h-a.akamaihd.net/hphotos-ak-ash4/268513_1801528887076…] National Telecommunication Regulatory Authority [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523405_telephone] Office Tel.: +2 02 35341582 - +2 02 35341300 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Mobile] Mobile: +2 010 0049068 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: ICON] Fax : +2 02 35370537 [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: oNLINE] Website: http:\\www.mcit.gov.eg<http://www.mcit.gov.eg/> : http:\\www.tra.gov.eg<http://www.mcit.gov.eg/> [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523294_email] E-mail :agalila@mcit.gov.eg<mailto:agalila@mcit.gov.eg> :atharwat@tra.gov.eg<mailto:atharwat@tra.gov.eg> [Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: Description: 1365523469_error]DISCLAIMER This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify your system support manager. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the National Telecom Regulatory Authority (NTRA) . Finally, the recipient should check this email and any attachments for the presence of viruses. The NTRA accepts no liability for any damage caused by any virus transmitted by this email.

6 12