Bug 671280

Summary:	when a NS record is deleted, it cannot be recreated
Product:	[Retired] freeIPA	Reporter:	Michael Gregg <mgregg>
Component:	ipa-admintools	Assignee:	Rob Crittenden <rcritten>
Status:	CLOSED ERRATA	QA Contact:	Chandrasekar Kannan <ckannan>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	benl, dpal, jhrozek
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	freeipa-2.0.0-1.fc15	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-03-28 09:26:06 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:

Description Michael Gregg 2011-01-20 23:36:11 UTC

Description of problem:
After deleting a NS<possibly additional types> record, I am unable to add the same record back into the zone

Version-Release number of selected component (if applicable):
ipa-server-2.0-0.2011011418gita68b2d2.fc14.x86_64

How reproducible:
unknown

Steps to Reproduce:
 Assuming that your current NS record is 10.16.98.193.
1. ipa  dnsrecord-del newzone1 @ --ns-rec=10.16.98.193.
2. dig newzone1 NS
3. ipa  dnsrecord-add newzone1 @ --ns-rec=10.16.98.193.
4. dig newzone1 NS
  
Actual results:
dig newzone1 NS returns nothing. 

Expected results:

Additional info:
Oddly enough, "ipa dnsrecord-find newzone1 @" returns what I'd expect.

Comment 1 Dmitri Pal 2011-01-21 00:09:07 UTC

This might be a DNS issue. Can you restart DNS to see if it makes a difference? If so we got a DNS problem.

Comment 2 Michael Gregg 2011-01-21 00:25:30 UTC

That's a good though. 

Unfortunately, I'm getting the same result after a bind restart.

Comment 3 Michael Gregg 2011-01-21 00:30:32 UTC

Rather, that's a good thought. I should have tried restarting bind before creating the bug.

Comment 4 Jakub Hrozek 2011-01-24 21:41:51 UTC

https://fedorahosted.org/freeipa/ticket/842

Comment 5 Jakub Hrozek 2011-01-31 09:35:42 UTC

This was fixed by 0a6b1c4bced35dc0943ae38fcea71586274395ba, too.