use of "rev-srv" attribute in "inetnum" (and "inet6num") objects
Dear colleagues, rather recently I was involved in clearing up some old inetnum assignments in the RIPE database. During that archaeologic work a couple of objects with the "rev-srv" attribute were discovered and it turned out that the presence of this attribute not necessarily contributed to an easy solution. The rev-srv attribute was intended to specify the name servers for the "reverse mapping" for a given address range. However, it is just informative in nature. For quite some time now the automatic generation of the IN-ADDR.ARPA zones has been based solely on the "domain" objects (see <http://www.ripe.net/reverse/>). So, it turns out "rev-srv" has some disadvantages: (D1) the "rev-srv" attribute is redundant, because only "domain" objects cause delegations to be present in reverse zone maintained by the NCC (D2) "rev-srv" lacks consistency checks with both the reality and any potential "domain" object; several attributes just contain incorrect information (D3) the "rev-srv" attribute does not really help finding the zone for address ranges smaller than /24 (where delegations are following RFC 2317) On the other hand, it might still have advantages: (A1) where there is a delegation from an NCC maintained zone to an LIR for, say, a /16 address range, the "rev-srv" attribute for enclosed /24s may provide useful additional information (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 (A3) "rev-srv" attributes could provide additional information in legacy class B space (D1), (D2), and (A1) similarly apply to v6 reverse and inet6num objects. Today, approximately 5% of all "inetnum" objects have at least one "rev-srv" attribute. Of these objects, 17% have been changed in 2007 (which does not imply the rev-srv was changed or checked), and 35% were changed in 2006 or 2007. That means "rev-srv" does not only appear in old objects, but may still be carried as a legacy. The objects with "rev-srv" are maintained by 1300 different maintainers, almost 500 of which own only a single object with "rev-srv". Given the confusion mentioned in the introduction and looking at the pros and cons (where the lists above are not meant to be exhaustive), what is the use of "rev-srv" for a "user" of the object or for its publisher/maintainer? 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? -Peter (speaking as $self)
Hi, Peter Koch schrieb: [...]
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?
i actually see no real sense in it anymore either, and some people seem to use rev-srv even in NEW objects. So my opinion on this is rather to remove it the sooner the better - as long as it _really_ doesn't serv any purpose anymore. Since i'm not really "interested" in the database that much (i just "use" it - i'm no database person :-), i'm not 100% sure that there is no hidden sense in keeping this attribute. My thoughts on that always was "there surely must be some reason that it is still there". If not, dump it. -- ======================================================================== = Sascha Lenz SLZ-RIPE slz@baycix.de = = Network Operations = = BayCIX GmbH, Landshut * PGP public Key on demand * = ========================================================================
--On lördag, lördag 31 mar 2007 22.32.46 +0200 Peter Koch <pk@DENIC.DE> wrote:
So, it turns out "rev-srv" has some disadvantages:
(D1) the "rev-srv" attribute is redundant, because only "domain" objects cause delegations to be present in reverse zone maintained by the NCC (D2) "rev-srv" lacks consistency checks with both the reality and any potential "domain" object; several attributes just contain incorrect information (D3) the "rev-srv" attribute does not really help finding the zone for address ranges smaller than /24 (where delegations are following RFC 2317)
The worst part here probably is ambiguity.
On the other hand, it might still have advantages:
(A1) where there is a delegation from an NCC maintained zone to an LIR for, say, a /16 address range, the "rev-srv" attribute for enclosed /24s may provide useful additional information
MAY, yes, but not "will". DNS is probably better maintained (not that it is good, but probably better.)
(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
dig +trace is your friend.
(A3) "rev-srv" attributes could provide additional information in legacy class B space
This is A1 again. I think the objects can be disregarded, if not outright discarded. -- Måns Nilsson Systems Specialist +46 70 681 7204 cell KTHNOC +46 8 790 6518 office MN1334-RIPE INSIDE, I have the same personality disorder as LUCY RICARDO!!
On Mar 31, 2007, at 9:32 PM, Peter Koch wrote: [...]
Today, approximately 5% of all "inetnum" objects have at least one "rev-srv" attribute. Of these objects, 17% have been changed in 2007 (which does not imply the rev-srv was changed or checked), and 35% were changed in 2006 or 2007. That means "rev-srv" does not only appear in old objects, but may still be carried as a legacy. The objects with "rev-srv" are maintained by 1300 different maintainers, almost 500 of which own only a single object with "rev-srv".
Do you know what percentage of rev-srv records are fully or partially accurate? Regards, -- Leo Vegoda IANA Numbers Liaison
On Sun, Apr 01, 2007 at 03:37:56PM +0100, Leo Vegoda wrote:
Do you know what percentage of rev-srv records are fully or partially accurate?
I had hoped to be able to avoid this :-) Seriously, that depends on what you consider accurate - or even 'partially accurate'. Is it reality or what the domain: objects say? And is reality what the delegation says or what the authoritative NS RRSet suggests? Just one example: 1000 out of ~ 6000 name servers pointed at by rev-srv attributes didn't even resolve. Whether that's good or bad depends on what the quality of the domain: objects' nserver: attributes looks like. For a match between rev-srv: and nserver: I've tried to get hold of those address ranges greater or equal than /24, postulating /24 or /16 equivalent in-addr.arpa domains where appropriate. The calculation is very rough since /24s may be covered by /16s and sometimes there are domain: objects for both the /16 and (some of) the lower /24s as well (which is confusing in and of itself). With all caveats, out of 38000 candidate domain: objects, only about 50% were actually present. Of those, approximately 2/3 had the same idea of the NS RRSet as the inetnum: object. For those disagreeing, there might be overlaps ("partially accurate") or disjoint sets. -Peter
On Apr 2, 2007, at 4:00 PM, Peter Koch wrote:
On Sun, Apr 01, 2007 at 03:37:56PM +0100, Leo Vegoda wrote:
Do you know what percentage of rev-srv records are fully or partially accurate?
I had hoped to be able to avoid this :-)
[analysis snipped] I must admit that I've always thought of rev-srv as misinformation rather than useful information. I think you've demonstrated that it's difficult to use and doesn't reflect reality well. Seeing as a mechanism for auto-populating rev-srv fields with accurate information is likely to open up a new world of pain, deprecating it sounds like a good way of improving the accuracy of DNS data in the RIPE database. Regards, -- Leo Vegoda IANA Numbers Liaison
Hi,
I must admit that I've always thought of rev-srv as misinformation rather than useful information. I think you've demonstrated that it's difficult to use and doesn't reflect reality well.
Seeing as a mechanism for auto-populating rev-srv fields with accurate information is likely to open up a new world of pain, deprecating it sounds like a good way of improving the accuracy of DNS data in the RIPE database.
Sounds to me like we should get rid of it as soon as possible. I certainly wouldn't miss it. And wrong / conflicting information in the RIPE db should be avoided (where posible). - Sander
On Sat, Mar 31, 2007 at 10:32:46PM +0200, Peter Koch wrote: Hi,
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?
In my personal opinion it is useless nowadays. I believe it should be removed. Regards, Piotr Strzyżewski -- gucio -> Piotr Strzyżewski E-mail: Piotr.Strzyzewski@polsl.pl
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 31 Mar 2007, at 21:32, Peter Koch wrote:
That said, what do you think about deprecating the "rev-srv" attribute?
Deprecate! /Niall -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFGEMeReYfkja6ZXtkRAl8jAJ0TWP6X1UDaoyDMhB5bfnjLi+NUkwCcD5tG eVSX22Sl6T6l2P1+p2wL3zs= =Rw3R -----END PGP SIGNATURE-----
On Sat, Mar 31, 2007 at 10:32:46PM +0200, Peter Koch wrote:
Dear colleagues,
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). Regards, Andre Koopal -- Andre Koopal EMEA Server & Service Management - EMEA O&T Verizon Business H.J.E. Wenckebachweg 123 1096 AM Amsterdam Netherlands VNET: 711 6990 tel : +31 (0)20 711 6990 fax : +31 (0)20 711 2519 Verizon Business - global capability. personal accountability. This e-mail is strictly confidential and intended only for use by the addressee unless otherwise indicated. Verizon Nederland B.V. - H.J.E. Wenckebachweg 123, 1096 AM, Amsterdam, the Netherlands - Commercial Register No. 34199467
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
participants (9)
-
Andre Koopal -
Janos Zsako -
Leo Vegoda -
Måns Nilsson -
Niall O'Reilly -
Peter Koch -
Piotr Strzyzewski -
Sander Steffann -
Sascha Lenz