different TTLs for multiple TXT records

Verne Britton vbritton at staff.wvnet.edu
Sat Sep 26 21:33:50 UTC 2020

Thank you to Mark Andrews and Matus Uhlar for your quick responses ...

I see now how my thought process is fundamentally flawed  :-)

Sorry for the silly question !!

Verne Britton, Lead Systems Programmer   voice:   (304) 293-5192 x230
Systems Support Group                    (in WV, call 1-800-253-1558)
West Virginia Network for                FAX:     (304) 293-5540
      Educational Telecomputing           vbritton at staff.wvnet.edu
837 Chestnut Ridge Road                  http://www.wvnet.edu
Morgantown, WV  26505


On 9/26/2020 1:56 PM, Matus UHLAR - fantomas via lists.isc.org wrote:
> On 26.09.20 09:58, Verne Britton wrote:
>> I see that RFC2181, written I think 20+ years ago, says in part
>>> 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.
>> [...]
>> but in the last few years, perhaps even a decade, TXT record usage has
>> expanded to be used for many different and unique purposes, such as domain
>> ownership verification and SPF data.
> unfortunately, TXT is overloaded with multiple uses. SPF record was
> deprecated ...
>> What is the proper avenue to request an enhancement so each TXT record can have its own unique TTL value?
> not possible. IF you ask for a TXT, you must get all TXTs, the same for A, NS, MX
> and all other records of the same type.
> if you don't get something, it means it's not there. This is not just
> documented standard - doing it differently would make DNS unreliable.

More information about the bind-users mailing list