Subject: Re: [DNSOP] New Version Notification for draft-wessels-dns-zone-digest-01.txt

From: Shane Kerr <[email-masked]>
Date: Fri, 01 Jun 2018 10:51:00 +0000

Wessels, Duane:
> 
>> On May 25, 2018, at 11:33 AM, 神明達哉 <[email-masked]> wrote:
>>
>> At Wed, 23 May 2018 15:32:11 +0000,
>> "Weinberg, Matt" <mweinberg=[email-masked]> wrote:
>>
>>> We’ve posted a new version of draft-wessels-dns-zone-digest.  Of note,
>> this -01 version includes the following changes:
>> [...]
>>> We plan to ask for time on the dnsop agenda in Montreal.  Your feedback
>> is welcome and appreciated.
>>
>> I've read the draft.  I have a few high level comments and specific
>> feedback on the draft content:
>>
>> - It was not really clear exactly what kind of problem this digest
>>   tries to solve, especially given that the primarily intended usage
>>   is for the root zone, which is DNSSEC-signed with NSEC.
> 
> Thanks you for the feedback.  We will write a clearer problem statement
> in the introduction for the next version.

As I mentioned, I have seen zones broken during transfer in production,
and having a standard way to check for this seems reasonable.

>> - This digest can't be incrementally updated, that is, you'll need to
>>   calculate the digest over the entire zone even if just a single
>>   record is modified (am I correct?).  That's probably an inevitable
>>   cost for the motivation of providing cryptographically strong
>>   integrity check, but that's a pity for me.  One case I know of where
>>   things like "zone digest" is wanted is to ensure consistency for a
>>   very large zone between primary and secondary servers that are
>>   synchronized using IXFR.  In principle they must be consistent, but
>>   operators may want to have a lightweight (albeit not
>>   cryptographically strong) way to confirm no unexpected events (such
>>   as an implementation bug) quietly broke the consistency.  Perhaps
>>   such usage is just outside the scope of this proposal, but I first
>>   expected I could use it for this kind of purpose it was a bit
>>   disappointing and I wanted to mention it.
> 
> Incremental updates could be supported if the working group feels it is
> important.  We have a working proof-of-concept implementation of this that
> hashes individual RRsets and then XORs them into a final message digest
> (thanks to Roy Arends for the suggestion).
> 
> However, this complicates the implementation.  It almost certainly requires
> more CPU processing but probably not to an extent that matters significantly.
> We could do some simple benchmarks.
> 
> If there is desire to follow this path, then we should discuss whether or
> not to keep having the zone digest algorithms exactly match the DS digest
> algorithms.  For example, digest alg 2 could mean "SHA256 over the zone
> as a whole" while digest alg 3 could mean "SHA-256 digest and XOR individual
> RRsets" to support incremental updates.

As I mentioned in my review of the first version of this document, I
think that inserting digest records periodically throughout the zone
could serve to allow incremental updates (as the recipient can cache
unchanged values) and also allow a degree of parallelism.

I certainly won't push for it. My main concern is that for large-ish
zones with frequent updates digest is basically useless without such a
mechanism.

Cheers,

--
Shane

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 1 Jun 2018 16:54:02 +0530

> unchanged values) and also allow a degree of parallelism.

Interesting. Merkle tree for the domain name space nodes would also be
suitable. It means that for a zone with a large number of labels at a
single domain tree level, all the individual hashes underneath would
have to be hashed, but it seems OK. e.g., with SHA-256:

[muks@jurassic ~]$ openssl speed sha256
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha256           67640.07k   146564.37k   254310.49k   313201.19k   337102.17k   339285.33k

Merkle tree would lend itself well to representation in current DNS tree
implementations, and they may be used for other DNS purposes in the
future too. ;)

Instead of use of plain SHA-1 and GOST in table 1, I'd like to see
SHA3-256. I'd also make SHA-384 as mandatory as for hashing this large
amount of data as SHA-512 is known to perform better than SHA-256 on
popular processors.

