I have my IPA (4.5.0 on EL7) instance set up to receive DDNS updates from a DHCP server for the network.
While this generally works, names that are queried during the DDNS updates end up returning SERVFAIL even though there is reason those names shouldn't successfully resolve.
The most common scenario here is an Android phone jumps on the network, gets an IP address and immediately starts reaching out to Google services such as www.google.com. While these queries are happening, BIND is processing the DDNS updates for the IP address that is leased to the Android phone and returning SERVFAIL for these queries.
The SERVFAILs will continue for about 10 minutes or until an rndc reload is issued.
rndc reload
BIND starts returning SERVFAIL for names queried just as it's processing DDNS update records from the DHCP server.
Clearly, BIND should not return SERVFAILs.
ipa-server-4.5.0-22.el7.centos.x86_64 ipa-client-4.5.0-22.el7.centos.x86_64 389-ds-base-1.3.6.1-24.el7_4.x86_64 pki-ca-10.4.1-17.el7_4.noarch krb5-server-1.15.1-8.el7.x86_64
I have lots of BIND logs at trace level 11 showing the correlation of SERVFAILs happening when DDNS requests are being made. They don't really indicate why though.
I have also stood up another BIND server instance a couple of days ago to receive the DDNS updates and there has not been a single SERVFAIL for www.google.com since doing that when there were many a day before doing it.
I am happy to gather any further information that would be useful i getting to the bottom of this.
Can we see the logs you've captured?
@rcritten To be clear, the only logs of any greater detail than the default logging level that I have are bind's named logs, at trace level 11. Is that what you are looking for?
They, unfortunately, don't really say a whole lot in and of themselves. I am happy to provide a sample of a SERVFAIL from one of them if you think it's of any use.
In any case: http://brian.interlinx.bc.ca/named.run.log
As I understand it what Android will do is try to hit www.google.com to see if there is a web portal that needs authentication
I'm not clear how DDNS is related since it shouldn't need its own entry recorded in DNS in order to do a lookup, right? What does the DDNS update look like?
@rcritten
Yes, that's correct.
I'm not clear how DDNS is related
It's related because every DHCP client that connects to the network gets a DNS entry created for it and while that DDNS entry is being created, BIND starts returning SERVFAIL for any requests done while it is doing that DDNS update. Typically this is the www.google.com that an Android phone does the moment it gets a lease, but I have seen it happen for other names that happen to fall into the window.
It's well worth noting that this was never a problem for plain BIND9. It only seems to be a problem with the LDAP pkcs11-bind that FreeIPA is using.
since it shouldn't need its own entry recorded in DNS in order to do a lookup, right?
Indeed not, no. The DNS entry is just there so that everything on the network has a name.
What does the DDNS update look like?
It's a standard ISC DHCP DDNS update using RFC 2136. There are several in the log I posted the link to previously. Just search for add (leading and trailing space to reduce false positives).
add
Just to gather some more information, how is DNS configured? Forward policy, etc? (looks like first)
Yes, Forward policy is Forward first.
I'm not sure what other info you might want. Of course I have a few zones configured for address and PTR records. Some are authoritative and some are forwarding.
And of course happy to provide any additional information you might want.
Anything additional that can be done here?
Can I provide any more information for this issue?
Sorry for the delay, we haven't had a chance to investigate this fully yet.
@brianjmurrell would it be possible to provide 389-ds access/errors logs and the more precise time when problem occurs ?
Closing this ticket as we don't know how to reproduce the bug with the given info. If the bug is still happening/relevant and you're able to provide more info, please, open it again.
Metadata Update from @fbarreto: - Issue close_status updated to: insufficientinfo - Issue status updated to: Closed (was: Open)
Login to comment on this ticket.