Eszett and IDNAv2 vs IDNA2008

[Eric Brunner-Williams]

Andrew,

Thanks, but temporal inconsistency with identical participating nodes, 
and atemporal, as well as temporal inconsistency across non-identical 
participating nodes, seems a given if the intra-query time is proximal 
to the rate at which state change is propagated in a distributed system. 
I mean, if two queries (local caching ignored) have non-identical 
results, does it matter what type the labels queried for are?

I'm trying hard not to think of zonefile default mod ttls of 15 seconds 
(and less) and not succeeding.

Being rather dull I only just realized that the 2003-2008 delta is an 
area where front-running, by recursive resolver operator, or 
authoritative resolver operator, and a registrar, is possible. A PDP is 
something to start before all this goes live with the usual suspects, 
assuming the delta-t is something we can live with (least awful bucket).

Eric

Andrew Sullivan wrote:
> On Thu, Mar 12, 2009 at 10:15:39AM -0400, Eric Brunner-Williams wrote:
>   
>>> ...  the various try-2008-fail-to-2003 strategies people have talked
>>> about, which includes the two-lookup approach.  (That two-lookup
>>> approach is indeed broken in principle, but it might be good enough
>>> for a transition strategy.)
>>>   
>>>       
>
>   
>> I appreciate the desire to get the right answer the first time, but 
>> "broken in principle" needs technical justification, specific to the 
>> problem domain.
>>     
>
> Someone -- I think it was Marcos?  anyway, apologies for not citing
> correctly -- made the argument recently, but it bears repeating.  You
> cannot ask the DNS two questions in two different transactions and
> make the assumption that the state hasn't changed in the meantime.
> Therefore, if you ask q1, get back an answer you didn't want, and then
> ask q2 thinking that it can provide the answer instead of q1, you have
> made a fundamental error: the answer you get to q2 is possibly from a
> different state, and there is no way in principle for you to tell.
> This is a direct consequence of the loose coherence of the DNS.
>
> But, as I said, it might be good enough much of the time.  So, if we
> have, "If lookup IDNA2008 form results in an empty answer, then lookup
> the 'mapped' form from IDNA2003," we have a technically incorrect
> idea: the reason you get the answer from the IDNA-mapped query _could_
> be because the IDNA2008 (and a "bundled" form the registry provided
> for backward compatibility) record was added to the DNS in between
> your first and second queries.  Or maybe you ended up at a different
> DNS server the second time.  Or something else.  It might nevertheless
> be the least awful answer, if we assume that this is something we only
> have to live with for (say) two generations of browser.  I know, I
> know, some people are still using Netscape version 3, so there's an
> infinitely long tail.  But the tip is so pointy that the hold-out
> IDNA2003 users will end up in the DNS noise.  That's a trade-off worth
> talking about.
>
> A
>
>