[muks@jurassic ~]$ openssl speed sha512
...
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
sha512           46730.69k   187840.56k   291941.29k   416484.51k   475806.75k   476692.21k

		Mukund

---

From: 神明達哉 <[email-masked]>
Date: Fri, 1 Jun 2018 11:06:48 -0700

At Thu, 31 May 2018 18:18:16 +0000,
"Wessels, Duane" <dwessels=[email-masked]> wrote:

> > - This digest can't be incrementally updated, [...]
>

It's just an observation, not a blocking issue.  But I think it's
worth discussing in the WG if and when this document is adopted.

> > Specific comments:
> >
> > - Section 4.1
> >
> >    This specification adopts DNSSEC's canonical ordering for names
> >    (Section 6.1 of [RFC4034]), and canonical ordering for RRs within an
> >
> >   This means upper case letters in owner names are converted to lower
> >   case ones.  It could be considered a feature, but I guess some
> >   operators might want to check integrity including letter case of
> >   names.  For example, recent versions of ISC BIND 9 tries quite hard
> >   to preserve the letter case of owner names per RRset basis, which I
> >   think suggests operator needs for preserving the case as much as
> >   possible.
>
> We do not propose that owner names be permanently converted.  DNSSEC has this
> same characteristic, does it not?  The validator canonicalizes the owner names
> upon validation, but does not cache them canonicalized.

Perhaps I wasn't clear.  What I tried to say is that we can't notice
that using this digest if 'WWW.EXAMPLE.COM. IN AAAA 2001:db8::1' is
magically changed to 'www.example.com. IN AAAA 2001:db8::1' in the
zone.  This is also slightly related to the "problem statement".  If
the digest can detect this kind of change, it will be another new
feature that DNSSEC-based integrity check can't detect.  Of course,
whether we want this feature is a different question.  I wonder there
might be a need for this by referring to the BIND 9 changes, but I
don't know if it's real or just imaginary.

> > - Section 4.4
> >
> >    The zone digest is calculated by concatenating the canonical on-the-
> >    wire form of RRs in the zone, in the order described above, subject
> >    to the inclusion/exclusion rules described below, and then applying
> >    the digest algorithm:
> >
> >   I wonder whether glue records are included in these RRs.  Either
> >   way, it would be better to clarify the point.
>
> If we say "calculated by concatenating ... all RRs in the zone" is that sufficient?

I'd be even more explicit, like 'all RRs in the zone including glue
records' or 'all RRs in the zone including those on and below a zone
cut'.

BTW, there may be some interesting corner cases related to this point.
If we configure the 'example.com' zone with the following records:

d.example.com. IN DNAME d.example.org.
a.d.example.com. IN AAAA 2001:db8::1

then, should the AAAA record be included in the digest?  BIND 9
doesn't consider it an error, does load it into memory and transfer it
via AXFR, and, IIRC, would use it to answer queries if the DNAME is
removed via DDNS or IXFR.  So this question has a practical
implication at least for such an implementation.

--
JINMEI, Tatuya

---

From: Mukund Sivaraman <[email-masked]>
Date: Fri, 1 Jun 2018 23:57:00 +0530

RFC 6672 (DNAME) seems to contradict itself for this.. it first says:

> 2.4.  Names next to and below a DNAME Record
>
>    Resource records MUST NOT exist at any subdomain of the owner of a
>    DNAME RR.

Then, it continues and says:

>   A server MAY refuse to load a zone that has data at a
>   subdomain of a domain name owning a DNAME RR. 

Further:

> 5.2.  Dynamic Update and DNAME
>
>    DNAME records can be added, changed, and removed in a zone using
>    dynamic update transactions.  Adding a DNAME RR to a zone occludes
>    any domain names that may exist under the added DNAME.

