Mailing List Archive: NANOG: users

What DNS Is Not

1 2 3 4

View All

Index | Next | Previous | View Threaded

abalashov at evaristesys

Nov 8, 2009, 2:39 PM

Post #1 of 92 (2021 views)
Permalink

What DNS Is Not

Thought-provoking article by Paul Vixie:

http://queue.acm.org/detail.cfm?id=1647302

--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671

davet1 at gmail

Nov 8, 2009, 3:58 PM

Post #2 of 92 (1963 views)
Permalink

Re: What DNS Is Not [In reply to]

Alex Balashov wrote:
> Thought-provoking article by Paul Vixie:
>
> http://queue.acm.org/detail.cfm?id=1647302
>
I doubt Henry Ford would appreciate the Mustang.

-Dave

abalashov at evaristesys

Nov 8, 2009, 4:01 PM

Post #3 of 92 (1966 views)
Permalink

Re: What DNS Is Not [In reply to]

Dave Temkin wrote:

> Alex Balashov wrote:
>> Thought-provoking article by Paul Vixie:
>>
>> http://queue.acm.org/detail.cfm?id=1647302
>>
> I doubt Henry Ford would appreciate the Mustang.

I don't think that is a very accurate analogy, and in any case, the
argument is not that we should immediately cease at once all the
things we do with DNS today.

DNS is one of the more centralised systems of the Internet at large;
it works because of its reliance on intermediate caching and
end-to-end accuracy.

It seems to me the claim is more that DNS was not designed to handle
them and that if this is what we want to do, perhaps something should
supplant DNS, or, alternate methods should be used.

For example, perhaps in the case of CDNs geographic optimisation
should be in the province of routing (e.g. anycast) and not DNS?

-- Alex

--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671

davet1 at gmail

Nov 8, 2009, 4:06 PM

Post #4 of 92 (1966 views)
Permalink

Re: What DNS Is Not [In reply to]

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?
>
> -- Alex
>
In most cases it already is. He completely fails to address the concept
of Anycast DNS and assumes people are using statically mapped resolvers.

He also assumes that DNS is some great expense and that by not allowing
tons of caching we're taking money out of peoples' wallets. This is
just not true with the exception of very few companies whose job it is
to answer DNS requests.

-Dave

dga at cs

Nov 8, 2009, 4:17 PM

Post #5 of 92 (1967 views)
Permalink

Re: What DNS Is Not [In reply to]

On Nov 8, 2009, at 7:06 PM, Dave Temkin wrote:

> 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?
>>
>> -- Alex
>>
> In most cases it already is. He completely fails to address the
> concept of Anycast DNS and assumes people are using statically
> mapped resolvers.
>
> He also assumes that DNS is some great expense and that by not
> allowing tons of caching we're taking money out of peoples'
> wallets. This is just not true with the exception of very few
> companies whose job it is to answer DNS requests.

This myth (that Paul mentions, not to suggest Dave T's comment is a
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

Basically: Caching of NS records is important, particularly higher up
in the hierarchy. Caching of A records is drastically less important
- and, not mentioned in the article, the cost imposed by low-TTL A
records is shared mostly by the client and the DNS provider, not some
third party infrastructure.

From the paper:

"Our trace-driven simulations yield two findings. First, reducing the
TTLs of A records to as low as a few hundred seconds has little
adverse effect on hit rates. Second, little benefit is obtained from
sharing a forwarding DNS cache among more than 10 or 20 clients. This
is consistent with the heavy-tailed nature of access to names. This
suggests that the performance of DNS is not as dependent on aggressive
caching as is commonly believed, and that the widespread use of
dynamic low-TTL A-record bindings should not degrade DNS performance.
The reasons for the scalability of DNS are due less to the
hierarchical design of its name space or good A-record caching than
seems to be widely believed; rather, the cacheability of NS records
efficiently partition the name space and avoid overloading any single
name server in the Internet."

-Dave

bmanning at vacation

Nov 8, 2009, 4:17 PM

Post #6 of 92 (1966 views)
Permalink

Re: What DNS Is Not [In reply to]

DNS is NOT always defined by Paul... :)

--bill

On Sun, Nov 08, 2009 at 05:39:47PM -0500, Alex Balashov wrote:
> Thought-provoking article by Paul Vixie:
>
> http://queue.acm.org/detail.cfm?id=1647302
>
> --
> Alex Balashov - Principal
> Evariste Systems
> Web : http://www.evaristesys.com/
> Tel : (+1) (678) 954-0670
> Direct : (+1) (678) 954-0671

scott at doc

Nov 8, 2009, 4:30 PM

Post #7 of 92 (1957 views)
Permalink

