Adding new domain 1

[suedaisy]

Hi, I have hunted for an answer on this, and I've tried everything, but to no avail.
We have Win2k with Exchange2k. 1 have 1domain.com and now 2domain.com.
I have a DNS entry for the new domain, and I set up a receipents policy in Exchange server. The email works in house, but it doesn't receive external email. The DNS entry mail server points to 1domain.com instead of 2domain.com.. I didn't know if I should make a mail.2domain.com, and I'm not sure even how to set that up. Some current users of 1domain.com will receive 2domain.com, but I need it kind of seperate so they know which domain the email was sent to (makes sense?)
What am I doing wrong? Thanks so much, Suzanne

 

[PHead2]

Do you really think no one runs their own public DNS???? Plenty of people do or use a third party which they have to configure (like dyndns.org which I like to use for companies that want to manage their own records but don't want the expense of extra servers and redundant WAN connections).

There is absolutely NO reason you can't and anyone who relies on their servers being available 24/7 does.

It does not make any difference who runs the server, it is
a requirement if you want your host names to be resolvable.

And fine, you ask your DNS when you send but do you know how it knows where to send? It asks a root server where the DNS servers for my domain are and with that info it asks my (or my ISPs - who runs it is totally irrelevant) DNS server. It then caches the info for the specified TTL and the process starts over once the record is flushed from the cache (if needed again). And yes, if the plug got pulled on thoese servers which host records (again you can run your own or use your ISPs) your server would not come up with any results.

If I'm wrong then please provide an explanation of how DNS works so I'll know what I'm doing the next time I have to set it up.

 

[Marcs41]

Please do me, and yourself a favour and post your story in forum950. But, before you do, READ about DNS in there.

As a little aside, I am sorry but you are confusing internal and Global DNS. There are not many ISP that will let YOU update their DNS servers! That would be a joke, if it were that simpel, I would be able to make myself anything I wanted and redirect request to me.
Explaining: Suppose I make myself in my own DNS mail.yahoo.com and I push my DNS settings to my ISP, anyone using my ISP's DNS would end up on my side, and I would be able to get all their userid and passwords while they try to connect. So, there is no way an ISP is going to allow you to do that.

Where you refer to dyndns that in no way means you are running your own DNS. THEY do!
All you do is update THEIR DNS server with your IP to point everyone to you, you are not pulling them.
DynsDNS on their part are updating the root servers and that way anyone will be able to connect to you, wherever they are and wheter you are down or not.

Again, pull out your connection, I would still be pointed to you, but hit a wall since you are down, obviously.
So, wheter your own internal DNS is working or not, anyone would still get your MX record, that is where root servers and ISP's come in.
If you really don't believe it, stop your DNS service and you still see mail get in (but maybe not out, depending your setup).

 

[PHead2]

I don't see why you are so fixated on the fact that people can't run their own 'global' as you call it DNS. This simply isn't true. This does not mean you can make records for Yahoo it just means you can make records for domains that are registered to your DNS server.

I never said using dyndns was running your own DNS, I specifically said it was a third party service that you update yourself. Re-read my post.

You seem to be completely ignoring the fact that all I was saying is that it is possible (and very common) for people to run their own DNS servers which the root servers are pointed to. There is nothing special about an ISP that allows them to have a DNS server while noone else on the internet can.

I am not confusing global and internal DNS, am I merely saying that you can provide servers which run both. This is relevant to the orginal post as it was never clearly stated wether or not this was case. I realized that it was probably not but it is important to know. If they were running their own 'global' DNS then they would need to update the records.

I'm not going to argue the issue anymore, I am confident in my understanding as 90% of what I do deals with internetworking (routing, switching, firewalls, DNS servers, etc.) and I manage to keep my jobs. Maybe because I work for ISP type companies the way I define things is a little bit different than yours (I don't know what sort of work you do). If your understanding works fine for you then that's great too.

Just try to understand that the way your systems are setup are not necessarily the only way of doing things.

 

[Marcs41]

Aha, you work from an ISP side, that explains your point of view. But that is not the same from the customer side.
And I also on occasion use DYNSDNS, so I do know that since years, although before it was more DNS2Go.

But I do strongely disagree with this being relevant to this issue, as far as the RECEIVING part goes.
If the ISP has the MX record, the mail WILL get there, wheter suedaisy is having DNS troubles or not.

The mail will be sent to an IP address, on port 25, not by name. DNS has no intervention in that part.

So I suggest we let suedaisy figure out the MX issue first with the ISP and wait to report back.
There is no point going on about DNS at this time.

 

[suedaisy]

I haven't heard anything back from the ISP, but if I do an nslookup now.. it's working. Or at least it appears to be. The MX record is showing my ISP's mail though.. ? Which of course we don't use seeing how we have our own exchange server..

 

[Marcs41]

Kick them, you are paying them right?
Honestly, you should not leave them alon until it is fixed. It takes them 2 minutes to do it, so insist, every hour if needed.
The MX of the 2nd domain HAS to pint to your 1st domain, or you will never get anything.

 

[suedaisy]

I emailed them not too long ago and got a response back saying it'll take 12-24 hours to update.. which is fine, I have other stuff to take care of anyways..
So I'll find out tomorrow if everything works.. I'll report back.

 

[PHead2]

Yes, it really should only take them a minute to change. It may take a day or two for the change to be reflected everywhere however.

In the end the nslookup of the MX for both domains should point to the same address in order for everything to work.

I 100% percent agree that in this case as long as the ISP has the records it doesn't matter what the status of suedaisy's DNS server(s) is, the only thing is I still call this a DNS problem (a problem with the ISP's DNS).

I only brought it up on the off chance they didn't use their ISP for this service because if they did use their own or something else it would be their responsibility to configure it.

 

[dotcomstudio]

Hmm... I have to agree with PHead2 here. Anyone can run their own DNS or even manage their own DNS with a thrid party. It's all very simple! The changes I MAKE to MY DNS records are propogated across the Internet, therefore, if I do not set up my DNS records properly I WILL NOT get mail, as everyone else will have the same incorrect DNS records that I SET UP. That's gotta makes sense if you know anything about DNS.

Rob

 

[jbud]

This thread doesn't really need extending, but here it goes anyway: the important thing to know is which nameservers have been delegated authority for the zone that definies the domain in question. If the nameservers are at an ISPs, such as appears to be the case with suedaisy, then that's where the mx changes need to be made.

On the other hand, many, many people choose to delegate authority to nameservers that they control, meaning they are responsible for updating their own mx records.

And to extend dotcomstudio's comments, DNS records have time-to-live values associated with them, which explains why it takes 12-24 hours for other nameservers to begin querying for new data.