[luci] Router hostname DNS resolution

Hannes Beinert argovela at gmail.com
Mon Aug 8 01:28:43 CEST 2011


Hello,

I've just been using LuCI (v0.10+svn7292) to configure a Linksys
WRT54GL router and stumbled across a few things about which I'm
curious if anyone else might have some comments.

(1) It struck me that it would be nice to have the UI provide an
option to automatically add the router's hostname to dnsmasq for both
forward and reverse name resolution.  Specifically, I could envision a
UI tweak where there might be a checkbox next to the [System > System
> hostname] field which reads "DNS Registration", and if that's
checked, the hostname will be entered on the [Network > Hostnames]
table.  My thought is that these entries could/should be readonly, and
that they could only be deleted if the checkbox is unchecked on the
[System > System > hostname] page.  This would make sure that the
hostname and the DNS resolution would never be out-of-sync.

(2) To achieve the above goal, I added my own entries to the [Network
> Honstnames] table, where I stumbled across something else.  For my
internal network, I tend to use unqualified hostnames.  Therefore, if
the router's hostname is "ROUTER", then I would like to be able to
resolve both ROUTER and ROUTER.DOMAIN.TLD.  When I inspected the
/etc/init.d/dnsmasq init script, it appears that any unqualified
hostname in the [Network > Hostnames] table is automatically given the
domain name suffix from [Network > DHCP and DNS > General Settings >
Local domain].  My initial impression is that this is not an ideal
semantic.  It would seem to me that it might be preferable to only
apply the domain suffix only if the [Network > DHCP and DNS > Advanced
Settings > Expand hosts] checkbox is set.  In other words, use the
same semantics on the [Network > Hostnames] table as exist for the
/etc/hosts file.

(3) In my situation, to get around the situation described in case
(2), I thought I'd try adding the unqualified hostname with a trailing
period, to prevent the addition of the domain suffix.  The UI
validation script wouldn't allow a trailing period, however.  I
ultimately placed this hostname-with-period directly into the
/etc/config/dhcp configuration for dnsmasq, and it seems to be
working.  The LuCI UI is still upset with this specification, however,
and obviously won't let me update the table without deleting this
entry.

An obvious question is whether this is too much of an edge case (or an
absurd case :-) to worry about, and whether it makes sense to allow
the configuration of dnsmasq to resolve unqualified hostnames.  I
would welcome comments on this point.

If this seems like a legitimate issue, then my suggestions would be as follows:

(1) Add two checkboxes next to the [System > System > hostname] field
to specify automatic registration of the host's FQDN, and for the
unqualified hostname.

(2) Allow the specification of names in the [Network > Hostnames]
table with a trailing period.  If the period exists, then the dnsmasq
init script will not add the domain suffix.

(3) The dnsmasq init script might be tweaked to check the expandhosts
setting to determine whether the domain suffix should be appended to
an unqualified hostname.  Since this seems more like an OpenWRT issue
as versus a LuCI issue, I'm only mentioning it here for the sake of
completeness.

As I initially wrote, I'd be really curious about any thoughts on
this.  Thank you!

Hannes.


More information about the luci mailing list