MX and domain in separate locations

[Jonathan Villa]

That's not a valid command.  Did you mean "dig isdesigndev.com any 
> @ns1.apolloservers.com"?  I tried that, and got:

Right, I was trying to do

dig +short isdesigndev.com ns @ns1.apolloservers.com.

Thanks for the explanation...I will try to get them to remove the zone
file.

On Thu, 2004-02-12 at 12:38, Barry Margolin wrote:
> In article <c0gekc$22kf$1 at sf1.isc.org>,
>  Jonathan Villa <ksadmin at killerspin.com> wrote:
> 
> > I was hosting the domain isdesigndev.com with a hosting company who
> > managed the DNS information for me.I now changed to a hosting company
> > which has me maintaining the zone file myself.
> > 
> > Via the web, ssh, ping, whois, etc... the domain points to the new
> > nameservers, i.e. ns1.isdesigndev.com and ns2.isdesigndev.comhowever the
> > mail seems to be at the old location....I think this because I can view
> > my maillog on the old server and see everything getting rejected as
> > "relaying denied"...
> > 
> > Anyway, I tried to query the domain at the old location
> > 
> > dig isdesigndev.com ns1 @ apolloservers.com
> > 
> > and I get in return
> > 
> > ;; ANSWER SECTION:isdesigndev.com.        4573    IN      A      
> > 69.10.149.186
> 
> That's not a valid command.  Did you mean "dig isdesigndev.com any 
> @ns1.apolloservers.com"?  I tried that, and got:
> 
> ;; ANSWER SECTION:
> isdesigndev.com.        259200  IN      SOA     ns1.apolloservers.com. 
> root.ihmac.infinityhosting.com. 2003041633 7200 3600 604800 3600
> isdesigndev.com.        259200  IN      NS      ns2.apolloservers.com.
> isdesigndev.com.        259200  IN      NS      ns1.apolloservers.com.
> 
> No A record, no MX record, so no way for mail to be delivered at all.
> 
> > which is my new server...so, any ideas as to why my mail would still go
> > to the old server?
> > 
> > Do I need to check with the old hosting company to see if they have
> > "released" the zone file?  Do I even need to do that?  I changed the dns
> > info at the registrar level...
> 
> Yes, you should get them to remove the zone from their servers.  Other 
> servers may have cached the NS records that point to them, and every 
> time they query the old servers the cache gets refreshed.  As long as 
> they keep querying before the TTLs run out, they'll never go back to the 
> root servers to get the new delegations.