Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
Ben Bridges
bbridges at springnet.net
Thu Mar 24 16:18:26 UTC 2016
TXT records are multiple-purpose. They can be used for SPF records, Office 365 "MS" records, DMARC records, or whatever arbitrary uses someone dreams up, all for the same domain name. Microsoft wants a short TTL for their Office 365 records, but I would prefer to generally use a longer TTL for most records (including other TXT records) in order to reduce the query load on our servers. It would be nice to be able to set a short TTL for the Office 365 record but a longer TTL for other TXT records for the same domain name.
Thanks,
Ben
From: bind-users-bounces at lists.isc.org [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Darcy Kevin (FCA)
Sent: Thursday, March 24, 2016 9:55 AM
To: bind-users at lists.isc.org
Subject: RE: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
This is deliberately forbidden by standard. See RFC 2181, Section 5.2 ("TTLs of RRs in an RRSet")
Why would you want to do this?
- Kevin
From: bind-users-bounces at lists.isc.org<mailto:bind-users-bounces at lists.isc.org> [mailto:bind-users-bounces at lists.isc.org] On Behalf Of Ben Bridges
Sent: Thursday, March 24, 2016 10:48 AM
To: bind-users at lists.isc.org<mailto:bind-users at lists.isc.org>
Subject: Configuring different TTLs in multiple RRs for the same domain name, TYPE, and CLASS
Greetings.
Is it possible in BIND to configure multiple resource records for the same domain name, TYPE, and CLASS with different TTL values? For example:
Test-txt.example.com 300 IN TXT "Test 300"
Test-txt.example.com 400 IN TXT "Test 400"
Test-txt.example.com 500 IN TXT "Test 500"
Test-txt.example.com 600 IN TXT "Test 600"
Test-txt.example.com 700 IN TXT "Test 700"
I tried it, and BIND set the TTL for all five records to 300 (or more specifically, the TTL of the first one of the RRs in the file). I looked for a BIND directive in the manual to change this behavior but could find no obvious candidate.
Thanks,
Ben Bridges
Springfield, MO
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/bind-users/attachments/20160324/0a4a97d8/attachment-0001.html>
More information about the bind-users
mailing list