One domain (of many) won't resolve

Several domains have now been set up on my Debian Etch server using ISPC. But one won't resolve whilst the rest are all fine.

I've checked /etc/apache2/vhosts/Vhosts_ispconfig.conf to compare its formation with others, no difference, similarly in /var/www/webx/www compared with /var/www/weby/www but there's no difference there, either.

The symlinks to the two sites, apart from the domain names, are identical, too and I have set them all up in the same way. Is there anywhere else I can look for a solution?

<edit>Now the client has called to say email isn't working on that site, as well as the site itself not resolving. Any helpers, please?</edit>

 

If the site isn't resolving, I'd first want to check that the NS records with the domain's registrar point to the proper DNS servers. If you run "whois <the domain name>", who does the registrar are the authoritative name servers for the domain?

If the registrar says that your machine is authoritative, are you serving up the DNS properly? Speficially, if you execute "dig @<your server IP> <the domain name>", does it return your server's IP address? And for mail, does "dig -t mx @<your server IP> <the domain name>" also return your IP address (more accurately, a host name that resolves to your IP address)?

Finally, if all of the above steps return proper values, is the domain in question in your /etc/postfix/virtusertable?

 

I have it on Nominet whois return. Yes both steps return sensible values and yes the domain and aliases are in/etc/postfix/virtusertable. In fact, each alias is in the form alias@fqdn and alias@dn in /etc/postfix/virtusertable - something I have never seen before. Is there a reason for it?

 

Bump.

I have a client with, so far as I can see, properly configured web site, email config, username and password in ISPConfig. The web site doesn't show and the email doesn't work. I configured them myself as my own reseller.

The tests as suggested by catdude return what look like good results to me, i.e. nameservers, webservers, mailservers, IP addresses all showing as they should.

I have spent several hours trying to find out what may be wrong.

Can anybody help me, please?

 

IN my previous message I asked about DNS resolution issues. Do you have ssh access to a machine outside of your netblock? If so, does "dig <the domain name>" return the proper value? That is, doing the tests I mentioned before without the @<your server IP> part. I'm sorry about being fixated on dig but if the problem is with domain resolution I keep thinking that the problem has to be somewhere in the DNS chain.

As for the mail issue, does it appear to be a problem with DNS resolution of where the customer is pointing his mail client, or is it actually a problem with Postfix? If you telnet into port 25 and send an e-mail to an address within the customer's domain, does it delivered into the proper mailbox or Maildir?

 

One more thing: could you describe in detail exactly what does happen when you attempt to access the customer web site in your web browser?

 

The WHOIS (NominetUK) still shows the correct tagholder and DNS settings.

The machine I am sitting at here is in Yorkshire, north England. The server is in London. So I open a terminal and:

~$ dig mymissingsite.co.uk

; <<>> DiG 9.3.4 <<>> mymissingsite.co.uk
;; global options: printcmd
;; connection timed out; no servers could be reached

with the same response when using the -t mx parameters.

Which is very different from the original result using @serverIP. Sorry, catdude, I'm not very bright.

However, the settings in ISPConfig -> "DNS Manager" the correct IP address under domain and both DNS Entry boxes are filled with correct DNS server entries. The DNS server set-up has three possible entries, but there is only space for two in ISPConfig. The browser just times out with "Server not found. Firefox Could not find the server at www.missingsite.co.uk" and tells me to check my spelling, connection and Firefox's permissions.

Given the dig -t mx return above, is it worth trying telnet yet?

I agree it's in the DNS chain, but where? What do I check? DNS is something of a black art to me and I really need to help this client before I start reading up on the whole topic.

Idea? Is it worth trying by deleting one of the DNS entries at the tagholder, so both sets of entries are exactly the same?

 

No, I wouldn't bother with the telnet test yet. And don't feel bad, it's all to easy to miss these things!

The fact that dig with the "@<your server ip>" returns the right values says that you've got bind9 running properly.

Are you on a residential DSL circuit or something similar? If so, it's possible that your ISP or your router might be blocking DNS traffic. Can you log in to a server off your network (preferably off your ISP's network entirely) and try to dig with the IP address? If that doesn't work, then you could suspect a firewalling sort of problem.

If you don't have access to a machine completely outside of your provider's network, send me a private e-mail (dan at catfolks dot net) and I'll set you up with an account on my home machine you can test from.

 

I'm on an Ubuntu workstation (standalone at the moment) with a domestic adsl connection, mainly using ssh to access my server. I just tried using dig on another domain hosted there under exactly the same circumstances, without logging in - just cl from a terminal here:

