[Yeti DNS Discuss] 答复: Notification and Call for comments for the incoming Yeti experiment (Changes in 5.1 and 5.21 )
ljsong at biigroup.cn
Fri Apr 20 04:10:48 UTC 2018
<Kato-san once mentioned the multi-provider-dnssec draft to me. And I cc the authors of this draft as well to keep them posted on the discussion, if helpful>
IMHO this draft is different with Yeti's Multi-DM model mainly in two aspects:
1) The multi-provider-dnssec draft intends to build a multiple signer model in lower level. Yeti does it in root level. The difference offer me another notable finding that Multiple KSK signers works in lower level because DS RR contained in father zone can contain more than one KSK (need confirm). Yeti has limit to introduce two KSK signers, because there is no upper DS record which accommodate two KSKs.
2) The daft claims a different problem to solve. The raised problem is that the current "sever only model" cannot support DNSSEC for smart DNS features which returns query-specific response, for load balance purpose for example. But I'm not fully convinced by the problem statement in this draft only because current zone transfer does not supports different optional answers for a query... I have a feeling that they are making a big change to solve a small problem which IMHO can be worked around by non-standardized approaches (need confirm).
Return to your questions.
1) Does PINZ precede the draft? Or any helpful adding from PINZ to multi-provider-dnssec draft?
PINZ is a optimized Multi-DM model (let's me just say it). The purpose of PINZ is to minimized the changes from the original zone (from IANA). In contrast the multi-provider-dnssec draft intend to offer DNS operators with capability of making and signing changes if necessary. Right now, I do not see any benefit if the draft borrowing PINZ idea to include the zone owners ZSK and signatures. It needs future discussion.
2) What's the relationship between Yeti's work and multi-provider-dnssec draft?
Yeti multiple-DM model and PINZ conceived long before multi-provider-dnssec draft. I do not have any exchange with the author (this mail is the first time : p ). I'm not sure whether they are inspired from Yeti's work. Given Yeti is not mentioned as related work in this draft, I prefer to treat these as co-incidental separate inventions.
> 发件人: Paul Vixie [mailto:paul at redbarn.org]
> 发送时间: 2018年4月18日 3:56
> 收件人: "Davey Song(宋林健)"
> 抄送: discuss at lists.yeti-dns.org
> 主题: Re: [Yeti DNS Discuss] Notification and Call for comments for the
> incoming Yeti experiment (Changes in 5.1 and 5.21 )
> davey, this work appears to have preceded the multi-provider draft
> can you tell me whether there was any influence exchanged, or should i treat
> these as co-incidental separate inventions?
> Davey Song(宋林健) wrote:
> > Hi folks,
> > I'm writing to send this notification and call for comments for a
> > incoming yeti experiment which may cause unforeseen impact to Yeti users.
> > The experiment called PINZ (Preserving IANA NSEC Chain and ZSK RRSIGs)
> > which is proposed last year. And the first introduction of PINZ is in
> > a Yeti blog
> > post:
> > http://yeti-dns.org/yeti/blog/2017/08/22/Preserving-IANA-NSEC-Chain-an
> > d-ZSK-
> > RRSIGs.html.
> > Yeti coordinators prepared it for quite a while in a prudent manner
> > because PINZ will change the Yeti root zone largely. The lab test was
> > done and it proved OK currently in lab environment, but unforeseen
> > problems may be beyond our control which may cause DNSSEC validation
> > fail for some validating resolvers. So we draft a experiment plan for
> > PINZ in Github repo
> > (https://github.com/BII-Lab/Yeti-Project/blob/master/doc/Experiment-PI
> > NZ.md) and send this notification in advance for Yeti resolver
> > operators.
> > Please do check the draft plan and be aware what will be changed
> > during PINZ experiment at two milestone the 1st May and 21st May.
> > Best regards,
> > Davey
> > _______________________________________________
> > discuss mailing list
> > discuss at lists.yeti-dns.org
> > http://lists.yeti-dns.org/mailman/listinfo/discuss
> P Vixie
More information about the discuss