Have just finished a website, and we are in the process of setting up the domain name etc.

Domain name has been transferred from Demon to Titan, and the site is now viewable (well the holding page is anyway).

The problem is with the email. All internet/email access is done through NetPilot, a small router system that allows SME's to have multi email/internet access without the costs involved.

But for some reason we cant setup the email system properly to collect the email. Have entered correct details etc, but the system seems to be blocking access, as they cant see the domain name also.

Strange thing is this - there are 2 domain names, the main one and then another which points to the main one. Email is arriving on the 2nd domain, but not arriving at the original.

So how is that possible?

Anyone any experience with NetPilot/latency/routers etc.

Chiark - you around - you will be able to help on this one

 

I Presume you have checked the mx records?

David

 

David - Not sure, the MX records are setup with the ISP I believe?

Probably Demon not doing their job right - it took 2 weeks to transfer (due to illness apparently) [img]images/smilies/mad.gif[/img]

 

The problem seems to be the link between client and server. You can view the mail online by using the mailserver address.

I can see it in a browser, but they cant. Hence, it is obviously their ISP connection problem.

Not sure though

 

Can you ping the Titan mail server Simon?

How about Telnetting to port 110 or 25 from inside the customers LAN - will test out the connectivity.

 

if you can see the mail on the mailserver then it aint mx records...

like chris says try that if that doesnt work then the router is failing to connect...

Assuming it has the correct Ip adress, Subnet mask, Default Gateway, and the new dns server Ip adresses configured??

Is it behind a firewall, are you blocking any ports such as smtp and pop3 25 and 110?

Can you view any firewall logs and see what is happening or do a network trace / capture?

David

 

my understand is that when you move your domain to another ISP, you need to move the mx records as well which will enable you to run your email server (smtp). or move the mx records to your static IP address.

i setup a small company for internet and email access via ADSL with static IP address. before they were using pop3 email from their ISP via dial-up. i requested the mx records to be transfer to the static IP address which goes into a ms exchange server.

it takes a while to sync but the ISP should inform you once they have done it.

 

What do you mean by a problem between client & server. Are you meaning the NetPilot acting as a client to the Mail Server OR a Desktop Mail Client (MUA) and the NetPilot as the server ?

 

Client as in person that owns the website

 

If the clients are still using Demon as an ISP it's possible that Demon's nameservers still have the zone file for that domain loaded so believe they are authoritive for it, which they aren't, but when anyone using Demon tries to resolve things the Demon servers will return their answers and not the correct ones being handed out by the ones at Titan, which are authoritive.

That probably explains their problem of not being able to see the site.

As to the mail problem, that could be MX records, firewalling or anything else, but if the mail for the other domain you mention is coming through those same servers then it's likely a mx record problem or misconfigured mail server not accepting the mail for the first domain.

Since all DNS entries are public (at least ones used on the internet) it would be easier if you told us the domains and the IPs they are meant to resolve to then someone could just look them up and see what's wrong most likely.

 

Yep - post the domain and we will do some digging (no pun intended for u geeks) for ya!

 

Andrewza - that was the theory I put forward.

When we take on domains from other ISPs we do find from time to time they leave the zones on their own dns servers. This screws up web/email for any customer who uses those dns servers.

Unfortunately whilst I find DNS an easy topic to investigate/resolve it appears that there are plenty who regard it as a black art and problems like this go unresolved.

I've asked Simon to ask Tom for his nameservers and to try ours instead.

 

Yeah, I've had it happen before. It's a nuisance, but usually nothing than a few minutes with dig is needed to find out what's going on, getting the other people involved to sort their misconfiguration is usually the problem...

 

Here..look at a query made against ns0.demon.co.uk

> schofieldinsurance.co.uk
Server: ns0.demon.co.uk
Address: 158.152.1.65

schofieldinsurance.co.uk MX preference = 100, mail exchanger = relay-1.mail.demon.net
schofieldinsurance.co.uk MX preference = 100, mail exchanger = relay-2.mail.demon.net
schofieldinsurance.co.uk MX preference = 50, mail exchanger = mailgate.schofieldinsurance.co.uk
schofieldinsurance.co.uk nameserver = ns0.demon.co.uk
schofieldinsurance.co.uk nameserver = ns1.demon.co.uk
schofieldinsurance.co.uk nameserver = ns2.demon.net
relay-1.mail.demon.net internet address = 194.217.242.51
relay-2.mail.demon.net internet address = 194.217.242.10
mailgate.schofieldinsurance.co.uk internet address = 62.49.236.42


I wonder if Demon would be so good as to remove the zone from their servers lol

 

Thanks all - all sorted now.

Demon had screwed up the DNS zones as discussed. New Titan nameservers added now and all is well

Thank god

DW

 

