Questions: Should we automatically make the suggested changes in the RIPE database? No.

I agree because there could be some cases which are not properly detected by the automated scripts or other cases where a dns-manager is voluntarily keeping things disalligned

Or should we send mail to the technical contacts asking them to change things? Yes.

I agree because many dns-managers do not even know of their registration problems.

We have asked the NIC accept change notices from us, so that registration of reverse servers in the database would be enough to get them into the DNS. Is this desirable? NO!!

I do not agree, I think it would be very useful to the European networking community to interact with RIPE-NCC only instead of having to interact with both RIPE-NCC and the US NIC I don't see the point in what Piet says:

These actions would bring RIPE on the edge of interfering with the responsabilities of the authoritative persons for a given zone, be it for "forward" or reverse mapping. The best RIPE can do is to send a notification to the authority of a given zone in case of obvious *errors*, NOT if servers are missing in the DB, since there may be good reason why they are "missing". Suppose I would be in foo.XX and I would have a large network with, say, 10 internal and 2 external nameservers for my domain; if I would loose connectivity to the outside world, those 10 internal nameservers would be unreachable and it would be pointless to have nameservers all over the Internet try to query them all. Therefore I would have only, say, 2 internal and the 2 external servers listed for foo.XX in the XX zone file and in the RIPE DB and I would absolutely not appreciate it if RIPE would send me time and again a notification that there are more servers for foo.XX than actually listed in the XX zone or the DB.

If you "have only, say, 2 internal and the 2 external servers listed for foo.XX in the XX zone file" how could the RIPE-NCC script discover the other 8 internal servers? Looking in glass ball? ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

> > We have asked the NIC accept change notices from us, so tha t > registration of reverse servers in the database would be > enough to get them into the DNS. Is this desirable? > NO!! I do not agree, I think it would be very useful to the European networking community to interact with RIPE-NCC only instead of having to interact with both RIPE-NCC and the US NIC Interaction is fine. But RIPE stepping into someone else's authority is quite something different!

I don't see any problem with that as long as we (european networking people) agree to send update to the RIPE-NCC instead of sending them to the NIC. This is exactly what we already do when registering new networks. Is there anybody who liked more the previous situation (having to wait many days, frequent errors in the database, etc) than the present one? I don't see any difference between registering a new network and registrering inverse nameservers for a network. I only need a place where to send my updates that can guarantee that they are put in the proper servers...

I don't see the point in what Piet says: ..... If you "have only, say, 2 internal and the 2 external servers listed for foo.XX in the XX zone file" how could the RIPE-NCC script discover the other 8 internal servers? Looking in glass ball? Reread the original message: it explicitly contained a sentence: Then a list of all reverse servers found in the DNS: which implies that DNS is queried to find all (in this case reverse) nameservers. How that's done is irrelevant.

If you do not list server in the authoritative zone file they ARE NOT FOUND in the DNS. In fact it makes no sense to list Internet unreachable servers in a zone file which is exported to the world by an Internet connected server ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

Interaction is fine. But RIPE stepping into someone else's authority is quite something different! I don't see any problem with that as long as we (european networking people) agree to send update to the RIPE-NCC instead of sending them to the NIC. RIPE-DB and DNS are entirely different objects.

Yes, indeed. Nonetheless I think it would be extremely useful for network managers in Europe to send their DNS updates to the RIPE-NCC only, knowing that they interface the NIC about the DNS root servers updates. Daniel, you can poll RIPErs on this, can you?

I would like RIPE to notify me *in some cases* about discrepancies between my entries in the RIPE-DB and my DNS entries, but I do *NOT* want RIPE to step into my authority by asking or telling the NIC to change *MY* DNS info because they found discrepancies: I may well have good reason why those discrepancies exist. If someone in Europe likes to have discrepancies, for whatever reason, he can certainly tell to RIPE-NCC: please do not forward my updates to the NIC!

---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------

