Discuss mailing list

[Jeff Taylor <shdwdrgn AT sourpuss.net>]

Domain zones are updated the same same way you do it now... If there is a change made that requires an update, I have a script that will create the new zone file and generate a new serial for that file.  If you are the administrator of a TLD, you can run the script at set times to check for updates, and when you reload your nameserver with the file changes it will announce that there are new zone files available.

It is also configured so that users can create simple zones files for their domains and the TLD server will host those records.  For the domains created that way, the above script will also generate a file that you can include in named.conf.

As an example, please browse through http://opennic.oss/reg/zone.oss/
The file "oss" is the TLD file which includes all NS pointers where the users host their own dns zones.  For any complex zone files that I am hosting from my own server, you will see entries pointing at ns1.sourpuss.net (my dns server), and you will also find separate files in the same folder for those domains, plus an entry in the named.conf file.

On 03/10/2014 07:06 AM, Alejandro Bonet wrote:

Well...

This is a Babel Tower!!

When the system Jeff is coding will be completed, please, tell my how
can i permit my
customers to update their RR records under opennic tlds...


Alejandro Bonet
albogoal AT gmail.com

PD: A registry is a web page.
Another registry is another web page.

There must be an automated protocol between registry web pages to update data,
because to test if a domain is available, dig will be sufficient.

If my web server tries to make a change (triggered allways by an
identified customer) in another web page, it is my web page server
responsability...

Not everybody uses the same programming languages or database models!!

But the data to exchange is clear: Resource Record Changes.

And the roles of web servers is clear also: One client making the
changes, and one server aplying them in the underlying DNS server.

And the identification also: Web page servers with a cripto key pair,
or ssl certificate.

We only need a clear text protocol to make initial tests, and then
cipher it with a good ciphering system... (based of course on
public/private key pairs).


2014-03-09 23:06 GMT+01:00, Jeff Taylor <shdwdrgn AT sourpuss.net>:

Well if I get this reconfigured properly, basically a TLD owner would
have full control over all the domains within their TLD, and a domain
owner would have full control over any subdomains within their domain.
There needs to be varying levels of access to the TLDs and domains.
Top-level administrators need to be able to make repairs to anything
that could affect other users.

We cannot have a simple flat model where each user only gets access to
the domain or TLD they created, or things will break quickly. I've had
people asking me for help when their zone is broken, and without
administrative access, I would not be able to provide that help.

On 03/09/2014 03:44 PM, Quinn Wood wrote:

On Sunday, March 9, 2014, Jeff Taylor <shdwdrgn AT sourpuss.net
<mailto:shdwdrgn AT sourpuss.net>> wrote:

    I don't understand what you mean?

    On 03/09/2014 01:24 PM, Quinn Wood wrote:

    Might I suggest a less "top level zone" approach? The stuff
    you're designing could easily be appropriated for intra-zone use.

Instead of focusing on one type of zone is being administered (in this
case top level ones) the system should be designed so "resellers" can
maintain their own delegation of second level zones and so on.

Since all levels of zone authority operate basically the same way.



--------
You are a member of the OpenNIC Discuss list.
You may unsubscribe by emailing
discuss-unsubscribe AT lists.opennicproject.org

--------
You are a member of the OpenNIC Discuss list. 
You may unsubscribe by emailing discuss-unsubscribe AT lists.opennicproject.org