Solved CMD_API_DNS_CONTROL action=delete answers "Records Deleted" but never deletes the record (1.705)

[castris]

Hi,

I would like to report a persistent bug in CMD_API_DNS_CONTROL action=delete: the API answers error=0&text=Records Deleted while the record is still in the zone. The delete never happens, in any of the parameter formats documented or mentioned in older threads.

Environment

• DirectAdmin 1.705
• Bind/named zones, cluster DNS (two receivers)
• Reproduced both as the reseller/owner of the domain and as admin — identical result

Steps to reproduce

1. Create a disposable TXT record in a test zone, e.g. _deletetest.example.com. 3600 IN TXT "probe-1234567890" (via panel or API).
2. Call the API delete. One of the formats tried:
   

   curl -k -u "user:pass" "https://server:2222/CMD_API_DNS_CONTROL?domain=example.com&action=select&delete=yes&txtrecs[]=name=_deletetest&value=probe-1234567890"

3. The response is error=0&text=Records Deleted.
4. The record is still there: CMD_API_DNS_CONTROL?action=view&domain=example.com still lists it, and the zone file is unchanged.

Parameter formats tried (12 in total, none works)

• Flat fields: type=TXT&name=_deletetest&value=... with action=delete
• Per-type record arrays (txtrecs[]= / nsrecs0= / arecs0=) carrying the combined name=...&value=... string exactly as returned by action=view
• action=select with select0=<combined string>
• The same variants with and without confirmed=Confirm
• The "fixed" format from the 2020 thread on this same command (value in quotes + short record name without the domain): also fails

Verification of "not deleted" was done against action=view immediately after each call, not with dig (named reload lag gives false negatives).

What works
The web panel deletes the same record without any issue, and the change propagates normally to the DNS cluster. So the data path is fine: only the API action is broken.

Expected
action=delete removes the record, or at least returns an error when it does not.

Actual
error=0&text=Records Deleted with the record untouched — a silent false positive. This is the worst part: automation believes the delete succeeded.

Questions

1. Is there a working parameter format for action=delete on 1.705+?
2. Has the accepted format changed again since the 2020 thread? undocumented changes in CMD_API_DNS_CONTROL

Thanks!

 

[zEitEr]

Hello,

Did you try the actual version of DirectAdmin? As a user?

When I try as a da admin, I get the error:

error=1&text=Cannot%20View%20Dns%20Record&details=Domain%20does%20not%20belong%20to%20you

so server admin can not use the API command.

It is the USER level API command. And I successfully completed a record removal as a user over API. Tested and confirmed it's working on:

- DirectAdmin 1.713 d5304b4463cd05d0ef4e238c0cb56dbd7afc882b
- DirectAdmin v.1.668 f4e07fbf439d2a3a9ff7e745ba88c29671c50052

Reproduced both as the reseller/owner of the domain and as admin — identical result

 

[sysdev]

If you want to call the api as a specific user, use the user impersonation option.

curl <options> 'https://admin|user:adminpass@server:2222/api/....'

 

[zEitEr]

curl <options> 'https://admin|user:adminpass@server:2222/api/....'

Which can be autogenerated in CLI under root login:

da api-url --user=username

for example:

curl -k "$(da api-url --user=dbtest)/CMD_API_DNS_CONTROL?domain=dbtest.localhost&action=select&delete=yes&txtrecs[]=name=_deletetest&value=probe-1234567890"

 

[castris]

Thanks both — you were right, and I owe a correction.

I re-tested on a disposable zone (DA 1.712, user-level via da api-url --user=..., verdict taken from the zone file, not the API
response):

• action=select + txtrecs0=name=X&value=Y (URL-encoded) deletes correctly — as long as the value matches byte-for-byte
  how it is stored in the zone file. TXT records added via API are stored unquoted; records created from the panel are stored quoted. My original
  test sent the wrong form for how the record was stored.
• action=delete is not a valid action: it just returns the zone dump. My mistake.
• As admin without impersonation I get error=1 "Domain does not belong to you", as you said — my "reproduced as admin" claim was wrong.

Two things worth noting for anyone automating this:

1. On a non-matching value the API still returns error=0&text=Records Deleted; the only signal is in details ("... did not
   exist"). Treating error=0 as success is unsafe — parse details or verify the zone. An error=1 here would be much
   friendlier.
2. Careful with the example in #4: with the inner &value= unencoded, value is parsed as a separate parameter and the call
   deletes ALL TXT records with that name (tested: two records sharing the name, both removed). Use:

curl -sk "$(da api-url --user=USER)/CMD_API_DNS_CONTROL" \
     --data-urlencode "domain=example.com" \
     --data-urlencode "action=select" \
     --data-urlencode "txtrecs0=name=_deletetest&value=probe-1234567890"

Marking this as solved on my side. Thanks!