On 1.4.2015 07:51, Jorgen Lundman wrote: > >> Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that >> there is 1:1 mapping between DNS name<->LDAP DN. This makes implementation of >> dynamic updates much easier. > > Well, you weren't wrong there. :) I did try a few different solutions, > first letting ARecord/NSRecord trickle in after SOA setup is done. But that > did not fit well with some of the checks. (diff tests of SOA updates need > to be tuples etc, SOA is handled much more strictly), you can't "just" > re-register/update a zone as easily as records.. and so on. > > In the end, I went for the change where, before calling "update_zone()", I > query DLZ for the additional information needed for the SOA record. > ARecord/NSRecord etc, then tag those onto the "entry->attrs" list. This > fits better with bind-dyndb-ldap existing framework, and only makes it > worse for DLZ users. > > In addition to creating src/schema.h - to define the name of the common > ldap attributes based on WITH_DLZ_SCHEMA. > > Annoyingly, DLZ Schema reuses the generic "DNSData" for a lot of things, so > "one large search" just overwrote previous attributes - sigh. > > So, I was forced to do single individual ldapqueries for each > ARecord/NSRecord/... type, then call finally update_zone(). > > Some additional mapping for update_record() as well, to map things like > DNSIPAddr -> ARecord was needed. > > > > > 01-Apr-2015 12:09:13.601 ldap_entry_create dn is > 'DNSRecord=SOA,DNSHostName=@,DNSZoneName=example.com,ou=dns,dc=test,dc=jp' > 01-Apr-2015 12:09:13.601 Attempting to pre-populate zone: dn > DNSHostName=@,DNSZoneName=example.com,ou=dns,dc=test,dc=jp > 01-Apr-2015 12:09:13.602 Adding 'DNSData' -> 'NSRecord' mapping here > 01-Apr-2015 12:09:13.603 Adding 'DNSIPAddr' -> 'ARecord' mapping here > > 01-Apr-2015 12:09:13.606 fakesoa is 'hostmaster.example.com > dns01.example.com. 20081028 3600 300 3600000 600 ' > > 01-Apr-2015 12:09:13.606 DLZ attrib scam map 'soa' + 'DNSPrimaryNS' > 01-Apr-2015 12:09:13.606 dns_rdatatype_fromtext GOOD attr 'NSRecord' > 01-Apr-2015 12:09:13.606 Matched 'DNSPrimaryNS' to 'dns01.example.com.' > > 01-Apr-2015 12:09:13.606 DLZ attrib scam map 'soa' + 'ARecord' > 01-Apr-2015 12:09:13.606 ldap_entry_nextrdtype: checking 'ARecord' on dn > DNSRecord=SOA,DNSHostName=@,DNSZoneName=example.com,ou=dns,dc=test,dc=jp > 01-Apr-2015 12:09:13.606 dns_rdatatype_fromtext GOOD attr 'ARecord' > > 01-Apr-2015 12:09:13.606 leaving ldap_parse_rrentry > 01-Apr-2015 12:09:13.606 make sure we have NS record here? > 01-Apr-2015 12:09:13.606 diff.c:185: unexpected error: > 01-Apr-2015 12:09:13.606 unexpected non-minimal diff
I guess that minimal diff can contain only one del + add operation for arbitrary (name, RR type, data) combination. Maybe you are adding NS which is already in there or something like that. > 01-Apr-2015 12:09:13.606 ldap_entry_create dn is > 'DNSRecord=A,DNSHostName=pop,DNSZoneName=example.com,ou=dns,dc=test,dc=jp' > > 01-Apr-2015 12:09:13.607 DLZ attrib scam map 'A' + 'DNSIPAddr' > 01-Apr-2015 12:09:13.607 dns_rdatatype_fromtext GOOD attr 'ARecord' > 01-Apr-2015 12:09:13.607 Matched 'DNSIPAddr' to '210.157.5.28' > > 01-Apr-2015 12:09:13.607 zone example.com/IN: loaded serial 1427857753 > > > > > > # dig -p5353 @0 example.com any > > ; <<>> DiG 9.6-ESV-R8 <<>> -p5353 @0 example.com any > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22383 > ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0 > ;; WARNING: recursion requested but not available > > ;; QUESTION SECTION: > ;example.com. IN ANY > > ;; ANSWER SECTION: > example.com. 600 IN A 210.157.5.35 > example.com. 600 IN NS dns01.example.com. > example.com. 600 IN SOA > hostmaster.example.com.example.com. > dns01.example.com. 1427857753 3600 300 3600000 600 > > > Not entirely sure why I trip on the "unexpected non-minimal diff" INSIST. I > had to comment it out. > > Obviously still very much hack'n'slash, to get a feel for what is involved. Thank you for letting us know. (It is worse than I expected :-) Anyway, let me know if you have some specific questions about bind-dyndb-ldap. > We could also change the schema of course, at least long term. That sounds like a good idea, unless you want to get crazy from maintenance of this hybrid. -- Petr^2 Spacek -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
