Subject: [dnsext] Re: George Barwood's Birthday Observation...

From: Florian Weimer <[email-masked]>
Date: Tue, 14 Oct 2008 14:38:25 +0200

* George Barwood:

> Some of the observed behavior is probably just a way of working around
> broken resolvers / client programs that do not properly select a
> random host when more than one is available.

RFC 3484 prescribes an algorithm which does not select hosts randomly.

> DNS is not a good vehicle for implementing large scale load balancing,
> as it imposes unreasonable loads on clients and caches. Instead
> routing techniques seem more appropriate to me, such as Anycast.

I disagree.  Host load-balancing should not be implemented at the
routing layer.  (Exceptions exist for infrastructure services.)  The
reason is that a domain name is much cheaper than a global routing
table slot.

On the other hand, I don't think DNS needs to accommodate services
which require fast-changing DNS data at the cost of other design
goals.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/namedroppers/>

---

From: Dean Anderson <[email-masked]>
Date: Tue, 14 Oct 2008 12:30:25 -0400 (EDT)

[ Note: Post was moderated. ] 

> RFC 3484 prescribes an algorithm which does not select hosts randomly.

And there is no requirement in any draft that a resolver select a random
host when more than one is available. 

> > DNS is not a good vehicle for implementing large scale load
> > balancing, as it imposes unreasonable loads on clients and caches.
> > Instead routing techniques seem more appropriate to me, such as
> > Anycast.

Anycast is not suitable for stateful services, such as those over TCP,
and some UDP services are also stateful. (RFC1546 states that
explicitly)

> which require fast-changing DNS data at the cost of other design

Exactly right. I would add that load balancing is an application layer
service. The load balancer generally has have enough application
specific information to be able to keep the application state correct
amount the balanced hosts.

		--Dean

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000

---

From: "George Barwood" <[email-masked]>
Date: Tue, 14 Oct 2008 20:52:47 +0100

----- Original Message ----- 
From: "Florian Weimer" <[email-masked]>
To: "George Barwood" <[email-masked]>
Cc: "Brian Dickson" <[email-masked]>; "Nicholas Weaver" 
<[email-masked]>; "Paul Vixie" <[email-masked]>; "Namedroppers" 
<[email-masked]>
Sent: Tuesday, October 14, 2008 1:38 PM
Subject: Re: George Barwood's Birthday Observation...

Florian > On the other hand, I don't think DNS needs to accommodate services
Florian > which require fast-changing DNS data at the cost of other design 
goals.

On the other hand practical recursive resolvers have to accomodate these 
"awkward" authorities, or they will not be useable.

Today I have been experimenting as follows: if full convergence does not 
occur after say 10 queries, apply a weaker check that may discard unchecked 
RRsets where the owner name does not match the question.

With Akamai ( which is the only really tricky case I have found ), this 
typically results in 7 out of 9 of the glue A records being cached ( as well 
as the NS records). The other two, if required, are fetched later with a 
specific query.

However there is a problem : in some sense Akamai needs "whole response" 
integrity ( which is stronger than RRset integrity ), if the resolver is to 
be sure of having 9 distinct IP addresses for the name servers. I don't 
think it is a practical problem in the Akamai case, because the probability 
of getting just 1 server from nine is small, but one can make a simple 
hypothetical example (see below) where the resolver can end up with only 1 
IP address. This is also a problem for Nicolas Weaver's "cache policy".

Example:

Query: www.example.com
Response:
example.com NS ns1.example.com
example.com NS ns2.example.com
ns1.example.com A 1.1.1.1 ( not cached, per cache policy )
ns2.example.com A 1.1.1.2 ( not cached, per cache policy )

Query: ns1.example.com
Response: ns1.example.com A 1.1.1.1

Query: ns2.example.com
Response: ns2.example.com A 1.1.1.1 ( but will return 1.1.1.2  sometimes )

Since "whole response" integrity can be expensive with Akamai ( I observed a 
case where 97 queries were needed for full convergence ),  I'm now going to 
investigate the another approach : "resolving glue". For the example given, 
when normal convergence is slow, we cache instead

example.com NSA 1.1.1.1
example.com NSA 1.1.1.2

Another fallback is verifying just the data values, rather than the full RR, 
on the plausible assumption that an attacker needs to inject values under 
his control to do any serious damage.