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

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 14 Apr 2016 18:38:56 +0000

The web.de domain has just published DANE TLSA records for its MX
hosts.  This follows earlier "pilot" deployments with the smaller
mail.com and mail.de domains.

    web.de. IN MX 100 mx-ha02.web.de. ; AD=1
    _25._tcp.mx-ha02.web.de. IN TLSA 3 1 1 409c9e91a2a9f4d7881dbf0094b3839d4343a4a57d9bf559fdeb0c1f4c5b8b3e ; passed

    Subject = CN=mx-ha02.web.de,emailAddress=[email-masked],L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE
    Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE
    Inception = 2014-07-22T11:21:46Z
    Expiration = 2017-07-27T23:59:59Z

    web.de. IN MX 100 mx-ha03.web.de. ; AD=1
    _25._tcp.mx-ha03.web.de. IN TLSA 3 1 1 33fccf0e82584b6133cf18d24ae592cc6cbc9cfcab13291a5585a2b20a30eb19 ; passed

    Subject = CN=mx-ha03.web.de,emailAddress=[email-masked],L=Montabaur,ST=Rhineland-Palatinate,O=1&1 Mail & Media GmbH,C=DE
    Issuer = CN=TeleSec ServerPass DE-2,street=Untere Industriestr. 20,L=Netphen,postalCode=57250,ST=Nordrhein Westfalen,OU=T-Systems Trust Center,O=T-Systems International GmbH,C=DE
    Inception = 2014-07-22T11:22:46Z
    Expiration = 2017-07-27T23:59:59Z

This is a major milestone in DANE adoption.  [ IIRC they host
mailboxes for a substantial fraction of the population of Germany. ]

One approach to making sure that DANE TLSA records are less likely
to fail that should work well for sites using CA-issued certificates
is to publish both "3 1 1" and "2 1 1" TLSA records:

    mx.example. IN TLSA 3 1 1 <digest of server public key>
    mx.example. IN TLSA 2 1 1 <digest of immediate issuer public key>

    * The "3 1 1" record protects against "expiration" accidents, and
      unexpected changes in the issuer's public key (if new certificate
      chain deployment is automated).

    * The "2 1 1" record protects against key rotation errors should a
      a new server private key be deployed without updating the TLSA
      RRs.  Provided the new certificate is issued by the same CA
      is unexpired, ... the "2 1 1" record will match.

With a bit of monitoring to ensure that both records match,
simultaneous failures of both is much less likely.

This even makes it possible to avoid pre-deployment DNS TLSA records
updates when rotating certificates, provided at least one of the
issuer public key or the server public key is unchanged in the new
chain.

In particular, this is the best practice with Let's Encrypt
issued SMTP server certificates, as explained in:

    https://www.internetsociety.org/deploy360/blog/2016/03/lets-encrypt-certificates-for-mail-servers-and-dane-part-2-of-2/

-- 
	Viktor.

---

From: Michael Kliewe <[email-masked]>
Date: Thu, 14 Apr 2016 21:58:18 +0200

I totally love it! 11:30am GMT we saw the first DANE connection to web.de:

Verified TLS connection established to mx-ha02.web.de[212.227.17.8]:25: 
TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)

It would be awesome to get some insights into this big deployment, to 
show and help others to also deploy DNSSEC and DANE. Which software is 
used, which steps were taken to slowly start using it, which problems 
came up on the way and how were they solved. Any information about 
increased traffic or load on the DNS-Servers, or failed mail transfers 
because of buggy mailservers, would be very helpful during the next 
days. Is DANE verification activated for outbound mail traffic?
I hope we get some insights here.

By the way: mail.de does not belong to United Internet (web.de, 
mail.com, GMX, 1&1...)

Michael

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 21 Apr 2016 16:17:35 +0000

On Thu, Apr 14, 2016 at 06:38:56PM +0000, Viktor Dukhovni wrote:

> hosts.

And today also the rest of the major 1&1 (Mail&Media) email domains:

    gmx.de
    gmx.net
    gmx.com
    gmx.ch
    gmx.at

