One Domain; Multiple IPs.

[Marc.Thach at radianz.com]

Brad:
> The idea behind giving different clients different answers based
> on where they are located in the network topology relative to the
> servers providing the answers is predicated on the servers having
> .....

The assumption is that Internet clients either host their own caching DNS
servers, or use those of their ISP, neither of which is too proposterous.
Where this breaks down is where the client workstation is attached to a
large internal network with several exits to the Internet, but with DNS
resolution more or less centralised (forwarders anyone?).  It may not work
perfectly, but perhaps some load-balancing is better than none even at the
cost of increased DNS traffic due to lower TTLs.

Brad:
> All of this becomes a non-problem if you hand out the same answer
> to everyone, and use routing protocols to automatically find the
> closest server farm that can handle the actual data request (as
> .....

Are you implying anycast addressing between the server farms?  If so, then
persistent connections to those servers will be vulnerable to routing
changes outside the control of the client or the server.

Brad:
> Regardless of what you may consider "conservative assumptions",
> the truth is that most Microsoft clients do some incredibly stupid
> .....

Again that's true (neither Netscape nor IE versions I've tested correctly
observe TTL) but again some balancing maybe better than none.

Brad:
> If you honestly believe in the "be liberal in what you accept and
> conservative in what you generate" theory, then you fundamentally
> *CANNOT* support load-balancing nameservers.  It's that simple.

On the other hand, maybe a requestor should liberally accept that some of
the DNS responses it may get are out of protocol spec, but that they
perform a useful function.

Mark:
> Try asking about things other than A records.  Some of the
> load balancers fail to do the rest of the protocol.
>
> Given that you usually delegate a single node to these boxes
> they should be able to answer NS and SOA queries for the name,
> return NODATA responses to queries for types that don't exist.
> If a subdomain does not exist it should return NXDOMAIN.
>
> I'm not sure if DD has these problems, but some of these boxes
> definitely do.

DD will return SOA and I think it does NS (I'll check tomorrow), I can't
say whether it returns NODATA for other types (I'll check that too).  Being
pragmatic, is this important?  DD is used for a very specific purpose, that
is to allow the operator of the DD to advertise A records to redirect
traffic to his/her published (named) servers appropriately.  For his/her
published and advertised purposes other record types should not be
requested.  Therefore no normal user will care, only those who dig and doc
at any available opportunity :-)
It is certainly true that DD should be delegated individual hosts as zones,
and as far as I have read the doco, Cisco do not adequately make this
point.  It as also true that DD does not accept TCP requests, and I worry
about whether the technique could be used in a future updated form to
provide DNSSEC signed answers (even given the CPU power to compute the
signatures on-the-fly, I would be unhappy to have the private key of the
zone stored on a device which could be reached on the Internet).

Rgds
Marc TXK
________________________________________________________________________
The views expressed are personal and do not necessarily reflect those of
the organisation providing the mail address from which this message was
sent