The Ultimate Guide for Subdomains with NameServes

The Ultimate Guide for Subdomains with NameServes (and DNS Zones/files) aka subzone

I've seen many people here trying to use subdomains on diferent hosts or even dynamic-ip (like no-ip).
I too have tried many times, until I recently figured out the step that I was missing.
Every new zone (for a top level domain or a subdomain) requires a name server where she SOA is located. Root Name servers only store information of first level domains, for example, DOMAIN.COM. For subdomains, this information is kept on the name servers responsible for the domain SOA zone.
The procedure that I indicate here is only valid for subdomains that use a diferent zone, and not the usual subdomains without a zone file.

So last start. If one has the domain DOMAIN.COM on a server and requires for the subdomain EXE.DOMAIN.com to be on another here whats we need:
For each subdomian we need a NS to handle the SOA file / DNS zone, so it looks like this: NSx.EXE.DOMAIN.com.
This new NS must have the A-Records on the parent domain ( on the DOMAIN.COM zone file ), much similar to the same way that private nameservers are done ( the owner of a domain must ask the registar to make to A-records for the ip of the NS, and then point the domain to them ).
Then on the subdomain zone, one adds the NS for that domain and the A-record ( along with any need MX record, etc ). It is necessary to once again place the NameServers IP as A-records to allow "glue" between the parent zone and this zone.
And thats it.

Now the zone files:
on the parent zone, you have:
NS1.DOMAIN.COM. in SOA admin.DOMAIN.COM

NS1.DOMAIN.COM. A 127.0.0.2 // for glue
NS1.DOMAIN.COM. A 127.0.0.3 // for glue
DOMAIN.COM. NS NS1.DOMAIN.COM.
DOMAIN.COM. NS NS2.DOMAIN.COM.
DOMAIN.COM. A 127.0.0.1
WWW.DOMAIN.COM. CNAME DOMAIN.COM.
DOMAIN.COM. MX 0 127.0.0.1
mail.DOMAIN.COM. MX 0 127.0.0.1

NS1.EXE.DOMAIN.COM. A 127.0.1.2 // for the subdomain
NS1.EXE.DOMAIN.COM. A 127.0.1.3 // for the subdomain

on the subdomain zone, you have:
NS1.EXE.DOMAIN.COM. in SOA admin.DOMAIN.COM

EXE.DOMAIN.COM. NS NS1.DOMAIN.COM.
EXE.DOMAIN.COM. NS NS2.DOMAIN.COM.
EXE.DOMAIN.COM. A 127.0.1.1
WWW.EXE.DOMAIN.COM. CNAME EXE.DOMAIN.COM.
DOMAIN.COM. MX 0 127.0.1.1
mail.DOMAIN.COM. MX 0 127.0.1.1

NS1.EXE.DOMAIN.COM. A 127.0.1.2 // for glue
NS1.EXE.DOMAIN.COM. A 127.0.1.3 // for glue

Don't get me wrong, but ... why are you posting this, here ? The wiki might have room for that sort of guide, though you fail to mention a motivation for what you do.

If all you wanted were domains of the form

something.example.com
somethingelse.example.com

or even

here.something.example.com
andhere.something.example.com

You do not need to explicitly delegate the authority for something.example.com to another nameserver; it's perfectly valid for the A records to be in the example.com zone (i.e. here.something IN A 127.0.0.X).

You should also probably mention that your example IPs are all just that, and in the local ip space in your example.

Last, but not least, a minor style point :

WWW.DOMAIN.COM. CNAME DOMAIN.COM.
WWW.EXE.DOMAIN.COM. CNAME EXE.DOMAIN.COM.

That's bad form and should be avoided unless absolutely necessary (for instance if the name you point to sits in a different zone and you personally have no control over that other zone and the A records therein). CNAMEs are, at best, an extra lookup. They also carry some semantic salt though, which you may or may not want (for instance, in the above if you define an MX record for example.com, the CNAME will essentially declare one for www.example.com as well). A plain old A-record would do (i.e. www.domain.com. A 127.0.0.1) instead of the CNAME, be faster on your visitors, and not necessarily incurr other interesting side-effects.

