I have to undo this as an Answer, because after running with this for a few days, I see that it doesn't work the way I was hoping. The auto-generated afxr bind9 output has a few limitations, and many of my subdomains cannot be accessed.
For the time being, I have switched back to tinydns, and I am just not using IPv6 for the moment.
I'll leave this original answer here, in case someone who reads it might be able to see the flaw(s) and possibly suggest something that will actually work.
I apologize.
Original Answer Which Turns Out Not To Work
This isn't quite a positive answer to my question, but it's the best that I've been able to come up with.
It seems like I am totally out of luck regarding djbdns and djbdns-fefe offering syntax for specifying IPv6 MX records, and after much searching, I still haven't found any hacks or workarounds which would allow me to do this exactly in the way that I have been asking here.
However, I found an indirect way to do this without completely abandoning my djbdns tinydns-based configuration info.
First of all, it's important for me to explain that years ago, I wrote a custom utility to generate tinydns commands based on a more user-friendly syntax (where the particular user I'm being friendly to is "me" ... LOL). For the time being, I want to continue to use this utility.
My "solution" to the IPv6 MX issue is to continue to use that old, custom utility, and now to also write a new utility that will allow me to generate bind9 configuration files based upon my current djbdns configuration, and then switch to using bind9 instead of djbdns. In bind9, I can then indeed get the IPv6 MX records set up.
Some day, I'll re-write my old, original custom utility so that it will directly generate bind9-specific records without my having to go through the intermediate step of djbdns-configuration-to-bind9-configuration conversion. But I don't have time to do that now, so here is the new utility I wrote to convert djbdns configuration information to bind9 configuration files ...
This new utility is a complicated python script which is too long to list here in its entirety, so I'll just summarize its workings. And in any case, a lot of it is specific to my particular host, and so I doubt that the script as written will run anywhere but on my own host. But in general, it functions as follows ...
(1) Install and set up a working bind9 service.
(2) Even though I'm now using bind9, the djbdjs server still needs to be running in order for my script to work. I set it up as a "dummy" DNS server which only listens on a private, local-only address.
(3) In the python script, I created a list called "email_hosts" which contains the names of the top-level domains which will need IPv6 MX records.
(4) When this new script is started, it first fires off a daemon via the python "multiprocessing" package which runs this comand ...
/command/envuidgid root /usr/bin/tcpserver -vDHRl0 [DNSSERVERADDR] 53 /command/axfrdns
... where [DNSSERVERADDR] is the private, local-only address that the dummy djbdns server is listening on.
(5) The script waits until that daemon is up and running, and it then fires off another daemon via the python "multiprocessing" package which loops through the names of all the domains that I am hosting, and for each domain (which I'll call [DOMAINNAME], below), it runs this command ...
/usr/bin/dig axfr [DOMAINNAME] @[DNSSERVERADDR]
(6) The output of each "dig" call is captured, and then I loop through all the lines in that output. If I encounter an AAAA record for any of the domains whose names I have stored in the "email_hosts" list mentioned above, I do the following ...
(7) Take the domain name of that particular AAAA record, which I'll call [DOMAINNAME], and prepend the prefix "mx." to that domain name. I'll call that result [MXNAME]. For example, if [DOMAINNAME] is "myhost.example.com", then [MXNAME] will contain the name "mx.myhost.example.com".
(8) I then add the following additional lines to the output list, assuming that the IPv6 address of "myhost.example.com" in its AAAA record is [IPV6ADDRESS]:
mx.myhost.example.com 86400 IN AAAA [IPV6ADDRESS]
myhost.example.com 86400 IN MX mx.myhost.example.com 10
(9) I concatenate all these output lines for the given domain, including the two new lines that I might have created, and then I write the result to a file called "db.[DOMAINNAME]" in the /var/lib/bind directory (whose original contents I have previously backed up as /var/lib/bind.backup).
(10) In addition, for each [DOMAINNAME] processed in this dig-axfr-output-based client, I also append the following text to a new /etc/bind/named.conf.local file (after having backed up the current version as /etc/bind/named.conf.local.backup) ...
zone "[DOMAINNAME]" {
type master;
file "/var/lib/bind/db.[DOMAINNAME]";
};
Also note that the top of this newly created /etc/bind/named.local.conf file looks like this:
include "/etc/bind/zones.rfc1918";
(11) After I have processed all of the domains in this manner, I terminate both of the daemons that I had started via python's "multiprocessing" mechanism.
(12) I then restart the "named" daemon.
This way, I can continue to use the same utility that I have written years ago for simplifying the generation of tinydns commands, but at the same time, I'm actually utilizing bind9 as my DNS server now.
And as I mentioned above, I'll eventually rewrite that utility to directly generate bind9-specific records. Then, this entire axfr-based procedure will go away.
As much as I have been happy with djbdns for all these years, I have to admit that I think I'm better off nowadays using bind9.
