In order to avoid having to generate a new key just to try nsupdate out, I initially tried to reuse a key I had generated for rndc. BIND9 doesn't require keys to be configured for rndc on localhost to work It didn't, and you get this blog post in return. In fact, if the authentication and server-side setup had been done properly, this would have taken a few minutes to set up. And with BIND9, updates to the secondaries are kicked off automatically.
That's all you need to add an A record for, and the change is applied immediately. I had held off doing this because I expected dynamic DNS updating, the topic of RFC 2136, to be really complicated, but it turns out that using nsupdate is trivial: once authenticated, a trivial 4 commands add a record: server 192.168.1.4 But anyway, we cut our fingers on a few rough corners of nsupdate and BIND9, and I wanted to share what we learned as part of it. Live DNS updating is more generally useful, of course: you can use it to automate your zone file maintenance, which in our case comes in handy as we roll out the stoq.link service to more users of our management solution, Stoq. Except when you don't know what IP address it got! We don't really run any services on the interface that listens on that dynamic link, but when the other links are down it's a life-saver to be able to ssh into it. And like probably every other domestic cable provider, Virtua gives out dynamically allocated IPs via DHCP: our firewall ( somewhat clunkily) bridges through a Humax HGR100R-L2 modem to get its IP address with dhclient.
The network at Async has multiple redundant upstream connections, and one of them is a domestic-grade cable link at 120Mbps.
0 kommentar(er)
