bonito@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