[Freeipa-users] bind-dyndb-ldap, AXFR and DS records

[Ben Roberts]

Hi all,

This is a question more about bind-dyndb-ldap rather than freeipa, but I
understand it's written/maintained by the freeipa project and so this might
be the most appropriate place to ask. I have setup bind-dyndb-ldap to read
some zones from openldap, with multiple nameservers acting as masters and
one nameserver running as a slave via the usual notify/transfer mechanism.
I'm not seeing any DS records transfer across to the slave nameserver, nor
when I manually query the primaries with an AFXR request. This includes
both the apex DS records, automatically generated by bind-dyndb-ldap, but
more importantly the glue dSRecord objects for a delegated subdomain.

I note that the dSRecord entries are present in
/var/named/dyndb-ldap/$view/master/$zone/raw but not present in
/var/named/dyndb-ldap/$view/master/$zone/signed.

Example (domain name and ip addresses obfuscated, but all other fields are
unmodified):
$ dig +noall +answer DS subdomain.example.local @127.0.01
subdomain.example.local.   600     IN      DS      38589 7 1
6C410EF5A47631FBA2C3BC295A90363EA86A1846
subdomain.example.local.   600     IN      DS      38589 7 2
23E22A49BBF2AD0E3F4668CB4C0DB52EE60ACA4308C1DE002A47AD7B 99734334

$ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | head -n 1
subdomain.example.local.   600     IN      SOA     ns1.example.local.
hostmaster.example.local. 2016050416 43200 3600 1209600 3600

$ dig +noall +answer AXFR subdomain.example.local @127.0.0.1 | grep '\bDS\b'
$

This behaviour doesn't seem right to me. I would expect the DS records to
be transferred to the slaves as normal so that any glue records are
correctly present on all nameservers. I can't see any references in the
bind-dyndb-ldap wiki/readme or code comments that would explain DS records
being treated specially, but please do correct me if I'm wrong.

Regards,
Ben Roberts
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20170208/35c58a14/attachment.htm>