It is clear that UPDATE introducing a DNAME could cause some RRs to be
occluded but remain part of the zone. Such zones written to a master
file should still be loadable from a usability point of view.  I guess
the RFC meant to say in 2.4 that "answers MUST NOT be served for any
subdomain of the owner of a DNAME RR" vs. "records MUST not exist".

It looks to me that BIND does the right thing, and the records must be
considered part of the zone, and should be digested.

Similarly with "NS" too in RFC 2136:

> 7.18. Previously existing names which are occluded by a new zone cut
> are still considered part of the parent zone, for the purposes of
> zone transfers, even though queries for such names will be referred
> to the new subzone's servers.

		Mukund

---

From: Petr Špaček <[email-masked]>
Date: Tue, 19 Jun 2018 16:31:55 +0200

> and having a standard way to check for this seems reasonable.

Hmm, can you share some details about your experience?
Did you find out when the data corruption took place?
a) network transfer
b) implementation bugs (e.g. incorrectly received IXFR)
c) on disk
d) some other option?

I wonder if this proposal is worth the complexity ... If we wanted plain 
checksum we could use TSIG with built-in key (all zeroes or so) and to 
get checksum for the network part with negligible implementation 
complexity. (TSIG trick is Mukund's idea, not mine.)

If we wanted checksum for on-disk data, well, the outside world has 
tools for this already ...

This proposal smells little bit as not-invented-by-dnsop syndrome 
because it does not build on existing technology. There are technologies 
to protect data in transit and technologies to protect data at rest 
already so we might look how to reuse them instead of reinventing wheel 
just for DNS. Reinvented wheels tend to have sharp edges, especially in 
security area :-D

> zones with frequent updates digest is basically useless without such a

It depends on what you want to protect from: If it is corruption during 
network transfer then TSIG is the answer, possibly with a built-in key 
(e.g. all zeroes to make it zero config/checksum only).

I think we need to first answer question why existing technologies do 
not fit the purpose.

-- 
Petr Špaček  @  CZ.NIC

---

From: Shumon Huque <[email-masked]>
Date: Tue, 19 Jun 2018 14:11:02 -0400

> I think we need to first answer question why existing technologies do

This is a reasonable question.

I noticed that the draft doesn't mention SIG(0) at all. One of the main
motivators of the draft is stated to be secure, wide scale distribution of
the root zone. To me, SIG(0) would have been an obvious candidate solution
for this problem. The zone owner can publish one public key to the world,
and signs zone transfers messages with the corresponding secret key. If the
zone owner supports IXFR, the incremental cost of these message signatures
is also quite small.

Possible issues with SIG(0):

* Although it is an existing technology, it isn't widely implemented or
used. I just learned on DNS twitter that BIND only supports SIG(0) for
UPDATE for example, and not XFR.

* If the goal is to support secure acquisition of the zone outside the DNS
protocol, then it can't do that. But neither is ZONEMD needed for that - we
can use an out of band signature using a variety of methods.

* And there is also the question of the status of SIG(0) which isn't clear
to me: Although RFC 2931 is not obsolete, it is based on the SIG record,
which is defined in an RFC that has been obsoleted by the DNSSEC-bis
documents.

-- 
Shumon.

---

From: "Wessels, Duane" <[email-masked]>
Date: Tue, 19 Jun 2018 18:56:43 +0000

> On Jun 19, 2018, at 11:11 AM, Shumon Huque <[email-masked]> wrote:
> 
> 
> I noticed that the draft doesn't mention SIG(0) at all.

I suppose this is happened because, as you say it isn't widely implemented or used.

> One of the main motivators of the draft is stated to be secure, wide scale distribution of the root zone. To me, SIG(0) would have been an obvious candidate solution for this problem. The zone owner can publish one public key to the world,

My reading of RFC 2931 contradicts this.  For example:

2.3 Keying

   The private keys used in transaction security belong to the host
   composing the DNS response message, not to the zone involved.
   
In other words, SIG(0), like TSIG, is about asserting the security of an individual transaction from a particular server, not the contents of zone data.

Also:

   The corresponding public key(s) are normally stored in and retrieved
   from the DNS for verification as KEY RRs ...  Thus it will be necessary
   to keep the private key on-line, for example in software or in a directly
   connected piece of hardware.

It doesn't make sense to me to consider using KEY RRs and online private keys when we already have working DNSSEC infrastructure.

> and signs zone transfers messages with the corresponding secret key. If the zone owner supports IXFR, the incremental cost of these message signatures is also quite small.
> 
> * Although it is an existing technology, it isn't widely implemented or used. I just learned on DNS twitter that BIND only supports SIG(0) for UPDATE for example, and not XFR.
> 
> * If the goal is to support secure acquisition of the zone outside the DNS protocol, then it can't do that. But neither is ZONEMD needed for that - we can use an out of band signature using a variety of methods.

Yes, this is the crux of it for me and the other authors as well I believe.  In my opinion, detached signatures/checksums are not good enough.  Our not-yet-released -02 draft has this new text:

1.1.2.  Detached Signatures

   Sometimes, detached checksums and signatures can be found adjacent to
   zone files.  This is the case for the root and other zone files
   published on the internic.net sites [InterNIC].  For example, the
   files root.zone.md5 and root.zone.sig are in the same directory as
   the root.zone file.  Unfortunately, since the checksum and signature
   are in separate files, they are only weakly associated with the zone
   file.  They remain associated only if the recipient is careful to
   keep them together.  Nothing in these files, other than their names
   and timestamps, ties them to a specific revision of the root.zone
   file.

DW

---

From: Shumon Huque <[email-masked]>
Date: Tue, 19 Jun 2018 15:14:47 -0400

On Tue, Jun 19, 2018 at 2:56 PM Wessels, Duane <[email-masked]>
wrote:

> > One of the main motivators of the draft is stated to be secure, wide
> scale distribution of the root zone. To me, SIG(0) would have been an
> obvious candidate solution for this problem. The zone owner can publish one
> public key to the world,
>
> In other words, SIG(0), like TSIG, is about asserting the security of an
> individual transaction from a particular server, not the contents of zone
> data.
>

Ah, right - I had forgotten that little detail - thanks for reminding me :)

