[Dnsmasq-discuss] Getting dnsmasq to serve fqdns as the hostname

Alex Kiernan alex.kiernan at gmail.com
Thu Oct 23 16:49:03 BST 2008


On Fri, Oct 17, 2008 at 9:55 PM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> Alex Kiernan wrote:
>>
>> On Wed, Oct 15, 2008 at 9:38 PM, Simon Kelley <simon at thekelleys.org.uk>
>> wrote:
>>>
>>> Alex Kiernan wrote:
>>>>
>>>> On Tue, Oct 14, 2008 at 3:07 PM, Simon Kelley <simon at thekelleys.org.uk>
>>>> wrote:
>>>>
>>>>> Alex Kiernan wrote:
>>>>>
>>>>>> On Tue, Oct 14, 2008 at 1:58 PM, Simon Kelley
>>>>>> <simon at thekelleys.org.uk>
>>>>>> wrote:
>>>>>>
>>>>>>> Alex Kiernan wrote:
>>>>>>>
>>>>>>>> I'm trying to use dnsmasq to serve DHCP/DNS for a Solaris network
>>>>>>>> install server (jumpstart). It works perfectly and the DNS/DHCP
>>>>>>>> integration means that lots of the traditional problems go away (the
>>>>>>>> problem is that the Solaris installation procedure won't setup DNS
>>>>>>>> as
>>>>>>>> the name service unless you already have DNS for the machine you're
>>>>>>>> building in place).
>>>>>>>>
>>>>>>>> dnsmasq works absolutely perfectly for this, with one minor problem
>>>>>>>> -
>>>>>>>> I need to serve an FQDN in the hostname option; if I feed this to
>>>>>>>> dnsmasq in a dhcp-host then unless my domain setting matches it
>>>>>>>> rejects it, and even then it strips it to the basename. If instead I
>>>>>>>> force through an option 12, whilst it serves the FQDN, it doesn't
>>>>>>>> update the DNS so the DNS checks fail later in the install.
>>>>>>>>
>>>>>>>> At the moment I'm working around it by removing the section of code
>>>>>>>> from check_dhcp_hosts which enforces the domain/fqdn
>>>>>>>> matching/stripping behaviour, but is there another way? Or another
>>>>>>>> way
>>>>>>>> which I could implement which is cleaner?
>>>>>>>>
>>>>>>> If you explicitly send the FQDN as option 12, set the basename (using
>>>>>>> dhcp-host) _and_ set the domain in dnsmasq to the correct value, I
>>>>>>> think
>>>>>>> that will do what you want assuming I've understood correctly that
>>>>>>> you
>>>>>>> want
>>>>>>> to
>>>>>>>
>>>>>>> 1) Send the FQDN as option 12
>>>>>>> 2) have the FQDN resolve in DNS to the IP address allocated.
>>>>>>>
>>>>>> Yeah, I should have mentioned that combo - it does exactly what I
>>>>>> need, but only for one domain, whereas I need it to work for many
>>>>>> domains (as I want this box to act as a jumpstart server across many
>>>>>> different hosts). If domain could be scoped with a tag that'd do what
>>>>>> I need (or even just support multiple maybe?)
>>>>>>
>>>>> That (domain scoped with a tag) is a long-standing feature request
>>>>> which
>>>>> is
>>>>> impossible to do in a backwards compatible way. See this list passim
>>>>> for
>>>>> the
>>>>> gory details.
>>>>>
>>>>> HOWEVER, the next best thing (domain based on subnet or IP address
>>>>> range)
>>>>> is
>>>>> available at the bleeding edge. Try
>>>>>
>>>>>
>>>>> http://thekelleys.org.uk/dnsmasq/test-releases/dnsmasq-2.46test15.tar.gz
>>>>>
>>>>
>>>> Thanks - I've had a play and it doesn't really do what I want as
>>>> whilst I have some networks which have one domain on a subnet, we have
>>>> others where we end up with a bunch of machines in differing domains.
>>>>
>>>> Is there a good way to go about adding FQDN hostname functionality[1]?
>>>> If I could just add that one feature it'd do exactly what I need (when
>>>> coupled with the dhcp-fqdn option).
>>>>
>>>> [1] which I'm happy to do and send you the diffs.
>>>>
>>> The problem is that the format of the leases file is fixed to contain a
>>> non-fully qualified domain, and no domain field. To work, dnsmasq has to
>>> be
>>> able to determine the FQDN of a host using just the information in the
>>> leases file. Hence the new arrangement, which allows the domain to be
>>> derived from the IP address.
>>>
>>> To allow arbitrary domains means breaking the lease file format, which I
>>> don't want to do.
>>>
>>> Presumably, you add some configuration for each new host that you
>>> install,
>>> if that consists of something like
>>>
>>>
>>> dhcp-host=<mac address>,<IP address>,<bare name>,net:<FQDN>
>>> dhcp-option=net:<FQDN>,12,<FQDN>
>>> domain=<domain-fromFQDN>,<IP>,<IP>
>>>
>>
>> Pretty much - a complete (Sparc) example is this:
>>
>> dhcp-host=01-0:3:ba:12:c6:21,192.0.2.165,net:010003BA12C621,"target"
>> domain=example.com,192.0.2.165/32
>> dhcp-option=010003BA12C621,12,"target.example.com"
>> dhcp-option=010003BA12C621,vendor:SUNW,11,"jumpstart.example.com"
>> dhcp-option=010003BA12C621,vendor:SUNW,10,192.0.2.166
>>
>> dhcp-option=010003BA12C621,vendor:SUNW,12,"/export/install/sol_10_508_sparc"
>> dhcp-option=010003BA12C621,vendor:SUNW,3,"jumpstart.example.com"
>> dhcp-option=010003BA12C621,vendor:SUNW,2,192.0.2.166
>>
>> dhcp-option=010003BA12C621,vendor:SUNW,4,"/export/install/sol_10_508_sparc/Solaris_10/Tools/Boot"
>> dhcp-option=010003BA12C621,vendor:SUNW,14,"192.0.2.166:/jumpstart"
>>
>> dhcp-option=010003BA12C621,vendor:SUNW,13,"192.0.2.166:/jumpstart/010003BA12C621"
>>
>> dhcp-boot=net:010003BA12C621,"010003BA12C621","jumpstart.example.com",192.0.2.166
>>
>>> then that should work, domains don't have to be over whole subnets, just
>>> defined by IP address.
>>>
>>
>> I was trying to avoid having to do static IP configuration at build as
>> even though that's the final config I need for most boxes, there are
>> some places where we have jumpstart servers on workstation networks
>> which are largely DHCP based; but thinking about it, on those networks
>> I'm constrained to using ISC DHCP anyway.
>>
>> So next question... is adding support for dhcp-bootfile (to supply
>> multiple dhcp-boot options) and domain-file (to supply multiple domain
>> entries) as easy as it looks it ought to be? I'm happy to hack it in,
>> just wanted to make sure I wasn't opening a can of worms first!
>
> You can supply multiple dhcp-boot options (with different net tags) is the
> standard configuration file, or another file included from it. The only
> extra that the dhcp-hostfile approach gives is the ability to re-read the
> file without re-starting dnsmasq. For most applications, re-starting dnsmasq
> is preferable (its always fast)
>
>  The only difficult  part of hacking in this stuff is making sure that
> exiting records are garbage-collected and freed properly before re-reading.
>

Yeah, in the end I decided to just restart it.

>> Sorry, one last question - is there a way to stop dnsmasq sending a
>> router option for a network?
>>
>
> Yes, for options which are send automatically, specifying an empty option
> suppresses this :
>
> dhcp-option=net:<tag>,3
>
> or
>
> dhcp-option=net:<tag>,option:router
>

Thank you!

-- 
Alex Kiernan



More information about the Dnsmasq-discuss mailing list