Subject: [DNSOP] A new version of mixfr

From: Matthijs Mekking <[email-masked]>
Date: Wed, 28 Mar 2018 15:31:57 +0200

All,

It's been a while, but I have put up a new version of the MIXFR draft:

     https://tools.ietf.org/html/draft-mekking-mixfr-02

The IETF 101 Hackathon lead to the revival of this draft.

Changes after the three year sleep:

- I removed the IXFR Gone Wild section. This document should focus in 
the in-band transfer improvements. I know there are others who like to 
see and work on a new DNS transfer protocol, but one does not exclude 
the other.
- Intended status: Standards track.
- Added a clarification from Bob Harold about class ANY (from 2015).
- Remove ambiguous "Delete All RRsets of a Type".
- Affiliation changes.

Who would like to contribute, review, and all that great fun?

Github is here: https://github.com/matje/mixfr

Best regards,
   Matthijs

---

From: Tony Finch <[email-masked]>
Date: Wed, 28 Mar 2018 15:08:04 +0100

>     https://tools.ietf.org/html/draft-mekking-mixfr-02

I've had a quick skim and it looks nice.

Suggestions for 2nd paragraph of intro:

   To keep the deltas small in zone transfers, we need to have a richer
   change syntax. This specification re-uses syntax from DNS UPDATE,
   [RFC2136].  It introduces a new query type MIXFR (minimal
   incremental zone transfer) that allows a client to request this richer
   syntax.  The goal of this proposal is to allow small changes to be
   communicated over UDP, and remove as much redundant information from
   the zone transfer as possible.

I still prefer the name "UXFR (update-style IXFR)" :-)

Is UDP support supposed to be required? (I believe BIND requires TCP for
IXFR even if the delta could fit in UDP.)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/  -  I xn--zr8h punycode
South German Bight: Cyclonic 5 to 7. Moderate or rough. Occasional rain.
Moderate or poor.

---

From: Pieter Lexis <[email-masked]>
Date: Wed, 28 Mar 2018 16:43:53 +0200

Hi Matthijs,

On Wed, 28 Mar 2018 15:31:57 +0200

>      https://tools.ietf.org/html/draft-mekking-mixfr-02

The draft speaks of an OPCode in the IANA section and of a meta
RRType in the examples and Introduction section, which is it?

If it is an RRType, some words need to be added about the fact that
current resolvers will pass through the MIXFR query and not reply with
NOTIMPL. In a similar vein, unaware auths will respond with an NXDOMAIN
or (more likely) a NODATA in that case.

Best regards,

Pieter

-- 
Pieter Lexis
PowerDNS.COM BV -- https://www.powerdns.com

---

From: tjw ietf <[email-masked]>
Date: Wed, 28 Mar 2018 10:52:31 -0400

"Transport of a query may be by either UDP or TCP. If an IXFR query

   is via UDP, the IXFR server may attempt to reply using UDP if the
   entire response can be contained in a single DNS packet.  If the UDP
   reply does not fit, the query is responded to with a single SOA
   record of the server's current version to inform the client that a
   TCP query should be initiated."

https://tools.ietf.org/html/rfc1995

On Wed, Mar 28, 2018 at 10:43 AM, Pieter Lexis <[email-masked]>
wrote:

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

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2018 11:52:43 -0300

> or (more likely) a NODATA in that case.

Draft's samples use regular QUERY opcode and I suppose a new met
RRType MIXFR.

Does current auth server have any special processing for meta RRTypes?
If not your are correct regarding the unaware server and this needs to
be stated and handled by clients.

Fred

---

From: Richard Gibson <[email-masked]>
Date: Wed, 28 Mar 2018 10:44:35 -0400

I really like this document, especially the changes to version 02.

One comment: Section 3.6 (Replace an RRset) specifies that "RDLENGTH 
must be non-zero" _and_ that "The same syntax is used to delete an RRset 
and to replace an RRset with an RR whose RDLENGTH is zero". I think the 
former should be dropped; replacing an RRset with a new record having 
zero RDLENGTH is disambiguated by containing section so there is no 
reason to prohibit it.

