Topic: SME won't resolve a particular domain

[Kelvin]

Hi everyone,

I've got a strange one here. I cannot get a consistent outcome when trying to access a particular domain (iproperty.com.au) for machines behind an SME Server.

At site 1 :
Originally connected via dial-up modem now connected via ADSL from a different ISP (both times, the modem and ADSL modem are connected to the SME server).
Trying to bring up www.iproperty.com.au page is intermitten at best. Pinging the address is also intermitten, sometimes it works, other times the name will not resolve (unknown host). Yet, the host is alive because you can ping the IP address each time even when you cannot ping the name.

At site 2 :
Connected via cable (again a different ISP altogether) and SME server as gateway as well. Same problem as at site 1. Strangely, sometimes when pinging the name www.iproperty.com.au from an XP workstation it resolves even though pinging from a command console of the SME server will not resolve the name !??

As and when the page does load, clicking on some of the links generally results in an error page stating that there is no DNS record.

Yet, when using a NAT router box to replace the SME servers (or if dialing directly from a modem attached to a workstation), the website (as well as pinging the name) always works (very quickly too I might add). There are no known problems accessing any other site that I know of, just this domain. The SME servers are not set to use any Master DNS servers (as I was under the impression that the SME servers can query the root servers themselves and should be able to find *anything* that any other internet account can)

Any ideas ? TIA !

Kelvin

[Bill Talcott]

Interesting. It works fine for me through our SME 5.0U6, but not if I use its proxy server. Perhaps a squid bug?

[Kelvin]

G'Day Bill,

Hmm.... Does ping make use of squid as well ? I did not think it did. Remember I have intermitten results from ping as well, not merely browsing. The error appears to be related to DNS not being able to resolve the name.

This client currently only runs SME at the head office (where the problem was encountered). However, they have a number of branch offices which were originally planned for SME rollouts as well, which is currently on hold because of this problem.

The second site I tested from is my own and all the problems they appear to be facing is also happenning here. The only thing that's the same in both cases is the SME 5.1.2 servers (fully patched and up to date with blades, etc). I have confirmed here and from speaking with staff from the other site offices that if we connect directly to the net either by direct dialing or via some kind of NAT box (as is currently used at some site offices), the problem does not appear.

Tech support at iproperty basically says it has nothing to do with them and the problem must be at the clients' end. I hate to admit it but given the current information at hand, I have to agree.

Any ideas ?

Kelvin

[Kelvin]

Here's another bit of info from further testing.

The client site also has a W2K Server. The server is setup to use itself as a DNS server and not the SME server like the rest of the workstations. The server has no problems accessing the iproperty sites whatsoever. I will need to reconfigure the workstations to use the W2K server as their DNS server and test them to see if they can access iproperty after that.

Unfortunately, I don't have a W2K server here myself at the moment to test and confirm this. If this checks out, then I would say almost certainly that I have hit a bug (phew ! there I said it !).

Kelvin

[Bill Talcott]

In either 5.1.2 or 5.5, transparent proxying with squid was added. I have no idea what is and isn't handled by squid, but it always seems to work fine here without the proxy enabled in the browser, but always not work with the proxy enabled.

Right now, with the proxy enabled, I can't browse to it. However, I can ping it from a DOS prompt just fine. Squid reports this error:

The following error was encountered:

Unable to determine IP address from host name for iproperty.com.au
The dnsserver returned:

No DNS records
This means that:

 The cache was not able to resolve the hostname presented in the URL.
 Check if the address is correct.

but http://216.14.200.162/ works fine. It also works fine as soon as I disable the proxy in IE.

It's definitely weird, but it looks like something with squid and DNS to my untrained eye, at least here on 5.0U6.

[Kelvin]

Hi Again Bill,

Thanks for keeping on this.

> but it looks like something with squid and DNS

Agreed.

I knew that 5.1.2 had transparent proxying enabled. However, because the errors being reported appears to imply that the name was not visible to DNS, I assumed it was a DNS problem rather than squid. Also, because ping did not work and again, I am assuming that ping does not go through squid, that it was more a DNS issue than squid. In my last post, the W2K server also needs to go through SME as a gateway to the net but it uses its own DNS server instead of the one on SME. The W2K server does not have any problem accessing the domain / site. One workaround at this site would probably be to reconfigure the LAN Workstations to use the W2K Server's DNS instead of SME's but this is not the end solution as the remote offices that were intended for SME rollouts will not have a W2K Server to do the same.

Kelvin

[Nate]

I can't ping it from my sme 512 box as well.  I found a thirdparty dns search site below, and the results.  It seems the site/their dns server is having some dns troubles, not your server.  Anyone else have similiar results?  I also noticed it doesn't have a reverse dns.  

http://demo.freshwater.com/SiteScope/cgi/go.exe/SiteScope?page=DNS&host=&misc=&group=&account=administrator
*** Request to ns2.freshwater.com timed-out
Server:  ns2.freshwater.com
Address:  206.168.112.53
DNS request timed out.
    timeout was 2 seconds.

