Joe,
Thanks for sharing your concerns.
On 04-04-18 05:31, Joe Abley wrote:
On Apr 3, 2018, at 21:32, Frederico A C Neves <fne...@registro.br>
wrote:
On Tue, Apr 03, 2018 at 02:37:12PM +0200, Matthijs Mekking
wrote: Hi Frederico,
On 03/29/2018 08:45 PM, Frederico A C Neves wrote: I was
looking at our server to evaluate the MIXFR implementation and
it seams to me that the current text covering dnssec aware
client logic don't take in account that a posterior record at
the addition section, by an MIXFR DNSSEC aware server, will
implicitly replace the RRSIG RRset.
I am unclear what case you are covering.
Any situation that you have an updated RRset. It is implicit that
you'll have to update the signature, so I was arguing that this is
afterward covered by 3.6 Replace a RRset. My "simplified" logic
take this in account to don't impose this extra logic at the client
for updated RRsets, only for removed RRsets, explicit or when a
removal of RR causes it.
I have not been reading this thread in depth and so I have not
commented up until now. But I sense that there is a proposed shift of
responsibility for coherency in the contents of a zone, specifically
with resapect to DNSSEC. Quite possibly I am wrong, in which case I
will enjoy being told as much.
I am happy to entertain you by telling that there is no shift in
responsibility for coherency in the contents of a zone.
We are merely trying to come up with a more sophisticated syntax such
that the primary has to use less bytes to achieve zone consistency.
If I am a zone administrator, responsible for the self-consistent
contents of my zone, and I make a mistake, the behaviour today (with
zones distributed by AXFR, IXFR, rsync, ftp, avian carrier) is that a
DNS zone is a DNS zone and the RRSets contained within are simply
that, no appreciation, understanding or accommodation of DNSSEC
required.
I see your argument. On the other hand, if you make a mistake with
DNSSEC you are in trouble anyway.
The line of thinking inherent in the lowest quoted paragraph above
suggests that distribution of sets of RRSets (together forming a
zone) must with this new transfer mechanism be completed with
semantic appreciation for the relationship between non-RRSIG-type
RRSets and the corresponding RRSIG-type RRSets that accompany them in
a signed zone. This worries me.
The protocol requirements for DNSSEC as described in RFC 4035 are
non-trivial to implement already (cf. the treatment of RRSets in a
response with their accompanying RRSIG RRSets as an atomic unit in
the cache, to be expired together regardless of differences in TTL)
and I don't think we want to extend them without good reason.
Note that this does not affect resolvers and caches: zone transfers are
between authoritative name servers only.
I am determined to back the specification with an implementation,
especially after the camel is our new favorite animal, so hopefully that
will take away your concerns regarding implementation complexity.
If we expect MIXFR (or whatever it is eventually called) to behave
differently in this respect to AXFR, IXFR or any number of
out-of-band transfer mechanisms, we should have a good reason for it.
I don't know that I see one, yet.
It is zone transfer size. It can be quite large with DNSSEC (zone
re-sign, NSEC3 resalt). To quote someone: Reducing the amount of data,
is the only way to keep up with our current and future workloads.
Best regards,
Matthijs
Joe _______________________________________________ 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
