[dnsext] Incoherency for the greater good, etc., was RE:...vandergaast...

[Edward Lewis <[e-mail]>]

At 11:09 -0800 2/1/10, Ted Hardie wrote:

>how does the
>DNS stack know that this application is one for which localization will
>be desirable, given that this is a decision made by the authoritative
>server?  Do you expect this to be opted-into for every query, or only
>for some?
...
>Coherence ain't just elegant, it's easier.

One of the aspects of this that is missing is that the authority 
server is in on the game and, yes, the incoherency does provide a 
benefit.  This is not the same as wild card redirection, which is 
where the notion "but the DNS doesn't know why you are asking" creeps 
in.  And yes, coherency is easier, but that isn't a weighted factor 
in this application.

Let's begin with the set up.  When I am operating an enterprise I can 
elect to name my networked services in such a way that I can deduce 
why a DNS query comes to me.  For example, I can use 
"www.store.example.", "smtp.store.example.", "imap.store.example.", 
"ftp.store.example." and even "ssh.store.example."  When I embed URLs 
in my web pages, I will use the right domain names and I when I send 
mail I'll put in the right domain names for Reply-To and what not.

By using explicit domain names in the above paragraph, you can 
probably deduce that this is not the same as the use of a wild card 
(from the what I've read it sounds like folks are still afraid of 
that).  With a wild card address record in a TLD, the administrator 
has lost the "knowledge" of the deeper labels.  Incoherent DNS is not 
the same as NXDOMAIN redirection, the challenges and motivations are 
very different.

DNS operators have a long track record of using incoherent DNS 
configurations.  Every employer I've been with since '96 has had one 
version of the zone for the office and another version for the 
public.  CDNs make use of the technique (I should write "are said to 
make use" as I have no hands on experience in that).  But even with 
all of this activity, it's never gotten further in the IETF than this 
draft: 
http://tools.ietf.org/html/draft-krishnaswamy-dnsop-dnssec-split-view-04.

The popular DNS implementation BIND has had support for incoherency 
for a long time, called "views."  (I can't recall when it came into 
being.)  That's a measure of how wide spread incoherency has gotten.

I agree that there are parts of the DNS system where coherency is 
essential.  The root zone and the TLDs (or other widely delegated 
zones) should be coherent because of the mixed operational population 
they cover.  It's hard to remotely debug a system that is in flux, so 
it's necessary to have stability there.  But this observation doesn't 
apply as you dive deeper into the DNS, down to places where there is 
more concentrated effort in maintaining the service.

It can be argued that incoherent DNS is just a special case of a 
coherent DNS system rapidly changing its contents.  Mathematically, 
it's the same.

Coherent operations are easier, no doubt.  But incoherent DNS servers 
can also be managed.  That "rapid change of coherent servers" is a 
lot of work, just like incoherent servers is a lot of work.  But this 
allows the authority to tailor responses to the clients they serve.

>You don't actually know that--you're providing a response based on the
>subrange, but depending on the liveness of your load balancing and the caching
>implementation you could get a wide variety of results.  If I previously
>provided a single response based on the IP address of the querying server
>and now provide one based on the subrange being served, I might choose to
>lower the TTL to 0 in order to make sure that each subrange query is served
>"fresh", rather than from the cache.  Otherwise, I have to trust that the
>cache is maintaining multiple entries on the subrange basis.  You want to
>set a bit for that too?

Load balancing as the differentiator instead of (or in addition to) 
source IP address is a challenge but is just as workable.  Yes, the 
TTLs are lower for this to work.  Generally, with such short TTLs, it 
doesn't matter much what a cache does.

Keep in mind that often times the service being used is much longer 
lived than the DNS lookup.  If it's a TCP connection that will be up 
for an hour, I'm just going to get the one that is best at 9:41 and 
keep it there, even if a 10:13 a different server comes along that 
would be a better fit.

>I recognize that there is value to
>the CDN approach, but the complications here (and the privacy implications)
>aren't trivial.  Doing this may be well past the 80/20 line for DNS-based
>localization.

The privacy implications are a red herring.  When you go to lookup 
www.store.example., someone is going to know you did that - at least 
so they can return the answer to you.

In many cases it is the operator of the recursive server you are 
using and not the authority server.    While any retailer would like 
to know the demographics of their customers - whether it's e-retail 
or Main Street retail - its a matter of what they can get.  If stub 
resolvers use servers @127.0.0.1 then the authority servers will get 
this.  If the stubs are using a "distant" (i.e., not @127.0.0.1) 
recursive server then the "issue" here is "how much of the 
information the recursive server collects are they willing to give up 
to the authority server?"  Recursive servers do not have the 
motivation to expose their stub resolvers, but there is motivation to 
get better responses to the questions they ask.

This statements address only the issues of the usefulness of 
incoherency, metrics like load balancing, and privacy.  I haven't 
made comments on the EDNS0 option request.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at [phone]

As with IPv6, the problem with the deployment of frictionless surfaces is
that they're not getting traction.