Multi-homing APNs in GPRS/UMTS

[phn at icke-reklam.ipsec.nu]

Paul Vixie <vixie at sa.vix.com> wrote:
> phn at icke-reklam.ipsec.nu writes:

>> > If APNs are mulithomed then some sort of redundancy or load balancin=
g
>> > can be implemented.  Should the TTL for the APN be set to 0?
>>=20
>> DNS TTL should never be zero. ( neither should TTL in a IP-header)

> In [RFC1034 3.6] we see the following text:

>         The meaning of the TTL field is a time limit on how long an RR =
can
>         be kept in a cache.  This limit does not apply to authoritative
>         data in zones; it is also timed out, but by the refreshing poli=
cies
>         for the zone.  The TTL is assigned by the administrator for the
>         zone where the data originates.  While short TTLs can be used t=
o
>         minimize caching, and a zero TTL prohibits caching, the realiti=
es
>         of Internet performance suggest that these times should be on t=
he
>         order of days for the typical host.  If a change can be
>         anticipated, the TTL can be reduced prior to the change to mini=
mize
>         inconsistency during the change, and then increased back to its
>         former value following the change.

> In [ibid 5.3.3]:

>         The ideal answer is one from a server authoritative for the que=
ry
>         which either gives the required data or a name error.  The data=
 is
>         passed back to the user and entered in the cache for future use=
 if
>         its TTL is greater than zero.

> In [RFC1035 3.2.1] we see:

>     TTL     a 32 bit signed integer that specifies the time interval
>             that the resource record may be cached before the source
>             of the information should again be consulted.  Zero
>             values are interpreted to mean that the RR can only be
>             used for the transaction in progress, and should not be
>             cached.  For example, SOA records are always distributed
>             with a zero TTL to prohibit caching.  Zero values can
>             also be used for extremely volatile data.

> In [ibid 7.1]:

>      Note that using the timestamp is superior to using a current
>      time, since it allows RRs with TTLs of zero to be entered in
>      the cache in the usual manner, but still used by the current
>      request, even after intervals of many seconds due to system
>      load, query retransmission timeouts, etc.

> I believe that a DNS TTL of zero is well specified, though ill-advised.

Agree, that's why i adviced not to use zero as TTL. There is also=20
a "grey zone" where ns are "forwarded", i think certain combinations
of nameservers does not behave correct when zero TTL is used.

To be safe and conservative, avoid zero.

Gettin back to the original question, make shure your app treats=20
multi-address RR correct, if the first address won't work, try the next
until the list is empty. A very smart app might even try them all=20
and decide some weighting which one to use ( simular to named's
choice of which NS to use if several is available).

> --=20
> Paul Vixie


--=20
Peter H=E5kanson        =20
        IPSec  Sverige      ( At Gothenburg Riverside )
           Sorry about my e-mail address, but i'm trying to keep spam out=
,
	   remove "icke-reklam" if you feel for mailing me. Thanx.