On 4/14/2012 02:20, Mark Morgan Lloyd wrote:
waldo kitty wrote:
[...]
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.
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 ;)
[...]
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).
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...
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.
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)...
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
