- What is the role of the domain's administrative contact?
Usually, a domain's adminstrative contact is simply the registrant.
If the registrant wants someone else
to have full change-control over the domain, a third party can be appointed
administrative contact.
Please note that the admin contact has full, web-based
control of the domain, including the ability to transfer the domain to a new registrant.
It is the registrants responsibility to ensure that proper contracts exist
between a third-party administrative contact and the registrant.
The annual renewal fee is EUR 39. The first year fee (the registration fee) must be
prepaid before registration can proceed.
For list of other fees see ISNIC's
tariff.
Please note that the first year fee must be prepaid within two (2) days
of sending in the application. The application will not be processed unless
the registration fee is paid.
The last step of the registration process allows the registrant to select to pay the
fees using a creditcard. The registrant can also register the card details with ISNIC
and register his/her domains for automatic renewal. In this case the renewal fee will
be debeted to the card 60 days prior to its expiry date, automatically.
Existing domains can similarly be registered for automatic renewal.
The domain's administrative or billing contact logs on the ISNIC web,
selects Modify automatic renewal status, and clicks Register for automatic renewal
for the each domain where automatic renewal is desired, either selecting
to use their already registered creditcard, or registering one for the renewal.
The domain will then be renewed 60 days prior to its expiry date,
automatically every year while the card is valid. Note that the domain's
administrative contact must then explicitly Delete the domain if the registration
is no longer desired.
If a domain remains unpaid on it's expiration date, ISNIC informs the domain's
billing contact (and the domain's administrative contact) that the domain is
about to be deactivated (put on hold).
Once the ISNIC staff has verified that no payment has been made, the domain is
removed from the .is zone and marked "on-hold" in the whois-registry.
This usually happens on the next working day after expiry.
The domain now enters a 60 day grace-period where the domain
remains registered but inactive.
During this period the registrant can reactivate the domain
by paying the renewal fee. No further communications/warnings are issued by
ISNIC during this period.
After 60 days, the domain is deleted and available for re-registration.
Modifications are web-based.
You must begin by logging in to the ISNIC web
using your NIC-handle and password and select
"My page". You will
then get a list of domains and nameservers for which you are registered
and over which you have change-control.
Select the domain/nameserver you wish to modify and follow the instructions.
The domains zone contact is the first (master) nameserver's technical contact. It is
automatically modified, when the domain is redelegated to a new set of
nameservers. The zone contact can thus only be changed by changing the technical contact
of the domains current nameserver as registered with ISNIC, or by redelegating
the domain to a different set of nameservers.
Glue record modifications are web-based.
Log on to the ISNIC web using your NIC-handle (you must use either
the NIC-handle of the administrative contact or of the technical contact).
On
"My page", select the domain you
wish to move (change nameservers for), click "Redelegate" on the
menu, and follow the instructions.
Note that you can only move your domain to a new set of nameservers
if the domain has already been set up on the new nameserver
according the
ISNIC's technincal requirements.
Please contact your prospective DNS provider
(the operator of the new nameservers) if you experience problems/errors when
trying to redelegate your domain.
It is important that nameservers are registered with ISNIC by the nameserver
operator/owner or their technical representative. The nameserver's technical contact
becomes the zone contact for all .is domains delegated to the nameserver and
therefore must be whoever administers the nameserver. ISNIC contacts the
domain's zone contact in case of technical difficulties with the nameservers and
this contact must have systemic access to the nameserver and be able to fix
DNS-technical problems.
To register a nameserver you must have available the nameserver's
intended technical contact handle (nic-handle). If that is not available
the server administrator must begin by
registering a contact object for the nameserver.
Once you have obtained and activated the NIC handle assigned
you can
login to our site
and proceed with the nameserver registration
by
clicking on
"Register"
under the "Nameservers" heading.
The only way to test a particular UDP service is to query the service that
listening on the particular port. Thus the only way to test if a DNS server is
running on UDP port 53 is to make a DNS query. As there is no way of knowing
wich zones are served by that host, so a query for the root zone NS records is
made. A secondary query is also made, in case the root zone fails.
To verify that a nameserver is running, a reply is required. It can be
any RCODE as long as some reply is sent. A timeout is not acceptable.
According to RFC1035 the RCODE should be one of those below:
(RCODE names are from BCP42/RFC2929)
SERVFAIL 2 Server failure - The name server was
unable to process this query due to a
problem with the name server.
REFUSED 5 Refused - The name server refuses to
perform the specified operation for
policy reasons. For example, a name
server may not wish to provide the
information to the particular requester,
or a name server may not wish to perform
a particular operation (e.g., zone
transfer) for particular data.
Or the reply can be NOERROR, with the root zone NS records, but not replying at all is
not an option.
It is important to realize that TTL is not an attribute of a domain (zone).
TTL is an attribute of each record in the zone. ISNIC only requires a minimum
TTL on the nameserver records within the domain (NS resource records).
The value of the TTL field in the NS records affects the query-rate on the .IS nameservers,
therefore there is a certain minimum enforced. Please note that this minimum TTL requirement
only applies to the NS records.
It is possible to debate as to what precisely the minimum value should be, but experience
in recent years suggests that these values should only be lowered from rather
high defaults if some changes are planned. According to RFC1912:
"Popular documentation like [RFC 1033] recommended a day for the minimum TTL,
which is now considered too low except for zones with data that vary regularly.
Once a DNS stabilizes, values on the order of 3 or more days are recommended.
It is also recommended that you individually override the TTL on certain RRs
which are often referenced and don't often change to have very large values
(1-2 weeks). Good examples of this are the MX, A, and PTR records of your
mail host(s), the NS records of your zone, and the A records of your nameservers."
and according to RFC1030:
"Most host information does not change much over long time periods. A good way
to set up your TTLs would be to set them at a high value, and then lower the
value if you know a change will be coming soon. You might set most TTLs to
anywhere between a day (86400) and a week (604800). Then, if you know some
data will be changing in the near future, set the TTL for that RR down to a
lower value (an hour to a day) until the change takes place, and then put it
back up to its previous value."
A recent study on DNS performance concludes
that
"It is not a good idea to make the TTL values low on NS records, or
for A records for name servers. Doing so would increase the load on the root
and [g]TLD servers by about factor of five and significantly harm DNS scalability."
from DNS Performance and the Effectiveness of Caching by
Naeyeon Jung, Emil Sit, Hari Balakrishnana and Robert Morris
ACM Transactions on Networking, Vol. 10, NO. 5 October 2002.
This applies to all TLD servers, both gTLD- and ccTLD-servers as well as
to the root servers.
According to RFC5966:
" ....any DNS server needing to send a UDP response
that would exceed the 512-byte limit is for the server to truncate
the response so that it fits within that limit and then set the TC
flag in the response header. When the client receives such a
response, it takes the TC flag as an indication that it should retry
over TCP instead."
And in section 4 of RFC5966 states:
" All general-purpose DNS implementations MUST support both UDP and TCP
transport.
o Authoritative server implementations MUST support TCP so that they
do not limit the size of responses to what fits in a single UDP
packet."
Accordingly, ISNIC requires nameservers hosting .is domains to support
queries over TCP.
All .is domains are checked for compliance with the
ISNIC technical requrements
once a month. Those that fail this compliance test (which you can execute at
Domains->Check Setup any time)
are then tested weekly and their technical- and zone contacts
informed via email about the nature of the problem. If the technical/zone
contact fails to remedy the situation and the domain fails these tests
for eight consecutive weeks, the domain is deactivated (removed from the .is zone, put on hold).
The domain now enters a 60 day grace-period where the domain remains registered
but inactive. No further communications/warnings are issued by
ISNIC during this period.
If, during the grace-period, the registrant arranges for the domain
to become compliant again (by fixing the nameserver setup, redelegating to a
compliant set of nameservers or by parking the domain) it is automatically reactivated.
After 60 days, the domain is deleted and available for re-registration.
When a contact object (admin, technical or billing contact) is registered with ISNIC
an email is sent to the registered email address requesting that the person (or role)
confirm their willingness to register, and the validity of the email address.
This email contains an URL that must be followed to activate the NIC-handle.
Alternatively, the NIC-handle can be activated by selecting a password. Visit
here and type in your NIC-handle and then
select the "Forgotten your password.." link.
The domain is transferred from one registrant to another via the
ISNIC web interface.
One of the domains contacts
logs on
using his/her
NIC-handle and password, selects the domain to transfer, and
selects "Transfer". The contact will be prompted for the details
on the new registrant. The domains current administrative contact will
then be asked to confirm the transfer request, and once that
is received, the request is queued for processing.
It is often simplest for the current administrative contact to change
the admin-c to that of the new registrant (or his representative). The new
admin contact can then effect the transfer and other changes that need
to be made to the domain's registration when it is transferred from one
registrant to another.
Please note that if the new registrant is a foreign party, special
rules apply and manual confirmation may be required..
The corresponding non-IDN domain is constructed from the IDN
domain according to the following table:
þ -> th á -> a í -> i
æ -> ae é -> e ó -> o
ö -> o ý -> y
ð -> d ú -> u
ISNIC does not have any official registrars. The registrants have direct access to the
.IS registry and deal directly with the registry. Anyone can host .IS domains as long as
their nameservers meet
ISNICs technical requirements,
and the domains zone as set up on
those nameservers meets
ISNICs delegation requirements.
A company that agrees to host .IS domains for their customers, needs to register their
nameservers with ISNIC, see
"How do I register my nameservers with ISNIC?",
and make sure
they are willing to meet ISNICs delegation requirements.
A company can additionally apply for status as an official
ISNIC service provider (ISP)
for .is domains and/or status as an agent for registrants. ISP's have additional control and access.
38498 .is
