Does a multi-level hostname makes a practical difference?

Multi tool use
The A
record for hello.world.example.com
can be registered
- as the
hello
entry in the domainworld.example.com
- or as the
hello.world
entry in the domainexample.com
Is there a practical difference, from the perspective of the services which resolve the name, between these two approaches?
As far as I can tell, the resolution of both of them yields the value A record (the IP) so the replies are not discernable for the client.
domain-name-system dns-zone
add a comment |
The A
record for hello.world.example.com
can be registered
- as the
hello
entry in the domainworld.example.com
- or as the
hello.world
entry in the domainexample.com
Is there a practical difference, from the perspective of the services which resolve the name, between these two approaches?
As far as I can tell, the resolution of both of them yields the value A record (the IP) so the replies are not discernable for the client.
domain-name-system dns-zone
add a comment |
The A
record for hello.world.example.com
can be registered
- as the
hello
entry in the domainworld.example.com
- or as the
hello.world
entry in the domainexample.com
Is there a practical difference, from the perspective of the services which resolve the name, between these two approaches?
As far as I can tell, the resolution of both of them yields the value A record (the IP) so the replies are not discernable for the client.
domain-name-system dns-zone
The A
record for hello.world.example.com
can be registered
- as the
hello
entry in the domainworld.example.com
- or as the
hello.world
entry in the domainexample.com
Is there a practical difference, from the perspective of the services which resolve the name, between these two approaches?
As far as I can tell, the resolution of both of them yields the value A record (the IP) so the replies are not discernable for the client.
domain-name-system dns-zone
domain-name-system dns-zone
edited 10 hours ago
WoJ
asked 11 hours ago
WoJWoJ
1,40832444
1,40832444
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
There will be potentially be an extra delay as creating a separate zone for the world.example.com
subdomain typically also implies delegation to different authoritative name servers.
If the same authoritative nameservers are used for both the example.com
and the world.example.com
zones there is no performance difference.
DNS resolvers need to follow the delegation from the TLD to an authoritative name server.
When the resolver reaches authoritative name servers for the example.com
domain and you have a resource record for hello.world(.example.com.)
in that zone a response will sent immediately.
If the authoritative name servers for the example.com
domain are also authoritative for the world.example.com
sub-domain, the response for the hello.world.example.com.
record will also be sent immediately.
If world.example.com
is configured as separate a zone the authoritative name servers for the example.com
will send a response with further delegation details and the NS
record(s) of authoritative name servers for the world.example.com.
zone:
world.example.com. IN NS ns.world.example.com.
world.example.com. IN NS ns1.example.org.
; GLUE
ns.world.example.com. IN A 192.2.0.1
The resolver will need to follow that delegation and sent extra queries to:
- potentially locate those name servers (for example in the case of the ns1.example.org. NS record)
- query one of the authoritative name servers for the
world.example.com.
zone for thehello(.world.example.com.)
record.
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP forhello.world.example.com
), correct?
– WoJ
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
add a comment |
Technically, as I understand DNS, only the hello
part is considered the host name, the rest is the domain name. As such, it resolves the same way, in your case the DNS zone includes both the example.com
and the subdomain world.example.com
, it's just a matter of preference how you annotate it.
However, the only time I've ever seen records like that are for DKIM and other TXT records, for example DKIM uses [selector]._domainkey
as the record for a given subdomain or the root domain. Handy of course if you only need a couple of records for a subdomain, no need to create a separate zone for them.
1
I know that it is possible to differentiate between them (by querying theSOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.
– WoJ
10 hours ago
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f952945%2fdoes-a-multi-level-hostname-makes-a-practical-difference%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There will be potentially be an extra delay as creating a separate zone for the world.example.com
subdomain typically also implies delegation to different authoritative name servers.
If the same authoritative nameservers are used for both the example.com
and the world.example.com
zones there is no performance difference.
DNS resolvers need to follow the delegation from the TLD to an authoritative name server.
When the resolver reaches authoritative name servers for the example.com
domain and you have a resource record for hello.world(.example.com.)
in that zone a response will sent immediately.
If the authoritative name servers for the example.com
domain are also authoritative for the world.example.com
sub-domain, the response for the hello.world.example.com.
record will also be sent immediately.
If world.example.com
is configured as separate a zone the authoritative name servers for the example.com
will send a response with further delegation details and the NS
record(s) of authoritative name servers for the world.example.com.
zone:
world.example.com. IN NS ns.world.example.com.
world.example.com. IN NS ns1.example.org.
; GLUE
ns.world.example.com. IN A 192.2.0.1
The resolver will need to follow that delegation and sent extra queries to:
- potentially locate those name servers (for example in the case of the ns1.example.org. NS record)
- query one of the authoritative name servers for the
world.example.com.
zone for thehello(.world.example.com.)
record.
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP forhello.world.example.com
), correct?
– WoJ
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
add a comment |
There will be potentially be an extra delay as creating a separate zone for the world.example.com
subdomain typically also implies delegation to different authoritative name servers.
If the same authoritative nameservers are used for both the example.com
and the world.example.com
zones there is no performance difference.
DNS resolvers need to follow the delegation from the TLD to an authoritative name server.
When the resolver reaches authoritative name servers for the example.com
domain and you have a resource record for hello.world(.example.com.)
in that zone a response will sent immediately.
If the authoritative name servers for the example.com
domain are also authoritative for the world.example.com
sub-domain, the response for the hello.world.example.com.
record will also be sent immediately.
If world.example.com
is configured as separate a zone the authoritative name servers for the example.com
will send a response with further delegation details and the NS
record(s) of authoritative name servers for the world.example.com.
zone:
world.example.com. IN NS ns.world.example.com.
world.example.com. IN NS ns1.example.org.
; GLUE
ns.world.example.com. IN A 192.2.0.1
The resolver will need to follow that delegation and sent extra queries to:
- potentially locate those name servers (for example in the case of the ns1.example.org. NS record)
- query one of the authoritative name servers for the
world.example.com.
zone for thehello(.world.example.com.)
record.
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP forhello.world.example.com
), correct?
– WoJ
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
add a comment |
There will be potentially be an extra delay as creating a separate zone for the world.example.com
subdomain typically also implies delegation to different authoritative name servers.
If the same authoritative nameservers are used for both the example.com
and the world.example.com
zones there is no performance difference.
DNS resolvers need to follow the delegation from the TLD to an authoritative name server.
When the resolver reaches authoritative name servers for the example.com
domain and you have a resource record for hello.world(.example.com.)
in that zone a response will sent immediately.
If the authoritative name servers for the example.com
domain are also authoritative for the world.example.com
sub-domain, the response for the hello.world.example.com.
record will also be sent immediately.
If world.example.com
is configured as separate a zone the authoritative name servers for the example.com
will send a response with further delegation details and the NS
record(s) of authoritative name servers for the world.example.com.
zone:
world.example.com. IN NS ns.world.example.com.
world.example.com. IN NS ns1.example.org.
; GLUE
ns.world.example.com. IN A 192.2.0.1
The resolver will need to follow that delegation and sent extra queries to:
- potentially locate those name servers (for example in the case of the ns1.example.org. NS record)
- query one of the authoritative name servers for the
world.example.com.
zone for thehello(.world.example.com.)
record.
There will be potentially be an extra delay as creating a separate zone for the world.example.com
subdomain typically also implies delegation to different authoritative name servers.
If the same authoritative nameservers are used for both the example.com
and the world.example.com
zones there is no performance difference.
DNS resolvers need to follow the delegation from the TLD to an authoritative name server.
When the resolver reaches authoritative name servers for the example.com
domain and you have a resource record for hello.world(.example.com.)
in that zone a response will sent immediately.
If the authoritative name servers for the example.com
domain are also authoritative for the world.example.com
sub-domain, the response for the hello.world.example.com.
record will also be sent immediately.
If world.example.com
is configured as separate a zone the authoritative name servers for the example.com
will send a response with further delegation details and the NS
record(s) of authoritative name servers for the world.example.com.
zone:
world.example.com. IN NS ns.world.example.com.
world.example.com. IN NS ns1.example.org.
; GLUE
ns.world.example.com. IN A 192.2.0.1
The resolver will need to follow that delegation and sent extra queries to:
- potentially locate those name servers (for example in the case of the ns1.example.org. NS record)
- query one of the authoritative name servers for the
world.example.com.
zone for thehello(.world.example.com.)
record.
edited 10 hours ago
answered 10 hours ago


