A DNS Database Referral Mechanism
Hi all, Below is a proposal put together by Wilfried Woeber and myself to address the need for a referral mechanism for domain name queries in the RIPE database. The mechanism is designed to address the immediate needs of those trying to get domain related information, and of DNS administrators trying to provide it. Certainly the mechanism may be adapted with time (see the three options below), however we choose to start with something that can provide the required functionality immediately. We hope to discuss this proposal on the mailing lists and in the database and dns working group meetings in Dublin. Carol Orange RIPE NCC --------------------------------------------------------------------- RIPE Database Referral Mechanism for Domain Queries - A Proposal Carol Orange & Wilfried Woeber, April 1997 ------------------------------------------ In the following, we propose a mechanism for forwarding whois queries to the appropriate database if the RIPE database does not contain the authoritative data for a given tree in the DNS name space or subset thereof. It is thus applicable for the "domain" object only: domain: [mandatory] [single] descr: [mandatory] [multiple] admin-c: [mandatory] [multiple] tech-c: [mandatory] [multiple] zone-c: [mandatory] [multiple] nserver: [optional] [multiple] sub-dom: [optional] [multiple] dom-net: [optional] [multiple] remarks: [optional] [multiple] notify: [optional] [multiple] mnt-by: [optional] [multiple] mnt-lower: [optional] [multiple] changed: [mandatory] [multiple] source: [mandatory] [single] The goal of the mechanism is to provide a means for TLD domain administrators (and other "high-level" domains) to enable users to obtain an authoritative response for a domain object query sent to the RIPE database, regardless of whether the data for the domain is maintained in the RIPE database itself. Algorithm --------- If the following query is submitted to the RIPE database: whois [flags] xxx.yyy.zz the algorithm will work as follows: ------- NAME="xxx.yyy.zz" until (NAME = "") { If object with domain = NAME found, If object contains referral (see "Referral" below) forward query (see "Forward" below) Else return object Else Strip(NAME) (xxx.yyy.zz -> yyy.zz, etc) } NOTES ----- 1. We move up the tree here, and return the next level answer if present. If the query requests "tuintje.cwi.nl" (Piet, do you mind?), they currently get "No entries found ...". In the new mechanism, they would get: domain: cwi.nl . . . mnt-by: NL-DOMREG changed: hostmaster@domain-registry.nl 19950227 source: RIPE Moreover, if the object for cwi.nl contains a referral, the query would be passed on to the specified server as explained below. 2. The algorithm will be set off by any query which causes a search in the domain object index. This means any query with "-T domain", or any general query (no -T flag) with something that "looks like a domain". Referral -------- A whois referral can be entered in a "refer" attribute by specifying the type of database in which the data is maintained, and the domain name of the server that should be queried: refer: <type> <host> <port> where <type> is one of RIPE, InterNIC or SIMPLE, indicating which style of whois service is provided. <host> is the DNS name of the whois service. <port> is the TCP port number (optional: 43 is the default). Examples: (CWI again): refer: RIPE domain-registry.nl 43 (InterNIC): refer: InterNIC whois.internic.net (Generic): refer: SIMPLE my.dns.tld Initially queries for the three types of databases shown here would be supported. If RIPE is specified, then the initial query together with all arguments would be passed to the specified whois server. If an InterNIC database is specified, then a query expected by the InterNIC database software would be generated for the specified domain name. The same would be true of "SIMPLE". In that case a simple query for the domain name would be passed on. If in the future, another domain name database is implemented with a given query language, it can be added. Forward ------- If the TLD object contains a whois referral, we can a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester a) has the advantage of giving the user an immediate answer, and requires that only the RIPE database software be modified, not that of the TLD admins. Nothing has to be changed there. a) has the disadvantage that the RIPE server can become a bottleneck. However, local mirrors of referred to databases can be set up on a RIPE NCC server to alleviate this problem. Summary ------- We propose the above mechanism with (option (a) request forwarding) be used for TLD/domain referrals. We believe it will make the domain part of the database more transparent to users and easier to manage for TLD administrators. Acknowledgements ---------------- We would like to thank Chris Fletcher, Daniel Karrenberg, and David Kessens for useful comments.
Quoting from Carol Orange's message:
Hi all,
Below is a proposal put together by Wilfried Woeber and myself to address the need for a referral mechanism for domain name queries in the RIPE database.
The mechanism is designed to address the immediate needs of those trying to get domain related information, and of DNS administrators trying to provide it. Certainly the mechanism may be adapted with time (see the three options below), however we choose to start with something that can provide the required functionality immediately.
We hope to discuss this proposal on the mailing lists and in the database and dns working group meetings in Dublin.
Carol Orange RIPE NCC
Hi Carol, would it be possible to implement the suggestion made by Robert Martin-Legene ? It is more flexible... Date: Mon, 28 Apr 1997 17:16:09 +0200 (MET DST) From: Robert Martin-Legene <robert@DK.net>
Forward ------- If the TLD object contains a whois referral, we can=20 =20 a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from=20 domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester
I like the a) as well, but it shouldn't be a problem doing all three and let it be up the the owner of the object. Then the refer attrib could be refer: <forward-type> <whois-server-type> <host> [<port>] I guess the whois-server-type isn't needed on forward-type b, but it look= s good for consistency... (it's up to the client to use it then) -- Robert Martin-Leg=E8ne (RM59), Network Manager (AS2109)
>would it be possible to implement the suggestion made by Robert >Martin-Legene? It is more flexible... >> If the TLD object contains a whois referral, we can >> a) query the server, and pass the response to the requester, preceded >> by a comment of the form: "The following data has been obtained from >> domain-registry.nl". >> b) pass the referral to the requester >> c) send the query to the server with the address of the requester More flexible and more complicated. What exactly is the gain over the original, more simple proposal? Piet
Quoting from Piet Beertema's message:
would it be possible to implement the suggestion made by Robert Martin-Legene? It is more flexible...
If the TLD object contains a whois referral, we can a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester
More flexible and more complicated. What exactly is the gain over the original, more simple proposal?
The proposal was: ...it shouldn't be a problem doing all three and let it be up the the owner of the object. Then the refer attrib could be refer: <forward-type> <whois-server-type> <host> [<port>] where forward-type could be: CHAIN for a) method REFER for b) method FORWARD for c) method To me the advantage is obvious: the owner of the TLD object can change the behaviour of the RIPE-DB server just by changing the refer field... ---------- ---------- Antonio-Blasco Bonito E-Mail: A.Bonito@cnuce.cnr.it Reparto Applicazioni Telematiche c=it;a=garr;p=cnr;o=cnuce;s=A.Bonito CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I I-56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
Hi Blasco, Antonio-Blasco Bonito writes:
would it be possible to implement the suggestion made by Robert Martin-Legen e ? It is more flexible...
Date: Mon, 28 Apr 1997 17:16:09 +0200 (MET DST) From: Robert Martin-Legene <robert@DK.net>
Forward ------- If the TLD object contains a whois referral, we can=20 =20 a) query the server, and pass the response to the requester, preceded by a comment of the form: "The following data has been obtained from=20 domain-registry.nl". b) pass the referral to the requester c) send the query to the server with the address of the requester
I like the a) as well, but it shouldn't be a problem doing all three and let it be up the the owner of the object. Then the refer attrib could be
refer: <forward-type> <whois-server-type> <host> [<port>]
I guess the whois-server-type isn't needed on forward-type b, but it look= s good for consistency... (it's up to the client to use it then)
-- Robert Martin-Leg=E8ne (RM59), Network Manager (AS2109)
We actually discussed this point a bit in a slightly different light. An important question is: should the forward type be up to the object maintainer, to the whois server providing the referral (in this case RIPE), or the whois client, or end user. As proposed here, it is the whois server, but could be modified in the future to also be the whois client. The object maintainer can in fact always prevent automatic request forwarding by putting the referral information in a remarks field. However, if such a mechanism should become popular, then it may be suitable that whois clients be developed that can parse the refer field and resend the request to the appropriate server. If we allow the object maintainer to determine this in the <forward-type> field, then it actually limits flexibility in the future. Or is my thinking twisted? -- Carol
Carol, Quoting from Carol Orange's message:
We actually discussed this point a bit in a slightly different light. An important question is: should the forward type be up to the object maintainer, to the whois server providing the referral (in this case RIPE), or the whois client, or end user.
This is a common problem in any distributed application (ie: DNS, X500, ...) Any of the party involved may wish a certain behaviour by other parties but the actual behaviour of the system is based on matching wishes with options chosen by implementors/administrators. The matching is usually done via a protocol. Proposing that the behavior of one of the components, the server, could be decided by the object maintainer is just a way to give a certain degree of autonomy to him.
As proposed here, it is the whois server, but could be modified in the future to also be the whois client.
The object maintainer can in fact always prevent automatic request forwarding by putting the referral information in a remarks field.
Yes, if you reduce to two cases only: referral and [chaining,forwarding] However it has to be said that the referral method is more robust and can scale: the server could be a bottleneck/point of failure
However, if such a mechanism should become popular, then it may be suitable that whois clients be developed that can parse the refer field and resend the request to the appropriate server. If we allow the object maintainer to determine this in the <forward-type> field, then it actually limits flexibility in the future.
No, if the server getting requests from "powered clients" decide that the wishes of the client take precedence over those of the object maintainer
Or is my thinking twisted?
-- Carol
---------- ---------- Antonio-Blasco Bonito E-Mail: A.Bonito@cnuce.cnr.it Reparto Applicazioni Telematiche c=it;a=garr;p=cnr;o=cnuce;s=A.Bonito CNUCE - Istituto del CNR Tel: +39 (50) 593246 Via S. Maria, 36 Telex: 500371 CNUCE I I-56126 PISA Italy Fax: +39 (50) 904052 ---------- ----------
>Below is a proposal put together by Wilfried Woeber and myself to >address the need for a referral mechanism for domain name queries in >the RIPE database. At last... the long asked-for and long waited-for automatic whois query forwarding. Great! So we can get rid of the kludge of having to put the info in a remark field, suitable for humans only, which in many cases don't even know how to handle the info presented... Piet
participants (3)
-
Antonio-Blasco Bonito
-
Carol Orange
-
Piet Beertema