193.in-addr.arpa block delegation procedures (draft)

 bonito at nis.garr.it (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