> 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).
Sure - I'm usually in #freeipa as JHogarth when I'm about ...

Yes indeed .. I've been doing quite a bit of work in dns.js the past week
or so to expose TTL in general anyway...

> 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<http://drift.uninett.no/nett/ip-nett/dnsattributes.schema>
> and it is used by BIND DLZ LDAP driver.
Ah that's a shame ... it would have been quite a smooth way to handle it
but compatibility is of course critical.

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?
As one example TXT record and SSHFP to describe a system (and it's
fingerprint) having a long TTL since they are unlikely to change and an A
record with a shorter TTL for a dynamic DNS scenario with a non-sticky

There was a specific issue I was bumping into with this in the past (but
not a major one) and became an itch to scratch... especially since BIND
zone files would support such a setup but the bind-dyndb-ldap won't ... the
disparity was something that niggled at me.

In all honesty this is an edge case and since I was planning to dive in
anyway I thought I might as well take a look given I have some free time at
the moment... The default TTL in bind-dyndb-ldap and the exposing/modifying
TTL in the Web UI is not dependent on such behaviour in any way.

This could work, but it has significant overhead. At least indexes in LDAP
> server could grow rapidly.
That is a legitimate concern for sure...

> 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'.
But you would still be limited to this since there could only be one
arecord, txtrecord, etc for a given idnsname with that structure.

> 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.
Hmm I'll have to check BIND again but I thought that when doing round robin
A records (as an example) differing TTL was possible ... but admittedly
I've not verified this and this would be an inconsistency if so.

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

>> dn: idnsName=bar+dNSTTL=3600,**idnsName=example.com
>> idnsName: bar
>> dNSTTL: 3600
>> aRecord:
>> 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...
I do like the compound RDN idea but it sounds like it would potentially be
a lot of upheaval...

> To summarize it: Is it worth to spend time on this? I would love to see
> some real numbers.
Good question! It's an itch I have a couple of weeks to scratch at the
moment so there's no 'cost' on my time right now associated with it
(although I recognise it increases complexity for the maintainers and QA of
course as an after-effect)... but the complexity is fairly high and could
potentially touch a lot of areas...

The more basic bit of work I was doing (just the exposure and modification
of TTL in the UI) would have a far improved cost-benefit ratio and only
touches dns.js and dns.py (the latter I propose exposing TTL by default
rather than needing --all for it in the API ... it makes the dns.js changes

Adding the ability to configure default TTL in bind-dyndb-ldap also doesn't
need any of the per RRtype stuff so avoids complexity there...

> Thank you for your time and passion!
Well it's about time the linux world had something like this (rather than
the old mish-mash of kerberos, openldap, etc and associated scripts to sort
of glue users together that was the previous situation) so I champion it
wherever I can!

Freeipa-users mailing list

Reply via email to