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. 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.
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.
>The predictability of resolver behavior.
Yes, there's work needed to do, both NS sets (at a cut) are needed in tandem.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
