Subject: Re: [dane] Fwd: New Version Notification for draft-york-dane-deployment-observations-00.txt

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 10 Nov 2014 16:46:17 +0000

On Mon, Oct 27, 2014 at 11:32:23PM +0000, Viktor Dukhovni wrote:

> What would be even more helpful is a site that not only tests DNSSEC
> validation and checks for the presence of TLSA RRs, but also connects
> to the domain's MX hosts and reports whether the TLSA RRs match
> reality!  I may end up partnering with some folks to build this,
> but if anyone wants to do it for us, that would be great.
> 
> A 3-4% error rate in deploying TLSA records is too high, we need
> better deployment validation tools.  And more prominent guidance
> to pick just either of "2 0 1" or "3 1 1" for SMTP.
> 
> I'm also considering releasing a tool that validates a server's
> off-line chain file against an off-line TLSA RRset.  This would
> allow folks to test before they break their server, rather than
> immediately after.

Speaking of testing, the Deploy360 site's list of test servers is
in need of ongoing maintenance.  A noticeable fraction behave
differently than advertised.  The data at

    http://www.internetsociety.org/deploy360/resources/dane-test-sites/

is quite dated.  It should probably be kept up to date or withdrawn.

-- 
	Viktor.

(The "Address records insecure" result below is how I avoid sending
TLSA queries for unsigned zones where these are likely to be
mishandled, and unlikely to be secure, see the SMTP draft for
details).

--- Testing fedoraproject.org...
;; Passed(depth 1, hostname fedoraproject.org): fedoraproject.org. IN TLSA 0 0 1 19400BE5B7A31FB733917700789D2F0A2471C0C9D506C0E504C06C16D7CB17C0
--- Exit code: 0

--- Testing www.freebsd.org...
;; Passed(depth 0): www.freebsd.org. IN TLSA 3 0 1 3F86A1FA85F6E5169CB27BF25C863805EBFD3225A16AADB75587804680992096
--- Exit code: 0

--- Testing torproject.org...
;; Passed(depth 0): torproject.org. IN TLSA 3 1 1 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10D2A58DA5
--- Exit code: 0

--- Testing jhcloos.com...
;; Passed(depth 3, hostname jhcloos.com): jhcloos.com. IN TLSA 1 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8
;; Passed(depth 0): jhcloos.com. IN TLSA 3 1 1 597CC279D90F0FB950B540921C4A76916590A2B7DEDDDDBC353C65337160E1A8
--- Exit code: 0

--- Testing www.kumari.net...
;; Passed(depth 4, hostname *.kumari.net): www.kumari.net. IN TLSA 1 0 1 8D930A464843E08660E3FD1DDCE8ED4269CC0CD9CD53A8A306BCE8ABCF47AEF5
--- Exit code: 0

--- Testing good.dane.verisignlabs.com...
;; Passed(depth 0): good.dane.verisignlabs.com. IN TLSA 3 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3
--- Exit code: 0

--- Testing www.statdns.net...
;; Failed: www.statdns.net. IN TLSA 3 0 1 C1D6431EAB897824E3A767A3CBE3B200D9160B20B0B5684C851C47782787D286: certificate not trusted: (27)
--- Exit code: 1

--- Testing dougbarton.us...
;; Passed(depth 3, hostname dougbarton.us): dougbarton.us. IN TLSA 1 0 2 F994F42839BE5C864F143A037D4E96BB0F559AD7284C57EA09BF6A69D37C1D8359E57C604BB42A9A56586DB21E700404C38B8152365C03543BBF210A4FE30E08
--- Exit code: 0

--- Testing hacklab.to...
Address records insecure
--- Exit code: 255

--- Testing nohats.ca...
;; Passed(depth 0): nohats.ca. IN TLSA 3 1 1 462573195C86E861ABAB8ECCFBC7F0486958EFDFF9449AC10729B3A0F906F388
--- Exit code: 0

--- Testing www.nlnetlabs.nl...
;; Passed(depth 0): www.nlnetlabs.nl. IN TLSA 3 1 1 F7DB964ED80ED0773F82A21997B2DCBAE434AE821AB1E3E337AD0CCFBFE2359F
--- Exit code: 0

