Re: [dnsext] Re: a definition of consistency

[Jim Reid <[e-mail]>]

On 29 Jan 2010, at 10:23, Colm MacCárthaigh wrote:

> On Fri, Jan 29, 2010 at 9:56 AM, Jim Reid <[e-mail]> wrote:
>> On 29 Jan 2010, at 09:32, Colm MacCárthaigh wrote:
>>
>>> If consistency was the primary objective then all TTLs would be 0  
>>> and
>>> there would be synchronous atomic updates only. DNS is intentionally
>>> inconsistent by design.
>>
>> That depends on the definition of consistency. Sure, DNS is loosely
>> consistent because of cacheing and zone propagation latency.  
>> However there
>> is a higher level consistency that is unwritten (and probably needs  
>> to be
>> formally documented). This is the principle of uniformity. ie No  
>> matter
>> where you are or what software you use or which server(s) you  
>> query, the DNS
>> always returns the same answer for the same lookup.
>
> That paragraph is self-contradictory.

Not really Colm. The higher level concept of uniformity expressed  
above isn't actually undermined by the above examples of loose  
coherency. For instance, the TTL for some resource record is (or  
should be) a commitment by the zone owner that that RR won't change  
inside the TTL. The window where authoritative servers may be out of  
sync is small these days and getting smaller. It's more of a  
theoretical concern than one that people worry about. And in  
environments where this is considered a significant risk, folk use  
databases to get immediate replication.

Yes, if someone looks *really* hard they *might* come across examples  
of loose consistency. However those transient anomalies will return to  
the usual steady state and converge on a consistent name space: think  
regression to the mean. That's not the same as violating the principle  
of uniformity by handing out different data *by design* to different  
clients who make the same query.

> Taking the tricks into account, they've been use for over a decade
> now, also evidently without any real problem.

Well in another thread, I've given a couple of examples where stupid  
DNS tricks cause very real problems. These problems are of course  
externalities to the people doing those DNS tricks, so they might not  
care about those problems or acknowledge their existence.

> Again, the principal of strict uniformity does not appear to matter.

In your opinion. I think the people who are proposing these sorts of  
DNS changes have the responsibility to prove that the changes cause no  
harm and make the engineering trade-offs clear. [ie Is the cost of  
changing the world's DNS software worth the benefits of the new  
feature? Are there any second- or third- order effects?] So far there  
isn't even a problem statement or any hard data.