I guess that was the design goal then, although it didn't have to be that
way. So, with SIG(0) as currently defined, we need a SIG(0) key per
authoritative server name ..

> > * If the goal is to support secure acquisition of the zone outside the
> DNS protocol, then it can't do that. But neither is ZONEMD needed for that
> - we can use an out of band signature using a variety of methods.
>
> Yes, this is the crux of it for me and the other authors as well I
> believe.  In my opinion, detached signatures/checksums are not good
> enough.  Our not-yet-released -02 draft has this new text:
>

Yes, that's a reasonable argument ..

Shumon.

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 20 Jun 2018 04:45:12 +0530

> zone owner supports IXFR, the incremental cost of these message signatures

There also seems to be a scalability problem with SIG(0) in that
generating the signature involves a public-key operation per DNS
message.

For a zone transfer of the root zone from F, the AXFR contains 79
messages in the TCP continuation:

;; XFR size: 22554 records (messages 79, bytes 1335768)

Unfortunately, because the request message's fields are involved in
calculating the signature for the reply message and the ID also varies,
it doesn't appear that the signatures can be re-used.

This scalability problem is probably a reason why TSIG's HMAC has become
the preferred method for transaction security and SIG(0) isn't used to
authenticate zone transfers.

		Mukund

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 20 Jun 2018 04:50:21 +0530