--- Testing www.vulcano.cl...
;; Failed: www.vulcano.cl. IN TLSA 3 0 1 5F301AD10923161E74EC4951C052C97963FEBCCB093019618964D69CAF7B5B34: unable to get local issuer certificate: (20)
--- Exit code: 1

--- Testing www.huque.com...
;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1 0013BEF11B875A58F3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281
--- Exit code: 0

--- Testing dane.nox.su...
DNS Lookup failed: dane.nox.su IN A ?: SERVFAIL
--- Exit code: 255

--- Testing rover.secure64.com...
;; Failed: rover.secure64.com. IN TLSA 3 0 1 D7D680E82EDA59B910D4CF37EC8398432251650A176A20E08ABE45DA728266EF: self signed certificate: (18)
--- Exit code: 1

--- Testing rogue.nohats.ca...
;; Failed: rogue.nohats.ca. IN TLSA 3 0 1 0000000000000000000000000000000000000000000000000000000000000000: unable to get local issuer certificate: (20)
--- Exit code: 1

--- Testing bad-hash.dane.verisignlabs.com...
;; Failed: bad-hash.dane.verisignlabs.com. IN TLSA 3 0 1 9999999999999999999999999999999999999999999999999999999999999999: certificate not trusted: (27)
--- Exit code: 1

--- Testing bad-params.dane.verisignlabs.com...
;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 119 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR
;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 51 0 1 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR
;; Failed: bad-params.dane.verisignlabs.com. IN TLSA 3 0 17 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3: error processing TLSA RR
--- Exit code: 1

--- Testing bad-sig.dane.verisignlabs.com...
DNS Lookup failed: bad-sig.dane.verisignlabs.com IN A ?: SERVFAIL
--- Exit code: 255

---

From: Dan York <[email-masked]>
Date: Mon, 10 Nov 2014 17:57:41 +0000

Viktor,

> is quite dated.  It should probably be kept up to date or withdrawn.

As the guy responsible for that page, I am glad to update it. I set it up quite some time ago when there was no such list and people needed DANE test sites. I don't yet have an automated test script but I am glad to use your output! :-)

Thanks for letting me know it had gotten out-of-date. I'll queue up a reminder to check it periodically. 

Thanks,
Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 10 Nov 2014 21:39:31 +0000

On Mon, Nov 10, 2014 at 04:46:17PM +0000, Viktor Dukhovni wrote:

> differently than advertised.

> ;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1 0013BEF11B875A58F3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281

As advertised.  Mind you there should perhaps be a distinction in
the classification of test sites between sites whose TLSA RRs
actually leverage the CA they're signed by "usage 0, 1 or 2" vs.
sites with a valid CA cert, but DANE-EE TLSA records.  This would
separate fedora and freebsd into separate categories.

> ;; Passed(depth 3, hostname dougbarton.us): dougbarton.us. IN TLSA 1 0 2 F994F42839BE5C864F143A037D4E96BB0F559AD7284C57EA09BF6A69D37C1D8359E57C604BB42A9A56586DB21E700404C38B8152365C03543BBF210A4FE3…

The jhcloos site is however, in both camps.  Above, my code is
misreporting the match depth for usage PKIX-EE(1) reporting the
depth of the cert chain, not the match, I'll fix that shortly.

> DNS Lookup failed: bad-sig.dane.verisignlabs.com IN A ?: SERVFAIL

As advertised.

=== The 5 out of date sites below ===

> ;; Failed: www.statdns.net. IN TLSA 3 0 1 C1D6431EAB897824E3A767A3CBE3B200D9160B20B0B5684C851C47782787D286: certificate not trusted: (27)

This site's TLSA RR asserts a certificate digest that does not
actually match the presented certificate:

    $ (sleep 1) |
	    openssl s_client -connect www.statdns.net:443 2>&1 |
	    openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout
    subject= /C=PL/CN=www.statdns.net/emailAddress=[email-masked]
    issuer= /C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA
    notBefore=Oct 31 00:37:02 2014 GMT
    notAfter=Nov  1 08:02:33 2015 GMT
    SHA256 Fingerprint=B8:00:50:18:A6:E7:75:FD:88:76:4B:5B:1D:3D:51:9F:89:1C:01:C7:FE:77:7E:74:A2:CF:22:37:B8:4A:43:B2