Re: What DNS Is Not [In reply to]

On Sun, Nov 8, 2009 at 4:06 PM, Dave Temkin <davet1 [at] gmail> wrote:

> He also assumes that DNS is some great expense and that by not allowing
> tons of caching we're taking money out of peoples' wallets. This is just
> not true with the exception of very few companies whose job it is to answer
> DNS requests.
>

And of course in many cases these are the same people who are benefiting
significantly by the geo-aware (and sometimes, network-aware) CDN's that
this type of DNS service provides.

Scott.

bmanning at vacation

Nov 8, 2009, 4:30 PM

Post #8 of 92 (1956 views)
Permalink

Re: What DNS Is Not [In reply to]

On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote:
>
> "Our trace-driven simulations yield two findings. First, reducing the

-----------
> -Dave
>

a simulation is driven from a mathmatical model, not real world
constructions.

--bill

dga at cs

Nov 8, 2009, 4:42 PM

Post #9 of 92 (1959 views)
Permalink

Re: What DNS Is Not [In reply to]

On Nov 8, 2009, at 7:30 PM, bmanning [at] vacation wrote:

> On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote:
>>
>> "Our trace-driven simulations yield two findings. First, reducing the
>
> -----------
>> -Dave
>>
>
> a simulation is driven from a mathmatical model, not real world
> constructions.

Hi, Bill -

The paper is worth reading.

"The paper also presents the results of trace-driven simulations that
explore the effect of varying TTLs and varying degrees of cache
sharing on DNS cache hit rates. "

emphasis on *trace-driven*. Now, you can argue whether or not their
traces are representative (whatever that means) -- they used client
DNS and TCP connection traces from MIT and KAIST, so it definitely has
a .edu bias, iff there is a bias in DNS traffic for universities vs.
"the real world", but to the extent that their traces represent what
other groups of users might see, their evaluation seems accurate.

-Dave

pauldotwall at gmail

Nov 8, 2009, 4:42 PM

Post #10 of 92 (1959 views)
Permalink

Re: What DNS Is Not [In reply to]

On Sun, Nov 8, 2009 at 6:06 PM, Dave Temkin <davet1 [at] gmail> wrote:
> In most cases it already is. �He completely fails to address the concept of
> Anycast DNS and assumes people are using statically mapped resolvers.
>
> He also assumes that DNS is some great expense and that by not allowing tons
> of caching we're taking money out of peoples' wallets. �This is just not
> true with the exception of very few companies whose job it is to answer DNS
> requests.

I don't know why Paul is so concerned, just think how many F root mirrors
it helps him sell to unsuspecting saps. The Henry Ford analogy was amazingly
apt, imagine 'ol Henry coming back and claiming that automatic transmissions
were a misuse of the automobile.