On Tue, Jun 19, 2018 at 04:31:55PM +0200, Petr Špaček wrote:
> checksum we could use TSIG with built-in key (all zeroes or so) and to get
> checksum for the network part with negligible implementation complexity.
> (TSIG trick is Mukund's idea, not mine.)

Well-known TSIG key trick is a Mark Andrews idea from the time when this
was discussed during the CHECKSUM draft.

		Mukund

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2018 09:48:40 +1000

> On 20 Jun 2018, at 9:15 am, Mukund Sivaraman <[email-masked]> wrote:
> 

Donald Eastlake’s early DNSSEC work had a working zone signature.  It doesn’t
require signing each message.  It’s just relatively expensive to compute for
large zones as it requires hashing the entire zone.

RFC 2065 4.1.3 Zone Transfer (AXFR) SIG.

Note this is SIG(AXFR) not SIG(0).

Mark

> 		Mukund
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Shumon Huque <[email-masked]>
Date: Tue, 19 Jun 2018 20:25:46 -0400

>    and timestamps, ties them to a specific revision of the root.zone

Hi Duane,

If you make this comparison, I think you should also mention that there are
many integrated signature/data formats too (supported in PGP, S/MIME, CMS,
PKCS7 etc) that can address your 'weakly associated' critique of detached
signatures. And then argue why the zonemd scheme is superior to those. I
guess one argument is that it uses keys that are already resident in the
DNS and doesn't rely on external protocols?

Shumon.

---

From: Mukund Sivaraman <[email-masked]>
Date: Wed, 20 Jun 2018 22:07:14 +0530

> Note this is SIG(AXFR) not SIG(0).

doc/misc/dnssec in the BIND tree has this text by Andreas Gustafsson
from 2001:

  Secure Zone Transfers

  BIND 9 does not implement the zone transfer security mechanisms of
  RFC2535 section 5.6, and we have no plans to implement them in the
  future as we consider them inferior to the use of TSIG or SIG(0) to
  ensure the integrity of zone transfers.

I wonder what the reasons for "inferior" were.

		Mukund

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Jun 2018 10:18:19 +1000

> On 21 Jun 2018, at 2:37 am, Mukund Sivaraman <[email-masked]> wrote:
> 

When you are getting data from a source that you know to be authoritative
and well behaved you only need to ensure that there is not corruption or
MITM in the transfer.  TSIG and SIG(0) work well for those scenarios.

When you have a untrusted source SIG(AXFR) is better as it is generated
by the ultimate source.  That does come at a cost as does validating the
transfer as both require processing the entire zone in a specified order.

Horses for courses.

---

From: Shumon Huque <[email-masked]>
Date: Wed, 20 Jun 2018 21:15:19 -0400

> ;; XFR size: 22554 records (messages 79, bytes 1335768)

Yup, I realize that. That was one fo the reasons is I mentioned that SIG(0)
can
also sign IXFR messages if they are available from the server, which could
significantly reduce the performance impact. Thinking about it more now
though,
I recall that the current root zone management scheme isn't that conducive
to
incremental transfer, since the zone is signed monolithically twice a day
(IIRC).

Anyway, I'm not really advocating for SIG(0). I'm persuaded that it isn't
optimal. I was just surprised that the draft mentions other potential
solutions,
but didn't mention this one - perhaps it should for completeness.

Longer term, perhaps the best solution will end up being XFR using DNS over
TLS (or HTTPS) with server authentication. Yes, I realize that authoritative
servers are not yet the targets of those protocols, but it's probably only
a matter
of time.

Shumon.

---

From: Petr Špaček <[email-masked]>
Date: Thu, 21 Jun 2018 08:19:37 +0200

On 21.6.2018 03:15, Shumon Huque wrote:
> On Tue, Jun 19, 2018 at 7:15 PM Mukund Sivaraman <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 
> Yup, I realize that. That was one fo the reasons is I mentioned that
> SIG(0) can
> I recall that the current root zone management scheme isn't that
> conducive to
> incremental transfer, since the zone is signed monolithically twice a
> day (IIRC).
> 
> servers are not yet the targets of those protocols, but it's probably
> only a matter
> of time.

HTTPS over TLS is what we did for root zone import into Knot Resolver's
cache (from version 2.3 onwards but beware, there are little bugs which
were fixed in 2.4 - to be released soon).

-- 
Petr Špaček  @  CZ.NIC

---

From: "Wessels, Duane" <[email-masked]>
Date: Thu, 21 Jun 2018 15:55:24 +0000

> On Jun 20, 2018, at 11:19 PM, Petr Špaček <[email-masked]> wrote:
> 
>> 

The problem I'm seeking to solve is somewhat different, and its probably
not clearly stated in the draft so I will add some text to rectify that.

I'm not trying to solve the problem that SIG(0), SIG(AXFR), or TLS addresses
-- that you're talking to the right server and that data wasn't modified
in transit.

My goal is to ensure that when you receive a zone file -- however you
receive it (DNS, HTTPS, P2P file sharing, Avian Carrier) -- you get the
data that the zone publisher actually published.

DW

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Jun 2018 12:40:46 -0400

> data that the zone publisher actually published.

I can't argue with that goal (and yes, you should probably clarify it in
the draft).

