In
<6(_dot_)0(_dot_)0(_dot_)22(_dot_)0(_dot_)20040308120809(_dot_)02d0dba0(_at_)unix01(_dot_)voicenet(_dot_)com>
"Arnold K." <aksup(_at_)voicenet(_dot_)com> writes:
At 11:59 AM 3/8/04, Greg Connor wrote:
On Mon, Mar 08, 2004 at 09:48:26AM -0500, Marc Alaia wrote:
Example:
alaia.net has two MX records, but let's say I make a mistake and have
different TTL's
alaia.net MX 10 mx.spfproxy.com ; TTL=14400
alaia.net MX 20 gw.alaia.net ; TTL=86400
The example deals with an MX record.
i.e.
domain TTL IN MX is the record.
The preference and server are instances within the record.
No, there are two MX records and one RR set resulting from one DNS
query.
RFC2181 has this to say on the subject of RR sets having records with
differing TTLs:
5.2. TTLs of RRs in an RRSet
Resource Records also have a time to live (TTL). It is possible for
the RRs in an RRSet to have different TTLs. No uses for this have
been found that cannot be better accomplished in other ways. This
can, however, cause partial replies (not marked "truncated") from a
caching server, where the TTLs for some but not all the RRs in the
RRSet have expired.
Consequently the use of differing TTLs in an RRSet is hereby
deprecated, the TTLs of all RRs in an RRSet must be the same.
Should a client receive a response containing RRs from an RRSet with
differing TTLs, it should treat this as an error. If the RRSet
concerned is from a non-authoritative source for this data, the
client should simply ignore the RRSet, and if the values were
required, seek to acquire them from an authoritative source. Clients
that are configured to send all queries to one, or more, particular
servers should treat those servers as authoritative for this purpose.
Should an authoritative source send such a malformed RRSet, the
client should treat the RRs for all purposes as if all TTLs in the
RRSet had been set to the value of the lowest TTL in the RRSet. In
no case may a server send an RRSet with TTLs not all equal.
-wayne