Wednesday, 22 December 2010

resolv.conf and DynDNS

So, in order to save a few pennies on my broadband service, I have downgraded my package which means I lose my static IP address.  Now the issue is that I have bridge mode setup on the router so I can manage my own internal network, placing different security policies onto different subnets and changing what services are listening on each network, like UPnP for example.  Since game consoles typically require UPnP and most other things don't, games consoles are locked down onto their own private subnet, connected to the outside world via a different interface on the server.

So back to the bridge mode issue.  Why is it an issue?  Well, when switching from static, it means your interfaces configuration must change from static to dhcp as well:

auto eth0
iface eth0 inet dhcp

What this means is, that dhclient will handle setting up routes and designating the IP address etc, to the interface, when it receives a DHCP response from the ISP's DHCP server.  This usually entails losing everything you have setup in resolv.conf when dhclient decides to overwrite it.  To prevent it being overwritten, you need to use the hooks provided in dhclient-script.  See dhclient-script man page.

Essentially, what is required is an enter hook that declares a function called 'make_resolv_conf'.  This function will replace the function defined in dhclient-script at the point the enter hook gets included, and thus, if the body of the function does nothing, resolv.conf doesn't get modified.  For me, this is good since DNS is managed by dnsmasqd and I forward DNS requests to to provide simple security on things like typos: -> Hmm, nice place to setup a spoof / phishing site I would imagine.  OpenDNS resolve addresses like these to one of your choosing.  For me, I have it resolve back to the address of my internal gateway, where I host a 404 page.

What next?  Well, there is the issue that this dynamic IP address being assigned to my bridged interface, is... well... dynamic.  So when the lease runs out, it could mean it will change to a new address, making my network inaccessible from the WAN.  To counter this, ddclient needs to be run whenever the lease runs out or a new address is assigned to the interface, as well as the periodic calls to ddclient in order to keep the DynDNS hostname alive.  I lost a host to DynDNS once before because I didn't force update it every so often, so I want to avoid that painful experience again.

So how on earth do you go about executing ddclient whenever the lease is renewed or the interface is bound to the DHCP server?  Well, lets use the dhclient-script hooks again.  I created an exit hook script this time, to listen for the dhclient-script being called with the reason of BOUND, RENEW or REBIND.  These three reasons will get triggered whenever the interface address is likely to change and often when the interface address hasn't changed.  But importantly, it will ensure ddclient can be called when the lease expires.  Here is the script:

# dhclient-script exit hook to ensure that the DYNDNS address is updated
# through the ddclient, whenever the address changes.

function ddclient_exithook() {
    local prog="${0##*/}::ddclient_exithook()"
    logger -t "$prog" "Reason: $reason"

    case $reason in
        # Run the ddclient script to rebind the address to the DYNDNS hostname
        cat <
Executing ddclient to renew DynDNS hostname...

$(/usr/sbin/ddclient -force -verbose 2>&1)

Executing ddclient returned exitcode: $?
        # No need to renew the DYNDNS address
        logger -t "$prog" "Nothing to be done for $reason"


Test the script works by taking down the interface and bringing it back up.  This will force the interface to bind to the DHCP server when it comes back up, causing dhclient-script to be invoked with the BOUND reason.

See also:


Man pages:


No comments:

Post a Comment