On 03/28/2018 09:31 AM, Matthijs Mekking wrote:
> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmekking-2Dmixfr-2D02&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI&s=9E3JS209vJp6dQBpJJBXlr32ZbLYLOLNNAiovQ1iAnY&e=
>
> Github is here: 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_matje_mixfr&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI&s=9jcbJIa5DBxRHlL2wVDEwCWBJXvbZffQobFtQvjEMH0&e=
>
> Best regards,
>   Matthijs
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI&s=n1GMn0ZrYJoVbOVyFWt2A2n2n6d5T3xoCwjdK8xsbiw&e= 
>

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2018 12:06:51 -0300

Hi Matthijs,

> - Remove ambiguous "Delete All RRsets of a Type".

Thanks for bringing this back. I like the simplification with the
removal of the wild section.

One comment,

[3.1] As section 3 states that MIXFR is DNSSEC aware we need text
regarding NSEC3PARAM update as well.

For that I suggest to change 3.1 section name and include an extra
paragraph.

3.1 Implicit DNSSEC deletions

When an NSEC3PARAM is modified, the MIXFR client MUST also remove all
existing NSEC3 records on the zone.

One clarification question,

At 3.6, last paragraph, what is the practical case that a updated
record has an RDLENGTH of zero bytes?

Fred

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 28 Mar 2018 17:14:04 +0200

Tony,

> I've had a quick skim and it looks nice.

Thanks.

>     the zone transfer as possible.

I am happy take this. Thanks for contributing text!

> I still prefer the name "UXFR (update-style IXFR)" :-)

I guess we can start a vote ;)

> IXFR even if the delta could fit in UDP.)

According to RFC 1995: Transport of a query may be by either UDP or TCP.

Best regards,
   Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 28 Mar 2018 17:23:12 +0200

Pieter,

> RRType in the examples and Introduction section, which is it?

Probably copy paste error from a different draft. MIXFR is a new query 
type, so that's an error in the IANA section. The intention is to 
request a new RRtype. Thanks for catching this.

> or (more likely) a NODATA in that case.

IXFR solved this by saying "If the query type is not recognized by the 
server, an AXFR (preceded by a UDP SOA query) should be tried, ensuring 
backward compatibility." Probably MIXFR can say something similar.

A resolver should behave similar for MIXFR as it does for AXFR and IXFR. 
I can't find words about this in RFC 1995 or RFC 5936, so I am not sure 
if this document should add something about that.

Groeten,

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 28 Mar 2018 17:37:47 +0200

Richard,

> I really like this document, especially the changes to version 02.

Thanks:)

> zero RDLENGTH is disambiguated by containing section so there is no 

Right. But we use RDLENGTH must be zero in the case to delete a whole 
RRset. So I do like to have some words to clarify it. But you are right 
that it is not a requirement.

Best regards,

Matthijs

---

From: Matthijs Mekking <[email-masked]>
Date: Wed, 28 Mar 2018 17:43:15 +0200

Frederico,

> removal of the wild section.

Thank you.

> existing NSEC3 records on the zone.

I agree that with the current syntax NSEC3 resalting is still a hassle. 
But I am not sure if this implicit NSEC3 deletion is the right solution: 
One can have multiple chains in the zone, the NSEC3PARAM just signals 
that the chain is complete. Signers may have incomplete chains as an 
intermediate step of NSEC3 resalting.

I shall add a GitHub issue for this. Thanks for bringing it up!

> record has an RDLENGTH of zero bytes?

It is as Richard pointed out not required, but I would like to clarify 
the difference between deleting an RRset and replacing an RRset.

Best regards,

Matthijs

---

From: Ray Bellis <[email-masked]>
Date: Wed, 28 Mar 2018 16:50:31 +0100

> or (more likely) a NODATA in that case.

A Meta RRType should never be passed through resolvers - they're only
used on the wire between client and server, and not end-to-end.

Ray

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2018 13:52:11 -0300

On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:
...
> I shall add a GitHub issue for this. Thanks for bringing it up!

Yes this needs to be further discussed. But I guess a partial resalting
the way you describe could be done today using IXFR with no decrease
on transfer size, so it defeats the purpose of MIXFR in this case.

