Bug 671280 - when a NS record is deleted, it cannot be recreated
Summary: when a NS record is deleted, it cannot be recreated
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: freeIPA
Classification: Retired
Component: ipa-admintools
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-01-20 23:36 UTC by Michael Gregg
Modified: 2015-01-04 23:45 UTC (History)
3 users (show)

Fixed In Version: freeipa-2.0.0-1.fc15
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-03-28 09:26:06 UTC

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

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.
Note You need to log in before you can comment on or make changes to this bug.