[dns-operations] BIND validation problem with some DE zones [was: Operational Note -- DNSSEC for DE]

Wolfgang Nagele wnagele at ripe.net
Tue May 24 18:48:28 UTC 2011


I think this might be a timing issue. It seems that .DE has included DS records
in the zone _before_ this zone was available on all systems. In that case I
believe BIND trips if it reaches a server where it does not get any DNSKEY set
because it would be wrong for .de to hand out DS records if the zone itself was
not even signed. This can be verified by clearing the cache and retrying - if
one reaches a server that carries the DUdeZ it just works.

One can reproduce this scenario by configuring .de to use a static-stub zone
(only supported in 9.8) that redirects .de requests to one of the systems known
to already carry the DUdeZ as follows:

zone de {
  type static-stub;
  server-addresses {; }; // z.nic.de

In this case it seems to work (although granted, the static-stub thing might do
some more magic that I don't know about).

I believe that .de should have first been rolled out onto all servers using the
DUdeZ and _after_ that the DS records should have been introduced. Refer to for
instance .com rollout[1] that used this kind of timing.

Attached is a BIND 9.8 log of a failed lookup for exanames.de. As another
datapoint. BIND 9.6-ESV does not seem to be affected.


[1] http://www.ietf.org/mail-archive/web/dnsop/current/msg08990.html

On 5/24/11 17:39, Chris Thompson wrote:
> On May 24 2011, Peter Koch wrote:
>> Dear list,
>> this is to inform the wider operator community that DENIC has started the
>> deployment of a deliberately unvalidatable DE zone (DUdeZ) end of last
>> week. [...]
> I have e-mailed Peter offlist about this, but as the scope of the
> problem looms larger, I should maybe post about it here as well as
> on bind-users, in case people prefer to discuss it here on dns-oarc.
> I would welcome some indication that we are not the only site in the
> world seeing this, of course!
> Here is a copy of my last bind-users posting::
> On May 24 2011, I wrote:
>> We are getting DNSSEC-related SERVFAILs on names in bund.de (e.g.
>> mx1.bind.de). This happens with all of BIND 9.7.3-P1, 9.7.4b1 and
>> 9.8.0-P1 configured with the root and dlv.isc.org trust anchors.
>> However, I can't see what is actually wrong with it, using dig +cd as
>> necessary. All the signatures appear to have valid start/stop times, and
>> http://dnsviz.net/d/mx1.bund.de/dnssec/ seems pretty happy with it. There
>> are a lot of false trails (e.g. the DS records for it in "de") but that
>> shouldn't stop BIND finding the one that works (DLV in dlv.isc.org ->
>> KSK with tag 10923 -> ZSK with tag 4814), should it?
>> It may be significant that this problem was reported to us on the same
>> day that obscured DNSKEY records were introduced into the "de" zone...
> That seems almost certain to be the precipitating event, in fact.
> I can produce the same effect for all 31 zones that are both registered
> in dlv.isc.org *and* have a DS record in de:
>  adns1.de.                           ralf-pulz.de.
>  brj-berlin.de.                      reichel-jens.de.
>  btw-kinderdorf.de.                  schrimpe.de.
>  buergerhaushalt-marzahn.de.         sgfun.de.
>  bund.de.                            sgmail.de.
>  com.de.                             stadtteilzeitung-nordwest.de.
>  exanames.de.                        stefan-gransow.de.
>  gun.de.                             stegranet.de.
>  idkom-networks.de.                  steinmuss.de.
>  ifw-dresden.de.                     unixbuero.de.
>  iks-jena.de.                        verein-kiekin.de.
>  ipse-online.de.                     wartenbergerhof.de.
>  judo-dresden.de.                    wikileaks.de.
>  ombudschaft.de.                     zrb-kiekin.de.
>  ombudschaft-jugendhilfe.de.
> Among other oddities:
>  dig +dnssec dnskey [zone] gives the right answer *without* the ad bit
>  dig +dnssec soa [zone] gives SERVFAIL, unless +cd is used as well.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: exanames.de_failed.txt
URL: <http://lists.dns-oarc.net/pipermail/dns-operations/attachments/20110524/dbe21a8a/attachment.txt>

More information about the dns-operations mailing list