On 02/10/2017 08:42 AM, Ben Roberts wrote: > Hi Martin, > >> I'm not sure how your DNS data are structured, but usually (properly) >> DS record is located in parent zone, so AXFR for >> subdomain.exmale.com should not return DS record, but AXFR >> for example.com should return DS record of >> subdomain.example.com. > Herein lies the problem. The nameservers are authoritative for both > the parent and child zones, and both are replicated from the primaries > to the secondary nameserver. The DS glue records for the child zone > contained within the parent zone are not being replicated across to > the secondary via AXFR. Thus there is a complete chain for DNSSEC > trust when queries are directed at the primaries, but not when queries > are directed at the secondary nameserver. > > This affects both the DS glue records, and also the apex DS records > which don't need to be present, but which bind-dyndb-ldap makes > available automatically anyway. I raise this not because it's needed, > but it might be relevant to identifying where the root cause is. > > Regards, > Ben Roberts If I understand you correctly, the primary server is filled with data using bind-dyndb-ldap from an LDAP backend. Then the DS records are present on the primary server. At this point, bind-dyndb-ldap's work should be done, since it only serves as the backend LDAP driver for BIND.
The issue happens when you try to replicate the zone to the secondary nameserver using AXFR. This leads me to believe that this might be some issue in the BIND component itself. Perhaps some special configuration is required. It might help you if you'd test the setup without bind-dyndb-ldap with some mock data directly in BIND. If the AXFR doesn't contain the DS records then, it's related to BIND. Perhaps the BIND users (bind-us...@lists.isc.org) list might be able to assist you. -- Tomas Krizek
Description: OpenPGP digital signature