DNS update issues

Hey all,
Sorry for the double post, apparently I don't know how to work Google
groups. Having some issues having foreman-proxy update my BIND9 dns setup.

When I go to create a new host, the foreman-proxy on the DNS server fails
to update the server via nsupdate. I was having this issue on my 1.8.1
install, upgraded to 1.9.0 with no success (successful upgrade, problem


  • BIND9 logging: DEBUG 3
  • foreman-proxy logging: debug
  • I can manually update it as foreman-proxy user using nsupdate (see

See log/command output on fedora pastebin

https://paste.fedoraproject.org/257419/12735414/raw/ (because I hate big

Is it possible the foreman-proxy is not executing the nsupdate command
exactly as show in the debug-level log? Specifically

running /usr/bin/nsupdate -k /etc/rndc.key

nsupdate: executed - server ns1.dev.lab
nsupdate: executed - update add 86400 IN PTR

When I execute those command manually as foreman-proxy, it works just
fine. I'm sure its a part of my configuration (I'd be surprised if this
was a bug), I'm just not sure what part it is. If configuration files are
needed, just let me know. Thoughts?

Thanks in advance!
Mike D

Why there are all those denied messages in your logs?

> Thanks in advance!

Can you tell if Foreman reads the key properly?

Also try to restart proxy, not sure if we cache the key in memory.

Also check SELinux.

··· -- Later, Lukas #lzap Zapletal

Thanks for the tip on potential caching. My inital issue was a
file-permissions issue on my rndc.key file. After I resolved that, it
started to look like it was working (no errors in either log), but no RR
was created. The following is just provided for other peoples reference.

Selinux was disabled, and now the foreman-proxy user could read the key
properly. The issue ended up being an interesting one. By default CentOS
(and presumably RHEL) automatically populates etc/hosts with both the IPv4
and IPv6 entries of localhost. The foreman-proxy instance was local to the
DNS server, so I didnt see any reason to populate the server field in the
dns.yml file.
It seems the default behavior (when no server is specified), is that
foreman-proxy would implicitly specify the server as "localhost" in running
the nsupdate command. Because I had IPv6 disabled, when the foreman-proxy
ran nsupdate, the nsupdate client would reverse resolve to ::1, which in my
case, didn't work. When you run nsupdate interactively, it shows a
connection timeout error. I would assume that it doesn't throw a proper
non-zero exit code as from the foreman side, it looks like it works, it
just takes a while. And even in the logs it looks like it works (or doesnt
show signs of failure) as the foreman-proxy log doesnt show a failure, and
the named log doesn't show anything (as there never was a connection).
Removing/commenting out the IPv6 localhost entry and a reboot to clear any
caches solved the problem.

It's not really a bug, as I shouldn't have had entries in my host file that
wouldn't resolve. That being said, nsupdate could have thrown a proper
non-zero error (triggering foreman-proxy to error, making the problem more
obvious). Or foreman-proxy could have just let nsupdate imply localhost.
While this works in the interactive mode (CentOS 6.6, Foreman 1.9.0), it
may not be best practice given nsupdate may behave differently on different
distros. If nothing else, hopefully this email chain will help someone

Thanks for the help!

··· On Mon, Aug 24, 2015 at 4:13 AM, Lukas Zapletal wrote:

Thanks in advance!

Can you tell if Foreman reads the key properly?

Also try to restart proxy, not sure if we cache the key in memory.

Also check SELinux.

Lukas #lzap Zapletal

You received this message because you are subscribed to a topic in the
Google Groups “Foreman users” group.
To unsubscribe from this topic, visit
To unsubscribe from this group and all its topics, send an email to
To post to this group, send email to foreman-users@googlegroups.com.
Visit this group at http://groups.google.com/group/foreman-users.
For more options, visit https://groups.google.com/d/optout.