Re: DNS: SRS mechanism

Re: DNS: SRS mechanism

From: Deus Ex Machina <vicc§cia.com.au>
Date: Wed, 25 Feb 1998 11:40:27 +1100 (EST)
>_From: Robert Elz
> 
>     Date:        Tue, 24 Feb 1998 02:33:31 +1100 (EST)
>     From:        Deus Ex Machina <vicc&#167;cia.com.au>
>     Message-ID:  <199802231533.CAA22720&#167;cia.com.au>
> 
>   | pr.au and tm.au is just a bandaid solution to rectify a problem which
>   | is more easily fixed by proper competition.
> 
> I personally tend to agree, though perhaps not for the reasons you do.
> I don't believe that products, trade marks, and such, belong in the DNS
> at all, putting them there is indeed a bandaid, until a directory in
> which they can be better placed comes along.

why is it you dont belevie people should be free to choose the names
they want for their IP addresses? why restrict them? this is plain wrong
and immoral.


>   | I would suggest incoming details should be pending-locked for a certain
>   | number of hours for the registry who first got the update,
> 
> That's perhaps part of a solution, it actually turns out to not be at
> all easy when you start looking at all the border cases - I know, I see
> these things happening now, and basically resolve them using human
> intelligence (ie: ask people...)   There are so many cases which look
> identical when all you see is the request, but actually are quite different
> that it is very hard to automate any kind of distinction.
> 
> Eg: the simple case, a client switches from one registry to another, clearly
> the info from the new registry should be preferred over the info from the
> old one.    Then, client has two service providers (typically this is one for
> their WWW pages, and the other for e-mail and general IP connectivity).  One
> is there first, and has registered the domain with one registry.  The
> client then gets the second service from the other ISP, which registers their
> domain name with their preferred registry (and their servers of course).
> To the zone file maker this looks just like the first case, but actually
> is totally different.   Then there's the case where the first example has
> happened, but someone in the client organisation accidentally pays an
> invoice from the first registry, which then re-instates their information
> (and looks to the zone keeper as if the client has switched back).
> 
> Now depending upon how the zone file is actually being built there
> are various problems - either the zone file builder maintains the data,
> the registries send uin updates - that causes bad updates to be made in
> some of those cases.  Or the registries send in their sets of information
> as they want it (complete) every time a new zone file is to be built,
> in which case the above cases cause conflicting information, and the zone
> file has to pick one, or simply omit the domain completely.   That probably
> means "pick one" applies, and the sane one to pick would seem to be the
> status quo (whatever applied previously)(.  Of course, that makes it real
> hard to change registries in the face of a registry that won't delete its
> old information (like: we have been paid until the end of the year, you
> want to switch because we're giving lousy service, tough, we've been paid,
> we're contractually bouind to keep publishing the info until then...)

registries should not own any information, the zone keeper should
own the information, that should be the official copy. the borderline
problems are really not the zone keepers problem. if a client stuffs up
its the clients problem. registrars have to have some value added service
ie make an easy efficient interface with a real turn around time. 
I think 2 hours is adequate for the time being.

registries responsiblities should end when they submit the info
to the zone keeper. if clients want to resubmit through another registry
then that then becomes the current information. registries should
contribute part of them money raised towards upkeep of the zone
keeper. by eliminating registry ownership of any info you eliminate
most of the problems. you also protect the dns from registries going
belly up.


>   | no. MIT cant uniformely enforce its own rules, how do you expect X
>   | separate companies to enforce them.
> 
> It is necessary.

precisely why is it necessary?

>   | forcing other registries to
>   | have the same rules defeats the purpose of competition.
> 
> No, competition is so you can get the best service (timely processing,
> assistance when things aren't working etc) at the lowest price.

yes. and it is up to the registry to decide the level of balls
it has regarding what risk they want to accept in relation to
what names they are willing to issue.  the current scenario
is not in the public interest.

>   | there are no good justifications for the current rules,
> 
> I think we can disagree about that.

well times have changed since these rules were brought into being
and its time we re-examined them, and started giving the public
some freedoms back.

Vic
Received on Wed Feb 25 1998 - 11:47:57 UTC

This archive was generated by hypermail 2.3.0 : Sat Sep 09 2017 - 22:00:03 UTC