Follow this link to the e-mail application form.

This page describes the most important parameters of the e-mail application form. The respective parts of the template are shown within a colored area, with helpful comments located below them. Self-explanatory parameters like email will not be mentioned here.

The e-mail application form is intended for experts and the automated processing by robots. You will need technical experience to fill out the form, e.g. to give the correct information in section 6. If you are not sure about the meaning of all the terms, you should use the comfortable web interface of our DRS.

The form is divided into multiple sections:

#-----------------------------------------------------------------------
#   |       |
#   | knipp |                        Knipp Medien und Kommunikation GmbH
#    -------

All the lines beginning with # are comments and can be ignored. These lines are only used to improve structure and readability. The same is true for blank lines. They are only used to clearly arrange the form and can be added or deleted arbitrarily.

         section: 0

The application form is divided into several sections. Each section forms a chapter by itself and is separated from the other chapters by the key section. Do not remove these lines.

          doc-id: appli-en-de.txt
         version: 5.0.0

Is required for further processing by Knipp. Please do not delete.

       reference:

You can insert any text you like here. This text will be quoted in all of the responses of our system. This allows for an easy recognition and classification of your applications by your robots, if you want to automatically process our responses.

You might want to use this field to indicate reference numbers of your customers, for example, or a contract number, etc.

           section: 1
              mode:
            domain:
           comment:
          language: de
          authinfo:
      new-authinfo:

With the mode-parameter you can define if you wish to perform a new registration ( mode: new), a transfer from another registrar (a so-called “Konnektivitätskoordination” - coordination of connectivity, mode: kk), an update ( mode: update), or a deletion ( mode: delete). An update can be used to modify the contact data or to change the WWW forwardings, for instance. If you leave the mode-parameter empty, a new registration will be initiated.

Important: If you choose mode: update you must fill out all sections, not only the parts to change. For mode: delete, only the sections 0, 1, 7, and 8 may be filled. The sections from 2 to 6 must not appear. Likewise, no authinfo-fields (see below) may be used for a deletion.

mode: update-dnssec: Due to its DNSSEC support there is an additional mode for this TLD that allows for a quick update of the DNSSEC data. In this mode it is sufficient to include the new DNSSEC data in section 6 of the form. The other domain data will remain unchanged. An optional comment can be included in section 1 to be stored with the domain. Please refer to our example template for a DNSSEC update and mind the note on PGP signing in section 6.

In a similar fashion, for mode: update-dnssec only the sections 0, 1, 6, 7 and 8 may be used. The sections 2 to 5 may not appear, while section 6 must solely contain the new DS- or DNSKEY entries.

Deletion: When deleting a domain via e-mail template, the domain is marked for deletion, i.e. the requested end date is set. The optional field

     deletion-date:

allows to set the requested end date. The value can be either a date in the future, e.g. 2096-02-29, or scheduled, which means that the domain will be deleted at its scheduled end date. If deletion-date is not specified, the deletion will take place at the earliest possible date.

Note that the effective deletion from our system does only take place in the course of specific maintenance phases that are scheduled in regular intervals. Thus, the deletion can be canceled using our web interface until the beginning of the relevant maintenance phase.

Creation and update of handles: In addition to the possibilities described above, you can also create new handles or update the data of an existing handle with the modes mode: new-contact and mode: update-contact. To do so, the sections 0, 1, 2, 7 and 8 have to be filled, with the complete new contact data in section 2. (Example: Template for the creation of a new handle for .de.) When creating a new handle for .de domains, an additional field type: has to be given to specify the type of the contact. Possible values are “person”, “org” and “role”.

Next to domain, the complete domain name has to be given. For example: domain: my-company.de. Only one domain name can be given per e-mail application form.

The field comment can be used to save a free-text comment about this domain.