HBruijnHBruijn
54k1087145
54k1087145
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP forhello.world.example.com
), correct?
– WoJ
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
add a comment |
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP forhello.world.example.com
), correct?
– WoJ
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP for
hello.world.example.com
), correct?– WoJ
10 hours ago
Thank you. So this is rather a matter of performance in the resolution (or speed / easiness of setup) more than technical differences in the response (for a client requesting a resolution, it will not make a difference, it will get an IP for
hello.world.example.com
), correct?– WoJ
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
Yes, either way the resolver should get a response with an ip-address for hello.world.example.com.
– HBruijn
10 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
@WoJ, it's usually more a matter of administration — you'd delegate the zone if it is easier to maintain this way. The performance difference is usually negligible.
– Simon Richter
6 hours ago
add a comment |
Technically, as I understand DNS, only the hello
part is considered the host name, the rest is the domain name. As such, it resolves the same way, in your case the DNS zone includes both the example.com
and the subdomain world.example.com
, it's just a matter of preference how you annotate it.
However, the only time I've ever seen records like that are for DKIM and other TXT records, for example DKIM uses [selector]._domainkey
as the record for a given subdomain or the root domain. Handy of course if you only need a couple of records for a subdomain, no need to create a separate zone for them.
1
I know that it is possible to differentiate between them (by querying theSOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.
– WoJ
10 hours ago
add a comment |
Technically, as I understand DNS, only the hello
part is considered the host name, the rest is the domain name. As such, it resolves the same way, in your case the DNS zone includes both the example.com
and the subdomain world.example.com
, it's just a matter of preference how you annotate it.
However, the only time I've ever seen records like that are for DKIM and other TXT records, for example DKIM uses [selector]._domainkey
as the record for a given subdomain or the root domain. Handy of course if you only need a couple of records for a subdomain, no need to create a separate zone for them.
1
I know that it is possible to differentiate between them (by querying theSOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.
– WoJ
10 hours ago
add a comment |
Technically, as I understand DNS, only the hello
part is considered the host name, the rest is the domain name. As such, it resolves the same way, in your case the DNS zone includes both the example.com
and the subdomain world.example.com
, it's just a matter of preference how you annotate it.
However, the only time I've ever seen records like that are for DKIM and other TXT records, for example DKIM uses [selector]._domainkey
as the record for a given subdomain or the root domain. Handy of course if you only need a couple of records for a subdomain, no need to create a separate zone for them.
Technically, as I understand DNS, only the hello
part is considered the host name, the rest is the domain name. As such, it resolves the same way, in your case the DNS zone includes both the example.com
and the subdomain world.example.com
, it's just a matter of preference how you annotate it.
However, the only time I've ever seen records like that are for DKIM and other TXT records, for example DKIM uses [selector]._domainkey
as the record for a given subdomain or the root domain. Handy of course if you only need a couple of records for a subdomain, no need to create a separate zone for them.
answered 10 hours ago
StuggiStuggi
593210
593210
1
I know that it is possible to differentiate between them (by querying theSOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.
– WoJ
10 hours ago
add a comment |
1
I know that it is possible to differentiate between them (by querying theSOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.
– WoJ
10 hours ago
1
1
I know that it is possible to differentiate between them (by querying the
SOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.– WoJ
10 hours ago
I know that it is possible to differentiate between them (by querying the
SOA
for instance) and this is why I added the "practical" aspect of the differentiation. Your examples for DKIM are good ones of a real-life case of such entries.– WoJ
10 hours ago
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f952945%2fdoes-a-multi-level-hostname-makes-a-practical-difference%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
var $window = $(window),
onScroll = function(e) {
var $elem = $('.new-login-left'),
docViewTop = $window.scrollTop(),
docViewBottom = docViewTop + $window.height(),
elemTop = $elem.offset().top,
elemBottom = elemTop + $elem.height();
if ((docViewTop elemBottom)) {
StackExchange.using('gps', function() { StackExchange.gps.track('embedded_signup_form.view', { location: 'question_page' }); });
$window.unbind('scroll', onScroll);
}
};
$window.on('scroll', onScroll);
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
YwD eDX9uGweQz,STsRGb11o