----- Original Message ----- > From: "Edward Lewis" <edward.le...@icann.org> > To: "Ondřej Surý" <ondrej.s...@nic.cz> > Cc: "dnsop" <dnsop@ietf.org> > Sent: Monday, 14 November, 2016 08:31:51 > Subject: Re: [DNSOP] Why 2 caches? draft-fujiwara-dnsop-resolver-update-00
> I'm a little confused to the feedback, so I'm asking for some clarification. > > On 11/14/16, 11:27, "DNSOP on behalf of Ondřej Surý" <dnsop-boun...@ietf.org > on > behalf of ondrej.s...@nic.cz> wrote: > >>I think this is a technical detail best left to the software vendors and it >>should be removed from the draft. > > My question/suggestion is in reaction to this passage in the draft "proposes > updated resolver algorithm that separate authoritative data cache that is > answered to stub resolvers and delegation cache" and some other responses > suggesting that having two caches might be troublesome. > > Are you saying that how this is implemented is to be left up to the software > developer? If so, I agree with that. Yes :) > But I am not sure you if are commenting on my "why it can't it be done this > way" > comment. Either way, my comment is not to overly specify how. > >>As a side note, having a (platform-sized) pointer for each RR in the RR-cache >>is >>a huge bloat... > > I hadn't claimed by idea was good. ;) It was the first alternative that came > to > mind. > >>If we were to design RFC1034/1035 again I would say that NS records are more >>close to DS. > > Hmmm. I'm not sure I understand what you mean by "more close." I was going > to > say that for DNSSEC, we found it tricky to find two data sets with the same > owner/class/type having two sources and so had to dance around the split > responsibilities for the NS set. But then we invented NSEC which is features > two set with the same owner/class/type but two authorities (as opposed to > sources) also, except that this time (NSEC and then NSEC3 and any proposed > updates) the RDATA was distinctly different. Yep, I understand why it was left alone, and it's ok that way. > If I were to redo what was in the base definitions, I would have used > different > type codes for the set above the cut and the set below the cut - but not for > NSEC/NSEC3/etc. I don't have a neat generalization, but, in summary having > the > NS set above and below, and having glue not marked as such in the type code > (GLUEA or GLUEAAAA) is, I don't know, suboptimal in retrospect. Sure. >>The predictability of resolver behavior. > > Yes, there's work needed to do, both NS sets (at a cut) are needed in tandem. Are they? What is child-NS needed for? Ondrej -- Ondřej Surý -- Technical Fellow -------------------------------------------- CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC Milesovska 5, 130 00 Praha 3, Czech Republic mailto:ondrej.s...@nic.cz https://nic.cz/ -------------------------------------------- _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