What I think Piet objects to, is that the RIPE NCC, after querying the DNS (which in far, far too many cases is misconfigured), would take the results and automatically 1) carry out a database update in the RIPE DB 2) forward a change request to the US NIC on the basis of the DNS information That's indeed exactly what I'm objection to, since that comes down to RIPE stepping into the authority of the really responsible persons. Nevertheless, I think it is a good idea to sometimes carry out a "consistency check" between what is in the RIPE database and what is actually registered in the DNS. In that case, it would probably be nice to register "known inconsistencies" (in the vein that Piet suggested, and which is in use for eg. dec.com -- use your favourite lookup tool), so that one is not reminded of the same "error" lots of times. Fully agreed. What I think Antonio is saying, is that it would be nice to only have to send in registration for a network to the RIPE NCC, and include the "rev-srv" attribute, and that this information could be forwarded to the US NIC for them to do the corresponding addition/ change in in-addr.arpa. I also happen to agree with Antonio that this is a good idea. I agree that this would indeed be a good idea, on the provision that not RIPE, but the person submitting the registrations/changes is taken to be authoritative in the NIC's database. Piet

To summarise and conclude from the discussion: All comments -also the ones sent to me privately- were unanimous on this: There will be no automatic updates of the RIPE DB. If database information is believed to be inconsistent the rechnical contact persons will be notified together with suggested corrections. They can then decide whether to send in the suggested corrections. What remains open is the question on whether in-addr.arpa zone registrations should be effected automatically by registering the 'rev-srv' field in the RIPE database. I have had quite a few comments from people who want this and I personally agree it would be a nice feature. Some people actually assumed this was the way it was working already and complained that they had to register in-addr.arpa separately with the NIC! I do not see Piet's argument that this would mean a loss of authority of the network contacts. They have the same authority for changing the RIPE database than they have for changing the NIC database which then generates the in-addr.arpa zone information. Just the procedure would be different, and easier: One stop shopping with no additional cost (and no warranty of agency :-), sorry inside joke). So my proposal would be to do this in steps: First clean up the inconsistencies in the RIPE database using the procedure above. Then populate the database with the current in-addr.arpa information, notifying the tech contacts of each change. After these two steps the information in in-addr.arpa and both the NIC and RIPE databases is consistent. Then initiate changes of in-addr.arpa whenever the 'rev-srv' attribute in the RIPE DB is changed. This means the one stop shopping is effective. Until confidence is built we can notify the tech contacts whenever such a change is made. Is this acceptable? Daniel

An indirect way of correcting things via submissions to the RIPE DB in my view is far from ideal, as it may well introduce unnecessary delays.

Soon this argument will be moot for at least 193.in-addr.arpa...

And once you start doing such things for the reverse servers, the next step may well be doing the same for "forward servers"; then how can e.g. a top level domain registrar determine whether a given change is valid, e.g. comes from an authoritative person?

Call (ie. phone) the supplied administrative contact person? How do you ensure authority today? - Havard

What remains open is the question on whether in-addr.arpa zone registrations should be effected automatically by registering the 'rev-srv' field in the RIPE database. I have had quite a few comments from people who want this and I personally agree it would be a nice feature. I do not see Piet's argument that this would mean a loss of authority of the network contacts. This form of "indirect registration" would indeed not mean loss of authority. The problem remains though that separate functions - DB and DNS - become intermixed here. And then whom do you contact/tell/flame if the root servers contain wrong information? An indirect way of correcting things via submissions to the RIPE DB in my view is far from ideal, as it may well introduce unnecessary delays. And once you start doing such things for the reverse servers, the next step may well be doing the same for "forward servers"; then how can e.g. a top level domain registrar determine whether a given change is valid, e.g. comes from an authoritative person?

There no need to do that for forward servers because they are structured as a distributed three and the authority is delegated at each level. In practice today the US NIC does not check at all if a rev-srv change comes from an "authoritative person" because they do not check where the mail request comes from and it is practically impossible for them to pick a phone an call someone in Europe. So this is not the point. ---------- ---------- Antonio_Blasco Bonito E-Mail: bonito@nis.garr.it GARR - Network Information Service c=it;a=garr;p=garr;o=nis;s=bonito c/o CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I 56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------