Re: [DNSOP] More work for DNSOP :-)

[Paul Vixie <[e-mail]>]

> Andrew Sullivan <mailto:[e-mail]>
> 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