Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=856293

I am not able to reproduce this one.

ipa dnszone-add --name-server=`hostname` --admin-email=ipaqar.redhat.com --serial=2010010701 --refresh=303 --retry=101 --expire=1202 --minimum=33 --ttl=55 idnszone.com 
  Zone name: idnszone.com
  Authoritative nameserver: vm-098.idm.lab.bos.redhat.com.
  Administrator e-mail address: ipaqar.redhat.com.
  SOA serial: 2010010701
  SOA refresh: 303
  SOA retry: 101
  SOA expire: 1202
  SOA minimum: 33
  SOA time to live: 55
  BIND update policy: grant IDM.LAB.BOS.REDHAT.COM krb5-self * A; grant IDM.LAB.BOS.REDHAT.COM krb5-self * AAAA; grant IDM.LAB.BOS.REDHAT.COM
                      krb5-self * SSHFP;
  Active zone: TRUE
  Dynamic update: FALSE
  Allow query: any;
  Allow transfer: none;

Version:

[tbabej@vm-098 freeIPA-scripts]$ rpm -qa | grep freeipa
freeipa-client-2.99.0-0.20121010T1215Zgitfff56ee.fc17.x86_64
freeipa-python-2.99.0-0.20121010T1215Zgitfff56ee.fc17.x86_64
freeipa-admintools-2.99.0-0.20121010T1215Zgitfff56ee.fc17.x86_64
freeipa-server-selinux-2.99.0-0.20121010T1215Zgitfff56ee.fc17.x86_64
freeipa-server-2.99.0-0.20121010T1215Zgitfff56ee.fc17.x86_64

Tested both on bind-dyndb-ldap 1.1 and 2.0:

[tbabej@vm-098 freeIPA-scripts]$ rpm -qa | grep bind-dyndb
bind-dyndb-ldap-1.1.0-0.14.rc1.fc17.x86_64

[tbabej@vm-098 freeIPA-scripts]$ rpm -qa | grep bind-dyndb-ldap
bind-dyndb-ldap-2.0-0.20121009T1320Zgit6a86b1f.fc17.x86_64

QE reports that they see this intermittently they will ping you when/if it comes up again.

Leaving ticket closed for now.

Reopening the ticket as I have been seen (with my own eyes, using vnc) this happen using Web UI on QE win machine.

Given steps to reproduce in Web UI(I did not manage so far):

1. add a new zone,click add and edit
2. click add for adding a DNS record
3. choose NS option in the add prompt ,type in a random name,ip addr is mango.testrelm.com ,click add ,and then you'll see the erro msg coming out

The ticket https://fedorahosted.org/freeipa/ticket/3248 explores exactly same code path. With recent fix to it please re-test and may be test with the same environment.

Scott re-tested with 3248's patch applied and the issue came up. QE reports the issue is not easily reproducible and they have not been able to identify the cause, it appears only after running DNS tests few times. I am negotiating with QE, they are to provide me with remote access to the machine where the issue is already reproducible for investigation.

I had retested the issue using automates tests (where the issue supposedly occured) on QA machine multiple (+10) times over the weekend, with no success of reproducing the issue. Full test suite done by QA also confirmes the bug is not reproducible as of ipa-server-3.0.0-8. Bug is marked as verified in BZ, closing the ticket.

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.