Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)

Ondřej Caletka <> Wed, 28 June 2017 11:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5049B1293E1 for <>; Wed, 28 Jun 2017 04:27:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id R68MxRQ_Lwki for <>; Wed, 28 Jun 2017 04:27:07 -0700 (PDT)
Received: from ( [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CFD2912EBF9 for <>; Wed, 28 Jun 2017 04:27:06 -0700 (PDT)
Received: from [IPv6:2001:718:1:6::134:196] ( [IPv6:2001:718:1:6::134:196]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 14BA5200AD; Wed, 28 Jun 2017 13:27:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=office2; t=1498649224; bh=s21TuIA95uMY5kjZFSQM+Akf6WjtJhkJYGnMr0G3s24=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=f37Ze0tynFfkeVKGHlVPF3zabjDbIRf3meMkBFX/9RS7eRV8hS16xSwIlPlT7Yd/F j2rs6oXPmv3oSYUyZJhXrEtVar9jxbLJTGG9rMWVhFnukj9bDBpLymNF349SJPkXgK IqYb2DLm18788ExyN3oSGCnCuZRMQ7ZEoFtzg8Fg=
To: Mark Andrews <>, Dick Franks <>
References: <> <> <> <> <> <> <> <> <> <> <> <>
Cc: tjw ietf <>, Matthijs Mekking <>, Jan Včelák <>, IETF DNSOP WG <>, Suzanne Woolf <>,,, Ólafur Guðmundsson <>, Olafur Gudmundsson <>, RFC Editor <>, Jaromír Talíř <>
From: Ondřej Caletka <>
Message-ID: <>
Date: Wed, 28 Jun 2017 13:27:03 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms010703010307080509000101"
Archived-At: <>
Subject: Re: [DNSOP] [Technical Errata Reported] RFC8078 (5049)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 28 Jun 2017 11:27:09 -0000


>Dick Franks:
>> What is needed now is methodical use-case analysis based on RFC8078 as it
>> exists now and tested against a real implementation.  The time to rewrite
>> the RFC will come if/when we discover we are unable to live with it. We
>> have not reached that point yet.
Mark Andrews:
> I can't go from RFC8078 to a working implementation because the
> existing description is not clear enough to do it.  I don't think
> anyone can do it.
> With the proposed errata fix I could write code.  For CDS the RRset
> is a single RR with a rdata of 0x00 0x00 0x00 0x00 0x00.  For CDNSKEY
> the RRset is a single RR with a rdata of 0x00 0x03 0x00 0x00 0x00.

I have a confirmation from the real implementation of RFC8078 in the .CZ
domain registry (cc jaromir.talir) that their understanding of CDNSKEY
DELETE operation is exactly the set of RDATA quoted by Mark Andrews,
which translates to the presentation form CDNSKEY 0 3 0 AA==

I don't think there is a big room to interpret RFC 8078 differently,
since it does not define any new presentation/wire format for
CDS/CDNSKEY record. Therefore, even future versions of software that
(de-)serializes RRs between wire and presentation format will have
issues if there are not all fields mandated by RFC 4034 present in the

Ondřej Caletka