[fpc-pascal] Resolving a local hostnames to an IP address

Mark Morgan Lloyd markMLl.fpc-pascal at telemetry.co.uk
Sat Apr 14 08:20:59 CEST 2012

waldo kitty wrote:
> On 4/13/2012 04:54, Mark Morgan Lloyd wrote:
>> If I use THostResolver.NameLookup I find that it can convert a 
>> fully-qualified
>> name but not one where the domain is omitted,
> can you explain this a bit more, please? the reason i ask is because 
> some code wants at least one dot separator...
> example:
> foo.bar  -- .bar is the TLD and foo is the hostname
> foo.bar. -- the last dot says this is the end, do not look to other domains
> so...
> foo      -- may result in other domains being automatically looked up by
>             stuffing known TLDs after it ie: foo.com, foo.net, foo.org...
> *BUT*
> foo.     -- says there is no more domains to look at... so effectively one
>             is looking for only the LAN name which should be easily served
>             up by the LAN DNS server or the HOSTS file...
> some systems need the trailing dot and others do not... i've seen this 
> problem for years and it seems to be limited to some OS' to a certain 
> extent...

That issue IME is specifically at the server, i.e. you've got to be 
careful with your DNS zone files. Cf the cricket book. I've not checked 
what the RFCs have to say about trailing dots at the client or in the 
client protocol, IMO strictly they're an error.

>> I notice that the README specifically says that resolv.conf isn't
>> fully parsed.
> in the above, i'm speaking purely from a network admin/tech/specialist 
> POV... i work with a FOS firewall product and this is quite a common 
> problem IF what i'm thinking it is is correct...
> sadly i've not (yet!) the coding knowledge in this area to be able to be 
> more specific or of more help :?
> the main point is that many do not know about the use of the trailing 
> dot to denote that there are no other domains to append in an attempt to 
> locate the given hostname...
> clarification:
> foo.bar     -- foo is the hostname, bar is the TLD...
> foo.bar.com -- foo is the hostname, bar is a SLD, and com is a TLD...
> foo.        -- says look up "foo" only...
> foo.bar     -- says look up "foo.bar" first and maybe other TLDs behind...
> foo.bar.    -- says look up "foo.bar" and don't look up more than that...
> i hope this makes sense and is of some assistance...

The point is that I was knocking together a demo terminal emulator 
(using non-standard coding etc.) that communicates using telnet, and I'd 
copied over the ltelnet library that requires (a string containing) an 
IP address as its parameter. Communicating with localhost worked, but 
rather late in the day I discovered that I was unable to set up a 
connection with named servers (i.e. DNS lookups were failing). This 
applies to Linux, I've not checked the Windows situation (there are 
other things that might not work such as keycodes, so porting isn't very 
high on my list).

Connecting to pye-dev-07 failed, but its IP address ( was 
OK. Qualifying the name manually so that it read 
pye-dev-07.telemetry.co.uk worked, but trying to get the domain name 
using GetDomainName didn't.

The unix /etc/resolv.conf file (normally on each client) has a line for 
search paths, which are suffixes to be applied to a name if it doesn't 
immediately match. The libc lookup implementation, wrapped in cnetdb, 
uses this, while resolve.pas doesn't. The file can also specify a domain 
although this is rarely used, it might be that this is what 
GetDomainName refers to.

I've ended up using a hybrid approach: first well-known names such as 
localhost and lo, then THostResolver, then cnetdb, with the possible 
fallback of parsing resolv.conf for cases where libc isn't available. If 
I look at porting to Windows I'll probably have to consult the registry 
in lieu of resolv.conf.

Mark Morgan Lloyd
markMLl .AT. telemetry.co .DOT. uk

[Opinions above are the author's, not those of his employers or colleagues]

More information about the fpc-pascal mailing list