[Dnsmasq-discuss] multiple domain support - question
richardvoigt at gmail.com
richardvoigt at gmail.com
Wed Aug 6 06:16:31 BST 2008
On Tue, Aug 5, 2008 at 1:46 PM, Simon Kelley <simon at thekelleys.org.uk>wrote:
> richardvoigt at gmail.com wrote:
> > On Mon, Aug 4, 2008 at 9:04 AM, Simon Kelley <simon at thekelleys.org.uk
> >> I have support for multiple domains working, but I've come across a
> >> wrinkle.
> >> Consider the case that two different DHCP clients claim the same name.
> >> With the existing code, only one can have it and the current behaviour
> >> is that when a second machine claims a name, the first one loses it.
> >> Now, consider the possibility that the two machines claiming the same
> >> name are in different domains. By default, the existing behaviour must
> >> continue, because the unqualified name is added to the DNS, so that even
> >> though the two clients could have "name.domain1.com" and
> >> "name.domain2.com", they are still fighting over just plain "name".
> >> It would be possible to introduce a new mode, which didn't put the
> >> unqualified name into the DNS, and allowed both hosts to keep their name
> >> as long as they are in different domains. Would that be useful, or just
> >> an confusing complication?
> > Would it be possible to track the domain, while still responding to the
> > unqualified name (perhaps a CNAME, or perhaps just track internally).
> > when the name was claimed a second time, the entry would be marked
> > and no further responses would be sent.
> It would: it would need a fair bit of thinking to make sure it always
I don't think there's any need for the last remaining address to start
responding to queries when all other leases expire. Such behavior would be
well-nigh undeterministic and confuse users. Just log "name 'xyz' in
contention, returning no results". Once a name becomes contended, it stays
that way. You could have a reference count on contended names so that they
don't become a permanent fixture in memory for long-running instances, but I
doubt that would be much of a problem either.
> > Or, if you choose a mode with no unqualified names, consider allowing
> > dotless names from /etc/hosts
> dotless names from /etc/hosts is fine: that's not affected.
> >and the config file to still be resolved.
> From dhcp-host lines is not there at the moment.
> It may be possible, but what happens when two hosts get a dotless name
> from dhcp-host lines?
Error (or warning, ignoring conflicting entries) while processing the
config, force the admin to change the names to fully qualified, leaving at
most one dotless, so there's no ambiguity. Maybe there's a need for a
syntax for specifying aliases in dhcp-host lines, just like you can have
multiple names on a single line in /etc/hosts. That way someone using
multiple domains would give every dhcp-host a FQDN, and set up an alias for
the one intended to be seen as a bare name.
If people want the questionable behavior of having their notebook receive
the same name whether connected wireless or wired, they'd need a dhcp-host
or /etc/ethers entry to map the MAC address to IP address, and an /etc/hosts
entry to map the name to the IP address. The name would not be placed in
multiple dhcp-host entries. From previous postings to the mailing list,
this scenario seems to be very troublesome anyway.
I think anything that breaks under the new rules would be broken under the
old, and I can probably give examples of how it breaks. Only now such
breakage would be reported at dnsmasq startup. But maybe I missed some
> Of course the search facility in the resolver should fix this.....
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Dnsmasq-discuss