I have a home webserver, /29 IPv4 addresses (3 currently assignable from the block due to having a routed subnet with gateway address requirement) and two addresses already assigned to my DNS records. Additionally, I have a /64 IPv6 subnet with two addresses already assigned to my DNS records.

I have altered my sysconfig > network-scripts file (managed via Network Manager, not DHCP) to make all the IPv4 addresses available to my system, with the IPv6 subnet assigned as secondaries, as shown (which I think is correct, but please tell me if it is not):


The problem? - I need to amend my Bind zone files to use both the additional available IP address and the entire IPv6 subnet. I guess that I could possibly add the IPv4 as an additional A record (although I have had problems where that has caused connectivity problems in the past), but can anyone here tell me how I would add in the IPv6 subnet?

  • Why do you need to add the whole subnet? (As opposed to the individual address assigned to the server's interface?) – user1686 Jul 1 '19 at 12:41
  • To make things easier: my concern is that, at present, I have two IPv4 addresses and two IPv6 addresses available; so, at most, my server can only support 3 https:// connections at any given time. I am therefore attempting to create a solution where BIND can dip into a pool of addresses should it need to, and I would have thought that making an entire subnet available would be easier and make more sense than adding a whole load of AAAA records for individual addresses – 9A4Sc6GW4LkvRD Jul 2 '19 at 16:26
  • It would have to be IPv6, too, because IPv4 subnets are expensive, whereas the IPv6 addresses are at no charge on the account I have ...and that should have been 2 https:// connections at any given time (always assuming that it is possible to have an IPv4 http:// with the https:// via IPv6). – 9A4Sc6GW4LkvRD Jul 2 '19 at 16:32
  • 1) I think you're misunderstanding what IPV6ADDR_SECONDARIES does. It doesn't assign a subnet; you merely assigned the single address 2a10:b900:10e4:0001:0000:0000:0000:0000 with netmask /64. – user1686 Jul 2 '19 at 17:25
  • 2
    1) It most likely hadn't. 2) is complete nonsense. Both HTTP and HTTPS run over TCP, and TCP has a built-in multiplexing mechanism: ports. The same client can make thousands of connections to the same server (technically ~65535, practically up to ~32k depending on configured "ephemeral port" range). This does not in any way change depending on the higher-layer protocols. – user1686 Jul 3 '19 at 18:31

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

  1. one client,
  2. 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.

| improve this answer | |
  • Well that has definitely well and truly cleared that issue: thanks, once again, for an amazing response and an in-depth reply. – 9A4Sc6GW4LkvRD Jul 4 '19 at 22:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.