> mailboxes for a substantial fraction of the population of Germany. ]

    https://icannwiki.com/.gmx

    With over 32 million customers Mail&Media covers nearly 50% of
    the German Webmail market. With its brands, Mail&Media is the
    largest free email provider in the German speaking countries
    of Germany, Switzerland, Austria, Luxembourg and Liechtenstein.

Together with web.de this likely makes over 30 million recently
added mailboxes with DANE TLSA records.  DANE is now supported by
the below home internet / email / hosting  providers.

    gmx.at
    gmx.ch
    gmx.com
    mail.com
    gmx.de
    posteo.de
    unitymedia.de
    web.de
    comcast.net
    gmx.net
    t-2.net
    xs4all.net
    xs4all.nl
    transip.nl
    udmedia.de
    nederhost.net

DANE is no longer just at hobbyist domains and a few smaller early
adopters like Posteo and Unitymedia.  This is starting to get
interesting.

While the even larger Gmail, Outlook.com/Hotmail, Yahoo ... are
not in the near term in a position to deploy DNSSEC, I expect that
doing so is simpler for outlook.com, because this domain does not
overlap with major web properties whose scale makes the transition
considerably more difficult.  So it would be great to add Microsoft
to the above list some time in 2017 (or sooner).

DANE for gmail.com is also plausible without impacting all of
Google, but requires moving the MX hosts out of the present
google.com.

-- 
	Viktor.

---

From: [email-masked]
Date: Fri, 22 Apr 2016 11:39:01 +0200

>> mailboxes for a substantial fraction of the population of Germany. ]

Hello,

congratulation, good work in pushing a useful security standard forward.

Do you some information if they are also doing DANE outbound?

Regards

Andreas

---

From: Viktor Dukhovni <[email-masked]>
Date: Fri, 22 Apr 2016 15:36:37 +0000

On Fri, Apr 22, 2016 at 11:39:01AM +0200, [email-masked] wrote:

> >    gmx.de ...
> Congratulation, good work in pushing a useful security standard forward.

Thanks.  It's taken a bunch of work behind the scenes.

> Do you some information if they are also doing DANE outbound?

I've not asked yet.  I expect that they will soon, if they've not
already.  It would be great if they posted some operational experience
of how this affected their outbound mail flow.

DANE is still quite new, and so some bumps in the road are to be
expected.  I've smoothed out many of the larger ones in the DNSSEC
space (notified DNS operators of issues to fix that then got fixed),
and also managed to help many an early adopter to get key rotation
right.  

So today, out of the ~300,000 DANE-capable domains (DNSSEC signed
and MX hosting not outsourced to an unsigned domain) that I've been
able to find, ~15,000 have TLSA RRs, while ~200 still have some
DNS issues and ~50 have invalid TLSA records.  Just one MX host is
doggedly sticking with PKIX-EE(1) TLSA records despite RFC7672 and
my attempts to reason with the operator:

    dougbarton.us. IN MX 10 dougbarton.us

So overall, the deployment picture picture is pretty good.  I've
not heard of any significant issues from posteo.de, they I believe
have enabled DANE outbound some time ago.

On the DNS front, while progress is slow, I still expect the number
of problem domains to fall as more DNS providers upgrade or remediate
their systems.  

Next on the list are isphuset.no and axc.nl, with the former
responsive, but very slow (ticket open since Aug/2015) and the
latter as yet unresponsive.  Help appreciated from anyone who has
a working relationship with either provider, particularly axc.nl.

-- 
	Viktor.

---

From: "Gumprich, Mario" <[email-masked]>
Date: Fri, 22 Apr 2016 16:28:51 +0000

> have enabled DANE outbound some time ago.
We from Unitymedia has enabled DANE outbound a couple of month ago.

