> 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 lease. 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: 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... > > 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 cleaner). 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! James
_______________________________________________ Freeipa-users mailing list Freeipa-users@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-users
