On Tue, 5 Jul 2005, Douglas Otis wrote:
See RFC2181 section 5.2.
,---
| 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.
'---
While this may address a publishing error, it could also address a set
handling error, which does not provide any solace. It seems a perm
error may unpleasantly uncover such simplified behavior, if it exists.
DNS protocol's implementation model is "be liberal in what you accept"
and this is a lot more so then you realize (until you write your own
resolver and test it). DNS resolvers are all liberal and deal with std
errors finding all ways possible to get the answer. If it were not for
that 25% of the dns queries would result in fail, because there is
quite a bit of inconsistency on when dns servers add and not nameserver
ips (glue) in response if they do it in additional or response section,
if they add SOA or not, etc, etc.
On the configuration side there are lots and lots and lots of places
which provide inconsistent and different responses depending on what
of the domain's nameserver is checked on (both different zone data and
different response if they run different dns server software). There
are often enough inconsistency in the core - for many TLD, the responses
are not the same from their main NS servers.
So trying to change to hard fail just because ttl happened to be
different on different RR in RRSet is very much against the liberal
core DNS implementation and beside that inconsistent TTL is not
as big of a deal as some other problems encountered in dns.
--
William Leibzon
Elan Networks
william(_at_)elan(_dot_)net