Re: Handling of External Host Objects

[janusz sienkiewicz <janusz@libertyrms.info>]

I assume that with the new external host approach domain transfer process would
be simplified. No error code 2305 for transfer requests and approvals.

Regards,

Janusz Sienkiewicz

"Hollenbeck, Scott" wrote:

> One of the reasons I think that this external host thing continues to be an
> issue is because it's a kludge.  I firmly believe that the only objects that
> should exist in a repository are objects for which the repository is
> authoritative.  Other needed data should exist as attributes of existing
> objects.
>
> I suggested this concept related to external hosts back when the topic first
> came up.  Some folks had issues with it, but I'll suggest it again as an
> alternative.  In a nutshell:
>
> - The only objects that should exist in a repository are objects for which
> the repository is authoritative.
>
> - Host objects should only be created in a repository that is authoritative
> for the host.  In the case of hosts as name servers, "authoritative" means
> that data in the repository (host name and address(es)) is used to publish
> DNS glue and the repository is the legitimate source for that data.
>
> - If an external host is needed for delegation purposes, it can be
> associated with a domain object as an attribute of the object with no host
> object needed in advance.  There's no need to create an external host object
> ahead of time, no need to worry about IP addresses, etc.
>
> This solution does not allow object-based management of external hosts,
> which means that renaming the external host would need to be done on a
> per-name basis.  It may address the other issues that people have talked
> about on this thread, though.
>
> I know this means that a domain can be associated with hosts as objects and
> host as attributes and some people think that's inconsistent.  I don't think
> it is if you agree with the first point above.
>
> -Scott-