Total time: 2.04 seconds

What is odd is that if I do a traceroute on that same site it will find the correct ip address.  Maybe the dns server is slow to respond and e-smith(and other dns servers) time-out waiting for a response?  I really don't know, as I'm far from a dns expert.

[Kelvin]

Interesting theory Nate.

The thing that doesn't add up is, if their DNS server really is slow to respond, it should affect any and all attempts to connect to it, not just the SME servers. Direct dial ups and simple NAT boxes don't have any problems accessing it and neither does the W2K server sitting behind the SME server but not using SME as the DNS server.

Kelvin

[Kelvin]

Hi all,

Would anyone who isn't in Australia mind testing the following for me ?

If you have a direct dial up account with an ISP, could you dial in from any Windows PC (direct, without going through the SME 5.1.2 server) and see if you can bring up the www.iproperty.com.au site and also ping it ? Then post the results here ?

Much appreciate any time spent on this test.

Cheers,

Kelvin

[John]

Kelvin wrote:
> Would anyone who isn't in Australia mind testing the
> following for me ?
>
> If you have a direct dial up account with an ISP, could you
> dial in from any Windows PC (direct, without going through
> the SME 5.1.2 server) and see if you can bring up the
> www.iproperty.com.au site and also ping it ? Then post the
> results here ?

Pingable and viewable from NZ

Cheers,
 John

[Cyrus Bharda]

Loads up fine and ping gives:

Pinging www.iproperty.com.au [216.14.200.162] with 32 bytes of data:

Reply from 216.14.200.162: bytes=32 time=189ms TTL=244
Reply from 216.14.200.162: bytes=32 time=164ms TTL=244
Reply from 216.14.200.162: bytes=32 time=139ms TTL=244
Reply from 216.14.200.162: bytes=32 time=134ms TTL=244

Ping statistics for 216.14.200.162:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 134ms, Maximum =  189ms, Average =  156ms

from QLD,

Cyrus Bharda

[Kelvin]

Thanks John and Cyrus.

I'll explain.

I reported this as a possible bug to bugs@e-smith.org. The reply I got from Charlie Brady was that this was likely a DNS configuration error of the domain holder (ie. iproperty.com.au) and that there is nothing that can be done about it.

The problem I have with this explanation is :-
1. Direct dialling an ISP always allows access to the domain and web site
2. Using ordinary NAT boxes also allows access
3. A Win2000 Server behind an SME 5.1.2 server have access to the domain as long as the W2K server does *not* use the SME 5.1.2 as its DNS server. The W2K server can set itself up as its own DNS server and it works fine even though it is behind the SME server provided it does not use the SME server as its DNS server.
4. Any workstation on the LAN behind the SME 5.1.2 server using SME as their DNS server cannot access the domain (or only have intermitten access at best).

If it is a DNS configuration error at iproperty's end, wouldn't it mean all other access means also will have problems ? Can it be that SME's DNS is inferior to the W2K server's (heaven forbid !) ? Or is it just a bug as I originally suspected ? I am by no means a DNS expert and am merely trying my best to get to the bottom of this issue.

Does anyone have any ideas on this ?

Kelvin

[Cyrus Bharda]

I had a similar problem with W2k and SME. What I did was to keep the W2k as the domain controller (because it was that pre SME) and setup a forward lookup zone in the active directory to the SME box. So that way I left all the clients on the LAN set to use the W2k box as DNS, but set the gateway to the SME box, (set this up in the DHCP part of AD because we are using DHCP on our LAN) that way the client uses the W2k box for dns resolution, and the W2k box uses the SME box for dns resolution and everything works dandy .

Cyrus Bharda

[Kelvin]

Thanks Cyrus.

As mentioned in my earlier post, I could do that for one site but the other sites don't have a W2K server handy ......

Kelvin

[Cyrus Bharda]

Have you tryed using you ISP's DNS servers at site 2, there are some free/public dns servers around, a search on google will find some. But still I use Optus@Home cable with SME 5.5 and havent had a problem with it

Cyrus Bharda

[Kelvin]

I did think of it but one thing that stopped me from doing it was the description on the configuration page which says :

Specify an address here if there is a firewall beween this server and the internet (not in this case), or if another DNS server resolves local addresses on your LAN.

I would not want all local address queries to end up going out to the ISP and then back again. On a slow link, this could be a killer.

Kelvin

[Cyrus Bharda]

We have it setup that way here at work and we rarly have usage above the 700MB/month range, thats with 160 people using http/ftp/email, on a dial-up 56k modem connection, so for me its not really much.

Cyrus Bharda

[Kelvin]

Hi Cyrus,

It's not the usage - it's the fact that any DNS lookups, etc. might need to go to the ISP's DNS server and fail before looking locally. I was asked to fix a network problem once for another company and tracked the problem to this issue (although they were using W2K servers instead of SME servers) ... another story for another day.

