[dns-operations] subzone delegation best practice

[Grant Taylor]

On 09/25/2018 12:19 PM, Sue Steffen wrote:
> I would like to get the opinions of this list concerning subzone 
> delegations to 3rd parties.

Aside:  I think you mean sub-domains and / or separate domains.  Zones 
are closely related, but distinct.  Namely, there is no such thing as a 
sub-zone.  Sub-domain(s) can be part of the parent zone, or in their own 
zone.

> We also have a multitude of 3rd party vendors providing various niche 
> services.    These vendors want to have subzones delegated to them so 
> they can manage their own email-related records an such.  Most of them 
> we have setup with their own domains to use on our behalf ( like 
> xyz-them.com <http://xyz-them.com>, xyz-those.com 
> <http://xyz-those.com>, etc).   We constantly get requests to use a 
> subzone off of our main zone for these vendors (like them.xyz.com 
> <http://them.xyz.com>, those.xyz.com <http://those.xyz.com>).

Okay.

> Is it preferable to have 3rd parties use an entirely separate zone, thus 
> protecting the reputation of our primary zone?  I worry about a mistake 
> by a vendor causing our main zone to be blacklisted.
> 
> Or is it preferable to use subzones off of the main zone, thus giving 
> the public comfort that they are clicking a link or receiving an email 
> from a valid xyz.com <http://xyz.com> site?

My personal preference is to use a sub-domain of the main domain.  This 
implies that there is a technical (thus likely also business) 
relationship between a parent domain and it's child sub-domain(s).

Anybody can go out and register secure-google.com.  But there is no 
implied relationship with the real google.com.  There /is/ implied 
relationship between secure.google.com and google.com.

> How does your firm handle 3rd party delegations?

I personally prefer delegating sub-domains as necessary.

> Thanks for your thoughts,

You're welcome.



-- 
Grant. . . .
unix || die

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3982 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20180925/85bc9307/attachment.bin>