Today’s list of DANE inbound enabled domains / MX-IPs extracted from logs.
mail.lux01.de[194.117.254.21]
mail.lux01.de[2a05:d580:0:1337::15]
mail.ud11.udmedia.de[194.117.254.51]
mail.ud11.udmedia.de[2a05:d580:0:1337::33]
mail.zeus06.de[194.117.254.36]
mail.zeus06.de[2a05:d580:0:1337::24]
mail.zeus08.de[194.117.254.38]
mail.zeus08.de[2a05:d580:0:1337::26]
mi.ruhr-uni-bochum.de[134.147.42.228]
mi.ruhr-uni-bochum.de[134.147.53.148]
mx00.emig.gmx.net[212.227.15.9]
mx00.gmx.net[212.227.15.10]
mx00.mail.com[74.208.5.20]
mx01.emig.gmx.net[212.227.17.5]
mx01.gmx.net[212.227.17.4]
mx01.mail.com[74.208.5.22]
mx01.mail.de[2001:868:100:600::210]
mx01.mail.de[213.128.151.210]
mx-01.ngi-net.de[2a01:4f8:161:302c::1:1]
mx-01.ngi-net.de[5.9.41.38]
mx01.posteo.de[185.67.36.61]
mx01.xworks.net[31.25.48.11]
mx02.mail.de[2001:868:100:600::211]
mx02.mail.de[213.128.151.211]
mx-02.ngi-net.de[2a01:4f8:161:302d::1:1]
mx-02.ngi-net.de[5.9.41.39]
mx02.posteo.de[89.146.194.165]
mx1.alpha-labs.net[46.229.47.141]
mx1.bund.de[77.87.224.131]
mx1.jpberlin.de[91.198.250.10]
mx1.mailbox.org[80.241.60.212]
mx2.bund.de[77.87.228.110]
mx2.comcast.net[2001:558:fe21:2a::6]
mx2.denic.de[2a02:568:102:211::1:2]
mx2.denic.de[81.91.161.38]
mx2.jpberlin.de[91.198.250.20]
mx2.mailbox.org[80.241.60.215]
mx2.xs4all.nl[194.109.24.138]
mx3.xs4all.nl[194.109.24.134]
mx4.xs4all.nl[194.109.24.139]
mx-ha02.web.de[212.227.17.8]
mx-ha02.Web.de[212.227.17.8]
mx-ha02.Web.De[212.227.17.8]
mx-ha02.WEB.de[212.227.17.8]:
mx-ha03.web.de[212.227.15.17]
postrelay1.lrz.de[2001:4ca0:0:103:0:25:1:1]
smtp4.rz.tu-harburg.de[134.28.205.34]
uhura.unitymedia.de[80.69.97.11]

Pretty cool, the list grows from month to month.

//br Mario

---

From: Viktor Dukhovni <[email-masked]>
Date: Mon, 25 Apr 2016 03:48:33 +0000

> We from Unitymedia has enabled DANE outbound a couple of month ago.

Thanks for the update.

> ...

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

-- 
	Viktor.

---

From: Daniel Stirnimann <[email-masked]>
Date: Thu, 28 Apr 2016 11:45:30 +0200

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

---

From: Daniel Stirnimann <[email-masked]>
Date: Thu, 28 Apr 2016 12:11:09 +0200

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:
> _______________________________________________
> dane mailing list
> [email-masked]
> 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-masked], http://www.switch.ch

---

From: Daniel Stirnimann <[email-masked]>
Date: Thu, 28 Apr 2016 14:40:17 +0200

Seems to be a typo and their signer (PowerDNS) correctly ignored it and
used the correct value of 1.

Daniel

---

From: [email-masked] (Martin Rex)
Date: Thu, 28 Apr 2016 16:19:20 +0200 (CEST)

> Given that the problem domans are rather few, perhaps you've never

doing DNSSEC verification is not exactly easy, more like sufficiently close
to the "beware of the leopard" in THHGTTG for practical matters.

None of the regular Linux distro builds of the "dig" tool from the
bind package seem to have the necessary code compiled into the binaries.

After download bind source and compiling dig myself (which requires
some non-intuitive wrangling with the build tool), I see the following
DNSSEC outputs:

$ bin/dig/dig +sigchase +trusted-key=./root.keys www.ietf.org. | tail -2
;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS

$ bin/dig/dig +sigchase +trusted-key=./root.keys datatracker.ietf.org. | tail -2
;; Ok this DNSKEY is a Trusted Key, DNSSEC validation is ok: SUCCESS

