On 15.7.2013 16:35, Jan Cholasta wrote:
On 15.7.2013 11:17, James Hogarth wrote:
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) :

Please contact me on IRC (pspacek in #freeipa @ FreeNode) or via e-mail. We need to coordinate, because bind-dyndb-ldap is undergoing heavy refactoring right now.

Also, remember that modification in bind-dyndb-ldap will require modification on FreeIPA side (CLI/WebUI/API).

https://fedorahosted.org/bind-dyndb-ldap/ticket/70

https://fedorahosted.org/freeipa/ticket/2956

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
like:
dn: idnsName=bar, idnsName=example.com <http://example.com>, cn=dns,
dc=example, dc=com
idnsName: bar
ARecord: 192.168.1.100 7200
We can't do this, because definition of *Record attributes is outside of our control. Definitions of these attributes come from
http://drift.uninett.no/nett/ip-nett/dnsattributes.schema
and it is used by BIND DLZ LDAP driver.

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.
Could you post some real world examples, please? I would love to see some real world records with real TTLs and statistics.
How many names with different TTLs have you?
How many names and records have you in total?

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=192.168.1.100,idnsName=bar, idnsName=example.com
<http://example.com>, cn=dns, dc=example, dc=com
aRecordName: bar
aRecordData: 192.168.1.100
aRecordTTL: 7200
This could work, but it has significant overhead. At least indexes in LDAP server could grow rapidly.

The other problem is that you will lost the uniqueness-check on LDAP side. DNS doesn't allow one record with same name and data to appear multiple times and current attribute-based design prevents this 'for free'.

The other problem is that records in single RRset can't have multiple TTL values. I.e. (under single name) all A records have to have the same TTL, all AAAA records has to have same TTL etc.

Of course, all of these can be handled in bind-dyndb-ldap, but doing so on database side is much more elegant.

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?

Cheers,

James


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
aRecord: 1.2.3.4

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

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

This one is my favourite, but again: It will require refactoring on FreeIPA side. Also, I'm not sure if this could work with BIND DLZ LDAP...

To summarize it: Is it worth to spend time on this? I would love to see some real numbers.

Thank you for your time and passion!

--
Petr^2 Spacek

_______________________________________________
Freeipa-users mailing list
Freeipa-users@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-users

Reply via email to