> Andrew Sullivan <mailto:a...@anvilwalrusden.com> > Friday, March 06, 2015 4:47 PM > > I seem to recall having this discussed at length more than once in > DNSEXT, and the conclusion was always that the additional complication > wasn't worth the effort.
i remember that position being advanced, but i do not think it was ever a consensus, other than leading into consensus-by-exhaustion, where the consensus was not "this is a bad idea" but rather "the status quo will have to serve, since we can't agree on changing it." > If a cache had an A but not AAAA or > conversely (a situation likely to happen), then there'd be no win > because you'd have to ask again anyway. Moreover, you couldn't even > tell whether you didn't get the thing you wanted because it wasn't in > cache or because it didn't exist, so you'd end up asking more often > than you wanted. perhaps there's been a misunderstanding. this is never imperative, always opportunistic. what additional data does is increase the likelihood of related data of being found in caches, whether that cache is inside the stub or inside the RDNS. > And because application developers would need to > handle all these cases anyway, the workflow would be more complicated. > (Simplification of the workflow seemed to be the main driver in the > past. Maybe latency would now trump that, but I actually am not > convinced this would lower latency as opposed to popping off queries > in parallel anyway.) i'm alarmed that you're not convinced. is your position falsifiable -- can you describe any conditions under which you might become convinced? (i'm willing to try, but not if there's no hope, not even a theoretical if-pigs-had-wings situation, under which you could find merit in this approach.) > > So it didn't seem to be worth it, at least the last time. I'm not > able to put my hands on those discussions at the moment, which makes > me think it probably happened on namedroppers@ and not on dnsext@. alas, we don't write RFC's about roads not taken, so, many negative conclusions remain undocumented even after well rounded debates that followed good rules and visited all corner cases. what's supposed to happen under my "just include the other kind of address as additional data" proposal is that existing clients are more likely to find the other kind of address in a nearby cache, and opportunistic clients can add nearby caches to take advantage of this increase in likelihood. there's no new signaling, no change to any specification, no requirement to change any code except on servers, who can send more additional data in certain cases, if they want the statistical benefit of receiving fewer followup queries. very few changes to the internet architecture are interest-aligned for all parties, entirely opportunistic, and entirely uncontroversial. perhaps our friends in the CDN world could make this change to some high volume authority servers and let us know if it decreased their overall DNS query rate. -- Paul Vixie
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
