On 15.7.2013 11:17, James Hogarth wrote:
Hi guys,

I'm just picking up the nice to have ticket of configure the default TTL
as part of my general TTL refactor work seeing as the exposing and
modification of TTL in the UI is unlikely to be complete before 3.3
freeze (mostly working but a few bugs remaining) :



The approach I'm considering is to make the record capable of an
individual TTL by just appending the TTL to the record so it would look
dn: idnsName=bar, idnsName=example.com <http://example.com>, cn=dns,
dc=example, dc=com
idnsName: bar
ARecord: 7200

This is an approach that matches how things like MX and SRV are dealt
with (except those have numbers at the front) and would require much
simpler modifications.

Then there would be a precedence to the actual TTL used in this order:
1) If a TTL is in the record data use that
2) If a TTL is in the idnsName data (the current dnsTTL attribute) then
use that
3) If a TTL is in the zone data (as per the ticket name to be decided)
then use that
4) If a TTL is specified in the named.conf configuration for the
bind-dyndb-ldap plugin then use that.

Although potentially not as nice as making each data entry a first class
citizen as an object in LDAP such as for an example:
dn: aRecord=,idnsName=bar, idnsName=example.com
<http://example.com>, cn=dns, dc=example, dc=com
aRecordName: bar
aRecordTTL: 7200

It'd require far less upheaval in terms of migrations and testing...

What are your thoughts on this before I start digging into this part of
the code base?



There's a third option: group DNS records by both name and TTL, instead of just name, like this:

dn: idnsName=bar+dNSTTL=7200,idnsName=example.com
idnsName: bar
dNSTTL: 7200

dn: idnsName=bar+dNSTTL=3600,idnsName=example.com
idnsName: bar
dNSTTL: 3600

This way you don't have to change the format of existing attributes nor add new attributes.


Jan Cholasta

Freeipa-users mailing list

Reply via email to