The problem your talking about is propogation. If you move a domain to another ISP then you will still have an overlap from the old ISP depending upon what settings you had in your zone file for retry, expiry and ttl. Depending on what dns resolvers a customer is using you will end up with varying results when you dig for dns records.

 

No its not propagation. The domain was moved over quite some time ago

 

Lee - I think you are getting confused between Nameservers and Resolvers!

When you query for a zone you query the authorative nameservers for that TLD e.g. Network Solutions for a .com they then tell you who is authorative for that particular domain. If these are correct and the zones held by that ISP are correct then you should have no problems. Problems arise when you query an ISP's DNS resolvers and its holding old information as they store the zone records when a query is made and then keep it until the ttl expires.

So in short it doesnt matter if your old ISP keeps the zones on its servers as long as network solutions or similar are pointing to the new ISP and its nameservers!

Simon.

 

> So in short it doesnt matter if your old ISP keeps the
> zones on its servers as long as network solutions or
> similar are pointing to the new ISP and its nameservers!

heh heh sorry thats crap

In this case Demon have the zone on their servers and it needs to be removed. It *does* matter since there are a gazillion people who use those same nameservers for their own lookups. Since the demon servers hold the zone locally they don't bother performing a recursive lookup, they just return the records they hold. So demon customers (specifically in this case Schofield) get the wrong records hence cannot see the site/email.

 

All Lee's trying to say is in normal order a nameserver will start at the root and follow the path of authority down until it hits a name server with an answer, with two exceptions.

1. It has an answer already who's TTL has not expired

2. It thinks it's authoritive thus hands out his own answer

In this case if you query the domain against Demon's server they're still answering for it and they shouldn't be, the problem isn't 'the rest of the world' it's just for demon's users who use those servers for all name resolution and they're handing out their own answers from the old zone file.

 

Sounds like Demon run a weird setup there. As if you check using their own DNS tools (http://www.demon.net/external/) you get the following:

host -t soa schofieldinsurance.co.uk.
The SOA record (Start Of Authority) shows who owns, or is responsible for a domain; badly administered domains may not have an SOA record, however.

schofieldinsurance.co.uk SOA ns1.titanhosts.net support.titanhosts.net(
2002082001 ;serial (version)
900 ;refresh period
300 ;retry refresh this often
604800 ;expiration period
86400 ;minimum TTL
)

However if you use their DNS resolvers (which you should do as opposed to the nameservers) then you get the incorrect records:

dig @cache-1.ns.demon.net schofieldinsurance.co.uk mx

; <<>> DiG 2.2 <<>> @cache-1.ns.demon.net schofieldinsurance.co.uk mx
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10
;; flags: qr rd ra; Ques: 1, Ans: 3, Auth: 3, Addit: 6
;; QUESTIONS:
;; schofieldinsurance.co.uk, type = MX, class = IN

;; ANSWERS:
schofieldinsurance.co.uk. 6894 MX 50 mailgate.schofieldinsurance.co.uk.
schofieldinsurance.co.uk. 6894 MX 100 relay-1.mail.demon.net.
schofieldinsurance.co.uk. 6894 MX 100 relay-2.mail.demon.net.

;; AUTHORITY RECORDS:
schofieldinsurance.co.uk. 86094 NS ns0.demon.co.uk.
schofieldinsurance.co.uk. 86094 NS ns1.demon.co.uk.
schofieldinsurance.co.uk. 86094 NS ns2.demon.net.

;; ADDITIONAL RECORDS:
mailgate.schofieldinsurance.co.uk. 6894 A 62.49.236.42
relay-1.mail.demon.net. 880 A 194.217.242.51
relay-2.mail.demon.net. 884 A 194.217.242.10
ns0.demon.co.uk. 14362 A 158.152.1.65
ns1.demon.co.uk. 14367 A 158.152.1.193
ns2.demon.net. 13157 A 209.246.126.109

;; Total query time: 80 msec
;; FROM: ccorpserve0.cbg.ops.eu.uu.net to SERVER: cache-1.ns.demon.net 158.152.1.58
;; WHEN: Wed Sep 18 16:32:42 2002
;; MSG SIZE sent: 42 rcvd: 285

As you say it looks like Demons Resolvers check their own records and these overide anything returned externally even if incorrect. Pretty pants really (all IMHO of course ).

Simon.

 

Well yeah, it reduces traffic on their external links, which is no doubt more expensive than a few CPU cycles.

 

So how long has the Schofields domain palava been going on as its not exactly a hard task to remove a zone file or delete it from a named.boot file?

 

I don't know, but I've used and still do use Demon for some stuff and they're pretty responsive to DNS changes, usually same day and they reload their servers 3 times a day with updates IIRC. That said I've not had to transfer a domain from them yet, but will be shortly, except a few domains and a leased line as well.