Code:

$ dig -t mx anotherhost.co.uk

; <<>> DiG 9.3.4 <<>> -t mx anotherhost.co.uk
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41210
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 4

;; QUESTION SECTION:
;anotherhost.    IN      MX

;; ANSWER SECTION:
anotherhost.co.uk. 43200 IN    MX      10 mail.anotherhost.co.uk.

;; AUTHORITY SECTION:
anotherhost.co.uk. 43200 IN    NS      a.ns.dnshost.net.
anotherhost.co.uk. 43200 IN    NS      b.ns.dnshost.net.
anotherhost.co.uk. 43200 IN    NS      c.ns.dnshost.net.

;; ADDITIONAL SECTION:
anotherhost.co.uk. 43200 IN A     xx.xx.xxx.xx
a.ns.dnshost.net.    10015   IN      A       xx.xx.xx.xx
b.ns.dnshost.net.    4343    IN      A       xx.xx.xxx.xx
c.ns.dnshost.net.    12642   IN      A       xx.xx.xx.xx

;; Query time: 58 msec
;; SERVER: yyy.yy.y.yyy#53(yyy.yy.y.yy)
;; WHEN: Tue Sep 18 15:39:03 2007
;; MSG SIZE  rcvd: 189

So not much evidence of a firewall preventing anything.

Very kind of you to offer, by the way.

<edit>Sorry, forgot to post the dig without parameters result - but they were equally good.</edit>

 

The server with ISPConfig is in Docklands, London. The two sites I've shown the dig results on are hosted on that server. I am remote from that server, only connected whenever I ssh in, or by browser to the ISPConfig via https://somedomain:81

 

Can you post the real domain name?

 

horsfieldsofhalifax.co.uk

 

I consulted "whois" to look up thename servers for that domain. The returned values were:
Name servers:
a.ns.bytemark.co.uk 80.68.80.26
b.ns.bytemark.co.uk 85.17.170.78

Doing "dig" against those IP's returned:
dan@dm:~$ dig @80.68.80.26 horsfieldsofhalifax.co.uk

; <<>> DiG 9.3.2 <<>> @80.68.80.26 horsfieldsofhalifax.co.uk
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached
dan@dm:~$ dig @85.17.170.78 horsfieldsofhalifax.co.uk

; <<>> DiG 9.3.2 <<>> @85.17.170.78 horsfieldsofhalifax.co.uk
; (1 server found)
;; global options: printcmd
;; connection timed out; no servers could be reached

dan@dm:~$ dig horsfieldsofhalifax.co.uk

; <<>> DiG 9.3.2 <<>> horsfieldsofhalifax.co.uk
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 42672
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;horsfieldsofhalifax.co.uk. IN A

;; Query time: 5155 msec
;; SERVER: 192.168.3.200#53(192.168.3.200)
;; WHEN: Tue Sep 18 11:44:43 2007
;; MSG SIZE rcvd: 43


So, I'd say the first question would be:
Are either of those 2 IP addresses your ISPConfig server? If so, do you get different results when you do those dig's from home? If you are getting proper results back, then I am puzzled!

 

They're the DNS servers, not the hosting server. From dig @serverIP I got a full set of results. From dig horsfieldsofhalifax.co.uk I got failed, as reported earlier.

Which gives me another tip. I'll try the guys at Bytemark to see if they can throw any light on it.

Incidentally, I have full control over the domain. I bought it on behalf of the client and set the tagholder myself, for the exact reason of being able to control DNS settings and so forth.

 

Ok, that enlightens me a bit. I had assumed that you were depending on ISPCOnfig for your DNS as well.

Yes, at this point it would definitely seem to point to Bytemark. If you have a DNS management interface available through them, you would want to look there.

 

I have found out what is wrong. It is an abject lesson in "Don't let DNS trip you up" for anyone new to DNS and to hosting management systems in general.

When I first got this LVM it was, as I'd asked, preloaded with a proprietary brand's hosting management system. The first thing I did was to load the settings for most, but not all, of the domains under my control into it. Hence A, MX and C records are all pre-set for those domains. The next thing I found out was that I didn't like that system, found an alternative (which is why I'm here) and wiped the virtual hard drive to start all over again. But I didn't wipe those DNS settings.

So it turns out ISPConfig hasn't put the DNS records where they should be at all. Nor has it put the records in for the one domain I have subsequently set up in ISPConfig.

Mods, I think the topic deserves a new thread. Please close this one so we don't have two concurrent conversations on the same topic. I'll call the new one "Setting up DNS automation post-installation"