At 04:00 PM 11/30/98 +0100, Joao Luis Silva Damas wrote: Just check http://www.checkdomain.com with some nonexistant domain housed at RIPE and tell me if something isn't wrong here. -Hank
Hello.
I am including the tld-wg into this discussion so as to make sure all involved parties are aware of the discussion.
Alexander Koch <akoch at sgh-net.de> writes: * Hello. * * > The design of this feature was specified some time ago by Carol Orange and * * > Wilfried Woeber (please see http://www.ripe.net/meetings/ripe/ripe-27/pres * /rout * > e/referral/) and discussed in the RIPE db-wg mailing list (please see * > http://www.ripe.net/mail-archives/db-wg/19970501-19970601/threads.html) * * Oh. Fine. Do I get it right that this was discussed and agreed on * more than a year ago? Argh. *
Yes, indeed. We had a period where we have been late with developments. That period is now behind us.
* This change breaks too many things, imnsho, and it seems again that if * you are not able to make it to the RIPE meetings, you have lost. A * special announce would have been most helpful (an explicit one, stating * this). *
But, we did... or so I thought. We'll look into more ways of getting this announcements across while trying to minimize the mails sent to people who don't care about this.
This particular feature has been actively asked for by the ccTLD adninistrators and seen as a good thing by everyone I have had a chance to speak with. These are actually the first complaints about it we have got so far.
* > As a side note I would like to stress that the RIPE Database is NOT the so * urce * > of authoritative data for domain objects (although we are happy to provide * a * > repository for TLD administrators). * > This is UNLIKE the internic whose business is to sell names. * * Oh. Fine. whois.nic.de *cough* barely ever working... Weak argument. * And If I wanted to know the data about the domain one level higher, * I can do so myself, I don't need to get it told to me by whois, I * want to know whether crab.de (bad example, it really exists) is in * the DB already or not.
I am sorry but I can't talk about the availability of services we don't operate.
I am sure you can look up domains yourself but this was actually seen as providing the users (specially the ones less familiar with the RIPE DB) with help on where to find the correct information.
It seems to me that over time people have developed a sense that the RIPE DB is the authoritative source of information regarding domain names in Europe. May be this issue should be up for debate now.
As a matter of fact the referral mechanism was seen as a way for ccTLD administrators to include information in the Database pointing to their own authoritative sources of information.
* * > The RIPE NCC is therefore acting according to users directives that were * > discussed and agreed on an open way. * * Hitchhiker's Guide, anyone? *sigh*
???
* * This was a not-so-nice change, really. Consider this a statement of * disagreement with the way the change took place. Ok, one more mailling * list to follow... Time to sell.
Will do so. As I said before, we will keep modifying and developing the RIPE DB software and in particular this feature if users feel that is what they want. We will also provide our point view. I would like to have the input of the community.
Regards, Joao
* * Regards, * Alexander Koch * * -- * SGH Internet Division, Alexander Koch, Systems Administration * Hannover, Germany, Phone +49 511 909198 0, Fax +49 511 391307 *
-------- Logged at Mon Nov 30 16:28:47 MET 1998 ---------
Hank Nussbacher <hank at ibm.net.il> writes:
Just check http://www.checkdomain.com with some nonexistant domain housed at RIPE and tell me if something isn't wrong here. -Hank
Hank, you know me and I am the last person to do fingerpointing exercises, but this complaint needs to be sent to <info at checkdomain.com>. BTW, checkdomain.com works correctly for Germany (.de). Daniel -------- Logged at Mon Nov 30 17:43:59 MET 1998 ---------
Hank Nussbacher wrote:
Just check http://www.checkdomain.com with some nonexistant domain housed at RIPE and tell me if something isn't wrong here. -Hank
Something is wrong but I don't think it's the RIPE db. If a third party writes an application which doesn't correctly parse the information it receives from the RIPE database then I don't see how this can be the fault of either the RIPE NCC or those participating in the development of the database. Returning the next object up in the hierarchy seems sensible behaviour. It's certainly what I become used to when querying for inetnum or route objects - when normally I just paste an "interesting" host IP address into my whois query and expect to get back the details of the allocation/assignment containing that host address. Perhaps, in the same way that the RIPE db supports the -L, -m and -M flags (at least where inetnum and route objects are concerned), there should be an option for the database to only return an exact match. [ -L find all Less specific matches -m find first level More specific matches -M find all More specific matches ] James ----- ___ - James Aldridge, Senior Network Engineer, ---- / / / ___ ____ _/_ -- EUnet Communications Services BV --- /--- / / / / /___/ / --- Singel 540, 1017 AZ Amsterdam, NL -- /___ /___/ / / /___ /_ ---- Tel: +31 20 530 5327; Fax: +31 20 622 4657 - ----- 24hr emergency number: +31 20 421 0865 -------- Logged at Tue Dec 1 13:39:36 MET 1998 ---------
On 30 Nov 98, at 17:14, Hank Nussbacher quoted someone who had written:
As a matter of fact the referral mechanism was seen as a way for ccTLD administrators to include information in the Database pointing to their own authoritative sources of information.
I can confirm that this was indeed the intention when this was first proposed in the RIPE (25, I think) DNS-WG meeting.
* > The RIPE NCC is therefore acting according to users directives that were * > discussed and agreed on an open way. *
Yes and no, I have to say. At RIPE 31, the functionality proposed certainly appeared to me to be what had been sought. I am no longer certain that this is indeed the case. In particular, the following surprises have arisen. First, the key notion of making the referral function available per TLD at the option of the TLD registry concerned seems to have been lost. This is a fundamental element of the original concept of over two years ago. Second, the "feature" of returning the data relating to the parent domain in the case that the specified domain cannot be found seems to me to have nothing to do with referral. The referral concept has to do with re-directing the query to an authoritative whois server, not with second-guessing the intent behind the query and substituting other data which is available locally. I suggest that this "feature" be declared a bug and removed. I am sure that these technical problems are based on misunderstandings which can easily be resolved. A more significant surprise is that TLD registries, who have had no specific prior notification, now find that data about their domains is being returned in response to a class of query for which this was not formerly the case, and that they have to deal with the unexpected fallout. Niall O'Reilly IE Domain Registry at UCD Chair, RIPE TLD-WG -------- Logged at Wed Dec 2 08:04:58 MET 1998 ---------
Folks, I have been pondering this for a day now and I conclude that there is no easy answer to this issue, i.e. it is not yes/no 1/0 black/withe in any aspect. I'll address two aspects here: process and technology. I'll then tell you what the RIPE NCC will do now. I apologise for the wordiness of this but I find no way to say it more concisely and stay civil at the same time. Process The number of regular database users is certainly measured in the thousands these days. This means is not OK any longer for Daniel or the RIPE NCC to decide what is right or wrong, or what gets implemented. Over the years we have developed a process within RIPE to develop database policy: the database working group which involves other working groups as required. Developments are discussed and announced in these fora. However it comes with a back side and that is that quick pragmatic changes are more difficult. Deciding to undo policy derived by proper process in an ad-hoc way is something the RIPE NCC has to be uncomfortable with and do only in rare exceptional cases. But it should be done when necessary and the RIPE NCC will take the responsibility when it does so. But it cannot be something one does lightly or even regularly. Technology In this particular case there are two changes that are relevant to the issue and they are inter-related. The first change is the introduction of a referral mechanism by which an object in the database can cause the query to be referred to another server. This apparently was well understood by everyone concerned, especially the fact that it is at the user's discretion whether to use this mechanism or not. A second but tightly related change is recursive resoloution of queries for domain object. This changes the database behavior on *all* domain name queries: if no object with the exact name queried exists this will search the domain name hierarchy upwards and return the first object found in this way; in other words subdomains will be stripped until a match occurs. At the time of the discussion it was explicitly noted that recursive referral will return a parent domain object for non-existing domains. This was regarded as a feature since it would return a pointer to the correct registrar with whom to register the non-existant name and we have seen that it works ;-). The reason these changes are inter-related is that without recursive querying TLD administrators will still be obliged to enter one object for each domain and all these will have the same content: a referral to the TLD whois server. With recursive querying, only one object is required and the need for regular redundant updates is eliminated. So the two changes are tightly inter-related and just switching off recursive querying will hurt those implementing referral. How to Proceed When deciding how to proceed we first had to consider whether the problems raised by a few users warranted a deviation from the process. Our conclusion in this case is positive because apparently even some of those involved in the process did not understand the proposal they agreed to. But we also do not want to make a fix that hurts those who have been waiting for this change and are abut to make use of the new functionality. So we decided to do a quick and *very* ugly fix: We will leave recursive querying active. But in the case of finding a parent domain the result will be determined by the content of the object found: if it is a referral, the query will be referred as before; if it is a normal (non-referral) object, the answer will be "no such object" as before the change. While addressing the problems raised by a few users this will not hurt those planning to use referral based on recursive querying. Anyone with half a background in computer science and anyone with a bit of intelligence will tell us that name scoping dependent on content of the object named is a bad idea. We agree! This is why this fix will only be kept up until the next RIPE meeting when the proper process can determine the permanent soloution. If the database WG can ome to a conclusive decision before the RIPE meeting we will implement it earlier. We also do not expect to modify this fix further based on anything other than a decision based on proper process. We will also set up a special announcement list via which those not participating in the policy developemnt process can be notified of changes. Kind regards Daniel Karrenberg RIPE NCC Manager -------- Logged at Mon Dec 7 20:08:56 MET 1998 ---------
participants (4)
-
Daniel.Karrenberg＠ripe.net -
hank＠ibm.net.il -
jhma＠EU.net -
Niall.oReilly＠ucd.ie