Re: 193.in-addr.arpa block delegation procedures (draft)
- Date: Thu, 18 Mar 93 17:48:18 +0100
bonito@localhost (Antonio_Blasco Bonito) writes:
* Uhmmm, may be I'm wrong but I see some inconsistencies in your consideration
* of
* > blocks in 193.in-addr.arpa if the information in the database has changed.
* > They could then update their zones if needed. This however does imply that
* > the "rev-srv:" field becomes authoritative for reverse mapping (and not vi
* ce
* > versa)
*
* Here you are saying to use rev-srv which is a network tag in the database.
*
* > nserver: ns.ripe.net
* > ....
* >
* > It is a domain, so why not pick the right object for it ?
*
* Here you say that the nserver (domain tag) should be used.
*
* What you say is right, so I can agree to use domains in the database to give
* reverse servers information but then we should always use them to be consist
* ent.
*
* In this case the decision should be to avoid the usage of rev-srv network ta
* gs
* in the future and to use nserver domain tag instead for each network
* regardless of being it class B, single or block class C.
* Moreover it makes no sense to register reverse servers for a block of class
* C
* because the DNS doesn't have any knowledge of blocks: any nameserver
* manager has to register every single network in a block in the DNS.
*
* If we adopt this way of registering reverse-servers it would be wise
* to issue a recommendation to convert old rev-srv network tags into
* domain entries with nserver tags.
Yes and no inconsistent. I was just brainstorming a bit here, and since it
would be nice for some people to have the delegated blocks in the database I
was looking for a way to include them in the database. I do NOT want to
suggest here that all the rev-srv fields should be changed by sending in
in-addr,arpa domains for individual nets, just for the blocks. This might be
a bit confusing. I am just looking for possibilities that are both easy and
clear ...
-Marten
