[dns-wg] use of "rev-srv" attribute in "inetnum" (and "inet6num") objects

Dear all,

>>The DB WG chairs' advice was that the purpose and/or future of "rev-srv"
>>should be discussed here first.  That said, what do you think about
>>deprecating the "rev-srv" attribute?
> 
> Deprecate it, perhaps in 2 steps (first make sure it can't be inserted
> anymore, and updated objects can't have it, remove from old objects later).

Yes, I think this is a wise approach, I support it.

Keeping the inetnum in sync with DNS (domain objects) seems to be a
hopeless task, if not enforced by the automatic in-addr.arpa zone
generation.

Having only inetnum defining the reverse zones is not an alternative
(due to assignment longer than /24).

Hence inetnum/rev-srv is redundant.

Peter originally said:

 >>(A2) even if the leaf zone name cannot be guessed for RFC 2317 delegations,
 >>     the "rev-srv" attribute might help in locating the zone containing the
 >>     CNAME RRs

I do not think this helps. If you cannot guess the domain name
(e.g. 0/25.2.0.192.in-addr.arpa), knowing that the zone is on
ns.A.domain and some.other.name.server (expample on page 2 of
RFC 2317) is of no help in my view. At the same time, you can
easily get the domain name with a `host -a 1.0.192.in-addr.arpa`
query on a recursive server. Therefore I do not think this is
a valid reason for keeping rev-srv.

Having outdated/erroneous data in the DB is not desirable at all.

In short: I think rev-srv can be deprecated.

Best regards,
Janos