Drive Slow ('cause someone left the door open at the old folks home)

bmanning at vacation

Nov 8, 2009, 4:46 PM

Post #11 of 92 (1956 views)
Permalink

Re: What DNS Is Not [In reply to]

On Sun, Nov 08, 2009 at 07:42:18PM -0500, David Andersen wrote:
>
> On Nov 8, 2009, at 7:30 PM, bmanning [at] vacation wrote:
>
> >On Sun, Nov 08, 2009 at 07:17:16PM -0500, David Andersen wrote:
> >>
> >>"Our trace-driven simulations yield two findings. First, reducing the
> >
> > -----------
> >> -Dave
> >>
> >
> > a simulation is driven from a mathmatical model, not real world
> > constructions.
>
> Hi, Bill -
>
> The paper is worth reading.
>
> "The paper also presents the results of trace-driven simulations that
> explore the effect of varying TTLs and varying degrees of cache
> sharing on DNS cache hit rates. "
>
> emphasis on *trace-driven*. Now, you can argue whether or not their
> traces are representative (whatever that means) -- they used client
> DNS and TCP connection traces from MIT and KAIST, so it definitely has
> a .edu bias, iff there is a bias in DNS traffic for universities vs.
> "the real world", but to the extent that their traces represent what
> other groups of users might see, their evaluation seems accurate.
>
> -Dave

I'm not debating the traces - I wonder about the simulation
model. (and yes, I've read the paper)

--bill

dga at cs

Nov 8, 2009, 4:59 PM

Post #12 of 92 (1955 views)
Permalink

Re: What DNS Is Not [In reply to]

On Nov 8, 2009, at 7:46 PM, bmanning [at] vacation wrote:
>>
>> "The paper also presents the results of trace-driven simulations that
>> explore the effect of varying TTLs and varying degrees of cache
>> sharing on DNS cache hit rates. "
>
> I'm not debating the traces - I wonder about the simulation
> model. (and yes, I've read the paper)

I'm happy to chat about this offline if it bores people, but I'm
curious what you're wondering about.

The method was pretty simple:

- Record the TCP SYN/FIN packets and the DNS packets
- For every SYN, figure out what name the computer had resolved to
open a connection to this IP address
- From the TTL of the DNS, figure out whether finding that binding
would have required a DNS lookup

There are some obvious potential sources of error - most particularly,
name-based HTTP virtual hosting may break some of the assumptions in
this - but I'd guess that with a somewhat smaller trace, not too much
error is introduced by clients going to different name-based vhosts on
the same IP address within a small amount of time. There are
certainly some, but I'd be surprised if it was more than a %age of the
accesses. Are there other methodological concerns?

I'd also point out for this discussion two studies that looked at how
accurately one can geo-map clients based on the IP address of their
chosen DNS resolver. There are obviously potential pitfalls here
(e.g., someone who travels and still uses their "home" resolver). In
2002:

Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and
Efficient Evaluation of the Proximity between Web Clients and their
Local DNS Servers. In Proc. USENIX Annual Technical Conference,
Berkeley, CA, June 2002.

Bottom line: It's ok but not great.

"We con- clude that DNS is good for very coarse-grained server
selection, since 64% of the associations belong to the same Autonomous
System. DNS is less useful for finer- grained server selection, since
only 16% of the client and local DNS associations are in the same
network-aware cluster [13] (based on BGP routing information from a
wide set of routers)"

We did a wardriving study in Pittsburgh recently where we found that,
of the access points we could connect to, 99% of them used their ISP's
provided DNS server. Pretty good if your target is residential users:

http://www.cs.cmu.edu/~dga/papers/han-imc2008-abstract.html

(it's a small part of the paper in section 4.3).

-Dave

jgreco at ns

Nov 8, 2009, 5:27 PM

Post #13 of 92 (1957 views)
Permalink

Re: What DNS Is Not [In reply to]

> 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?
> >
> > -- Alex
>
> In most cases it already is. He completely fails to address the concept
> of Anycast DNS and assumes people are using statically mapped resolvers.

I'm not sure that's a correct assumption.

> He also assumes that DNS is some great expense and that by not allowing
> tons of caching we're taking money out of peoples' wallets. This is
> just not true with the exception of very few companies whose job it is
> to answer DNS requests.

It's kind of the same sort of thing that led to what is commonly called
the "Kaminsky" vulnerability; the fact that it was predicted years before
continues to be ignored.

The reason that's relevant is because the resource consumption argument
in question is the same one; in the last ten years, bandwidth, CPU, and
memory resources have all moved by greater than an order of magnitude
in a favorable direction for DNS operators.

Paul's argument is best considered on an idealistic basis. For example,
with the CDN stuff, people who muck with DNS should absolutely be aware
of what Paul is saying; that does not mean that there aren't equally
valid reasons to treat DNS in a different manner. The technical
problems related to CDN-style use of DNS lookups are pretty well known
and understood. The resource consumption issues are trivialized with
the advent of high speed Internet, cheaper resources, etc. It doesn't
make it idealistically *right*, but it means it is really much less
damaging than ten or fifteen years ago.

To classify NXDOMAIN mapping and CDN "stupid DNS tricks" in the same
class of "DNS lies" is probably damaging to any debate. The former is
evil for breaking a lot of things, the latter ia only handing out varied
answers for questions one should have the answer to. It's the difference
between being authorized to answer and just handing out answers that Paul
objects to, and being unauthorized to answer and handing out answers that
many people object to.

My opinion is that it'd be better for Paul to avoid technical arguments
that were weak even in the '90's to support his position. As it stands,
people read outdated technical bits and say "well, we know better,"
which trivializes the remaining technical and idealistic bits.

That's damaging, because Paul's dead on about a lot of things. DNS is
essentially the wrong level at which to be doing "my web browser could
not find X" mapping; it'd be better to build this into web browsers
instead. But that's a discussion and a half. :-)

... JG
--
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.

simon at darkmere

Nov 8, 2009, 5:35 PM

Post #14 of 92 (1957 views)
Permalink

Re: What DNS Is Not [In reply to]

On Sun, 8 Nov 2009, 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?

Well my first answer to that would be that GSLB scales down a lot further
than anycast.

And my first question would be what would the load on the global routing
system if a couple of thousand (say) extra sites started using anycast for
their content?

Each would have their own AS (perhaps reused from elsewher in the
company) and a small network or two. Routes would be added and withdrawn
regularly and various "stupid BGP tricks" attempted with communitees and
prefixes.

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.

--
Simon Lyall | Very Busy | Web: http://www.darkmere.gen.nz/
"To stay awake all night adds a day to your life" - Stilgar | eMT.

jabley at hopcount

Nov 8, 2009, 5:58 PM

Post #15 of 92 (1957 views)
Permalink

Re: What DNS Is Not [In reply to]

On 2009-11-09, at 10:35, Simon Lyall wrote:

> And my first question would be what would the load on the global
> routing system if a couple of thousand (say) extra sites started
> using anycast for their content?

Are you asking what the impact would be of a couple of thousand extra
routes in the current full table of ~250,000? That sounds like noise
to me (the number, not your question :-)

Joe

jmamodio at gmail

Nov 8, 2009, 6:02 PM

Post #16 of 92 (1957 views)
Permalink

Re: What DNS Is Not [In reply to]

> DNS is NOT always defined by Paul... :)

I agree Bill, but Paul is right on the money about how the DNS is being
misused and abused to create more smoke and mirrors in the domain
name biz.

I really find annoying that some ISPs (several large ones among them) are
still tampering with the DNS responses just to put few more coins on
their coffers from click through advertising.

What I'm really afraid is that all the buzz and $$ from the domain biz
will create strong resistance to any efforts to develop a real directory
service or better better scheme for resource naming and location.

BTW simulations != real world.

Cheers
Jorge

drc at virtualized

Nov 8, 2009, 9:35 PM

Post #17 of 92 (1931 views)
Permalink

Re: What DNS Is Not [In reply to]

On Nov 8, 2009, at 4:59 PM, David Andersen wrote:
> Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and Efficient Evaluation of the Proximity between Web Clients and their Local DNS Servers. In Proc. USENIX Annual Technical Conference, Berkeley, CA, June 2002.

Given that paper is 7 years old and the Internet has changed a bit since 2002 (and the DNS looks to change somewhat drastically in the relatively near future) it might be dangerous to rely too much on their results. This might be an interesting area of additional research...

Regards,
-drc

fergdawgster at gmail

Nov 8, 2009, 9:40 PM

Post #18 of 92 (1931 views)
Permalink

Re: What DNS Is Not [In reply to]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, Nov 8, 2009 at 9:35 PM, David Conrad <drc [at] virtualized> wrote:

> On Nov 8, 2009, at 4:59 PM, David Andersen wrote:
>> Z. M. Mao, C. D. Cranor, F. Douglis, and M. Rabinovich. A Precise and
>> Efficient Evaluation of the Proximity between Web Clients and their
>> Local DNS Servers. In Proc. USENIX Annual Technical Conference,
>> Berkeley, CA, June 2002.
>
> Given that paper is 7 years old and the Internet has changed a bit since
> 2002 (and the DNS looks to change somewhat drastically in the relatively
> near future) it might be dangerous to rely too much on their results.
> This might be an interesting area of additional research...
>

Well, the marketing folks have sure taken advantage of it. It would be nice
to see the technology folks... not just lie there and take it.

- - ferg

-----BEGIN PGP SIGNATURE-----
Version: PGP Desktop 9.5.3 (Build 5003)

wj8DBQFK96suq1pz9mNUZTMRAni8AKDyw1NMu2FuXFVQ8vDjLSOONy8T2ACg+tNJ
2sJl1I22u18nJw0PPg1juL4=
=QI6K
-----END PGP SIGNATURE-----

--
"Fergie", a.k.a. Paul Ferguson
Engineering Architecture for the Internet
fergdawgster(at)gmail.com
ferg's tech blog: http://fergdawg.blogspot.com/

jbates at brightok

Nov 9, 2009, 7:28 AM

Post #19 of 92 (1919 views)
Permalink

Re: What DNS Is Not [In reply to]

Alex Balashov wrote:
> Thought-provoking article by Paul Vixie:
>
> http://queue.acm.org/detail.cfm?id=1647302
>

Bah, many of the CDN's I've dealt with don't seed geographical responses
based on DNS, but rather use many out of band methods for determining
what response they will hand out. The primary reason for short cutting
cache is to limit failures in case the system a requestor is going to
goes down.

And different CDN's behave differently, depending on how they deliver
content, support provider interconnects, etc. I'd hardly call many of
them DNS lies, as they do resolve you to the appropriate IP, and if that
IP disappears, try and quickly get you to another appropriate IP.

The rest of the article was informative,though.

Jack

vixie at isc

Nov 9, 2009, 12:00 PM

Post #20 of 92 (1891 views)
Permalink

Re: What DNS Is Not [In reply to]

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.

there three more-specific replies below.

Dave Temkin <davet1 [at] gmail> 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> 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> 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

nonobvious at gmail

Nov 9, 2009, 3:04 PM

Post #21 of 92 (1881 views)
Permalink

Re: What DNS Is Not [In reply to]

Hi, Paul - I share your dislike of DNS services that break the DNS
model for profit in ways that break applications.
For instance, returning the IP address of your company's port-80 web
server instead of NXDOMAIN
not only breaks non-port-80-http applications, it also breaks the
behaviour that browsers such as
IE and Firefox expect, which is that if a domain isn't found, they'll
do something that the user chooses,
such as sending another query to the user's favorite search engine.

There is one special case for which I don't mind having DNS servers
lie about query results,
which is the phishing/malware protection service. In that case, the
DNS response is redirecting you to
the IP address of a server that'll tell you
"You really didn't want to visit PayPa11.com - it's a fake" or
"You really didn't want to visit
dgfdsgsdfgdfgsdfgsfd.example.ru - it's malware".
It's technically broken, but you really _didn't_ want to go there anyway.
It's a bit friendlier to administrators and security people if the
response page gives you the
IP address that the query would have otherwise returned, though
obviously you don't want it to be
a clickable hyperlink.

However, I disagree with your objections to CDN, and load balancers in
general - returning the
address of the server that example.com thinks will give you the best
performance is reasonable.
(I'll leave the question of whether DNS queries are any good at
determining that to the vendors.)
Maintaining a cachable ns.example.com record in the process is
friendly to everybody;
maintaining cachable A records is less important.
If reality is changing rapidly, then the directory that points to the
reality can reasonably change also.

On Mon, Nov 9, 2009 at 12:00 PM, Paul Vixie <vixie [at] isc> 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.

Well, there's the built-in GPS navigation system that tells you to go
drive off the dock into the water,
because it wasn't smart enough to know that the route the map database
showed in dotted lines was a ferryboat...

--
----
Thanks; Bill

Note that this isn't my regular email account - It's still experimental so far.
And Google probably logs and indexes everything you send it.

abalashov at evaristesys

Nov 9, 2009, 3:06 PM

Post #22 of 92 (1881 views)
Permalink

Re: What DNS Is Not [In reply to]

When I write applications that make DNS queries, I expect the request
to turn NXDOMAIN if the host does not exist - HTTP as well as
non-HTTP, but especially non-HTTP.

Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or
why this could possibly be controversial.

--
Alex Balashov - Principal
Evariste Systems
Web : http://www.evaristesys.com/
Tel : (+1) (678) 954-0670
Direct : (+1) (678) 954-0671

davidu at everydns

Nov 9, 2009, 3:15 PM

Post #23 of 92 (1881 views)
Permalink

Re: What DNS Is Not [In reply to]

On 11/9/09 6:06 PM, Alex Balashov wrote:

> Anything else is COMPLETELY UNACCEPTABLE. I don't understand how or why
> this could possibly be controversial.

Because some people want the ability and choice to block DNS responses
they don't like; just as they have the ability and choice to reject
email they don't want to accept.

When the conficker worms phones home to one of the 50,000 potential
domains names it computes each day, there are a lot of IT folks out
there that wish their local resolver would simply reject those DNS
requests so that infected machines in their network fail to phone home.

To use your language, I don't understand how or why this could possibly
be controversial. -- Apparently it is.

-David

patrick at ianai

Nov 9, 2009, 3:24 PM

Post #24 of 92 (1881 views)
Permalink

Re: What DNS Is Not [In reply to]

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

jbates at brightok

Nov 9, 2009, 3:26 PM

Post #25 of 92 (1882 views)
Permalink

Re: What DNS Is Not [In reply to]

Alex Balashov wrote:
> When I write applications that make DNS queries, I expect the request to
> turn NXDOMAIN if the host does not exist - HTTP as well as non-HTTP, but
> especially non-HTTP.
>

Actually, the one I hate is when they return NXDOMAIN for any RR type
other than A, breaking DNS. Most common is AAAA to return NXDOMAIN,
which immediately has the effect of breaking the ability to fallback to
A (why query for another RR, when the domain doesn't exist?). Several
high end load balancers have the ability to do this according to the
content providers I have addressed the matter with.

As a side note, any IPv6 capable stack which has determined there is
IPv6 connectivity (through 6to4, native, teredo, etc) cannot access
these sites. For an example (an ongoing issue) see www.txu.com. Responds
to A, gives NXDOMAIN to AAAA.

I will not shame the high profile websites that have fixed their
loadbalancers/DNS servers, but everyone on this list knows and has
probably used them.

Jack

1 2 3 4

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads