Re: [dnsext] Re: a definition of consistency

[Colm MacCárthaigh <[e-mail]>]

2010/1/29 Jim Reid <[e-mail]>:>
> 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.

If this were the case; then all DNS record changes would have to be
scheduled in advance and authoritative TTLs would decrement in
anticipation of that time. But this is evidently not the case.

>The window where authoritative servers may be out of sync is small these days and getting
> smaller.

Even the root-zone and TLD TTLs are typically two days. But this
raises an interesting question; are DNS tricks ok if the TTL is always
0?

> 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.

My point is that the internet, clients, and all of us have to tolerate
such inconsistency - it's simply a fact of life, even if DNS tricks
did not exist. Holding up strong-consistency as a must-have property
of the DNS is simply at-odds with reality. We don't have it now, and
the internet still works :)

>> 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.

I saw your complaints about language choice and redirection, but I'm
not sure how this is related to DNS tricks. It seems more like a
consequence of generally poor operations and user-interface design
than related to directional naming. The engineering aim here is to
direct clients to the "best"/"closest"/"whatever" node - the
capabilities of that node are an orthogonal concern.

Interestingly, as the I-D specifies that where the option is set on
incoming queries it should be forwarded, it actually gives users
/more/ power over the problem you cite. A browser/OS could be
configured to specify any IP address it liked, it get the desired
behavior. To me it seems to do more to address the problem than to
cause it anew.

As for operational issues and debugging, yes this a problem - though I
think a marginal one. Practices have evolved for this; many auth DNS
providers provide records that reflect back the resolver IP, for
example, to aid debugging. (e.g. whoami.akamai.net,
whoami.ultradns.net).

>> 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.

There are problem statements, and some data. More data would be great.
But it still seems like an odd approach. The fact remains that
regardless of the draft, the technique (including ad-hoc client-ip
forwarding arrangements) are already in-use and are not going away.
The question is really "is having an interoperable standard for this
better than the de-facto behaviour of inter-provider arrangements and
exceptions". It is not being proposed in a vacuum as if it this will
be new never-seen-before behaviour. I think that makes our job easier.

-- 
Colm