Red Hat Bugzilla – Bug 856293
Nameserver does not have a corresponding A/AAAA record while creating new dns zone
Last modified: 2013-02-21 04:19:49 EST
This bug is created as a clone of upstream ticket: https://fedorahosted.org/freeipa/ticket/3063 [[br]]Description of problem: [[br]]When attempting to create a new dns zone, ipa reports the name server does not have a A record when it does. [[br]]Version-Release number of selected component (if applicable): [[br]]freeipa-server-2.99.0-0.20120829T2002Zgit7e9eb9c.fc17.x86_64 [[br]]bind-dyndb-ldap-1.1.0-0.20120828T1109Zgit6114ae2.fc17.x86_64 [[br]]How reproducible: [[br]]Always [[br]]Steps to Reproduce: [[br]]1. install ipa with dns support [[br]]2. ipa dnszone-add --name-server=<fqdn of master> --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 idnszone.com [[br]]Actual results: [root@zippyvm2 ipa-dns]# ipa dnszone-add --name-server=zippyvm2.testrelm.com --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 idnszone.com ipa: ERROR: Nameserver 'zippyvm2.testrelm.com.' does not have a corresponding A/AAAA record [[br]]Additional info: [[br]]zippyvm2.testrelm.com does have a A record. {{{ [root@zippyvm2 ipa-dns]# ipa dnsrecord-find testrelm.com zippyvm2 Record name: @ NS record: zippyvm2.testrelm.com. Record name: zippyvm2 A record: 10.14.5.134 SSHFP record: 1 1 2C0B9281ADBB3F584717C0A0D4508B058FB27ADE, 2 1 B6D4C452A34CCE9A92BD374D497115AF39A16783 }}}
Tomas has been unable to reproduce this, see the ticket for details. Can you re-test this?
We see this intermittently. will ping Tomas when we see it again
I was not able to reproduce this on QA machine using automated DNS tests (where the issue originally came from) multiple (10+) times during the last weekend on current nightly build. QA is to run whole test suite and determine whether the bug can be verified.
Will mark this verified for now. tests were done using ipa-server-3.0.0-8.el6.x86_64
I got hold of the machine where the issue is reproducible. Turns out this comes up when the server is not configured to look at its own DNS records (probably because /etc/resolv.conf was rewritten by a network tool). Adding nameserver 127.0.0.1 to /etc/resolv.conf and restarting solves the issue.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2013-0528.html