[syslinux] [Etherboot-developers] gPxe functionality in pxelinux

[Kevin Landreth]

On Thu, Nov 27, 2008 at 9:21 AM, Kevin Landreth
<crackerjackmack at gmail.com>wrote:

> On Thu, Nov 27, 2008 at 3:26 AM, Stefan Hajnoczi <stefanha at gmail.com>wrote:
>
>> > Is there any way to get it to honor the 'domain-name' setting from DHCP
>> and do a dns search like the libc resolver does for resolv.conf ?
>>
>> The following patch appends the DHCP Domain Name setting to relative
>> names.  Any name with one or more "." is considered qualified and is
>> not affected.
>>
>> DNS experts, please advise whether this is correct!  Pointers to the
>> relevant RFCs or source appreciated.
>> [snip]
>>
>>
> Thanks for the patch but I believe the behavior isn't quite as expected.
> It only works in one case where a host with no '.' (dots) is appended with
> <domain-name>.
>
> The behavior should be as follows
>
>    1. Attempt to resolve hostname
>    2. NXDOMAIN response, and only NXDOMAIN,
>    1. Does <domain-name> from DHCP exist?
>          1. If so, append <domain-name> from DHCP settings, if it exists
>       2. If not, goto 4
>       3. re-attempt to resolve the domain name
>    4. fail if not found (not just NXDOMAIN, any DNS failure)
>
> Here is a case where the current patch would not behave as expected:
>
> kernel http://repo-server.development/path/to/kernel
> wouldn't be appended with the localized DHCP setting of <domain-name> =
> dllstx03.internal.bigcorporation.net
>
> I've seen this setup in many places, though not related to net booting, but
> how clients work and expect the environment to behave.  True that this might
> not be the most optimal setup but it is what it is :(
>
> --
> Kevin Landreth, RHCE
>
>

I should also note that the current behavior IS correct, just limited in
scope :)  This method suggested would cover both cases and you can't assume
no dots is not a FQDN http://com/  is valid, technically.

-- 
Kevin Landreth, RHCE