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

[Stefan Hajnoczi]

Thanks for your feedback hpa.  I believe the current patch is already
useful but am happy to implement the more full-featured behavior
described by Kevin.

Marty and Michael: do you have any preferences on this issue?  Perhaps
we really do want to keep it minimal like hpa suggests to limit bloat?
 There is no standard here anyway.

A "qualifying DNS" resolver could be implemented as an optional gPXE
resolver.  Stripped down builds would only compile in the existing
"DNS" resolver, whereas full-featured builds would additionally
compile in the "qualifying DNS" resolver.  The "qualifying DNS"
resolver appends the local domain as appropriate and delegates to the
existing "DNS" resolver (as a child resolver like the mux resolver
code in core/resolv.c).

BTW resolv.conf(5) on Linux explains their resolver's behavior.  In
particular the ndots option "sets a threshold for the number of dots
which must  appear  in  a  name [...] before  an initial absolute
query will be made".  The default value for ndots is 1.

This produces the familiar behavior:
host1 -> host1.localdomain

host1.sub -> host1.sub
               -> host1.sub.localdomain

Stefan

On Thu, Nov 27, 2008 at 7:25 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> Stefan Hajnoczi wrote:
>>>
>>> Thanks for the patch but I believe the behavior isn't quite as expected.
>>
>> Thanks for explaining and giving a valid example.  Is there a
>> definitive reference (an RFC?) which describes the resolver algorithm?
>>
>>> This method suggested would cover both cases and you can't assume
>>> no dots is not a FQDN http://com/  is valid, technically.
>>
>> I don't agree with this point.  The name "com" is not absolute.  I
>> think you mean "com." which is rooted and absolute.
>> [http://tools.ietf.org/rfc/rfc1535.txt]
>
> Under that logic, *none* of the names in common use are absolute
> (example.com should really be example.com.).  The search algorithm for
> non-rooted pathnames is considered system-specific, but a non-rooted FQDN is
> obviously expected to work.  There has been a very small number of valid
> single-stanza FQDNs ("va" was valid for a while), but they are few and far
> between, and you can deal with them by adding a dot - "va."
>
> So I think what you have is perfectly fine for a boot loader, certainly.
>
>        -hpa
>