Speaking of MX records ...
DOMAIN.COM. MX 0 127.0.0.1
mail.DOMAIN.COM. MX 0 127.0.0.1

Yeah. no. Another bad form. Why define MXs for two different subdomains ? (the second line in there is only useful if you want an explicit @mail.domain.com email host). If you want more control over the IP you could do

DOMAIN.COM. MX 0 mail.domain.com
mail.domain.com. A 127.0.0.1

It's a nit, but this one is a wee bit more elegant. You don't actually lead anybody to believe that there is a @mail.domain.com email domain that way (although if people address mail to @mail.domain.com, most SMTP relays will use the A record in absence an explicit MX).

You mention glue :

NS1.DOMAIN.COM. A 127.0.0.2 // for glue
NS1.DOMAIN.COM. A 127.0.0.3 // for glue

Note that this is not glue. You mention this as part of the parent zone file, i.e. the DOMAIN.COM zone. In there this is not glue at all. It would be glue in the .COM name server. In this case it's just a plain old A-record without any special powers (though you are in deep **** if these A records do not match the glue at your registrar). Further down you use actual glue, but label it as "for the subdomain". Confusing for DNS beginners.

Last, but certainly not least, you try to define

DOMAIN.COM. MX 0 127.0.1.1
mail.DOMAIN.COM. MX 0 127.0.1.1

in the delegated zone. That's useless. You already defined those in the superzone of it, and no mailserver will ever ask the delegated nameserver about this (unless you use that nameserver as a resolver as well, which is probably not a good idea in any case :-)

Just pointing these things out; while the configuration may work for something you needed it to, if others use this as an example, they'll set themselves up for a fun evening of debugging weird errors down the line (when they've adapted the config to something else, going by the comments and the style you use :-)

Hya.
Thanks for the tips.

In reply to:
Don't get me wrong, but ... why are you posting this, here ? The wiki might have room for that sort of guide, though you fail to mention a motivation for what you do.

I need it here on DH.
While trying the best way, I've found this, and I thought it would be a good idea to share.
After some more inputs, I might put it on wiki.

In reply to:
You do not need to explicitly delegate the authority for something.example.com to another nameserver; it's perfectly valid for the A records to be in the example.com zone (i.e. here.something IN A 127.0.0.X).

Well, when one needs for the secondary zone just to manage everything, even new A-records, or new subdomains, I've found that this is the best way, because one does not need to edit the parent zone any more.

In reply to:
Last, but not least, a minor style point :

WWW.DOMAIN.COM. CNAME DOMAIN.COM.
WWW.EXE.DOMAIN.COM. CNAME EXE.DOMAIN.COM.

That's bad form and should be avoided unless absolutely necessary (for instance if the name you point to sits in a different zone and you personally have no control over that other zone and the A records therein). CNAMEs are, at best, an extra lookup. They also carry some semantic salt though, which you may or may not want (for instance, in the above if you define an MX record for example.com, the CNAME will essentially declare one for www.example.com as well). A plain old A-record would do (i.e. www.domain.com. A 127.0.0.1) instead of the CNAME, be faster on your visitors, and not necessarily incurr other interesting side-effects.

You are right, and I'll edit my first post if still possible

In reply to:
Speaking of MX records ...
DOMAIN.COM. MX 0 127.0.0.1
mail.DOMAIN.COM. MX 0 127.0.0.1

Once again, I didnt knew of a better way, but now, you have taught it to me.

In reply to:
Last, but certainly not least, you try to define

DOMAIN.COM. MX 0 127.0.1.1
mail.DOMAIN.COM. MX 0 127.0.1.1

in the delegated zone. That's useless. You already defined those in the superzone of it, and no mailserver will ever ask the delegated nameserver about this (unless you use that nameserver as a resolver as well, which is probably not a good idea in any case :-)

Just pointing these things out; while the configuration may work for something you needed it to, if others use this as an example, they'll set themselves up for a fun evening of debugging weird errors down the line (when they've adapted the config to something else, going by the comments and the style you use :-)

duh...
typo, of copy-past
it was supposed to be for the subdomain MX

EXE.DOMAIN.COM. MX 0 mail.domain.com
mail.EXE.domain.com. A 127.0.0.1

The Ultimate Guide for Subdomains with NameServes