Home / server / Questions / 1112846
In Process
Martin
Asked: 2022-10-12 11:28:56 +0800 CST

DNS: how to redirect website traffic only, to a specific server

  • 772

There are many similar questions on here but nothing that looks like it's actually what I need.

I know what I need is very simple but I can't websearch it, probably I'm missing a key word.

My issue:

There is a standard DNS set up on a third party (as yet unseen by my eyes) controlling the website and email. Defined as "Server Old". There is a new website set up on its own server, defined "Server New" this server hosts the website ONLY and so I need to update the DNS of the original "server Old" DNS hoster.

I understand I should update the original A record (only) to the IP of the server hosting the new website.

But I am having trouble understanding what to do about the DNS for the new-website server, it needs to recognise when dealing with email to send emils out to the WAN rather than dealing with them internally. How do I set up this DNS, for example if the new website sends emails to the website owner, the email needs to be send from the new server to the old server;

Is it simply a case of updating the MX record on the new-website server to point back to the original DNS server?

Or have I missed some things here?

Update 1

In response to Tilman's answer to my above query. A kinda rewrite and clarification response to the above answer.

There is a Domain; "Domain Alpha" that has it's A, MX and all other records set correctly.

  1. I believe that, in order to redirect the website -only- to a new server, that on the DNS rules set for "Domain Alpha" I should update the "A" DNS rule -only- to the IP of the new website server.

  2. I would then have a DNS ruleset on this new server that would -only- handle incoming HTTP requests and anything else be pushed back to the original FQDN DNS ruleset.

  3. Basically, I want to delegate all services EXCEPT email (MX) to the new server and leave the email as it is.

Can I do this (3) by setting an A ruleset record in the existing DNS ruleset that points to the new server, and then on the new server (which also contains DNS rulesets) setting an explicit MX record back to the "original" current server IP (or the orginal / current DNS host)?

website domain-name-system

2 Answers

  1. You need to sort out your concepts. There is no such thing as "the DNS for the new-website server". There is only the one worldwide domain name system (DNS) [1] containing resource records (RRs) for domain names, and within it one authoritative nameserver for your domain on which you can maintain and update RRs within that domain [2]. Nor does the DNS have "rulesets", or "recognize" anything. It just answers queries about RRs assigned to fully qualified domain names (FQDNs) without considering (or in fact even knowing) which service the client wants to access.

    With respect to your question, there is no such thing as "a DNS ruleset on this new server" that would be able to "-only- handle incoming HTTP requests" because DNS doesn't even know whether an incoming request is for HTTP. Nor is there a mechanism to "push back" anything once it has arrived on your new webserver.

    There are two relevant types of RRs for your purposes:

    • the A (address) or AAAA (v6 address) RR which assigns an IPv4 or IPv6 address to an FQDN; this is the RR consulted when accessing a webserver so it is this RR you need to change when moving the web service to a new server
    • the MX (mail exchange) RR which assigns a mail server to an FQDN; this is the RR consulted when sending mail to an address with that FQDN in the host part, so you need to change that only when moving the mail service

    There are however a few additional considerations:

    1. Be careful to use/modify the RRs for the correct FQDNs. Often the FQDN for your website is not the same as the one used as host part in your mail addresses. For example, your website URI might be https://www.example.com but your mail addresses will be [email protected]. In that case the A RR determining the webserver to consult will be the one on the FQDN www.example.com but the MX RR determining the mailserver will be on the FQDN example.com (without www.). If your website is reachable as both https://www.example.com and https://example.com you need to update the A RRs on both www.example.com and example.com.
    2. MX RRs refer to an FQDN, not an IP address. That FQDN is then in turn resolved to an IP address through an A RR. It is perfectly legal (though somewhat unusual) that the MX RR of your FQDN refers back to the same FQDN. In that case, the A RR on the FQDN is used for both the webserver and the mailserver, and changing the A RR of the FQDN to point to the new webserver would also change the IP address of the mailserver. To avoid that, you need to give the mailserver a new FQDN of its own and put that into the MX RR, as an exception to the statement above that the MX RR needs to be left untouched.
    3. Worse, even if your mail domain and website FQDN are different, it is still possible that the MX RR of your mail domain refers to the same FQDN your website uses. In that case, again, you'll first need to give the mailserver its own FQDN before changing the A RR on the website FQDN.

    So what you need to do is:

    1. Dress up a list of all FQDNs which are (or should be) used to access your website. If that list has only one entry, all the better.
    2. Check whether any of the FQDNs on that list are also used for another service that should not move to the new server together with the HTTP service. This includes, but is not limited to, the right hand side of any MX RR. It does not include HTTPS which will move to the new server along with HTTP. It does also not include the left hand side of MX RRs.
    3. For every service identified in step 2, create a new, separate FQDN to which you copy the RRs of the existing FQDN, and update all uses of that service to the new FQDN.
    4. Update the A RRs of the FQDNs identified in step 1 to the IP address of your new webserver.

    [1] leaving aside private split DNS in order not to complicate things unnecessarily

    [2] leaving aside subdomain delegation for simplicity

    • 3

  2. The authoritative DNS server for your domain should contain the proper MX record for your domain.

    When your new server is sending emails to your domain, the SMTP server that new server uses, will do a query for MX record of the destination domain.

    Then the mail server will resolve the A/AAAA record for the mail server mentioned in MX record, and then will connect to that server.

    Note that if the MX record pointed to domain name used for web services, then you need to set up another domain for your MX record.

    For example: If old server had www.example.com with IP address 192.0.2.1 and MX record pointed to www.example.com, then that doesn't work with new setup.

    A working set of DNS rules in your authoritative DNS server for the domain would be:

    www.example.com A 192.168.100.1
www.example.com MX mail.example.com
mail.example.com A 192.168.200.1

    Here 192.168.100.1 is the IP address of the new server, and 192.168.200.1 is the IP address of the old server.

    MX record must always be a domain name.

    • 1