> On Nov 14, 2016, at 5:01 PM, Ondřej Surý <ondrej.s...@nic.cz> wrote: > > > ----- 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. > I was designing it today I would have a different RR type in parent and child, and the parent type should be able to hold glue record contents.
> 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? That is what the NS set that the resolver should use, the one in parent is just a hint. All good resolvers should use the Parent as hint as to find the child one, once the resolver has the child one toss the one from the parent. I know this is one extra query which is almost free as it can be done in parallel with the query for real data. Olafur
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