Today, let me emphasize for large zones, the only practical way of
resalting is a full zone resign and transfer using AXFR. Partial
resalting results after the very last "part", before you will be ready
to updated the NSEC3PARAM and start to delete the old chain, a
doubling in the size of the nsec3 records. I guess the argument
regarding memory consumption is only relevant on the time that it will
be used, less during an AXFR/MIXFR more on the partial/IXFR case.

MIXFR the way I described will reduce the need to remove the old chain
records making a resalting viable without the need of an AXFR.

Fred

---

From: Paul Vixie <[email-masked]>
Date: Wed, 28 Mar 2018 11:53:02 -0700

> I still prefer the name "UXFR (update-style IXFR)" :-)

:-). +1, if we're voting.

-- 
P Vixie

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Mar 2018 07:28:22 +1100

No. You can have multiple nsec3 chains in a zone at the same time. Only one is active.  Some may be incomplete. 
 
Named builds and destroys chains incrementally to avoid large changes. 

Timely ness of changes is more  important than volume of changes.

-- 
Mark Andrews

> On 29 Mar 2018, at 02:06, Frederico A C Neves <[email-masked]> wrote:
> 
> Hi Matthijs,
>

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2018 18:12:09 -0300

> Timely ness of changes is more  important than volume of changes.

As I stated down on this thread this behaviour is the one that is
already supported by IXFR. For large zones, on large anycast networks,
the volume of changes on the wire is important. The current aproach is
impractical.

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Wed, 28 Mar 2018 19:05:10 -0300

> the volume of changes on the wire is important. The current aproach is

Perhaps this text is more specific and address the incremental re-salt
scenario and even improve it after the new chain in already in place
at the time of the removal of the old one.

When an NSEC3PARAM is deleted or replaced, the MIXFR client MUST also
remove all existing NSEC3 records on the zone that form the chain
related to the deleted or replaced salt.

Fred

---

From: Mark Andrews <[email-masked]>
Date: Thu, 29 Mar 2018 10:36:12 +1100

> On 29 Mar 2018, at 9:05 am, Frederico A C Neves <[email-masked]> wrote:
> 

Firstly we should just say “DO NOT CHANGE NSEC3PARAM” as it is POINTLESS!!!!

Secondly you lose the ability to determine is the MIXFR is still in sync if you do that.

Currently named requires that all delete operations in IXFR MUST find the record in the
zone and that all add operations MUST NOT find a existing record.  If either condition
fails then named falls back to a full AXFR of the zone as we know the zone contents are
no longer in sync.

That property needs to be preserved by this implementation.

You also need to be able to extract a MIXFR stream from a IXFR stream (as that is what
gets recorded to disk).  I don’t believe that will be possible from a arbitrary IXFR
stream.  Adding constraints like “the master server MUST delete all NSEC3 records when it
deletes the NSEC3PARAM would make it work but then you have to deal with time to record
the delta etc.

Removing all RRSIGs works because that work is REQUIRED to be performed when a RRset
is changed and that has issues with offline DNSKEY management.

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

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 29 Mar 2018 15:00:18 -0300

> I shall add a GitHub issue for this. Thanks for bringing it up!

This is documented at issue #8 with an updated proposed text after
discussion down this thread.

https://github.com/matje/mixfr/issues/8

Fred

---

From: Frederico A C Neves <[email-masked]>
Date: Thu, 29 Mar 2018 15:17:25 -0300

> That property needs to be preserved by this implementation.

AFAIK there is nothing on the current logic that a compliant server
implementation would not preserve this property for a compliant client
that expects it.

> stream.  

You are right if what you have is only the stream of IXFRs. But a
compliant server implementation at the time it updates the zone -
being looking for differences of a zonefile, processing Dynamic
Updates or reading an adequate jornal of updates - it will accordingly
produce the IXFR and the MIXFR to be recorded on disk.

Starting with the current zone representation and a stream of backward
IXFRs allow you do first get to the past zone representation, I mean
applying the IXFRs backward, and then start to produce the respective
MIXFRs. Awkward, very unlikely implementation for a compliant MIXFR
server, but possible.

Fred