Hello. Omitting invalid NS records would not help because BIND should load the zone as long as there is at least 1 valid NS record. If there is none, BIND will not load the zone in any case.

Technically this should go to https://fedorahosted.org/bind-dyndb-ldap/ Trac, but we do not need to over-complicate this. I'm closing this as invalid for reasons described above.

(Terminological nit: This has nothing to do with SOA record but only with NS records.)

Hi,

I have reproduced this.

With an SOA for example.com of:

ipa.example.com.    1800    IN  NS  server.ipa.example.com.   <<-- child domain
ipa.example.com.    1800    IN  NS  ns1.example.com. <<-- aaaa only

This zone will fail to load.

server.ipa.example.com has an A and AAAA record, but named disregards these.

It treats the ns1 record with only AAAA as a failure.

This causes the zone to not load or be served.

Okay, we need more information: Please see https://fedorahosted.org/bind-dyndb-ldap/wiki/BugReporting and add required information to this ticket. Thanks.

bind-dyndb-ldap-8.0-1.el7.x86_64
bind-9.9.4-29.el7_2.1.x86_64

Configure two zones:

child.example.com
example.com

Add these records.

ns1.example.com AAAA
ns2.child.example.com A
ns2.child.example.com AAAA

Configure the SOA to both zones to have the following NS servers:

ns1.example.com
ns2.child.example.com

Restart bind. The zone will fail to load due to having no "valid A or AAAA" records.

• Installed as part of freeipa

  dynamic-db "ipa" {
  library "ldap.so";
  arg "uri ldapi://%2fvar%2frun%2fslapd-IPA-EXAMPLE-COM.socket";
  arg "base cn=dns, dc=ipa,dc=example,dc=com";
  arg "fake_mname alina.ipa.example.com.";
  arg "auth_method sasl";
  arg "sasl_mech GSSAPI";
  arg "sasl_user DNS/alina.ipa.example.com";
  arg "serial_autoincrement yes";
  };

No other text based zones configured.

Server is configured to serve DNS64

Global forwarders are configured

IPA dns configuration object

ipaConfigString: DNSVersion 1
idnsAllowSyncPTR: TRUE
cn: dns
objectClass: idnsConfigObject
objectClass: nsContainer
objectClass: top
objectClass: ipaConfigObject

Replying to [comment:4 firstyear]:

Configure two zones:

child.example.com
example.com

Add these records.

ns1.example.com AAAA
ns2.child.example.com A
ns2.child.example.com AAAA

It is not clear to which zone(s) you added these records. To one of them? Or both? Please clarify. Thank you!

ns1.example.com is in example.com

ns2.child.example.com is in child.example.com.

I'm unable to reproduce the issue locally, but still it is not very clear what exactly you have configured.

Please provide exact IPA commands you used so I can setup exactly same environment. Thank you.

I can't provide them, because I've been running this system for a few years. The configuration of these NS servers got rolled over a few months ago.

What is not clear about what I have configured?

Well, texts in the ticket description differ from text in comment:4 and it is still not clear how you handled glue records.

Please provide following LDIFs:

ldapsearch -Y GSSAPI -b 'idnsname=example.com.,cn=dns,dc=example,dc=com' '(|(nsRecord=*)(idnsName=ns1)(idnsName=ns2)(idnsName=ns2.child))'
ldapsearch -Y GSSAPI -b 'idnsname=child.example.com.,cn=dns,dc=example,dc=com' '(|(nsRecord=*)(idnsName=ns1)(idnsName=ns2)(idnsName=ns2.child))'

Thank you.

I cannot do this: I have already corrected the zones in question. I could not leave my IPA domain in a broken state.

I believe there are two parts to the issue:

First, bind-dyndb-ldap does not consider a host with ONLY AAAA records to be "valid" for the purpose of serving the zone.

Second, because bind-dyndb-ldap loads the zones in order, it's doing it in one pass. (I assume)

IE:

      child.example.com --> Not yet loaded, so none of the records are known about
      example.com --> Not yet loaded, so none of the records are known about
      LOAD example.com 
      |
      \- Load all the A / AAAA records
         Load the SOA
         Check the NS. Here, because child.example.com isn't load, all of it's A/AAAA fail to exist. And because of the first issues, the last NS is invalid as it's only AAAA
      FAIL example.com
      LOAD child.example.com
      |
      \- Load all the A / AAAA records
         Load the SOA
         Check the NS. Here, because we HAVE child.example.com, this NS passes, because ns2.child.example.com has A and AAAA, so the NS validates.

If bind dyndb did a two-pass over this, it would fix the problem.

      child.example.com --> Not yet loaded, so none of the records are known about
      example.com --> Not yet loaded, so none of the records are known about
      TENTATIVE LOAD example.com 
      |
      \- Load all the A / AAAA records         
         Load the SOA
      TENTATIVE LOAD child.example.com
      |
      \- Load all the A / AAAA records
         Load the SOA
      VALIDATE example.com
      |
      \- Check the NS. Because now example.com and child.example.com are both tentatively loaded, this will allow the A/AAAA records of all the hosts to be available for NS validation.
      VALIDATE child.example.com
      |
      \- Check the NS. Because now example.com and child.example.com are both tentatively loaded, this will allow the A/AAAA records of all the hosts to be available for NS validation.

In the case a zone fails to validate, you unload it, then you re-run the validation for all other zones.

I hope that helps ....

My findings so far are:

• Zones with NS records pointing only to AAAA records are loaded without an obvious problem (tested with bind-dyndb-ldap 8.0 on Fedora 23).
• Zones are supposed to be self-contained. The problem you describe may happen only if the zone is missing glue records or something like that. (For further reference please see http://tools.ietf.org/html/rfc1034#page-21)

I'm going to close the ticket as invalid for now. Feel free to re-open it whenever you find a reproducer. I will be happy to investigate it.