subject:"\[DNSOP\] A new version of mixfr"

Re: [DNSOP] A new version of mixfr

2018-03-29 Thread Frederico A C Neves

On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote:
> 
> > On 29 Mar 2018, at 9:05 am, Frederico A C Neves  wrote:
> > 
> > On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> >> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> >>> 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.
> >> 
> >> 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.
> > 
> > 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.
> > 
> > 3.1 Implicit DNSSEC deletions
> > 
> > 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
> 
> 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.

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.

> 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.  

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-29 Thread Frederico A C Neves

On Wed, Mar 28, 2018 at 05:43:15PM +0200, Matthijs Mekking wrote:

> > 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.
> 
> 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!

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

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

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Mark Andrews

> On 29 Mar 2018, at 9:05 am, Frederico A C Neves  wrote:
> 
> On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
>> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
>>> 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.
>> 
>> 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.
> 
> 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.
> 
> 3.1 Implicit DNSSEC deletions
> 
> 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

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: ma...@isc.org

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Frederico A C Neves

On Wed, Mar 28, 2018 at 06:12:09PM -0300, Frederico A C Neves wrote:
> On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> > 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.
> 
> 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.

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.

3.1 Implicit DNSSEC deletions

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Frederico A C Neves

On Thu, Mar 29, 2018 at 07:28:22AM +1100, Mark Andrews wrote:
> 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.

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

> 
> -- 
> Mark Andrews
> 
> > On 29 Mar 2018, at 02:06, Frederico A C Neves  wrote:
> > 
> > Hi Matthijs,
> > 
> >> On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> >> 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.
> >> 
> > 
> > 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?
> > 
> >> Who would like to contribute, review, and all that great fun?
> >> 
> >> Github is here: https://github.com/matje/mixfr
> >> 
> >> Best regards,
> >>   Matthijs
> > 
> > Fred
> > 
> > ___
> > DNSOP mailing list
> > DNSOP@ietf.org
> > https://www.ietf.org/mailman/listinfo/dnsop
> 

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Mark Andrews

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  wrote:
> 
> Hi Matthijs,
> 
>> On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
>> 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.
>> 
> 
> 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?
> 
>> Who would like to contribute, review, and all that great fun?
>> 
>> Github is here: https://github.com/matje/mixfr
>> 
>> Best regards,
>>   Matthijs
> 
> Fred
> 
> ___
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Paul Vixie




Tony Finch wrote:

...

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


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

--
P Vixie

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Ray Bellis

On 28/03/2018 15:43, Pieter Lexis wrote:

> 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.

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


___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Matthijs Mekking


Frederico,

On 03/28/2018 05:06 PM, Frederico A C Neves wrote:

Hi Matthijs,

On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:

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.



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


Thank you.



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.


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!



One clarification question,

At 3.6, last paragraph, what is the practical case that a updated
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


  

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

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

Best regards,
Matthijs


Fred



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Matthijs Mekking

Richard,

On 03/28/2018 04:44 PM, Richard Gibson wrote:

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

Thanks:)

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.

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

On 03/28/2018 09:31 AM, Matthijs Mekking wrote:

All,

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

https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dmekking-2Dmixfr-2D02=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=9E3JS209vJp6dQBpJJBXlr32ZbLYLOLNNAiovQ1iAnY=

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://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_matje_mixfr=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=9jcbJIa5DBxRHlL2wVDEwCWBJXvbZffQobFtQvjEMH0=

Best regards,
Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop=DwICAg=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c=ycKKp45O3W2Hpn8RR_KFXUQy24YUrGwBK2HlmyMhCnI=n1GMn0ZrYJoVbOVyFWt2A2n2n6d5T3xoCwjdK8xsbiw=

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Matthijs Mekking


Pieter,

On 03/28/2018 04:43 PM, Pieter Lexis wrote:

Hi Matthijs,

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


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 draft speaks of an OPCode in the IANA section and of a meta
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.




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.


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



Best regards,

Pieter



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Matthijs Mekking


Tony,

On 03/28/2018 04:08 PM, Tony Finch wrote:

Matthijs Mekking  wrote:


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


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


Thanks.



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 am happy take this. Thanks for contributing text!



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


I guess we can start a vote ;)



Is UDP support supposed to be required? (I believe BIND requires TCP for
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



Tony.



___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Frederico A C Neves

Hi Matthijs,

On Wed, Mar 28, 2018 at 03:31:57PM +0200, Matthijs Mekking wrote:
> 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.
>

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?

> Who would like to contribute, review, and all that great fun?
> 
> Github is here: https://github.com/matje/mixfr
> 
> Best regards,
>Matthijs

Fred

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Richard Gibson

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

On 03/28/2018 09:31 AM, Matthijs Mekking wrote:

All,

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

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

Changes after the three year sleep:

- 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?

Best regards,
Matthijs

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Frederico A C Neves

On Wed, Mar 28, 2018 at 04:43:53PM +0200, Pieter Lexis wrote:
> Hi Matthijs,
> 
> On Wed, 28 Mar 2018 15:31:57 +0200
> Matthijs Mekking  wrote:
> 
> > 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 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.

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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Pieter Lexis

Hi Matthijs,

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

> 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 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

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

2018-03-28 Thread Tony Finch

Matthijs Mekking  wrote:
>
> 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

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    http://dotat.at/  -  I xn--zr8h punycode
South German Bight: Cyclonic 5 to 7. Moderate or rough. Occasional rain.
Moderate or poor.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

Re: [DNSOP] A new version of mixfr

17 matches

Site Navigation

Mail list logo

Footer information