# Bind MX record question



## dpalme (Sep 23, 2014)

This is a theoretical question but one which I'm considering doing if possible.

Is it remotely possible to have two different domains added to the same bind record for MX purposes?

IE: If I have two domains, can I use a singular master record to handle both and within there have ONE mx record?


----------



## SirDice (Sep 24, 2014)

Sure. Just create a mail.example.com for example and create an MX record pointing to a CNAME. 


```
MX mail.domain1.org
                   MX mail.domain2.org

mail.domain1.org CNAME mail.example.com
mail.domain2.org CNAME mail.example.com

mail.example.com A 1.2.3.4
```

As long as the end result is an IP address you can create all sorts of nice constructs.


----------



## usdmatt (Sep 24, 2014)

If you are talking about having two domains share the same DNS records, so you only need one zone file, yes this is possible. (I've done it and not had any issues although I've never looked to find out if BIND docs mention anything about it)


```
zone "domain1.com" {
  file "mydomain.com.zone";
};

zone "domain2.com" {
  file "mydomain.com.zone";
};
```

In the zone file, you obviously need to try and avoid using the domain name. You can use `@` as the resource on the SOA line, then either leave the first column blank on following lines to use the same resource, or make use of auto-expansion:


```
@      IN      SOA      data
       IN      NS       ns.example.com.
mail   IN      MX       mail.example.com.
web    IN      A        1.2.3.4
www    IN      CNAME    web
ftp    IN      CNAME    web
```

`@` will expand to $ORIGIN, which is either domain1.com. or domain2.com. depending on which zone BIND is loading. The blank line below will use the same value as the line above. Third line, without a dot after mail, will expand to mail.$ORIGIN.

I'm not 100% sure what will happen if you try and put a fully qualified entry in there for one of the domains:


```
somehost.domain1.com.   IN   A 1.2.3.4
```

I know BIND will complain about 'out of zone data' when loading the file for domain2.com. If BIND just ignores that line and continues to load the rest of the file as normal, you can use that to allow you to put domain specific entries in the zone file. If it rejects the entire zone file you'll need to obviously avoid it and both domains will have to have completely identical records.


----------



## dpalme (Oct 13, 2014)

Thanks for the replies everyone, what is partly driving this, is we have multiple domains that are on the same server, so when someone turns on the rDns function in Sendmail its coming back to bite us since in some cases that IP address is resolving to a name different than the domain.

Maybe there is a better workaround, if so I'd be all ears.


----------



## usdmatt (Oct 13, 2014)

When configured correctly, reverse DNS shouldn't be a problem with multiple domains on one server. Every ISP on the planet sends billions of emails a day from hosts that handle email for hundreds or even thousands of domains.

Let's say you are an ISP called myisp.net, and you have a mail server, mail.myisp.net, on 1.2.3.4.

You can have as many domains as you like hosted on that server, eg domain1.com, domain2.com, etc.
These domains can either have domain specific MX records that resolve to 1.2.3.4, or they can all point MX at mail.myisp.net.


```
domain1.com MX mail.domain1.com
mail.domain1.com A 1.2.3.4
OR
domain1.com MX mail.myisp.net
```

Sending is where rDNS becomes important. Your server has a hostname of mail.myisp.net. The A record for this hostname should resolve to 1.2.3.4, and you should have an rDNS entry for 1.2.3.4 that resolves to mail.myisp.net, so everything ties up neatly.

When sending emails, the destination server will see a connection from 1.2.3.4. During the start of the SMTP conversation your server will identify itself as mail.myisp.net (SMTP HELO/EHLO). The destination server doesn't really care what domain is in the email itself (until you start getting into things like SPF), they only care that mail.myisp.net ties up with the IP the connection came from, and that the rDNS matches:

Connection came from 1.2.3.4, identifying itself as mail.myisp.net
1) Make sure A record for mail.myisp.net resolves to 1.2.3.4
2) Make sure reverse for 1.2.3.4 matches "mail.myisp.net"

The important thing to understand is that everything relates to the real hostname of the server. The domain names used inside emails is fairly irrelevant. You can't start trying to make the SMTP server itself use different names because the reverse DNS will never match up.


----------

