matje / mixfr Goto Github PK

Mark Andrews:

Note there are some RR deletions / addition pairs that DO NOT change RRSIGs. e.g. case changes
in domain names that are subject to canonicalisation. There is no requirement to regenerate
RRSIGs for such changes though most implementations will do so.

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

Jinmei>
I see the motivation, and the proposed approach of MIXFR may make
sense. But, just like for any kind of optimization ideas, I would
wonder whether this could be a premature one. Do you have any
measurement of the effect of this idea?

On the draft text (also related to this higher level point):

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.

We still need to send new RRSIGs, and since the main concern is the
size of them (whether they are to be removed or added), I guess
sending a non-negligible number of RRSIGs could easily require TCP,
even if we can omit a half of them. So I'm not sure how often we can
avoid falling back to TCP (M)IXFR thanks to this in practice. Again,
some actual measurement or at least a quantitative analysis may help.

Pieter Lexis:

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.

Pieter Lexis:
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.

On 16-01-15 23:04, Bob Harold wrote:
> There seem to be a lot of "set CLASS to ANY" in the spec.  But I thought
> that a.b.c class IN was totally unrelated to a.b.c class CHAOS, and
> deleting or changing one should not affect the other.  Or am I

To clarify: A record with its CLASS set to ANY does *not* mean to
delete/change the record in all available classes. Note that an XFR is
encapsulated in SOA records that determine the zone name and class (see
Figure 2). Only changes in the zone matching that name and class will be
made.

Thanks for explaining. I think it would help to mention that somewhere
in the document.

Is the problem:

1. Transfer size of the IXFR to a remote location? If so, why isn't plain compression considered?
2. Nameserver need a richer language to express zone changes? Then this could be a solution.

Richard Gibson:
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.

Current client logic don't take in account that a posterior addition, by an MIXFR DNSSEC aware server, will implicitly replace the RRset with covering RRSIGs. Text and logic could be simplified only to Deletions of RR, when they conclude a removal of a RRset, or RRsets by itself.