To summarize the comments, there is no answer, because the question is entirely based on faulty assumptions.
[…] with the IPv6 subnet assigned as secondaries, as shown
This does not actually assign the entire subnet. It assigns a single address (the all-zeros-IID address, 2a10:b900:10e4:1:0:0:0:0) and sets the "subnet mask" to /64. The behavior is identical to assigning any other address; there's no special treatment for …:0:0:0:0. The /64 in both cases merely indicates which addresses are "on-link" (can be reached at MAC level over the physical interface).
a https:// connection cannot be shared (ie: you could have 10 connections via the same IP address if they are http://, but those self-same connections would require 10 IP addresses if they were https://
No they wouldn't, because the underlying transport protocol, TCP, already has a multiplexing mechanism – the combination of local port + remote port. Assuming you have
- one client,
- one server listening on one port,
you can in theory have up to 65535 unique
(local_addr, remote_addr, local_port, remote_port) combinations by varying the local_port. In practice the number is somewhere within ~32k or ~48k, depending on what "ephemeral port" range the OS has configured.
This mechanism is independent of the upper layer protocol, and a server can accept as many HTTPS connections to port 443 as it can accept HTTP connections on port 80. In both cases, the client's and server's network stacks will uniquely identify every packet of every connection.
Your story would still make some sense if it had been about HTTP(S) "virtual hosts" instead of "connections", i.e. sharing domain names on the same IP address. It would have been true 10–20 years ago that an HTTPS server (more accurately an SSL/TLS server) could only serve one certificate over a single IP address:port, and therefore could serve only as many domains as the single certificate had been issued for.
However, now all modern clients support TLS 1.1+ "Server Name Indication", which allows them to request a specific domain name during the TLS handshake, so that the server could choose the correct TLS certificate before starting the application-layer handshake.
In conclusion, assigning a subnet to the server is unneccessary to begin with.
Finally, the technically main question:
I am therefore attempting to create a solution where BIND can dip into a pool of addresses should it need to
DNS doesn't have such a feature – only AAAA records can point to IPv6 addresses, and each such record can only point to one address. (There are other types but they have different uses and most software will simply not look at them.)
You would have to use BIND's
$GENERATE feature, which is a macro that can expand to many records, or write a custom DNS server that would generate responses with random AAAA records on demand.