$ bin/dig/dig +sigchase +trusted-key=./root.keys tools.ietf.org. | tail -2
;; RRSIG is missing for continue validation: FAILED

and the latter failure is something that I don't understand.
If the IETF can not get DNSSEC right, who should?

-Martin

---

From: Daniel Stirnimann <[email-masked]>
Date: Thu, 28 Apr 2016 16:39:44 +0200

> If the IETF can not get DNSSEC right, who should?

tools.ietf.org is not signed
(http://dnsviz.net/d/tools.ietf.org/Vx-T4Q/dnssec/). You forced dig to
validate its signature but there are none.

Daniel

---

From: Jim Reid <[email-masked]>
Date: Thu, 28 Apr 2016 15:40:29 +0100

> On 28 Apr 2016, at 15:19, Martin Rex <[email-masked]> wrote:
> 

tools.ietf.org is an unsigned delegation of the signed ietf.org. Now maybe tools.ietf.org should be signed. Maybe it doesn’t. But it doesn’t *have* to be signed just because its parent zone is siged. After all the root is signed and we’re some way off universal deployment of DNSSEC. Or DANE.

BTW, you should be using proper DNSSEC debugging tools. The latest versions of bind ship with delv and there’s drill from NLnetLabs. Both are FAR superior to dig's ugly sigchase hack when it comes to looking at DNSSEC stuff. If you prefer GUIs, try dnsviz.

> If the IETF can not get DNSSEC right, who should?

They are getting it right AFAICT.

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 28 Apr 2016 16:10:01 +0000

> They are getting it right AFAICT.

Yes, basically right, here's the DS-free delegation:

    tools.ietf.org.         NS      gamay.levkowetz.com.
    tools.ietf.org.         NS      zinfandel.levkowetz.com.
    tools.ietf.org.         NS      merlot.levkowetz.com.
    tools.ietf.org.         NSEC    trac.ietf.org. NS RRSIG NSEC
    tools.ietf.org.         RRSIG   NSEC 5 3 1800 20170308083312 20160308073501 40452 ietf.org. <sig>

The thing one might quibble about is the IMHO much too long RRSIG
validity interval.  One year signatures are rather long.  With this
signature in hand, an attacker can deny any signature for tools.ietf.org
until March 2017 even if the zone were signed tomorrow.

-- 
	Viktor.

---

From: "Peter van Dijk" <[email-masked]>
Date: Fri, 29 Apr 2016 22:22:59 +0200

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/

---

From: Paul Wouters <[email-masked]>
Date: Sat, 30 Apr 2016 13:14:51 -0400 (EDT)

> until March 2017 even if the zone were signed tomorrow.

or until ietf.org rolls the ZSK, whichever time period is shorter.

Paul

---

From: Viktor Dukhovni <[email-masked]>
Date: Sun, 1 May 2016 04:18:01 +0000

> or until ietf.org rolls the ZSK, whichever time period is shorter.

No, they have to roll the KSK, because the attacker can also replay
the current DNSKEY RRset along with the current unsigned delegation,
the DNSKEY RRset is not surprisingly also good for a year.

The DS RRset at the .org level has a more sensible lifetime (21d+1h),
so if a new KSK were deployed now, the insecure delegation could
be invalidated around May 17th.

    $ dig +noall +ans +nocl +nottl +dnssec +multi -t dnskey ietf.org
    ietf.org.               DNSKEY  257 3 5 (
				    AwEAAavjQ1H6pE8FV8LGP0wQBFVL0EM9BRfqxz9p/sZ+
				    8AByqyFHLdZcHoOGF7CgB5OKYMvGOgysuYQloPlwbq7W
				    s5WywbutbXyG24lMWy4jijlJUsaFrS5EvUu4ydmuRc/T
				    GnEXnN1XQkO+waIT4cLtrmcWjoY8Oqud6lDaJdj1cKr2
				    nX1NrmMRowIu3DIVtGbQJmzpukpDVZaYMMAm8M5vz4U2
				    vRCVETLgDoQ7rhsiD127J8gVExjO8B0113jCajbFRcMt
				    UtFTjH4z7jXP2ZzDcXsgpe4LYFuenFQAcRBRlE6oaykH
				    R7rlPqqmw58nIELJUFoMcb/BdRLgbyTeurFlnxs=
				    ) ; key id = 45586
    ietf.org.               DNSKEY  256 3 5 (
				    AwEAAdDECajHaTjfSoNTY58WcBah1BxPKVIHBz4IfLjf
				    qMvium4lgKtKZLe97DgJ5/NQrNEGGQmr6fKvUj67cfrZ
				    UojZ2cGRizVhgkOqZ9scaTVXNuXLM5Tw7VWOVIceeXAu
				    uH2mPIiEV6MhJYUsW6dvmNsJ4XwCgNgroAmXhoMEiWEj
				    BB+wjYZQ5GtZHBFKVXACSWTiCtddHcueOeSVPi5WH94V
				    lubhHfiytNPZLrObhUCHT6k0tNE6phLoHnXWU+6vpsYp
				    z6GhMw/R9BFxW5PdPFIWBgoWk2/XFVRSKG9Lr61b2z1R
				    126xeUwvw46RVy3hanV3vNO7LM5HniqaYclBbhk=
				    ) ; key id = 40452
    ietf.org.               RRSIG   DNSKEY 5 2 1800 20170308083223 (
				    20160308073501 45586 ietf.org.
				    IOQgHR12mJD0TO9+wnJLDh7N/2lhnIrcvf5ZlwtwBWn6
				    LDg2OJVN/CGtoOaNUYMPxgrzG5Ww7qAMn84vAhunBf1c
				    +yfX5XCO99+K3tXsqRg+znMnAmOTFRcTztG2B8u4keRu
				    beKYWfXFk9LGmGd7BXczKa0F+HjhyeLpOeXOnfTMn1Gy
				    RvcVetJJqp7HpKowc23rxSEADC/NB+3euARWUTlrk9AX
				    P9OThWMzOlYk6hvBPNQtrl5iM8eZGw9QqF3SDlduHyFd
				    bmNdD3QR9XjfYpOq3MuqWCMbrBTUmljNRLO8eswUCYxl
				    IrE5vggDraAZiSGHmTf5g3YToPchp3DkTg== )
    ietf.org.               RRSIG   DNSKEY 5 2 1800 20170308083248 (
				    20160308073501 40452 ietf.org.
				    n5vYSrmnnylmFVP6KmqjujHDOVlr+A8o8RldrXZENJNU
				    BBGs/HsA/WkEQiLOBE3dv8CpOtF7fCH4fwNzS8J47K/K
				    64Zb4Z13Z0aEWtpKo1lJDGKr/UWn0s9PQelMWu3z2tQa
				    vfUeCHuZZDwhhHf2jSxiq5AOtRCOzbDCvAmPhzW4/sXX
				    QzVanXbQzBWAlIBIDO065zUla08ldkWC4xPE0S9MzAwA
				    MEWkhcfau6FfI0+W5ePRdcVpXKywZq8VmWjxV/g2f5sT
				    Ws+dXMvWVKfsvyYx94NIwxL+hbMUX+eik50d5S3T946s
				    AzyN5WzzkVR6QTxCs7THASBPuiruC2Luqw== )

    $ dig +noall +ans +nocl +nottl +dnssec +multi -t ds ietf.org
    ietf.org.               DS      45586 5 1 (
				    D0FDF996D1AF2CCDBDC942B02CB02D379629E20B )
    ietf.org.               DS      45586 5 2 (
				    67FCD7E0B9E0366309F3B6F7476DFF931D5226EDC534
				    8CD80FD82A081DFCF6EE )
    ietf.org.               RRSIG   DS 7 2 86400 20160516150430 (
				    20160425140430 20264 org.
				    gL/MRQuOAoHDE25R3K9pvSFjJdd6ugmdSuwZSvnhEqP2
				    FemzlHFbPV0eNwJlezIAV4p95U/Hxikb3dgGSTac6jch
				    9RIyfdtDU/Rp6nk2SYjJRnrc4VxBTSfugcBHPGOmlHtq
				    SPDrjk8iNM0x9r+ZTXwGod40oX9dobwCE3OQ5NM= )

-- 
	Viktor.