What DNS Is Not

Mon Nov 9 23:24:52 UTC 2009

On Nov 9, 2009, at 3:00 PM, Paul Vixie wrote:

> i loved the henry ford analogy -- but i think henry ford would have  
> said that
> the automatic transmission was a huge step forward since he wanted  
> everybody
> to have a car.  i can't think of anything that's happened in the  
> automobile
> market that henry ford wouldn't've wished he'd thought of.
>
> i knew that the "incoherent DNS" market would rise up on its hind  
> legs and
> say all kinds of things in its defense against the ACM Queue  
> article, and i'm
> not going to engage with every such speaker.

Paul: I completely agree with you that putting wildcards into the  
roots, GTLDs, CCTLDs, etc. is a Bad Idea and should be squashed.   
Users have little (no?) choice on their TLDs.  Stopping those is a  
Good Thing, IMHO.

However, I own a domain (or couple hundred :).  I have a wildcard on  
my domain.  I point it where I want.  I feel not the slightest twinge  
of guilt at this.  Do you think this is a Bad Thing, or should this be  
allowed?

Also, why are you upset at OpenDNS.  People _intentionally_ select to  
use OpenDNS, which is clear in its terms of service, and even allows  
users to turn off the bits that annoy you.  Exactly what is the issue?

And lastly, DNS is not "truth".  DNS is the Domain Name System, it is  
what people configure it to be.  You yourself have argued things like  
responding with "192.0.2.1"  for DNSBLs that are being shut down.   
That is clearly NOT "truth".

-- 
TTFN,
patrick

P.S. Yes, I am intentionally ignoring the CDN side of things.  Find me  
in private, preferably with a shot of single-malt, if you want my  
opinion.

> there three more-specific replies below.
>
> Dave Temkin <davet1 at gmail.com> writes:
>
>> Alex Balashov wrote:
>>>
>>> For example, perhaps in the case of CDNs geographic optimisation  
>>> should
>>> be in the province of routing (e.g. anycast) and not DNS?
>>
>> In most cases it already is.  He completely fails to address the  
>> concept
>> of Anycast DNS and assumes people are using statically mapped  
>> resolvers.
>
> "anycast DNS" appears to mean different things to different people.   
> i didn't
> mention it because to me anycast dns is a bgp level construct  
> whereby the
> same (coherent) answer is available from many servers having the  
> same IP
> address but not actually being the same server.  see for example how  
> several
> root name servers are distributed.  <http://www.root-servers.org/>.   
> if you
> are using "anycast DNS" to mean carefully crafted (noncoherent)  
> responses
> from a similarly distributed/advertised set of servers, then i did  
> address
> your topic in the ACM Queue article.
>
> David Andersen <dga at cs.cmu.edu> writes:
>
>> This myth ... was debunked years ago:
>>
>> "DNS Performance and the Effectiveness of Caching"
>> Jaeyeon Jung, Emil Sit, Hari Balakrishnan, and Robert Morris
>> http://pdos.csail.mit.edu/papers/dns:ton.pdf
>
> my reason for completely dismissing that paper at the time it came  
> out was
> that it tried to predict the system level impact of DNS caching  
> while only
> looking at the resolver side and only from one client population  
> having a
> small and uniform user base.  show me a "trace driven simulation" of  
> the
> whole system, that takes into account significant authority servers  
> (which
> would include root, tld, and amazon and google) as well as significant
> caching servers (which would not include MIT's or any university's but
> which would definitely include comcast's and cox's and att's), and  
> i'll
> read it with high hopes.  note that ISC SIE (see http://sie.isc.org/  
> may
> yet grow into a possible data source for this kind of study, which  
> is one
> of the reasons we created it.)
>
> Simon Lyall <simon at darkmere.gen.nz> writes:
>
>> I heard some anti-spam people use DNS to distribute big databases of
>> information. I bet Vixie would have nasty things to say to the guy  
>> who
>> first thought that up.
>
> someone made this same comment in the slashdot thread.  my response  
> there
> and here is: the MAPS RBL has always delivered coherent responses  
> where the
> answer is an expressed fact, not kerned in any way based on the  
> identity of
> the querier.  perhaps my language in the ACM Queue article was  
> imprecise
> ("delivering facts rather than policy") and i should have stuck with  
> the
> longer formulation ("incoherent responses crafted based on the  
> identity of
> the querier rather than on the authoritative data").
> -- 
> Paul Vixie
> KI6YSY
>