Re: [DNSOP] A new version of mixfr
On Thu, Mar 29, 2018 at 10:36:12AM +1100, Mark Andrews wrote: > > > On 29 Mar 2018, at 9:05 am, Frederico A C Neveswrote: > > > > 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
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
> On 29 Mar 2018, at 9:05 am, Frederico A C Neveswrote: > > 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
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
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 Neveswrote: > > > > 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
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 Neveswrote: > > 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
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
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
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
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
Pieter, On 03/28/2018 04:43 PM, Pieter Lexis wrote: Hi Matthijs, On Wed, 28 Mar 2018 15:31:57 +0200 Matthijs Mekkingwrote: 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
Tony, On 03/28/2018 04:08 PM, Tony Finch wrote: Matthijs Mekkingwrote: 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
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
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: 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
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 Mekkingwrote: > > > 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
Hi Matthijs, On Wed, 28 Mar 2018 15:31:57 +0200 Matthijs Mekkingwrote: > 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
Matthijs Mekkingwrote: > > 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