Sadly this is 'normal' for the OES DDNS (vs rest of the industry as far as I can tell.

I consider it a defect, but haven't gotten very far in pushing it yet, so any vote to the idea of fixing the lack of DDNS cleanup would be appreciated.

Only three votes including me and author

I suspect enough don't actually look at them,  don't have DDNS working, or have a system of cleaning up that they need to share with us.

I'd guess most folks would use dns-maint to wipe empty resource records.

I am the third voter 

You have to make a cron script with the user and password?

-d, Deletion of Empty Resource Records
dns-maint -d <LDAP host name> <LDAP port number> <Admin DN> <Secure LDAP or Not (0 -> non-SSL, 1->SSL)> <Read from Locator (0->No, 1->Yes)> <Locator FDN> <Zone List> <Date (Optional)>

Deletion of Empty Resource Records lets you delete the empty Resource Records of the zones in eDirectory tree. You can delete empty resource records of the list of zones specified as
command line parameter or using the zone list in the locator object.

Locator object FDN and Zone List are mutually exclusive; only one can be present at a time. If Locator object is present, then the Zone List is read from it. The empty resource records of
all the zones present in the Zone List are deleted. Else a semicolon separated list of zones(FQDN) for which deletion of the empty resource records is required should be provided.

The date mentioned is optional. It is used to delete the RRs not used since the date mentioned. Specify the date in the yyyy/mm/dd format.

For example:

dns-maint -d Acme.com 636 cn=admin,o=Acme 1 0 "cn=zone1,o=acme;cn=zone2,o=acme"
or
dns-maint -d Acme.com 636 cn=admin,o=Acme 1 0 "cn=zone1,o=acme;cn=zone2,o=acme" "2006/02/24"

I'm not sure whether this command allows for passing a password, but that's basically the way to clean things up a little. The historic (and likely also current) reason for keeping empty RRs was to keep burden from NDS. In a bigger network with thousands of RR it really made a difference whether you delete / recreate objects all the time (on expiration) or just change an attribute of an existing object.

clearly something to play with, see if there is a way to pass a password, and what are the minimum rights needed if I set an account for this.

so needs to be a function built in that uses something like an existing OESCommonProxy

and I see there is some provision for the CommonProxy, so I have some things to play with in the next few days

<sigh> The instance of <DNS Proxy user DN> <DNS Proxy user password> appears to only be in the creation of the DNS server object, and I figure this is the CommonProxy<server> ID. 

While I could try feeding it as the admin ID, feeding its password isn't trivial or without risk, and I feel it might be risky to test in a production environment. So queued for eventual lab time.

In the meantime, just saving our local instance of the command line and running it manually once in a while should do just fine for my clients.  Still, only adds fuel to needing the Idea implemented.