If you’re certifiably crazy, you serve multiple views of your DNS zones from the same BIND instance. Suppose one of those zones is dynamic — maybe it’s updated by the DHCP server or something — and wants to be shared between both views.
Apparently enough people are mad enough to want to do this that there’s an entry about it on the BIND FAQ page (entitled How do I share a dynamic zone between multiple views?). The problem is tricky because, for timely updates, each view has to be able to contact the other reliably: the slave must be able to request zone transfers from the master, and the master must be able to send notifications to the slave. The official solution involves inventing magical TSIG keys that the views can use to identify each other.
Unfortunately, this doesn’t actually work properly when you have more than two views. In the scenario the FAQ answer appears to be considering, the nameserver in question has only one IP address. There’s therefore no way for the master view to send update notifications to both slaves.
So, what do you do to fix this? Ideally, I’d suggest giving the server multiple external addresses and using match-destinations rather than match-clients to distinguish the views. Then you arrange for the master view to send a notify to the slave views’ addresses, and the slave views transfer from the master’s address: there aren’t any problems. But maybe you can’t do this: maybe your DNS server is hidden behind some awful NAT box and you don’t want to invent a new address range just for this kind of hacking.
Conveniently, there’s already a large range of addresses on which a host can talk to itself: 127.0.0.0/8. I have no idea why IPv4, which has a very tight address space, reserves 16 million addresses for each host to talk to itself, while IPv6, with its almost unimaginably vast address space, provides only one: ::1. That’s all right, though: nobody will complain if you carve a chunk out of fe80::/10. Maybe fe80::127.0.0.0/104?
So what you do is as follows.
Start by attaching extra addresses to your loopback interface. I’ll use 127.0.1.0/24 for this hacking: 127.0.1.1 will be the master and 127.0.1.2 and 127.0.1.3 will be the slaves. Set them up with a rune like
for i in 1 2 3; do ip addr add 127.0.1.$i/32 dev lo; done
or equivalent for your system. Unless you’ve done something hairy with listen-on, you won’t need to do anything complicated to get BIND to listen on these extra addresses. Now add
also-notify { 127.0.1.2; 127.0.1.3; };
to the master view. Finally, add each view’s respective address to its match-destinations or match-clients option. This last bit relies on you not having notify-source or transfer-source set on your views. In the absence of these options, BIND will let the kernel choose the source address, which will match the destination because it’s local. And everything will be fine.
I’m sorry.
Leave a comment