As I said - it is working now and the issue was a GROUP WRITE permission needed on the zone file
HOWEVER, it still does not work unless I restart BIND while the propagation is waiting
nsupdate setup also commonly called "dynamic updates" as a feature of BIND does not gracefully tell on itself if it is not working.
The page at Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation does not give any clues on the fact both nsupdate and dnspython are needed for the certbot-dns-rfc2136 authenticator to work
A journal file ( .jnl ) by the same name of the zone with a .jnl extention will be delivered to the directory and it contains the update - in this case the TXT challenges
BUT
if there are no write permissions for the GROUP (usually named or bind ) to the zone file - it will just leave it there and the rfc2136 authenticator will just keep going eventually to a "no TXT Record found" fail because the zone file never got written the challenge TXT's
A restart of BIND or a " rndc sync -clean " will flush the waiting journal file changes to the zone file and propagate them out at the same time ONLY if BIND is restarted if doing the rndc sysc -clean command, and if this is done while certbot is waiting - the rfc2136 authenticator actually - is waiting its default 60 second wait then a DIG will show the TXT challenges delivered to the zone.
It should be noted that no log at least on my system showed the .jnl file waiting - or not able to deliver the TXT challenges into the zone file itself.
The letsencrypt log was on little help as to WHY it was writing the challenges and then finding no challenges
It should also be noted that the BIND directory itself - in my case - /var/named - needed the group write permission also and I actually changed them to 770 with execute before NSUPDATE itself would work to even deliver the .jnl file
Once the .jnl file showed up, adding the GROUP WRITE permission to the ZONE file allowed the rfc2136 authenticator to write to the ZONE file and the DIG showed the TXT challenges while the 60 second propagate was waiting and then it worked
The CNAME set up was from as shown at Renew using dns-01 challenge and it apparently is working as a cert is delivered in the dry-run even though the zone file bing used is not the zone for the domain of the cert and is a different one from the domain the cert is obtained as called for - hence the need for the CNAME in that zone file the cert is being issued for.
Someone should modify the documentation page at Welcome to certbot-dns-rfc2136’s documentation! — certbot-dns-rfc2136 0 documentation to warn and advise of these permissions road block issues
Two pages at Agile Testing: Dynamic DNS updates with nsupdate (new and improved!) and Agile Testing: Dynamic DNS updates with nsupdate and BIND 9 helped me make sure nsupdate was actually working even though for Ubuntu - however the permissions issue did not present itself because I was running that testing as root and it always worked whereas the rfc2136 authenticator was running as user named and needed the group named to have write permission on the file
HOWEVER, it still does not work unless I restart BIND while the propagation is waiting
The documentation should warn of how this dns rfc2136 authenticator works