<div dir="ltr"><br><br><div class="gmail_quote">On Tue, Aug 5, 2008 at 1:46 PM, Simon Kelley <span dir="ltr"><<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><a href="mailto:richardvoigt@gmail.com">richardvoigt@gmail.com</a> wrote:<br>
> On Mon, Aug 4, 2008 at 9:04 AM, Simon Kelley <<a href="mailto:simon@thekelleys.org.uk">simon@thekelleys.org.uk</a>>wrote:<br>
><br>
>> I have support for multiple domains working, but I've come across a<br>
>> wrinkle.<br>
>><br>
>> Consider the case that two different DHCP clients claim the same name.<br>
>> With the existing code, only one can have it and the current behaviour<br>
>> is that when a second machine claims a name, the first one loses it.<br>
>><br>
>> Now, consider the possibility that the two machines claiming the same<br>
>> name are in different domains. By default, the existing behaviour must<br>
>> continue, because the unqualified name is added to the DNS, so that even<br>
>> though the two clients could have "<a href="http://name.domain1.com" target="_blank">name.domain1.com</a>" and<br>
>> "<a href="http://name.domain2.com" target="_blank">name.domain2.com</a>", they are still fighting over just plain "name".<br>
>><br>
>> It would be possible to introduce a new mode, which didn't put the<br>
>> unqualified name into the DNS, and allowed both hosts to keep their name<br>
>> as long as they are in different domains. Would that be useful, or just<br>
>> an confusing complication?<br>
><br>
><br>
> Would it be possible to track the domain, while still responding to the<br>
> unqualified name (perhaps a CNAME, or perhaps just track internally). Then<br>
> when the name was claimed a second time, the entry would be marked invalid<br>
> and no further responses would be sent.<br>
<br>
</div>It would: it would need a fair bit of thinking to make sure it always<br>
behaved.</blockquote><div><br>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.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<div class="Ih2E3d"><br>
><br>
> Or, if you choose a mode with no unqualified names, consider allowing<br>
> dotless names from /etc/hosts<br>
</div>dotless names from /etc/hosts is fine: that's not affected.<br>
<div class="Ih2E3d"><br>
>and the config file to still be resolved.<br>
</div>From dhcp-host lines is not there at the moment.<br>
It may be possible, but what happens when two hosts get a dotless name<br>
from dhcp-host lines?</blockquote><div><br>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.<br>
<br>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.<br>
<br>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 valid scenario.<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><br>
<br>
Of course the search facility in the resolver should fix this.....<br>
<br>
<br>
Cheers,<br>
<font color="#888888"><br>
Simon.<br>
<br>
<br>
</font></blockquote></div><br></div>