With the language parameter you can specify a language code for the domain name. The language code can be used to determine possible alternative notations of the name. Especially in asian regions it occurs that there are several different ways to represent the same term. Some registries offer to include possible alternative notations in a registration or to block their registration by third parties. Knipp's DRS is already featured with this option, so you can use this field to specify a language code.

For .de domains, however, language: de is the only possible option and is consequently preset in the template.

authinfo is some kind of password, which is required for changing the registrar of a domain. It thus protects you against unauthorized persons initiating such an operation. You can choose it freely during the registration of a new domain. It must consist of at least 8 and at most 16 characters. The allowed characters are lowercase and uppercase letters, digits from 2 to 9 and the following special characters: + - / *. Not allowed are uppercase I, lowercase l, uppercase O, lowercase o, 0 (zero) and 1, since these are most often confused. For security reasons, the authinfo is not valid indefinitely, but only for 30 days. Example: authinfo: secret-234.

If at some time you want to change the sponsoring registrar (CTSR), you have to know the authinfo for the respective domain and to name it in this field. This proves that you are authorized to request the change. At the same time, you have to constitute a new password by using the new-authinfo-field. This specification is mandatory. The same rules concerning the characters apply for new-authinfo, of course, since it becomes the authinfo for the domain after the change.

Important: The authinfo-fields may not be used for deletions (i.e. mode: delete).

Important: The new-authinfo-field is only neccessary to change the registrar and may not be used for updates or for the registration of a new domain!

              type:

A contact can be of one of the following types. When creating a new contact for a registrant, the field type is mandatory, when changing an existing contact it is prohibited.

Please note that for general and abuse contacts, only contacts of type “request” may be used. For the domain owner, on the other hand, only contacts of type “org” or “person” are allowed. This is also true if the contact is specified via a handle.

            person:
      organization:

The registrant is the designated holder of the domain. This can be a natural person or a legal person.

In case of a natural person, only person has to be filled out. If the holder is a legal person (e.g. a company), you have to specify it at organization in any case. Nevertheless, a contact person must also be given at field person

A distinctive feature is that the mapping of these two values for the appropriate DENIC contact is being interchanged if both fields exist. The field “name” is then filled with the value of organization from this template and “organization” with the content of the field person in the template.

         address-1:
         address-2:
         address-3:
       postal-code:
              city:
           country:

The parameter address-1 is intended for the street address. Filling this field is mandatory. address-2 and address-3 can be used for additional entries (for the zip-code or other add-ons).

The postal-code-parameter (mandatory field) is intended for the zip/postal code, while city (mandatory as well) holds the name of town. The mandatory country-parameter is required to hold the international country code representation according to ISO-3166, like “DE”, “AT”, or “CH”. This field is case-insensitive (so using “de” or “De” will work as well), but it may not contain periphrases like “Germany” or “Switzerland”!

             phone:
             fax:

Please note that phone and fax numbers are no longer supported (since DeNIC RRI 3.0).

            handle:

handle provides an alternative way to specify contact data. With every successful registration of a domain, a handle is being created for every contact provided during the registration process. Once you have a handle for a set of contact data, you don't have to manually fill out the fields if you want to use the same data again. Instead, it suffices to specify the appropriate handle in this field. This saves you a lot of typing. If you fill out the fields and enter a handle at the same time, the values specified in the fields will be ignored and those from the handle will be taken instead.

Example: handle: DENIC-60-DRS-XXXXXXX.

Important: The different top level domains each require their own set of handles. For example, .biz handles can not be used for .de domains, even if both handles specify the same contact data!

In addition to the mandatory registrant contact (section 2), DENIC only supports abuse and general contacts as further contact types, since Version 3.0 of the DENIC RRI specification has been introduced. Both contacts are optional. Other contact types as they are still in use for other top level domains (administrator, technical contact, zone contact) are not supported anymore.

The abuse contact serves as target address for requests and notifications concerning potentially illegal or abusive usages of a domain.

              type:

Important: Generally speaking, a contact can be of one of the types listed in section 2. For abuse and general contacts, however, only type: request is allowed.

       uri-template:

A URI template is composed of a URI plus optional variables. It can either specify a URL or an e-mail address. In case of a web whois request for a domain, the variables in the template are being replaced with the name of the domain. Following an example for a URI template with a URL.

       uri-template: https://denic.de/c-form?val1={Alabel}&val2={Ulabel}

The variables in the URL are contained in curly braces. Here, we have the variables Alabel and Ulabel as specifically provided by DENIC for the ACE and UTF-8 string representations of domain names, respectively. In case of a web whois request for a domain named “beispiel-fünf.de”, for example, these variables get assigned with that name in the respective form (Alabel := xn--beispiel-fnf-mlb.de, Ulabel := beispiel-fünf.de). The resulting URL looks as follows:

https://denic.de/c-form?val1=xn--beispiel-fnf-mlb.de&val2=beispiel-fünf.de.

A second example for a URI template, this time with an e-mail address:

       uri-template: mailto:info@denic.de?subject=domain:{Ulabel}

Here, a web whois request for the domain “beispiel-fünf.de” results in:

mailto:info@denic.de?subject=domain:beispiel-fünf.de.

Note that “request” type contacts (like this one) may only contain a “uri-template” field and no other fields; it must contain a URI template compliant with RFC 6570. Also note that “org” or “person” type contacts (such as the registrant contact) may not contain a “uri-template” field.

             handle:

Alternatively, you can specify a handle to reference an existing contact.

The general contact specifies contact information for general and technical requests for a domain.

              type:
      uri-template:
            handle:

These fields must be filled out in the same way as for the abuse contact. Alternatively, you can specify an adequate handle.

Since Version 3.0 of the DENIC RRI specification has been introduced, no other contact types are allowed than the mandatory registrant contact (section 2) and the optional abuse and general contact (sections 3 and 4, respectively).

Other contact types as they have been previously used by DENIC (and as they are still in use for other top level domains) are not supported anymore. Thus, section 5 is omitted without substitution.

    www-forwarding:
  email-forwarding:
          nsentry1:
          nsentry2:
          nsentry3:
          nsentry4:
          nsentry5:
   ns-domain-name1:
    ns-ip-address1:
   ns-domain-name2:
    ns-ip-address2:
   ns-domain-name3:
    ns-ip-address3:
           hserver:
                ds:
            dnskey:

The completion of this section requires some amount of previous technical knowledge. It will be difficult for you to specify the proper values without an adequate knowledge of the technical background. Some basic terms are listed in our glossary. If you are not familiar with these terms, we suggest that you use the comfortable web interface of our DRS, which will assist you with helpful information.

For registered domains, several different modes of operation with many variants exist. In the enumeration below we have only listed those modes that can be configured by means of this e-mail application form. All the other variants, including mixed ones, can be adjusted via our DRS.

You do not need to actually use the domain right away, but you want to register it already. You can easily do this by providing the following entries:

   ns-domain-name1: ns2.knipp.de
   ns-domain-name2: ns3.knipp.de

The remaining parameters of this section (not listed here) remain empty. Whenever you want to start using the domain, you can update these entries free of charge.

All http requests shall be forwarded to an existing URL. All e-mails targeted at this domain shall be forwarded to another e-mail address. Example:

    www-forwarding: http://students.example.edu/home/~jjones/index.htm
  email-forwarding: j.jones@aol.com

The remaining parameters of this section (not listed here) remain empty. Our DRS provides several other features, like multiple e-mail forwardings, etc. See our frequently asked questions and answers on forwardings for more information.

You operate all the name servers by yourself.

   ns-domain-name1: your-first-dns.some-domain.de
   ns-domain-name2: your-second-dns.new-domain.de
    ns-ip-address2: 195.194.2.77
   ns-domain-name3: possibly-another-dns.other-domain.de

If one of the name servers that you operate is part of the .de zone of the domain that you are about to register (“new-domain.de” in this case), then you have to additionally provide the IP address of that server in the corresponding “ns-ip-address” field.