Kelvin

[Kelvin]

Unconvinced and not satisfied that the problem lies with iproperty's DNS settings (I mean, just look at all the symptoms and evidence - if only SME 5.1.2 can't find it but *everything* else can, how can it be anyone else's fault but SME's ??), I tried a few experiments.

1. I setup a new SME 5.6 beta server. Hooked it up to a dial up connection. Hooked up my laptop to it as a client. Fired up the connection. Tried www.iproperty.com.au -> works first go. Ping www.iproperty.com.au also works first go.

2. Reformatted the HDD and reloaded SME 5.1.2. Hooked up the connection as before. Tried www.iproperty.com.au -> cannot find. Ping www.iproperty.com.au -> unknown host.

3. Downloaded latest bind I could find for Redhat 7.1 (bind-9.2.1-0.71.1.i386.rpm and the corresponding bind-utils rpm). Installed them into the SME 5.1.2 server using rpm -Uvh *.rpm, rebooted, connected again, found a slight problem (see later) and tested www.iproperty.com.au -> worked first go. Ping also worked first go.

So, apparently, there must be a problem with the version of bind installed in SME 5.1.2. Now for the problems encountered.

After installing the updated bind packages and rebooting, I found that named did not start up automatically, resulting in no DNS resolutions at all. I had to manually start named with the command :-

service named start

After running a few minutes, the server console had a number of messages about "ld" spawining too fast and another message about the usage of named (which I failed to copy down before having to rush out earlier).

I do not know if the update command I used was the proper way to have upgraded bind or not. If anyone knows of the correct way to perform the upgrade and fix the errors / problems, I would be vary happy to know it. I've only tested on the test server and don't as yet dare to try it on the production servers unless I know the upgrade procedure will work correctly.

My thanks to all who have been participating in this little exercise. I will be submitting my results to bugs@e-smith.org as well, even if they reckon it may be iproperty's fault.

Kelvin

[Cyrus Bharda]

Sounds like you's be better off just upgrading to SME 5.5, but good luck

Cyrus Bharda

[Kelvin]

Actually, I'm hanging out for 5.6. I don't think 5.5 is worth all the hassles of upgrading, given that it still uses the same kernel as 5.1.2, very little gain IMHO. At least 5.6 will be using a standard RH kernel.

Plus, we are talking about lots of installed 5.1.2 servers out there. Even with M$ servers, you don't go out and upgrade them everytime M$ releases a new server OS (though they will love you for it if you did ! Ha ! Ha !). Especially if a Service Pack (oops, Blades in SME terminology) or hotfix, will fix the immediate problem. Besides, one cannot adopt the attitude that just because 5.5 is out therefore people with problems with 5.x (prior to 5.5) or even 4.x are on their own. Especially when the 5.x series really isn't all that old. The only real problems I have with 5.1.2 are :-

1. It occasionally loses mail (not often, but in some cases, once is too often).
2. The file system is too easily corrupted on an unexpected shutdown (UPSes don't help when people ignore GIANT signs in front of the power button to NOT turn off the system under any circumstances !)
3. This current problem with DNS (who knows what other domains it may have trouble with)

So, if I can patch up all existing 5.1.2 servers out there with an upgrade to bind to fix the DNS issue, I'm more than happy to do so.

Kelvin

[Rob Wellesley]

Kelvin wrote:
>
>
> So, if I can patch up all existing 5.1.2 servers out there
> with an upgrade to bind to fix the DNS issue, I'm more than
> happy to do so.
>
> Kelvin

Let me know if I can help - we install 5.1.2 servers and have had similar - sporadic - instances.

rob

[Kelvin]

Hi Rob,

I've been trying very hard to get the updated bind to work correctly. As I did not receive any replies of help from my later post on this issue, I had to tackle it alone (no small task for a linux newbie !).

I think I managed to figure it out (as of my last attempt late last night). I will try and note down the steps and redo it again on a clean loaded 5.1.2 server and if it works then I will post my results. The version of bind I am upgrading to should also fix up the bind security issue mentioned on e-smith.org, I think, not that anyone else seem to think it is an important issue at the moment.

Kelvin

[rob wellesley]

Hi Kelvin

The arrival of 5.6 has "solved" the problem for us. The workaround we have been operating is to set up a repeating 30 min cron job to dnsquery or dig for the "offending" name on that names registered nameserver. This reloads the local dns cache. Crude but effective.

Sorry we couldn't put any time into testing your update.

rob

[Kelvin]

Hi Rob,

That's all-right. I've successfully used the upgrade procedure at a number of 5.1.2 sites so far. I think my procedure uses the same bind version as 5.6 so whatever 5.6 "sees", my upgraded servers should also see.

Due to the PPTP issues, I'm holding back upgrading users to 5.6 (unless they have no need for PPTP - like file servers and non gateway servers).

Cheers !

Kelvin