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
--------------------------------------------------------------------
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