Return two locations or low TTL [was: DNS caches that support partitioning ?]

Mark Andrews marka at isc.org
Mon Aug 20 23:54:37 UTC 2012


In message <0D919D57-BDA0-4FDA-873D-3DC0CD5745C0 at ianai.net>, "Patrick W. Gilmore" writes:
> On Aug 20, 2012, at 06:49 , "Dobbins, Roland" <rdobbins at arbor.net> =
> wrote:
> > On Aug 20, 2012, at 5:24 PM, Patrick W. Gilmore wrote:
> >=20
> >> But I do not think returning multiple A records for multiple =
> datacenters is as useful as lowering the TTL.
> >=20
> > Some folks do this via various GSLB mechanisms which selectively =
> respond with different records based on the assumed relative topological =
> distance between the  querying resolver and various server/service =
> instantiations in different locations.
> 
> "Some folks" =3D=3D "more than half of all traffic on broadband modems" =
> these days.
> 
> However, I think you missed a post or two in this thread.
> 
> The original point was you need a low TTL to respond with a single A =
> record or multiple A records which all point to the same datacenter in =
> case that node / DC goes down.  Mark replied saying you can respond with =
> multiple A records pointing at multiple DCs, thereby allowing a much =
> longer TTL.
> 
> My question above is asking Mark how you guarantee the user/application =
> selects the A record closest to them and only use the other A record =
> when the closer one is unavailable.

You can't but a GSLB also can't know if the path from the client
to the DC selected by the GSLB will work.  There is a high probability
that it will but no certainty.  By returning addresses to multiple
DC's you increase the probability that a client will be able to
connect in the presence of network errors not visible to the GSLB
control algorithms.

If you want to add weights etc. then you need to use something like
SRV to pass this information to the client.  The GSLB can then
adjust these.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org




More information about the NANOG mailing list