Bug #13237


ERROR_ACCESS_DENIED when deleting DNS A record (dns_dnscmd plugin)

Added by Dmitry Sakun almost 8 years ago. Updated over 5 years ago.

Target version:
Fixed in Releases:
Found in Releases:


Record creation works just fine but when you try to delete the host you will get access denied and HTTP 404 back from the smart proxy.

dnscmd.exe /RecordDelete A /f

Command failed: ERROR_ACCESS_DENIED 5 0x5

It looks like it's necessary to include RRData (e.g. IP address in this case) when deleting A record.

Syntax: dnscmd ServerName /recorddelete ZoneName NodeName RRType RRData[/f]

Quick hint to fix it:
< cmd = "/RecordDelete #{zone} #{fqdn}. A /f"

cmd = "/RecordDelete #{zone} #{fqdn}. A #{ip} /f"

DNS service is running on W2k12R2

Actions #1

Updated by Alex Fisher over 7 years ago

I've hit this too.

I don't think the fix is quite as trivial as suggested though.
From what I can see, the foreman smart-proxy API for deleting DNS A records doesn't support the IP address being sent as well as the fqdn.

I don't think it should be too hard to use dnscmd /EnumRecords to build a list, (of most likely 1), specific entries that need to be deleted though. I'll try hacking on a patch...

Meanwhile, does anybody know why the current solution isn't working for some of us? All dnscmd documentation I've come across certainly suggests that specifying the RRData field is optional.

Actions #2

Updated by The Foreman Bot over 7 years ago

  • Status changed from New to Ready For Testing
  • Pull request added
Actions #3

Updated by Anonymous over 7 years ago

Would be helpful to see the contents of event log when this error is reported...

Actions #4

Updated by Alex Fisher over 7 years ago

It's been a while, but I've finally been able to get some time with a domain admin to investigate this further. Even after much fiddling we weren't able to get anything useful logged, but we did discover the following...

The only way to delete records (without specifying the RRData option) was to (temporarily) give the service account user 'Full Control' privileges on the zone. No other combination of privileges worked, (including ticking everything other than 'full control'). This might be acceptable to some, but I won't be allowed to run with the account configured this way (eg it can delete the whole zone in a single click). Some organisations might be prepared to grant the user these elevated privileges, but I imagine many won't.

Actions #5

Updated by Alex Fisher about 7 years ago

  • Status changed from Ready For Testing to Closed
  • % Done changed from 0 to 100
Actions #6

Updated by Dominic Cleal about 7 years ago

  • Assignee set to Alex Fisher
  • translation missing: en.field_release set to 189

Also available in: Atom PDF