The other parameters of this section (not listed here) remain empty.

You operate one name server by yourself, while the slave name server shall be operated by Knipp. We provide this service free of charge, by the way. Please use ns3.knipp.de for this purpose. Example:

   ns-domain-name1: dns.your-server.de
   ns-domain-name2: ns3.knipp.de

If one of the name servers that you operate is part of the .de zone of the domain that you are about to register (“new-domain.de” in this case), then you have to additionally provide the IP address of that server in the corresponding “ns-ip-address” field. Example:

   ns-domain-name1: your-first-dns.new-domain.de
    ns-ip-address1: 195.194.2.77
   ns-domain-name2: ns3.knipp.de

The other parameters of this section (not listed here) remain empty.

You operate the master name server yourself but do not want it to be known to the outside world for some reason. In this case, Knipp can operate the official name servers for you, which then retrieve the data from your name server. You just have to specify the IP address of your name server (which is the stealth name server in that case). This service by Knipp is free of charge. Example:

           hserver: 105.207.3.3

The other parameters of this section (not listed here) remain empty.

Important: Please make sure that the name servers “ns2.knipp.de” and “ns3.knipp.de” are allowed to carry out zone transfers from your system.

Knipp shall operate the name servers, but you would like to define the data to be used in the zone. In the example below, a WWW server is supposed to be entered, to which the domain itself points, as well as a mail relay.

          nsentry1: my-domain.de. IN A 195.254.6.12
          nsentry2: www IN A 195.254.6.12
          nsentry3: mail IN MX 10 smtp.provider.de.

The other parameters of this section (not listed here) remain empty. Additional entries or modifications are possible by using our DRS.

Important: If you would like to add zone entries, whose first entry is empty (the so-called owner-entry), you have to put the whole entry in quotation marks. Leaving it blank means that the entry of the previous line will be used. Example:

          nsentry1: my-domain.de. IN A 195.254.6.12
          nsentry2: " IN MX 10 smtp.provider.de."
          nsentry3: " IN MX 20 backup.provider.de."
          nsentry4: www IN A 195.254.6.12

Please bear in mind that MX-entries can point to host names only, but never to IP addresses (the host names used here are “smtp.example.com.” and “backup.example.com.”, respectively). Remember that MX-entries of a different domain than the domain itself must always end with a dot as shown in the example above. (backup.example.com<DOT>)

Please note that the lock: field is not available for .de, .ch/.li- and .eu domains and that it is not allowed in these templates, since these registries do not support a lock function.

Two kinds of DNSSEC data can be specified: DS records and DNSKEY records.

The number of records in the e-mail template is not limited. The names of the fields are all the same, always “ds” or “dnskey”. In case more records are specified than allowed by the registry, an error is returned.

The format of the entries is the RDATA presentation format defined in RFC 4034:

                ds: <key-tag> <alg> <digest-type> <digest>
            dnskey: <flags> <protocol> <alg> <pub-key>

The placeholders for DS records have the following meaning:

The placeholders for DNSKEY records have the following meaning:

Note on PGP signing: In order not to counteract the purpose of DNSSEC and to guarantee for a genuine transmission it is advisable to sign e-mails containing DNSSEC data via PGP. Please get in touch with Knipp Support who will activate the signature functionality for you and accept your public PGP key.

       customer-no:
          password:

Please provide your 5-digit customer number at customer-no, and your e-mail password in field password. (Attention: Your e-mail password is required here, not the one used for the web interface). Each employee of a company receives his own unique access data. This ensures that the DRS can identify which person within your company initiated which process.

           section: 8
accept-agb: http://drs.knipp.de/.../agb-rev...-en.txt
accept-registry: http://drs.knipp.de/domains/types/.../reg-rev...-en.txt

These fields have to be included as in the template without any changes.

Please note the following information concerning this e-mail application form: