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
> 01-Apr-2015 12:09:13.601 Attempting to pre-populate zone: dn
> 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
> 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
> 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 '220.127.116.11'
> 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 18.104.22.168
> example.com. 600 IN NS dns01.example.com.
> example.com. 600 IN SOA
> 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
Manage your subscription for the Freeipa-users mailing list:
Go to http://freeipa.org for more info on the project