DATA INTEGRITY CHECKS EMAIL ADDRESSES --------------- Email addresses are treated as two components separated by a single @ character. The host (to the right of the @) must be syntactically correct, must exist in DNS, and may have any number of dots. Forward/reverse name checks are not done. See FQDN CHECKS for details. Email names must conform to a list of allowed characters, and name-comments are not allowed (eg. user@host is OK, but "Some Body" and otherwise-legal variants are not). The list of allowed characters is configurable. ERROR MESSAGES (in addition to FQDN errors): "There must be only one @ in an email address", "Illegal characters in the name portion (before @)", "Missing the \@hostname portion of the email address", DOMAIN to be created/modified ----------------------------- The name of the domain to be registered or modified is tested according to the FQDN section, below, for basic sanity. Additionally, the domain must be a sub-domain of the allowed list of higher-level domains, as given in the configuration file. Allowed higher-level domains are specified as a list of suffixes, eg. .com.cc .net.cc ... Only immediate subdomains of this list are allowed, eg. in this example, FOO.com.cc is allowed but FOO.BAR.com.cc is not. If more levels are required they must be added explicitly to the list. HANDLES ------- Syntactically, NIC handles must conform to RIPE-223, when present. (They should be empty fields when creating a new person contact.) Also, if a handle from a source not supported by domreg is given, an error is returned. NIC handle fields, and the person contact data in the fields that follow them, can be selected from a pick-list after searching for keywords. Presumably, the returned keys adhere to RIPE-223. ERROR MESSAGES: "Please provide a valid NIC handle here or fill in \ the other contact fields below to create a new one.", "This is not a valid handle, syntactically-speaking.", "This system does not support handles from that source.", "No person with this handle can be found in WHOIS.", "No person with this name can be found in WHOIS.", PERSON NAMES ------------ Person names, when required, must also adhere to RIPE-223. ERROR MESSAGES: "A person's name is required here.", "Honorifics not allowed (for example Mr, Prof, Ms, Mv, Dr).", "The first name cannot end with a dot.", "The last name cannot end with a dot.", FQDNs ----- The tests performed on Fully Qualified Domain Names (FQDNs) depend on the context. Names of new domains need only be syntactically correct (and of course must not yet exist) while nameservers require fully correct in-addr data, etc. The following syntax checks are made on FQDNs: 1. It must be 64 characters or less in length. 2. Must not contain any of the configurable list of illegal characters. 3. At least one allowed character must exist before and after each dot. 4. Names between dots must not begin or end with any of the configurable list of restricted characters (eg. A-B allowed, but AB- not). 5. Must be less than or equal to the maximum number of allowed dots (domains), depends on context. The following are each individually optional, depending on context: 6. The name must resolve eventually to an A record. 7. There must be at least one reverse name that matches the stated forward name. ERROR MESSAGES: "This hostname is malformed or contains illegal characters", "There are too many domains in this name", "There is no IP address associated with this hostname", "There is a mismatch between the forward and reverse names" (list), NAMESERVERS ----------- This applies to the following form fields: 8a. Primary nameserver 9a. Secondary nameserver 9b..9e. Secondary nameservers 8a and 9a are required, but 9b through 9e are optional and the list does not need be contiguous. If 9b through 9e are non-null then the same requirements must be met as in 8a and 9a. The following tests are performed on every nameserver hostname listed in the form: 1. Each name must be syntactically sensible, as described in the FQDN section. Hostnames are allowed any number of dots. 2. Each must resolve to at least one IP address. 3. There must be at least one reverse name that matches the given forward name. 4. All hostnames must be unique; no IP address associated with any one nameserver may be associated with any other nameserver. 4a. Localhost and 127/8 responses to above DNS queries are ignored. 5. Every IP address of every nameserver must return SOA when queried. After these preliminary checks enough data exists to begin testing of SOA and NS record data. Next, the authoritative host is determined: 6. Every SOA header must have identical authhost and serial number. 7. One of the host names from the form (not necessarily 8a) must match the SOA authhost. At this point we assume that the common authhost is in fact the authoritative host, and that its NS records are the correct, authoritative list of nameservers for this domain. 8. Every nameserver in the authhost's list must be present in the form (therefore will pass all tests). 9. Every hostname given in the form must be in the authoritative hosts list of nameservers. 10. Every nameserver's list of nameservers (NS records) must match that of the authoritative hosts' list. ERROR MESSAGES: "This host's name is malformed or contains illegal characters", "There are too many domains in this name", "There is no IP address associated with this host's name", "There is a mismatch between the forward and reverse names", "That name is already in use", # dubious "Your input is required here", "This is not a supported domain.", "This host's IP address(es) have no in-addr name(s)", "This nameserver has no data for this domain.", "This nameserver did not respond; please check \ for errors or try again later.", "An error occurred trying to retrieve data \ from this nameserver.", "This nameserver is duplicated elsewhere.", "This nameserver has IP address(es) shared with \ another nameserver.", "The SOA serial number of this nameserver \ does not match that of the master server.", "Bad nameserver configuration; can't determine \ which nameserver is authoritative.", "None of the nameservers is authoritative.", "Only one nameserver can be authoritative.", "This host is not in the master nameserver's list", "This host returns a different list of nameservers than the master", "Could not verify; no authoritative server responded", "One of the nameservers referred to by this host \ is not entered in the form.", SPECIFYING DOMAINS AND RPSL-COMPLIANT DATABASES ----------------------------------------------- From the example config file: # --- D O M A I N I N F O R M A T I O N -------------------------- # # First, define the list of RPSL-compliant # databases that support the domains # we will work with. The first entry here # becomes the default RPSL database for # domains in the domain table (see below). # DB name mntner email address(es) no spaces! rpsl: TEST MAINT-WPS test-dbm@ripe.net,tomj@wps.com rpsl: FOO MAINT-WPS test-dbm@ripe.net,tomj@wps.com rpsl: RIPE MAINT-X auto-dbm@ripe.net rpsl: APIRR MAINT-WPS auto-irr@irr.apnic.net,tomj@wps.com # This is the list of domains and their # registry databases; eg. to modify # domain FOO.CO.KE, .CO.KE must be a # supported domain. You can specify an # RPSL database per domain by preceding # the domain name with a name from the # RPSL data above prefixed with -, for # example: # domain: -FOO .co.ke # If you omit the registry it uses the # first rpsl entry defined previously. domain: .co.ke -TEST .com.ke domain: .net.ke The rpsl: lines are defining the RPSL-compliant databases domreg/registrar can work with. This is fairly abstract, there is yet no relation to the domains supported. That comes later. The DB name is well known, and the mntner object under which you (registrar) has authority. For now, only mail-from is supported. Mntner must be manually configured. The email address is of course the auto submit address for that database. Note that the first one defined is the "default" RPSL database, which will mean something in a minute. Next we define the domains that domreg/registrar can deal with using the domain: lines. The example above is poor, don't worry about it too much (I left it in becaus eit was in the files I sent earlier). A more sensible example might be: # DB name mntner email address(es) no spaces! rpsl: RIPE MAINT-X auto-dbm@ripe.net domain: .cd .co.cd .net.cd .com.cd We define one RPSL database, and a small list of domains we will accept. All object creations will go to that database. I am assuming this is a more likely real-world use of domreg. Note that there is no funny -DATABASENAME in the domain: line; this uses the "default" concept. Since there is only one database, it is default, and need not be specified. A more complex example might be: # DB name mntner email address(es) no spaces! rpsl: FOO MAINT-WPS test-dbm@ripe.net,tomj@wps.com rpsl: RIPE MAINT-X auto-dbm@ripe.net domain: -RIPE .cd .net.cd .co.cd domain: -FOO .ke .net.ke .co.ke Here nothing refers to default, databases are explicit. The -DATABASENAME option means that anything that follows the option uses that database. (The scope of this option is within the line only.) This could have been specified alternatively as: domain: -RIPE .cd .net.cd .co.cd -FOO .ke .net.ke .co.ke Or even as: domain: -RIPE .cd domain: -RIPE .net.cd domain: -RIPE .co.cd ... domain: -FOO .ke .net.ke .co.ke