Relationship between nslookup and hosts file.
Here is a strange one that I don't think I can quickly wrap my head around:
Peer-to-peer network with 3 inter-routed subnets with name service traffic between subnets.
IP addresses are static so we generally just use IP addresses for inter-subnet accesses.
We have one application that doesn't seem to be "used to" such networks.
So, we added a hosts file for the entire set of computers to that one workstation.
Presumably this helps the application and it's caused no problems.
Now that workstation can ping *names* across all 3 sites - with suitable Private network firewall rule scopes of course.
I now realize that nslookup doesn't work across these subnets *including* the local subnet.
It's obvious why. nslookup on each workstation is using an external DNS address entered on the NIC.
So, on the workstation in question, I added 127.0.0.1 as the first DNS address on the NIC.
And this is the workstation with a full hosts file.
We can still ping *names* across all 3 subnets from this workstation.
But, nslookup still won't resolve even the local subnet names.
So, in some sense, it appears that the hosts file isn't doing what we (or our quirky application) may expect.
It would be good if I understood the interplay between nslookup and the hosts file.
Any references you might suggest?
Peer-to-peer network with 3 inter-routed subnets with name service traffic between subnets.
IP addresses are static so we generally just use IP addresses for inter-subnet accesses.
We have one application that doesn't seem to be "used to" such networks.
So, we added a hosts file for the entire set of computers to that one workstation.
Presumably this helps the application and it's caused no problems.
Now that workstation can ping *names* across all 3 sites - with suitable Private network firewall rule scopes of course.
I now realize that nslookup doesn't work across these subnets *including* the local subnet.
It's obvious why. nslookup on each workstation is using an external DNS address entered on the NIC.
So, on the workstation in question, I added 127.0.0.1 as the first DNS address on the NIC.
And this is the workstation with a full hosts file.
We can still ping *names* across all 3 subnets from this workstation.
But, nslookup still won't resolve even the local subnet names.
So, in some sense, it appears that the hosts file isn't doing what we (or our quirky application) may expect.
It would be good if I understood the interplay between nslookup and the hosts file.
Any references you might suggest?
ASKER
noci: Thanks for the response!
Yet, I'm still confused by this.
If "applications" includes nslookup, then it isn't falling back to the hosts file as nearly as I can determine.
C:\Users\adm>nslookup
Default Server: UnKnown
Address: 127.0.0.1
C:\Users\adm>nslookup fredlb2
Server: UnKnown
Address: 127.0.0.1
*** UnKnown can't find fredlb2: No response from server
Taken from the workstation that HAS a hosts file and fredlb2 is another workstation that's on the list.
And the NIC DNS addresses start with 127.0.0.1
Yet, I'm still confused by this.
If "applications" includes nslookup, then it isn't falling back to the hosts file as nearly as I can determine.
C:\Users\adm>nslookup
Default Server: UnKnown
Address: 127.0.0.1
C:\Users\adm>nslookup fredlb2
Server: UnKnown
Address: 127.0.0.1
*** UnKnown can't find fredlb2: No response from server
Taken from the workstation that HAS a hosts file and fredlb2 is another workstation that's on the list.
And the NIC DNS addresses start with 127.0.0.1
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
OK. So now I can imagine that nslookup isn't good for anything but checking to see if a DNS server can resolve things. UNLESS, nslookup can be used by an application. In that case, if it is, then that application will be similarly limited.
Does that sound right?
Does that sound right?
Not really right.
"Normal" applications use the resolver library to translate names to IP addresses.
This library can be configured to use different "databases" to do the translation.
One of those databases is the "hosts" file.
The "nslookup" command is a utility to only query ONE specific database: the DNS server.
So you cannot use nslookuo as part of your application.
It is not a library you can link to your software when creating it, but a utility for testing DNS.
"Normal" applications use the resolver library to translate names to IP addresses.
This library can be configured to use different "databases" to do the translation.
One of those databases is the "hosts" file.
The "nslookup" command is a utility to only query ONE specific database: the DNS server.
So you cannot use nslookuo as part of your application.
It is not a library you can link to your software when creating it, but a utility for testing DNS.
The best test whether a hostname can be resolved is ping -n 1 -t 50 yourhostname, even if ICMP is blocked. That uses all available resolvers, and should behave like other applications.
The best test whether a hostname can be resolved is ping -n 1 -t 50 yourhostname, even if ICMP is blocked.
I don't think that syntax is correct in Windows, since -t doesn't accept a parameter.
Sorry. it should have been ping -n 1 -w 50 yourhostname.
nslookup is the old (limited) DNS query tool.
dig is a bit more modern / versatile, as it also can handle/verify DNSSEC and do some extended testing for validity of resolvability.
They both don't use the normal resolver library.
Regular applications (ping, your self written programs, windows net share , net use etc. etc. ) use the resolver library.
The resolver library is used by all kinds of programs. and the interface is gethostbyname() / gethostbyaddr() and family. (getnetwork...)
dig is a bit more modern / versatile, as it also can handle/verify DNSSEC and do some extended testing for validity of resolvability.
They both don't use the normal resolver library.
Regular applications (ping, your self written programs, windows net share , net use etc. etc. ) use the resolver library.
The resolver library is used by all kinds of programs. and the interface is gethostbyname() / gethostbyaddr() and family. (getnetwork...)
ASKER
it appears that dig works for external addresses. This issue is about internal addresses including on the same machine.
Perhaps I should elaborate:
I'm trying to access a http/https server running on the local machine using a browser.
So from the server itself:
https://localhost:port# this one works
or
https://127.0.0.1:port# this one works.
or
https://10.1.1.1:port# this one does NOT work (where 10.1.1.1 is the ip address of the server itself)
or
https://computername:port# this one does NOT work and it does not work from any computer on the same subnet; where computername is the name of the app server.
This is a peer-to-peer network with no AD. Yet, the software tech support folks seem to only trust AD-based systems.
I'm doubting that's the issue.
The machine is pingable by ip address or name.
nslookup of local addresses doesn't work throughout.
Perhaps I should elaborate:
I'm trying to access a http/https server running on the local machine using a browser.
So from the server itself:
https://localhost:port# this one works
or
https://127.0.0.1:port# this one works.
or
https://10.1.1.1:port# this one does NOT work (where 10.1.1.1 is the ip address of the server itself)
or
https://computername:port# this one does NOT work and it does not work from any computer on the same subnet; where computername is the name of the app server.
This is a peer-to-peer network with no AD. Yet, the software tech support folks seem to only trust AD-based systems.
I'm doubting that's the issue.
The machine is pingable by ip address or name.
nslookup of local addresses doesn't work throughout.
Dig and nslookup will both work for internal addresses, if there's an internal DNS server. They're both tools intended to troubleshoot DNS issues, though, and nothing more; they both need to be able to query a DNS server in order to be of any use. Since you mentioned that this is a peer-to-peer network, it doesn't sound like there is such a server in the environment.
I don't believe you've actually described the problem you're dealing with. You mentioned adding a hosts file to one workstation so that the workstation can resolve names of machines on the network, but it sounds like that's working. So what can we help with?
I don't believe you've actually described the problem you're dealing with. You mentioned adding a hosts file to one workstation so that the workstation can resolve names of machines on the network, but it sounds like that's working. So what can we help with?
ASKER
DrDave242: Did you see my last post? If not then it may answer some questions.
Anyway, we are finding that Windows name resolution and the Network list appears to be deprecated and is no longer reliable.
And, in order to address between subnets we have to use IP addresses instead of names anyway.
So, generally, I just use IP addresses and forego name resolution.
I asked this question because the tech support folks were a bit put off by the nslookup failure and I wanted to understand better.
The only DIG I found was a web interface. So I really didn't expect it to work for local addresses.
Is there a DIG app that can run locally?
Anyway, we are finding that Windows name resolution and the Network list appears to be deprecated and is no longer reliable.
And, in order to address between subnets we have to use IP addresses instead of names anyway.
So, generally, I just use IP addresses and forego name resolution.
I asked this question because the tech support folks were a bit put off by the nslookup failure and I wanted to understand better.
The only DIG I found was a web interface. So I really didn't expect it to work for local addresses.
Is there a DIG app that can run locally?
This looks more like an issue with no-one listening to the port for the real IP address, only for the loopback address. Did you check that with netstat-a -n | find "port" ?
you may have to make sure your NETBIOS Over TCP in enabled.
Much depends on what resources you have.
You can easily setup a DNS server how are the IPS allocated? It is possible for the DHCP server to register the IPs in name service...
distributing a hosts file when the IPs might change is ..
Much depends on what resources you have.
You can easily setup a DNS server how are the IPS allocated? It is possible for the DHCP server to register the IPs in name service...
distributing a hosts file when the IPs might change is ..
DrDave242: Did you see my last post? If not then it may answer some questions.
Ah, it is much clearer now. Somehow I missed that post entirely except for the first sentence. I think Qlemo is on the right track; from your description, the web service seems to be listening only on the loopback address and not the actual IP address of the machine. That will prevent any other machine from being able to access it, and it explains why you can't even access it from the local machine using that machine's actual address or its name.
The only DIG I found was a web interface. So I really didn't expect it to work for local addresses.
Is there a DIG app that can run locally?
There is, but it's not built into Windows and has to be downloaded as part of the BIND DNS server software. It's not going to help with your situation, though.
Make sure the web service is listening on the machine's actual address, as Qlemo said. That should take care of the immediate problem. Name resolution can absolutely work across subnets, but it really needs to be something centralized like DNS or the largely-obsolete WINS. This is probably one of the reasons why the tech-support folks prefer an AD environment: DNS is mandatory in AD, so as long as it's set up correctly, name resolution works throughout the domain.
only listening to localhost or 127.0.0.1 probably means your webserver has been configured to bind to 127.0.0.1 in stead of 0.0.0.0
So it will explicitly not listen to any other address. This is commonly done to prevent "unwanted" insecure access before proper configuration.
First get a few things straight:
IP is based on ip-addresses ONLY. names are completely irrelevant to IP, IPv6 etc.
Names are a later bolted on solution to help humans that think in symbols aka names.
So first get IP address working (that is basic webserver config)
Names are different whether you use hostfile/dns whatever.
[ with https names ARE relevant as those are needed in the certificates. Anything a browser uses to get to your server needs to match the subject in the certificate ]
So it will explicitly not listen to any other address. This is commonly done to prevent "unwanted" insecure access before proper configuration.
First get a few things straight:
IP is based on ip-addresses ONLY. names are completely irrelevant to IP, IPv6 etc.
Names are a later bolted on solution to help humans that think in symbols aka names.
So first get IP address working (that is basic webserver config)
Names are different whether you use hostfile/dns whatever.
[ with https names ARE relevant as those are needed in the certificates. Anything a browser uses to get to your server needs to match the subject in the certificate ]
ASKER
noci: Yes, I understand most of that. But the information regarding certificates is very likely a problem.
From what I understand you to say, there would need to be a certificate for each of:
127.0.0.1
localhost
10.1.1.1
computername
... for each of these to work.
In the end, the ONLY thing that's going to do the job is the IP address.
In reviewing the one existing certificate, the Subject is: computername.
Yet, that one doesn't work even locally.
From what I understand you to say, there would need to be a certificate for each of:
127.0.0.1
localhost
10.1.1.1
computername
... for each of these to work.
In the end, the ONLY thing that's going to do the job is the IP address.
In reviewing the one existing certificate, the Subject is: computername.
Yet, that one doesn't work even locally.
The certificate need only include references that commonly will be used to access the site.
Often, it would be just the computername
Subject alternate name is an option to include multiple references.
Often, it would be just the computername
Subject alternate name is an option to include multiple references.
The certificate would work if computername is what is mentioned in a broser.
if you specify in a browser: xyz (without a domain being specified...)
the translation to IP for xyz would be 1.2.3.4
and the system at address 1.2.3.4 would respond with a certificate nameing xyz yes computer name would be sufficient.
AND the certificate is signed by a trustworthy source (valid CA certificate from the localcal trusted store)
(The browser verifies the certificate it receives).
If there is a mismatch anywhere in the chain the certificate will not be trusted.
Any name you use in the browser for trying to connect must match. whether IP address or computername, servicename, including any domains....
if you specify in a browser: xyz (without a domain being specified...)
the translation to IP for xyz would be 1.2.3.4
and the system at address 1.2.3.4 would respond with a certificate nameing xyz yes computer name would be sufficient.
AND the certificate is signed by a trustworthy source (valid CA certificate from the localcal trusted store)
(The browser verifies the certificate it receives).
If there is a mismatch anywhere in the chain the certificate will not be trusted.
Any name you use in the browser for trying to connect must match. whether IP address or computername, servicename, including any domains....
ASKER
Right.
The whole chain is controlled by the software vendor and I doubt I'm going to be able to fix this alone.
I believe there's a certificate generator within the code on the local machine but it's not easily knowable.
I have a remote session with them tomorrow (again!).
Thanks for all the insights.
The whole chain is controlled by the software vendor and I doubt I'm going to be able to fix this alone.
I believe there's a certificate generator within the code on the local machine but it's not easily knowable.
I have a remote session with them tomorrow (again!).
Thanks for all the insights.
ASKER
Thanks all!!
Those routines used to use the hosts file (from long before DNS existed; 1970's 1980's), later DNS (and still later Multicast DNS) queries were added to the lookup methods.
On some systems also other lookup methods were introduced like using LDAP for name service translations.
So applications will use more recent methods first and fall back to older methodes ultimately falling back to the hosts file. ( default )
Although the lookup order can be established on f.e. Linux.
The hosts file works without specifying any address.
The only difference will be that by specifying 127.0.0.1 as a DNS server, your system will immediately return an ICMP port not available and thus prevents timeouts.
(not specifying any address should be a tad faster because it will not even attempt a lookup).
So 127.0.0.1 will resolve more quickly than any other system not having a DNS server, or even a non-existing server. If ICMP is blocked outside of your system the full timeout will be used on any query if an address has been specified.