Add MX record for subdomain

Endre Ottem

Verified User
Joined
Jul 4, 2019
Messages
13
I'm trying to figure out how to add an MX record for a subdomain. Let's say I want to end up with this DNS record:
subdomain.domain1.com. 600 IN MX 20 target.domain2.com.

Creating a MX for the main domain is no problem, but I can't seem to figure out how to the same for a sub domain. This works for adding MX to the main domain:
/CMD_API_DNS_ADMIN?domain=domain1.com&action=add&type=MX&name=target.domain2.com.&value=20&urlencoded=yes&full_mx_records=yes

Where would the subdomain go in the command above?
 
Did you add the subdomain as the main domain in its own DirectAdmin account, or is it added as a subdomain beneath an existing DirectAdmin account?

If you added it as the main domain of its own DirectAdmin account, then you should be able to treat it like main domain in that it will have its own DNS zone file. For example, I created a new DA user account for


user@box:~$ dig mx +short test.domain.tld
10 mail.test.domain.tld
user@box:~$ dig a +short mail.test.domain.tld.
108.XX.XX.XXX
user@box:~$

So, in this case, using the API command, you should theoretically be able to use this:

Code:
domain=subdomain.domain1.com

Note that the domain= portion determines the name of the DNS zone file, so in this instance, it would have its own and be looking for /var/named/subdomain.domain1.com.db.

If you added it as a subdomain beneath an existing account as that main domain's subdomain, then it will typically use the main domain's MX records. It won't have its own zone file. You may be able to edit the main domain's zone file to add a MX record for the subdomain if you want it to use a different mail server than the main domain. If you want the subdomain to use a local mailserver while the main domain uses a remote mailserver, you may need to adjust the MX records accordingly, and check that /etc/virtual/domains contains an entry for the subdomain (since this file is responsible to routing mail locally in addition to the MX record itself.

In this case, using the API command, you should be able to format your POST string like this:

Post string:
Code:
domain=domain1.com&type=MX&name=subdomain.domain1.com.&value=20&mx_value=target.domain2.com&ttl=14400&affect_pointers=yes&json=yes&action=add

You can determine your own POST strings by running a trial run of the action you need to perform in DirectAdmin while it's running in debug mode:

https://help.directadmin.com/item.php?id=293

Also, I prefer to test my API commands via curl:

https://help.directadmin.com/item.php?id=580

You may want to test thoroughly following setup.
 
One last thing, this is the curl command I used to test on my test server for a subdomain that existed under a main domain (not with the subdomain set as the main domain for the account):

Code:
curl  --request POST --user 'admin:$ADMINPASS' --data 'domain=domain1.com&type=MX&name=subdomain.domain1.com.&value=20&mx_value=target.domain2.com&ttl=14400&affect_pointers=yes&json=yes&action=add'  -k https://108.XX.XX.XXX:2222/CMD_API_DNS_ADMIN
 
Thanks scriptkitty!

This is for clients with DNS only. The subdomain should only exist as a record in the DNS zone on the main domain.

I wasn't aware of the mx_value parameter, and that did the trick! :p Modified my command to this:
/CMD_API_DNS_ADMIN?domain=domain1.com&action=add&type=MX&name=subdomain&value=20&mx_value=target.domain2.com.&ttl=3600&urlencoded=yes

The name parameter would also work with the domain appended (name=subdomain.domain1.com).

(I'm sure it's just an oversight, but the MX should have a dot at the end to make sure you get a proper lookup).

I didn't know about the TTL parameter either, but that doesn't seem to work quite as expected. It changes the minimum TTL for the domain as a whole, but the new entry is assigned the default TTL. So using the above command will change the minimum TTL to 3600, while the newly created record will look like this:
subdomain.domain1.com. 14400 IN MX 20 target.domain2.com.

Also, I didn't think of testing my commands with cURL, so thank you for that. :)
 
Oops, that missing period was an oversight... thanks for 'looking out'! 😄

I just tested with a TTL of 3600, and it seems to have worked for me. Were any errors reported?
 
No errors. It returns a successful result:
{ "result": "", "success": "Record Added" }

However, the ssl parameter only worked the first time I tried it, and as I mentioned, it only replaced the minimum TTL for the zone. The record is saved with whatever is set as default. When I try again (exact same command, just with another TTL value), nothing is changed.

I don't get TTL for the records when I fetch them either:
/CMD_API_DNS_ADMIN?domain='.$domain.'&json=yes&full_mx_records=yes&urlencoded=yes

Example:
[type] => A [name] => domain.com. [value] => 1.2.3.4 [combined] => name=domain.com.&value=1.2.3.4

The ability to edit TTL may have to do with one of these settings (also returned using the command above):
[dns_ttl] => 0 [default_ttl] => 14400 [ttl_selected] => default [allow_ttl_override] => 1 [ttl_is_overridden] => 0 [ttl_value] => 14400

(I struggle to find any documentation that explains these (and a lot of other) parameters. To be honest, the API docs leaves a lot to be desired. I'm working on a complete, separate client area for managing DirectAdmin (just to make advanced things simpler to do for non-tech savvy people). I'd say that 80% of what I have achieved so far is based on guesswork. I'm using the same system for cPanel, and although we are moving away from cPanel and we don't really respect their way of doing business, I must say that their API documentation (and their API in general) is very high quality compared to DA. Not trying to diss DA in any way, there's more reasons for choosing DA over cPanel than not to.)

The TTL thing is not a big issue though. Instead of allowing the clients to set TTL for each and every record, I'll just add a place for them to change the TTL for the zone.
 
To be honest, the API docs leaves a lot to be desired.
Did you only see the old docs?
and features
and (bit older) sample

or also the new docs they are working on?

There are also lots of things about api in the versioning system.
However, you are right that documentation could be better, but as you can see they are working on improvement in a the new docs.directadmin.com section.
 
I didn't know about the new docs, actually. 🙃 Unfortunately, I can't seem to find anything there to fill in the missing pieces from the old docs as far as the API goes.

I have figured out most of it by now, I think. I'm just a bit frustrated with how much time I've spent on this project compared to what I spent doing the exact same thing with cPanel, simply because most of DA's API is undocumented. I'm happy to see that they're working on it, though!

Also, it looks like there's very little input validation in the DA API - I'm allowed to put almost anything I want into the DNS, so I really, really have to make sure that everything is tight and secure in my end (which I always do, but I would have liked that extra layer of security). At least there's not many restrictions to care about. 🤪
 
I understand what you mean. I almost don't use api's in my system.
However, you have a good point as probably more ex cPanel customers might want to make use of api calls and maybe more input validation.
It might be a good idea maybe to put in a request for something like that in the new request system. They are improving lots of things so one never knows.
 
Back
Top