Recent key rotation, no corresponding TLSA RR update.

> --- Testing hacklab.to...

The hacklab.to zone is unsigned, or if it is signed uses the ISC
DLV, which my tests don't consult.  I don't expect DNSSEC resolvers
to generally support the ISC DLV service.

> ;; Failed: www.vulcano.cl. IN TLSA 3 0 1 5F301AD10923161E74EC4951C052C97963FEBCCB093019618964D69CAF7B5B34: unable to get local issuer certificate: (20)

    $ (sleep 1) |
	openssl s_client -connect www.vulcano.cl:443 2>&1 |
	openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout
    subject= /CN=www.vulcano.cl
    issuer= /O=CAcert Inc./OU=http://www.CAcert.org/CN=CAcert Class 3 Root
    notBefore=Oct 16 13:09:01 2014 GMT
    notAfter=Oct 15 13:09:01 2016 GMT
    SHA256 Fingerprint=2A:84:22:B0:BE:D6:96:07:AA:EB:7C:1A:75:2A:97:8E:22:EB:3E:C6:12:2E:A0:17:C8:67:89:48:67:36:A8:B0

Recent key rotation, no corresponding TLSA RR update.

> DNS Lookup failed: dane.nox.su IN A ?: SERVFAIL

    $ perl ssldane.pl dane.nox.su 443
    DNS Lookup failed: dane.nox.su IN A ?: SERVFAIL

Validating "unbound" resolver fails for this domain, a DNSSEC issue.
However, the A record exists, and is visible to non-validating
resolver report:

    $ (sleep 1) |
	openssl s_client -connect dane.nox.su:443 2>&1 |
	openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout
    subject= /C=RU/L=Moscow/O=NOX.SU/OU=Supervisors group 7/CN=dane.nox.su
    issuer= /C=RU/L=Moscow/O=NOX.SU/OU=Supervisors group 7/CN=dane.nox.su
    notBefore=Jul  2 12:19:19 2014 GMT
    notAfter=Jul  1 12:19:19 2016 GMT
    SHA256 Fingerprint=23:58:E8:10:27:F4:9C:39:47:92:49:93:51:80:30:B3:7F:4B:D6:19:1B:09:7D:44:4E:AF:07:29:FD:61:22:B5

Which matches the published TLSA RR, if one is willing to ignore
the signature problem.

    $ dig +noall +ans -t TLSA _443._tcp.dane.nox.su
    _443._tcp.dane.nox.su. IN TLSA 3 0 1 2358E81027F49C3947924993518030B37F4BD6191B097D444EAF0729FD6122B5

> ;; Failed: rover.secure64.com. IN TLSA 3 0 1 D7D680E82EDA59B910D4CF37EC8398432251650A176A20E08ABE45DA728266EF: self signed certificate: (18)

    $ (sleep 1) |
	openssl s_client -connect rover.secure64.com:443 2>&1 |
	openssl x509 -subject -issuer -dates -sha256 -fingerprint -noout
    subject= /CN=ubuntu
    issuer= /CN=ubuntu
    notBefore=May 29 21:18:25 2012 GMT
    notAfter=May 27 21:18:25 2022 GMT
    SHA256 Fingerprint=5D:D8:53:6B:3F:6C:0D:FB:7D:CC:14:B0:AA:18:0A:13:D1:80:05:ED:CB:45:26:18:D5:4A:01:BB:69:AC:ED:9A

Certificate unrelated to TLSA RR.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 10 Nov 2014 22:06:28 +0000

> depth of the cert chain, not the match, I'll fix that shortly.

If anyone is already using the ssl_dane code, the fix for the above
is below.  I'll push it to github later this evening.

diff --git a/danessl.c b/danessl.c
index 5d1ead0..f7e5993 100644
--- a/danessl.c
+++ b/danessl.c
@@ -871,8 +871,8 @@ static int verify_chain(X509_STORE_CTX *ctx)
 	 * Check for an EE match, then a CA match at depths > 0, and
 	 * finally, if the EE cert is self-issued, for a depth 0 CA match.
 	 */
