On 17.7.2013 13:02, James Hogarth wrote:
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.
I understand. Anyway, you can always set TTL in LDAP to the minimum value from all values in the original name/zone. Yes, the performance will be worse, but hopefully not so significantly.

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.
Hmm... This reminds me another possibility ...

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.
See http://tools.ietf.org/html/rfc2181#section-5.2

E.g. content of file example.db is:
154 ipa-ca  555 IN  A
155 ipa-ca  324 IN  A

bind-9.9.3-3.P1.fc19.x86_64 complains about this problem:
example.db:155: TTL set to prior TTL (555)

The another way could be something like this:
dn: rrtype=a, idnsname=bar, idnsName=example.com
dnsTTL: 555

This structure clearly solves uniqueness && RRset TTL constrains at the same time. I can imagine solution like this on the implementation side, but still - is it worth? :-)

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

This way you don't have to change the format of existing attributes nor
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...
I realized that this change heavily affects planed changes. I plan to heavily refactor bind-dyndb-ldap internals, but the whole proposal depends on 1:1 mapping between objects in LDAP and *names* in DNS database. I will think about this problem, but this is going to be really complicated.

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...
I agree. https://fedorahosted.org/bind-dyndb-ldap/ticket/70 would be good starter :-)

Thank you for your time and passion!

Petr^2 Spacek

Freeipa-users mailing list

Reply via email to