The question for me is what are the use cases for this protocol
enhancement, and is this the only way to satisfy those use cases?

In my mind, the main compelling use case is secure distribution of the root
zone at scale to anyone on the Internet. For that, I'd bet that many
consumers would be quite okay with a channel security mechanism to a
"trusted" root zone operator, whatever that mechanism is (TSIG, SIG(0),
TLS, HTTPS, etc) as long as it could be done efficiently and at scale. A
full zone signature from the zone publisher/signer is ultimately more
secure of course. But if the security model is satisfied by trust in RSOs,
then that isn't needed.

The normal case of distributing a zone securely to all your authoritative
server operators, I believe, is adequately satisfied today by zone
transfers authenticated by pre-configured static TSIG keys provisioned
between the authorized parties. Do you see the full zone signature as a
replacement for this scenario too? (There are many zones much larger and
more frequently updated than the root zone, for which I believe the
computational cost of this is too prohibitive).

As noted earlier, out of band verification of the full zone using an
integrated signature that does not rely on an external keying
infrastructure, is also a plausible use case. I'm just wondering if it has
a compelling need.

Anyway, not trying to derail this effort, just asking questions. On
balance, I think I support this draft.

Shumon.

---

From: Shumon Huque <[email-masked]>
Date: Thu, 21 Jun 2018 12:46:23 -0400

> were fixed in 2.4 - to be released soon).

Out of curiosity, which HTTPS source are you using for the root zone import?

Shumon.

---

From: "Paul Hoffman" <[email-masked]>
Date: Thu, 21 Jun 2018 12:08:39 -0700

> I can't argue with that goal (and yes, you should probably clarify it 

Fully agree. However, Duane's goal is only reachable if the zone is 
DNSSEC signed. Otherwise, an attacker can just change zone contents and 
the hash as well.

> enhancement, and is this the only way to satisfy those use cases?

Yes, the use cases are pretty central here. As we have discovered in the 
DOH WG, DNS folks can read a document and come away with quite different 
use cases from the authors *and* from each other, all the time thinking 
that their use case is obvious.

> secure of course. But if the security model is satisfied by trust in 

While "many" consumers think that is OK, some (very vocally) do not. 
Having a hash over the complete root zone, and having that recorded as 
part of the signed zone, should satisfy those that do not want a second 
trust anchor (that is, for the channel security).

> balance, I think I support this draft.

I agree, as long as the use cases are made clear so that we can compare 
the solution against them.

--Paul Hoffman

---

From: Shane Kerr <[email-masked]>
Date: Thu, 21 Jun 2018 22:09:03 +0200

Petr,

> b) implementation bugs (e.g. incorrectly received IXFR)

I don't know. I have seen incorrectly transferred zone files both in 
BIND and NSD slaves. IIRC our solution was to include sentinel records 
in the zone files to spot problems, take the node out of service, and 
force a re-transfer. This of course won't work if you are slaving zones 
that you do not control, and it doesn't prevent a small window of time 
when the servers are operating with broken zones. TSIG was being used.