-	if (leaf_rrs)
-	    matched = match(leaf_rrs, xn, 0);
+	if (leaf_rrs && (matched = match(leaf_rrs, xn, 0)) > 0)
+	    n = 0;
 	while (!matched && issuer_rrs && --n >= 0) {
 	    xn = sk_X509_value(ctx->chain, n);
 
-- 
	Viktor.

---

From: Shumon Huque <[email-masked]>
Date: Mon, 10 Nov 2014 13:18:39 -1000

On Mon, Nov 10, 2014 at 11:39 AM, Viktor Dukhovni <[email-masked]>
wrote:

> > ;; Passed(depth 1, hostname fedoraproject.org): fedoraproject.org. IN
> TLSA 0 0 1 19400BE5B7A31FB733917700789D2F0A2471C0C9D506C0E504C06C16D7CB17C0
> > ;; Passed(depth 0): www.freebsd.org. IN TLSA 3 0 1
> 3F86A1FA85F6E5169CB27BF25C863805EBFD3225A16AADB75587804680992096
> > ;; Passed(depth 0): torproject.org. IN TLSA 3 1 1
> 578582E6B4569A4627AEF5DFE876EEC0539388E605DB170217838B10D2A58DA5
> > ;; Passed(depth 0): good.dane.verisignlabs.com. IN TLSA 3 0 1
> 0332AA2D58B3E0544B65656438937068BA44CE2F14469C4F50C9CC6933C808D3
> > ;; Passed(depth 0): nohats.ca. IN TLSA 3 1 1
> 462573195C86E861ABAB8ECCFBC7F0486958EFDFF9449AC10729B3A0F906F388
> > ;; Passed(depth 0): www.nlnetlabs.nl. IN TLSA 3 1 1
> F7DB964ED80ED0773F82A21997B2DCBAE434AE821AB1E3E337AD0CCFBFE2359F
> > ;; Passed(depth 0): www.huque.com. IN TLSA 3 0 1
> 0013BEF11B875A58F3B0B1D7A0D439A608277F58433BBB12245B2A28B398C281
>

My site (www.huque.com.) also falls into that latter category. The
annotation on Dan York's page should be updated - it currently says I don't
have a secure delegation, which was true at one time in the past (blame a
DNSSEC oblivious registrar), but no longer.

--Shumon.

---

From: Dan York <[email-masked]>
Date: Mon, 10 Nov 2014 23:49:15 +0000

Shumon (& also replying to Viktor),

On Nov 10, 2014, at 1:18 PM, Shumon Huque <[email-masked]<mailto:[email-masked]>> wrote:

My site (www.huque.com<http://www.huque.com/>.) also falls into that latter category. The annotation on Dan York's page should be updated - it currently says I don't have a secure delegation, which was true at one time in the past (blame a DNSSEC oblivious registrar), but no longer.

Yes, I noticed that when I looked at Viktor's test results this morning.  I updated the page to move your site into the appropriate category:

Based on Viktor's recent test (Thank you, Viktor!), I'm updating the page with other information.

I find it interesting that 3 of the 5 out-of-date sites would seem to be be operational errors.  Two of the sites Viktor tags as:

  - Recent key rotation, no corresponding TLSA RR update.

and one is:

  - Certificate unrelated to TLSA RR.

All of these would seem to be related to operational processes where some part of the security layers get updated without other corresponding layers being also updated.  I don't know that this is really anything that we as the IETF can do anything to help with... but it's interesting to understand where the breakdown in the process occurs.

Dan

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Nov 2014 00:13:24 +0000

On Mon, Nov 10, 2014 at 11:49:15PM +0000, Dan York wrote:

> All of these would seem to be related to operational processes where some
> part of the security layers get updated without other corresponding layers
> being also updated.

That's definitely the main problem.  Though
to be fair with HTTPS sites, nobody cares if they don't verify,
browsers don't do DANE and seem unlikely to do so in the near
future.  [ Yes, folks like us might install a plugin, which may or
may not work correctly. :-( ]

I think more/better tools to validate the configuration, and
awareness of those tools will help, as will the relevance of getting
the records right.  If TLSA records are just a fashion statement
with no operational significance, the bits will rot.

For SMTP at least, one of these days people getting their records
wrong might actually feel some pain in the form of delayed mail,
and then the problem may start to self-correct as people acquire
the appropriate operational habits.  That would be accelerated by
a large sender or two enabling opportunistic DANE TLS for SMTP.

No large providers appear in my curated list of 330 DANE-enabled
SMTP domains.  Though, IIRC, Unity Media in Germany has ~500,000
users, which is nice, but not quite the requisite scale.

Speaking of SMTP, the same deploy360 site lists some SMTP test
domains.  I'd like to suggest removal of dougbarton.us, or (with
his consent) adding that domain to a new category, his records are
PKIX-EE(1), and are not aligned with the DANE SMTP draft.  (Per
the draft, these would be treated "unusable" in SMTP, resulting in
a sender policy of mandatory unauthenticated TLS).

-- 
	Viktor.

---

From: James Cloos <[email-masked]>
Date: Mon, 10 Nov 2014 19:39:03 -0500

>>>>> "VD" == Viktor Dukhovni <[email-masked]> writes:

VD> The jhcloos site is however, in both camps.

These days that is mostly just to help others test.

I used 111 and 311 to make things easier for me, as both share the same
hash.

Another such is _5061._tcp.gate.jhcloos.com. (discoverable from
jhcloos.com. naptr).

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Viktor Dukhovni <[email-masked]>
Date: Tue, 11 Nov 2014 01:30:35 +0000

> These days that is mostly just to help others test.

No problem with that on the server side.  It is clients
that should make up their mind.

Your site could be listed twice.

--
	Viktor.

---

From: Paul Wouters <[email-masked]>
Date: Tue, 11 Nov 2014 14:11:02 -0500 (EST)

> to generally support the ISC DLV service.

The .to TLD is unsigned, so it has to rely on DLV.

Paul
ps. best TLD webpage ever: http://to/
pps. they should make http://to/infinity/and/beyond/

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 14 Nov 2014 16:19:57 +0000

On Mon, Oct 27, 2014 at 11:32:23PM +0000, Viktor Dukhovni wrote:

> Out of ~280 domains that have TLSA RRs, 10 or so had erroneous
> records:

On a more positive note, my (not comprehensive) list of working
SMTP with DANE domains crossed the 360 mark today.  So for SMTP
"Deploy 360" is done.  :-)

Top 10 SMTP with DANE TLDs:

 121 de.
  67 net.
  35 org.
  34 com.
  15 eu.
  13 ch.
   9 cz.
   5 uk.
   5 nl.
   5 info.

As I mentioned before, many of net/com/org/eu/info domains are in
fact registered by DE domain owners, so deployment is still
substantially a DE phenomenon.  It would be good to get some traction
in other jurisdictions.  In Germany Heise.de and other IT trade
publications have written about DANE, and there have been presentations
at multiple technical conferences for users.  So DANE awareness is
growing there.

Perhaps there could be some similar articles in the US IT press?
Do people still read the US trade rags?  Perhaps it would be easier
to market DANE to users if more MTAs than just Postfix had implementations.  

I'm working with the Exim developers, and they are close to having
it done.  It would be nice to have Microsoft also ship a DANE-capable
Exchange SMTP server, and of course Sendmail.

After that it is support in the various SMTP appliances, IronPort
Barracuda, ... and last but not least the big providers Outlook.com,
Gmail, Yahoo, AOL, ...

I hope this will move faster once the draft is published as an RFC,
but some additional marketing may be helpful if anyone on this list
can pitch implementation to people in a position to make progress
happen.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Nov 2014 06:29:42 +0000

On Mon, Oct 27, 2014 at 10:55:31PM +0000, Dan York wrote:

> Feedback is very definitely welcome... I'm not intending anything
> with this document other than using it as a catalyst for discussions.

Dan, here's something you may be able to help with.

A number of large DNS hosting providers have enabled DNSSEC support,
but are using nameserver software that is not compatible with the
specification with respect to authenticated denial of existence.

In particular, given a zone containing the RRsets below

    *.example.com.	IN A|CNAME|... RDATA
    example.com.	IN MX 0 mail.example.com.
    mail.example.com.	IN A 192.0.2.1

A query for the non-existent "_25._tcp.mail.example.com" is thrown
off by the wildcard record, which has other data, but has no TLSA
RRs, and returns "NODATA" rather than "NXDOMAIN".  So TLSA queries
for such hosted domains SERVFAIL, and mail delivery to these domains
breaks from DANE-enabled MTAs.

    DNS provider     Example domain
    --------------------------------
    forpsi.cz        gigacomputer.cz
    forpsi.cz        websurf.cz
    --------------------------------
    hosting2go.nl    flashpatterns.nl
    hosting2go.nl    informatieplatform.nl
    --------------------------------
    hostnet.nl       bergsalaenigma.nl
    hostnet.nl       brandsupply.nl
    hostnet.nl       expert.nl
    hostnet.nl       foodness.nl
    hostnet.nl       ikkijkonline.nl
    hostnet.nl       leestrainer.nl
    hostnet.nl       studeersnel.nl
    --------------------------------
    transip.nl       aanbodpagina.nl
    transip.nl       androidworld.nl
    transip.nl       bitonic.nl
    transip.nl       codingunit.com
    transip.nl       dresscode.nl
    transip.nl       fonq.nl
    transip.nl       gamesync.nl
    transip.nl       headliner.nl
    transip.nl       icheckmovies.com
    transip.nl       kinderspiele.de
    transip.nl       mediumchat.nl
    transip.nl       notprovided.eu
    transip.nl       performance.nl
    transip.nl       redskillz.nl
    transip.nl       refdag.nl
    transip.nl       seoshop.nl
    transip.nl       trendstats.nl
    transip.nl       webshopapp.com
    transip.nl       webwinkelsoftware.nl
    transip.nl       wrts.nl
    transip.nl       zipzoo.nl
    --------------------------------

For example:

    zipzoo.nl. IN MX 10 mail.zipzoo.nl.
    mail.zipzoo.nl. IN A 95.170.70.251
    mail.zipzoo.nl. IN AAAA 2a01:7c8:eb:0:95:170:70:251
    ;; _25._tcp.mail.zipzoo.nl IN TLSA ?: SERVFAIL

The presence of such broken domains can deter deployment.  Can the
"Deploy360" effort coordinate remediation?  Such hosting sites must
do one of the below to avoid breaking DANE TLSA (at least for SMTP):

  * Deploy a non-broken nameserver.

  * Create kludgey defensive records that make the NODATA response
    correct.

    _25._tcp.mail.zipzoo.nl IN TXT "No TLSA RRs here"

  * Remove the zone's wildcard RRs.

  * Work with the domain owner to remove the DS records for
    the zone making it "insecure".

I don't have the cycles to interface with each hosting provider
and domain owner myself.  We to get the message out to DNS hosting
providers that their software needs to be a robust DNSSEC
implementation, not an ad-hoc patch-set.  At least in the case
of forpsi.cz, I know they're using djbdns, which does not have
fully functional DNSSEC support.

On a related note, some nameservers are failing to provide proof
of the non-existence of a "*._tcp" wildcard, along with the NXDOMAIN
reply for "_25._tcp".

  fuhrt.de.               IN      NS      ns2.remotedienst.de.
  fuhrt.de.               IN      NS      ns1.remotedienst.de.
  fuhrt.de.               IN      MX      10 fuhrt.de.
  ;; _25._tcp.fuhrt.de    IN      TLSA    ?: SERVFAIL

On the other hand for other domains, some sort of firewall or
nameserver bug causes "TLSA" queries to often be simply dropped,
while "A" queries for the same node return NXDOMAIN:

  disa.mil
  fbi.gov
  nic.mil

So I'm running into a non-trivial fraction of signed domains for
which DNSSEC is not working right, and DANE will run into interop
problems.  Can you do anything to help.  My basic plea is:

      * Do it right

but failing that:

      * Don't do it at all.

Neither DNSSEC nor DANE should be fashion statements about how
"cool" a domain is.  These should only be deployed when thoroughly
tested and the ongoing operational responsibilities are under
control.

Finally, while "dnsviz.net" provides the most detailed information
I've found at any testing site, its visual nature and the requirement
to "mouse-over" things to get the key details is often a distraction,
while due to space constraints, the text is often terse and difficult
to understand.

I'm looking for better tools, that non-cryptically explain what is
wrong a query response fails to validate.  A command-line tool I
can run locally would be great, the web version can be for reports
to remote admins so they can use the same tool to check that they've
fixed the problem without needing to install anything.

-- 
	Viktor.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Nov 2014 07:34:45 +0000

> specification with respect to authenticated denial of existence.

Note, by far the bulk of the problem is with transip. From their
website:

    https://www.transip.co.uk/domain-name/transdns/

    DNSSEC

    TransDNS is the foundation of our DNSSEC implementation, a DNS
    protocol security extension. Signing more than 500.000 domain
    names with DNSSEC was a challenge we gladly accepted. Because
    of TransDNS we were one of the first domain providers in The
    Netherlands that signed all our domain names. We are now the
    largest DNSSEC provider in the world. We could not have done
    this with third-party solutions. That is the reason why we
    develop everything in-house.

Perhaps they have more problems that show up in interop tests
because they indeed signed so many more domains that anyone else.
In any case, they would be a good place to start remediation.

If anyone has contacts there and can reach out that would be great.

-- 
	Viktor.

---

From: "Marco Davids (SIDN)" <[email-masked]>
Date: Thu, 20 Nov 2014 09:29:02 +0100

Hi,

At SIDN (registry for .nl) we are aware of these problems and we are in
touch with the registrars involved.

In particular TransIP is a bit of a challenge, because they run their
own DNS-software and feel no rush to fix this issue. But rest assured
that we will keep on trying to have them improve things.

--
Marco

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Nov 2014 15:17:16 +0000

> that we will keep on trying to have them improve things.

At this point the "feel no rush" attitude will cause loss of email
between SMTP with DANE early adopters to transip sites that employ
wildcard records.  They really need to get off their rear-ends and
fix the problem.

Otherwise, I may need to develop a new unbound feature that considers
a zone insecure if all its NS records lie in a given blacklisted
domain.

I don't suppose it is possible to pressure transip with a threat
of removal of the problem DS records from the '.nl' registry by
say 6 months from now if the problem is not addressed?

-- 
	Viktor.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 21 Nov 2014 07:31:30 +1100

In message <[email-masked]>, Viktor Dukhovni writ
> say 6 months from now if the problem is not addressed?

We have a documented complaints proceedure.  We should follow it.
 
RFC 1033 COMPLAINTS

   These are the suggested steps you should take if you are having
   problems that you believe are caused by someone else's name server:

   1.  Complain privately to the responsible person for the domain.  You
   can find their mailing address in the SOA record for the domain.

   2.  Complain publicly to the responsible person for the domain.

   3.  Ask the NIC for the administrative person responsible for the
   domain.  Complain.  You can also find domain contacts on the NIC in
   the file NETINFO:DOMAIN-CONTACTS.TXT

   4.  Complain to the parent domain authorities.

   5.  Ask the parent authorities to excommunicate the domain.

With a DNSSEC problem we may want to add a 4.5 step, ask the parent
to remove the DS record.

Mark

> -- 
> 	Viktor.
> 
> _______________________________________________
> dane mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dane
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 20 Nov 2014 22:15:36 +0000

> With a DNSSEC problem we may want to add a 4.5 step, ask the parent

Thanks for the info.  I guess we're not nearly up to steps 4.5 or
5 yet.  And I did contacted off-list by transip, who I hope will
follow-up on-list.  I am however asking for help with cycles for
this process.  I can no longer keep up with the communication
requirements.

If anyone can help work the issue through the various domain
contacts, registrars, and registries that'd be great!  Below are
the SOA RRs of the signed domains where MX host TLSA lookups SERVFAIL
due to various nameserver bugs or zone signing problems.

    --- Likely systemic applying to many hosted domains ---
    aanbodpagina.nl.        SOA     ns0.transip.net. hostmaster.transip.nl.
    codingunit.com.         SOA     ns0.transip.net. hostmaster.transip.nl.
    connections-it.com.     SOA     ns0.transip.net. hostmaster.transip.nl.
    dresscode.nl.           SOA     ns0.transip.net. hostmaster.transip.nl.
    entix.nl.               SOA     ns0.transip.net. hostmaster.transip.nl.
    erdee.nl.               SOA     ns0.transip.net. hostmaster.transip.nl.
    fonq.nl.                SOA     ns0.transip.net. hostmaster.transip.nl.
    gamesync.nl.            SOA     ns0.transip.net. hostmaster.transip.nl.
    infonu.nl.              SOA     ns0.transip.net. hostmaster.transip.nl.
    kinderspiele.de.        SOA     ns0.transip.net. hostmaster.transip.nl.
    mediumchat.nl.          SOA     ns0.transip.net. hostmaster.transip.nl.
    notprovided.eu.         SOA     ns0.transip.net. hostmaster.transip.nl.
    ooshopping.nl.          SOA     ns0.transip.net. hostmaster.transip.nl.
    performance.nl.         SOA     ns0.transip.net. hostmaster.transip.nl.
    redskillz.nl.           SOA     ns0.transip.net. hostmaster.transip.nl.
    reviewspot.nl.          SOA     ns0.transip.net. hostmaster.transip.nl.
    seoshop.nl.             SOA     ns0.transip.net. hostmaster.transip.nl.
    splendense.nl.          SOA     ns0.transip.net. hostmaster.transip.nl.
    studio-donder.nl.       SOA     ns0.transip.net. hostmaster.transip.nl.
    trendstats.nl.          SOA     ns0.transip.net. hostmaster.transip.nl.
    trentt.com.             SOA     ns0.transip.net. hostmaster.transip.nl.
    webshopapp.com.         SOA     ns0.transip.net. hostmaster.transip.nl.
    webwinkelsoftware.nl.   SOA     ns0.transip.net. hostmaster.transip.nl.
    wrts.nl.                SOA     ns0.transip.net. hostmaster.transip.nl.
    zipzoo.nl.              SOA     ns0.transip.net. hostmaster.transip.nl.
    banoshop.eu.            SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    bergsalaenigma.nl.      SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    brandsupply.nl.         SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    expert.nl.              SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    foodness.nl.            SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    ikkijkonline.nl.        SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    leestrainer.nl.         SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    studeersnel.nl.         SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    utopiagekte.nl.         SOA     ns1.hostnet.nl. hostmaster.hostnet.nl.
    androidworld.nl.        SOA     ns0.transip.nl. hostmaster.transip.nl.
    gigacomputer.cz.        SOA     ns.forpsi.net. admin.forpsi.net.
    jursoft.cz.             SOA     ns.forpsi.net. admin.forpsi.net.

    --- Possibly sporadic applying to just the domains shown ---
    flashpatterns.nl.       SOA     ns1.hosting2go.nl. postmaster.flashpatterns.nl.
    informatieplatform.nl.  SOA     ns1.hosting2go.nl. postmaster.informatieplatform.nl.
    developmentaid.org.     SOA     ns0.transdns.eu. hostmaster.transip.eu.
    fuhrt.de.               SOA     ns1.remotedienst.de. natalie.fuhrt.de.
    fbi.gov.                SOA     ns1.fbi.gov. dns-admin.fbi.gov.
    nic.mil.                SOA     dns2.nipr.mil. disa\.columbus\.ns\.mbx\.hostmaster-dod-nic.mail.mil.
    disa.mil.               SOA     ns1.csd.disa.mil. disa\.meade\.esd\.list\.es312-ccc-hostmaster.mail.mil.
    stj.jus.br.             SOA     ns1.stj.jus.br. netmaster.stj.jus.br.
    dominion.ch.            SOA     ns.dominion.ch. hostmaster.dominion.ch.
    mec-import.de.          SOA     ns5.kp-dns.de. hostmaster.mec-import.de.

-- 
	Viktor.