I need to resolve a hostname to an IP address, to pass to a minimal telnet implementation that expects that as its parameter. The reason that I'm not using something "industrial grade" like Synapse is that I'm trying to restrict myself to standard libraries so that I can ship sources to people who have no FPC experience, making the program both useful and a good demonstration of the development tools.

If I use THostResolver.NameLookup I find that it can convert a fully-qualified name but not one where the domain is omitted, I notice that the README specifically says that resolv.conf isn't fully parsed. Unfortunately I find (2.6 on Debian "Squeeze") that GetDomainName returns nothing useful- I've not yet investigated whether that's down to a particular development system but if it happens to me it might happen to others.

In short, how best should I work around this?

In our previous episode, Mark Morgan Lloyd said:

a particular development system but if it happens to me it might happen to others. In short, how best should I work around this?

Have a look at unit cnetdb.pp in fcl-net package.

Thanks Marco, now working. I see I've used that elsewhere in the past... I rather loathe those return structures :-)

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...

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...

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.

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 (192.168.1.22) 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 wrote

waldo kitty wrote:

[...]

no... it is different than that... i have never used bind or "zone files"... this issue exists and is especially notable with winwhatever boxen...

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 should have included better examples, i guess... nslookup easily shows this problem when it happens... part of it has to do with the way a client _machine_ is configured... ie: is there a default domain suffix defined in the dns configuration?

as for the trailing dot, as i wrote before, it signals that there are no more TLDs to look at... if ralf quint is on this list, he can definitely provide more info and better examples... we both work with the same FOSS firewall software ;)

[...]

ahhh...

Connecting to pye-dev-07 failed, but its IP address (192.168.1.22) 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.

now /that/ is much better for understanding the problem... in the above, pye-dev-07 is the host name so the DNS server(s) you were querying needed to know that this was a local LAN host OR you needed to provide the FQDN...

AHHH... so *that's* what you meant about "resolv.conf not being fully parsed"... ok... yes, this is similar to what i mention above about domain suffixes to add and try looking up...

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.

not sure about that on windows... i just did a search in this w2k box... because it is different than my previous w98 box... the hosts file is found in %systemdir%/drivers/etc where on w98 it was found in %systemdir%... there is no resolv* found anywhere in my OS base directory... i also have this machine configured for pseudo-static IP assignment via DHCP so all address, gateway and DNS settings come from my DHCP server which just happens to be my main firewall box... that box is specifically configured to set a DNS suffix of my internal LAN domain TLD for all lookups with one or less dots in the name ie: foo and foo. both return the same IP... foo. returns just the name as given with the IP and foo (without the dot) returns the name with the domain suffix added and the same IP as foo. returns...

[quote]
Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\Documents and Settings\user>nslookup darkstar
Server: perseus
Address: 192.168.42.1

Name: darkstar.wpusa
Address: 192.168.42.22

C:\Documents and Settings\user>nslookup darkstar.
Server: perseus
Address: 192.168.42.1

Name: darkstar
Address: 192.168.42.22
[/quote]

i get the same output on my *nix boxen, as well...

does this make sense and/or help any at all? it may be that some portion of your problem comes from a partially configured DNS setup on the client end of things (ie: the default domain suffix to add) but it may also extend to the DNS server as well if it is not configured to return proper responses for these lookups... in the past, i have seen local lookups traversing to the WAN and lookups being attempted out there that should never have left the LAN... there are many thousands of networks that erroneously do this which leads to the leaking of internal machine names and possibly roles (determined by the name)...

waldo kitty wrote:

[...]

Bear in mind that files of that type are very much optional on Windows, a sop to those who demanded them in order to implement things like innd so they could claim it was as good as Unix. My experience is that the nameserver addresses are available from the Windows registry if configured statically, I suspect- but I've not checked and aren't going to- that that sort of thing will be copied into the registry if it arrives using DHCP.

[...]

No. The issue is solely that resolve.pas doesn't refer to the searchpath (no criticism intended), this is explicitly noted in fcl-net's readme file. For unqualified lookups on unix you need to use cnetdb, i.e. go via libc, or parse resolv.conf in application code.

The synapse library has in synamisc.pas function GetDNS: string; which returns all DNS servers known on the system (windows or unix). It uses on windows the GetNetworkParams api function from IPHlpAPI.lib and, if not succesfull, tries the windows registry.

Ludo

I'd have used Synapse if this were a program of any significance. However as it is it's purely a demo, and in case any of the target audience tries to recompile it I've specifically avoided anything non-standard (I'm using FPC's ltelnet, but since that isn't in the search paths by default I've copied it into my own source).

A later version might use something like cmdline in order to support coloured text, but I'll probably make that optional so that the base configuration will still compile.