Another scenario is when you are not using TSIG at all. For my own zones
I don't bother because I don't have any confidential data in them and I
prefer the operational simplicity of not having to set up keys 
everywhere. But this may also be the case for things like the root zone 
where the zone publishers explicitly want people to be able to transfer 
the zones without authentication.

> complexity. (TSIG trick is Mukund's idea, not mine

I kind of like this approach. It doesn't provide any help for 
stand-alone zone files, but in general there is no interoperability 
requirement there and a simple sha256sum file is probably good enough.

Instead of zone digest maybe it makes sense to document Mukund's 
approach in an informational (?) RFC? It still doesn't solve problems 
where something on the receiving side doesn't work due to an 
implementation bug, but I'm basically okay with the recommendation being 
"don't run software that doesn't work". 😉

Cheers,

--
Shane

---

From: Hugo Salgado-Hernández <[email-masked]>
Date: Thu, 21 Jun 2018 16:31:16 -0400

On 22:09 21/06, Shane Kerr wrote:
> BIND
> and NSD slaves. IIRC our solution was to include sentinel records in
> the
> zone files to spot problems, take the node out of service, and force a
> re-transfer. This of course won't work if you are slaving zones that
> you do
> not control, and it doesn't prevent a small window of time when the
> servers
> are operating with broken zones. TSIG was being used.

We have also seen broken transfers between secondaries. Our solution
is to dump the zone after transfer, calculate a hash and compare. We
would benefit from having a ZONEMD record inside the zone.

Hugo

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jun 2018 11:52:46 +1000

> On 22 Jun 2018, at 1:55 am, Wessels, Duane <dwessels=[email-masked]> wrote:
> 
> 

SIG(AXFR) does that.  It is part of the zone’s contents.

---

From: Petr Špaček <[email-masked]>
Date: Fri, 22 Jun 2018 12:48:36 +0200

On 21.6.2018 18:46, Shumon Huque wrote:
> On Thu, Jun 21, 2018 at 2:19 AM Petr Špaček <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> 

It is user configurable and examples in docs
http://knot-resolver.readthedocs.io/en/latest/modules.html#cache-prefilling
use
https://www.internic.net/domain/root.zone

After download the data are DNSSEC validated and inserted into cache.

-- 
Petr Špaček  @  CZ.NIC

---

From: Petr Špaček <[email-masked]>
Date: Fri, 22 Jun 2018 12:58:54 +0200

> would benefit from having a ZONEMD record inside the zone.

If the zone got broken during TSIG-secured transfer then it was not most
probably not caused by network problem because TSIG would have caught that.

Honestly I do not think it is worth the effort because all the
complexity does not help to prevent implementation bugs, I would say it
even increases probability of a bug!

What is left is bug on auth and/or slave sides and in that case there is
no guarantee that
a) master did not compute ZONEMD from already broken data
b) slave verification of ZONEMD actually works

If we wanted to catch problems with implementation we need something
which is outside of the DNS stack we are attempting to check, be is
simple checksum or some fancier crypto.

I can easily imagine OPENPGPKEY RR located at _zonefile.apex.example
node and an utility which would extract OPENPGPKEY RR from the zone file
and verify that the zone file signature (either detached or in .gpg
file) can be verified using that key (+ add DNSSEC into the mix if you
wish).

-- 
Petr Špaček  @  CZ.NIC

---

From: Shumon Huque <[email-masked]>
Date: Fri, 22 Jun 2018 10:56:52 -0400

> incremental transfer, since the zone is signed monolithically twice a day

One other comment on this: Getting better performance than this requires
re-inventing
something akin to TLS key exchange, and I was wondering if anyone had
thought of that
during the development of SIG(0). And sure enough, RFC 2930 proposes (among
other
things) SIG(0) authenticated symmetric key establishment using TKEY, either
via
Diffie-Hellman or client chosen key transport.

So, together with AXFR-SIG (i.e. full zone signature), Don Eastlake appears
to have
long ago contemplated most of the design space around this draft and its
problem space!
:-)

Shumon.