Bu sözleşme ile daha.net’e ait olan https://www.daha.net adresli internet sitesinde belirtilen hizmetleri sağlayan daha.net ile Müşteri, sitenin ve bu site üzerinden satın alınabilen hizmetlerin kullanımı ile ilgili aşağıda belirtilen madde ve koşulları kabul etmiş sayılacaktır. Müşteri, siparişinin internet ortamında daha.net’e gönderilmesi ile bu sözleşmeye imza atmış sayılır. daha.net, Müşterinin siparişini kabul etmekle bu sözleşmeye imza atmış sayılır.
daha.net: SoftCom Bilişim Hizmetleri ve Tic. A.Ş. yi ifade eder.
Müşteri: Hizmet ve/veya hizmetlerden faydalanmak için başvurup Müşteri kaydı oluşturmuş kişi, kurum veya kuruluşu ifade eder.
Hizmetler: https://www.daha.net adresli internet sitesi üzerinden sunulan, satılan ve sağlanan servisler ve hizmetlerin tümünü ifade eder.
Bu belge daha.net tarafından, daha.net’in güvenlik ve gizlilik konusundaki politikalarını belirtmek için hazırlanmıştır.
Sitemizde alışveriş yaparken üyelik sistemimize kayıt olmanız gerekmektedir. Üyelik sistemimiz dahilinde sizden istenen iletişim bilgileri alan adı tescilinde, acil durumlarda ve faturalarınızın teslimatında kullanılacaktır. Üyelik sistemi içerisinde vermiş olduğunuz bilgileri istediğiniz zaman düzenleme ve güncelleme haklarına sahipsiniz. Üyelik sistemi içerisinde verilen kişisel ve kurumsal bilgiler bu sistem dışında bir işlem için kullanılmayacaktır.İsterseniz daha sonra bu bilgileri sildirebilirsiniz. Alınan finansal bilgiler satın alınan ürün ve hizmetlerin bedelinin tahsil edilmesinde ve diğer gerek duyulan durumlarda kullanılacaktır. İstatistiki bilgiler ve profil bilgileri ayrıca sitemizin içinde de toplanmaktadır. Bu bilgiler ziyaretçi hareketlerinin izlenmesi, kişiye özel içerik sağlanması gibi istenilen tüm durumlarda kullanılabilir.
Kişisel bilgilerinizin yanında IP adresinizi sunucularımızdaki sorunların giderilmesi ve internet sitemizi yönetmek için kullanacağız. IP adresiniz, sizi ve alışveriş sepetinizi tanımak ve açık demografik bilgilerinizin toplanması için kullanılacaktır.
Sitemizde bilgi kaybını, bilginin izin verilmeyen kullanımını ve izinsiz değiştirilmesini engellemek için firmamızca uygulanan güvenlik önlemleri bulunmaktadır. Bu güvenlik önlemleri şunlardır:
1 – SSL Güvenlik Sertifikası ile kredi kartı tahsilatı sayesinde Secure Socket Layer ile şifreli olarak kredi kartı bilginiz bankamıza iletilir.
2 – Kredi kartı bilgileriniz kesinlikle kaydedilmez. Kredi kartınızdan ücret tahsilatı yalnızca siz ve bankanız arasında gerçekleşmektedir.
3 – Sistemimiz sunucu düzeyi uygulamalarda güvenilir olarak belirlenmiş Linux işletim sistemi üzerinde PHP programlama dili ve MySQL veritabanı ile hizmet vermektedir. En son güncellemeler ve güvenlik önlemleri tarafımızca düzenli olarak yapılmaktadır.
Ücret iadesi yapılmayacak ürünler aşağıda listelenmiştir.
Özel olarak 5651 sayılı Kanun kapsamında açık olarak ifade edilen:
daha.net kişisel bilgileri yalnızca söz konusu bilgilere erişimin, bu bilgilerin korunmasının veya ifşa edilmesinin (a) yürürlükteki herhangi bir yasaya, düzenlemeye, yasal işleme veya uygulanabilir resmi isteğe uyulması, (b) potansiyel ihlallerin araştırılması dahil olmak üzere ilgili Hizmet Şartlarının uygulanması, (c) sahtekarlıkla veya güvenlikle ilgili sorunların veya teknik sorunların saptanması, önlenmesi ya da başka bir şekilde ele alınması veya (d) yasaların gerektirdiği veya izin verdiği şekilde kamunun haklarına, mülkiyetine veya güvenliğine ilişkin olarak oluşabilecek zararlara karşı korunması için makul bir şekilde gerekli olduğu takdirde üçüncü kişilerle paylaşır.
Background: One of the new provisions added to the 2009 RAA requires ICANN to develop in consultation with registrars a webpage that identifies available registrant rights and responsibilities. This published document is the result of initial input from a joint working group of the GNSO Council and the At-Large Advisory Committee and subsequent consultations with the registrars; and provides a “plain language” summary of registrant rights and responsibilities that currently exist under the 2009 RAA.
This document provides some “plain language” summarization of terms related to Registrant Rights and Responsibilities as set out in the Registrar Accreditation Agreement (RAA), for posting on Registrar websites. While some of the terms included here do not specifically refer to registrants, those terms are included because of the potential import to understanding registrar/registrant relations. This document also summarizes registrant rights and responsibilities that arise within ICANN Consensus Policies and specifications, as those policies and specifications are incorporated into the RAA.’
The summarization of terms within this document do not override or replace the terms set forth in the RAA or within those specifications or policy.
In order to register a domain name, a Registered Name Holder (also known as a Registrant) has to use the services of an ICANN-accredited Registrar. In order to become an ICANN-accredited Registrar, the Registrar must enter into a contract with ICANN, referred to as the Registrar Accreditation Agreement or the RAA. The RAA sets out various rights and responsibilities for Registrants, and Registrants have additional rights and responsibilities that are set forth in separate ICANN policies and specifications that the Registrars agree to follow.
The RAA and the related policies are drafted in very specific, often legal terminology. In order to help Registrants better understand the rights and responsibilities that come along with the registration of a domain name, these rights and responsibilities are being summarized and presented within a single document. The summaries provided here do not override or replace the actual terms as written in the RAA or the related policies and specifications.
As the RAA is between ICANN and a Registrar, no one else – including a Registered Name Holder – may sue ICANN or the Registrar to claim a breach of the RAA.
Registrars may not make claims that they can provide registrants with superior access to any relevant TLD in comparison to other Registrars.
Some of the Registrar obligations are dependent upon Registered Name Holders fulfilling certain responsibilities, particularly as it relates to payment of registration fees, submission of required data points to the Registrars, and submission of accurate data and timely updates to that required data. Registrars also have specific items on which they must provide notice to Registered Name Holders, including notifications of the end of a registration term, use of Registered Name Holder’s Personal Data, and notices regarding escrowing of data for domain names registered through privacy or proxy registration services, as well as the posting of fees for the recovery of registered names.
Registrar Submission of Data to Registry Operators
For each relevant TLD, Registrars must submit certain data points relating to each Registered Name within a TLD:
Registered Name Holders are normally required to provide the Registrar with information relating to nameservers (126.96.36.199 – 3), and there may be additional data required under Section 188.8.131.52 that the Registered Name Holder must provide. If the Registered Name Holder provides an update on these data points, the Registrar has five (5) days to provide the update to the Registry Operator.
Registrars are required to have an interactive web page and port 43 Whois service that is available to the public to query free of charge. The RAA specifies certain data points that must be provided in response to a query:
These data points are commonly referred to as Whois data. As discussed below, Registered Name Holders are required to provide a Registrar with timely updates to Whois data for a Registered Name. Upon receiving the update, a Registrar is to “promptly” update the Whois data. Registrars may contract out the maintenance of the public query function.
The RAA allows Registrars to provide bulk access to Whois data to third parties. When providing bulk access or access to the Whois data through the public query function, the Registrar is required to restrict access for high volume queries or other restrictions on uses of Whois data as specified in the RAA, including marketing activities and mass solicitations. If a Registrar contracts the public function query to an outside party, the Registrar must require any contractor providing the port 43 service to impose the same restrictions on access to and use of the Whois data.
Communications with Registered Name Holders
Registrars are required to maintain records of all communications with Registered Name Holders, as well as records of information provided to Registry Operators.
Escrow of Registered Name Holder Data
A Registrar is required to maintain a database of all Whois data for all Registered Names registered through the Registrar’s accreditation, as well as all data the Registrar submits to the Registry Operator. In addition, the Registrar must include in the database the name and (where available) postal address, e-mail address, voice telephone number, and fax number of the billing contact for each Registered Name.
In some instances, a registrant may choose to limit the amount of personal information that a Registrar makes available in a Whois query. To do so, the name may be registered through a privacy service (allowing a registrant to conceal personal identifying information and often replacing it with the information of the privacy service). Customers may also choose to register names through a proxy service, where the proxy service is the Registered Name Holder, and the proxy service licenses the use of the domain name to the customer. In that situation, the proxy service, as the Registered Name Holder, has its information listed for most or all required data points.
When a Registered Name is registered through a privacy or proxy registration service, that affects the information that is placed in the database, and a Registrar must do one of two things: The Registrar must either (1) include in the database the name and postal address, e-mail address, and voice telephone number provided by the customer in connection with each registration, even when a privacy or proxy registration is used; or (2) at the time that a customer elects to use a privacy or proxy registration service, display a notice that the customer’s data is not being escrowed. When a customer’s data is not being escrowed, only the contact information associated with the privacy or proxy registration service will be escrowed. If a customer’s data is not escrowed, and only the information of the proxy or privacy service is maintained in the database, in the event of Registrar or Registry failure future notices may only be sent to the contact information within the database.
Registrar Business Dealings with Registrants
The RAA imposes many requirements on a Registrar’s business dealings, including its dealings with Registered Name Holders.
A registrar may not activate a Registered Name until it receives reasonable assurance from the Registered Name Holder that the registration fee will be paid.
The RAA sets forth actions the Registrar may take at the conclusion of the registration period if a Registered Name Holder has not provided consent to renew the registration, including the Registrar cancelling the registration at the end of the current registration term. If the Registered Name Holder did not consent to renewal, the Registrar must make sure that a Registered Name is deleted from the Registry database within 45 days of the end of the registration term.
This right for the Registrar to cancel the registration and the obligation to the delete the domain name is not absolute. Section 184.108.40.206 of the RAA sets forth a list of potential “extenuating circumstances,” that, if exist, allows the Registrar to renew the domain name even without the consent of the Registered Name Holder. These circumstances include the Registered Name being subject to a UDRP action, court order, bankruptcy proceeding, or billing dispute, among other items. The Registrar must keep a record of reasons why the Registrar renewed a registration without the consent of a Registered Name Holder.
Registrars have to provide each new registrant with notice of the Registrar’s deletion and auto-renewal policies. If the Registrar’s deletion policy changes during the time of the registration agreement, the Registrar has to make efforts to inform the registrants of those policy changes. Details of the deletion and auto-renewal policies have to be displayed on any website the Registrar operates for domain name registration and renewal, and the Registrar should also state on those sites any fee that will be charged for the recovery of a domain name during the Redemption Grace Period (the 30 day period of time during which the name is in “Pending Delete” status with the Registry).1
If a Registered Name is the subject of a UDRP dispute at the time of deletion or expiration of the registration, the UDRP complainant has the right to renew (or restore, in the case of a deletion) the domain name. If the complainant renews or restores the name, the Registrar must place the name in a HOLD or LOCK status,2 and must modify the Whois information to show that the name is subject to dispute. Section 220.127.116.11 of RAA also provides for a right for the original domain name registrant to recover or renew the name in the event the UDRP complaint is terminated without decision, or the UDRP complaint is decided in favor of the original domain name registrant.
The Registrar/Registered Name Holder Agreement
Registrars are required to enter into electronic or paper registration agreements with all Registered Name Holders. According to the RAA, the Registrar/Registered Name Holder Agreement must include – at minimum – the following items (as stated at Sections 18.104.22.168 – 12 of the RAA):
Verification of contact information
As described in more detail below, there are specifications and policies that may be created and that apply to the Registrars. Some of the specifications or policies may address a Registrar’s obligation to verify the contact information supplied by the Registered Name Holder when the domain is first registered, as well as setting out requirements for periodic re-verification of contact information.
Registrars are also required to take “reasonable steps” to verify contact information in the event any person notifies the Registrar that contact information for a Registered Name is inaccurate. The Registrar also has obligations to act to correct inaccuracies in contact information that the Registrar becomes aware of, even if the inaccuracy was not reported by anyone.
The Registrar must also maintain proper contact information for itself, including a valid email and mailing address. This contact information should be posted on the Registrar’s website.
The RAA imposes obligations on Registrars working with third-party Resellers – persons or entities that the Registrar contracts with to provide Registrar Services. The RAA now requires Registrars to include specific items in the Registrar/Reseller Agreements, including: prohibiting the Reseller from making representations that it is accredited by ICANN; requiring that all Reseller registration agreements include all provisions that the Registrar is required to include in its Registrar/Registered Name Holder Agreement; requiring the posting of all links to all ICANN websites that the Registrar is obligated to post; and identification of the sponsoring registrar. The Reseller is also required to make sure that that if a customer is using a Reseller’s privacy or proxy registration service for a domain name registration, the Reseller does one of the following three things: (1) deposit the identity and contact information of the customer with the Registrar; (2) deposit the identity and contact information in escrow; or (3) posts a notice to the customer that their contact information is not being escrowed.
The RAA also requires the Registrar to take compliance and enforcement action against a Reseller violating any of the required provisions.
The Restored Names Accuracy Policy (http://www.icann.org/en/registrars/rnap.htm) requires that when a registrar restores a name (from the redemption grace period) that had been deleted on the basis of submission of false contact data or non-response to registrar inquiries, the name must be placed on Registrar Hold status until the registrant has provided updated and accurate Whois information.
In addition to the RAA requirement that a Registered Name Holder represent that to the best of its knowledge, the registration or use of the domain name does not infringe on the legal rights of others, the Uniform Domain Name Dispute Resolution Policy (“UDRP“) requires that same representation to be made, as well as a representation that the domain name is not being registered for an unlawful purpose, and will not be used in violation of any applicable laws.
The UDRP also requires Registered Name Holders to submit to mandatory administrative proceedings to resolve disputes under the UDRP. These mandatory administrative proceedings, as described in the UDRP, are disputes that are filed before one of the ICANN approved UDRP dispute resolution providers (listed at http://www.icann.org/en/dndr/udrp/approved-providers.htm) and following the uniform Rules for UDRP administrative proceedings (set out at http://www.icann.org/en/dndr/udrp/uniform-rules.htm). The requirement for submission to mandatory administrative proceedings does not mean that Registered Name Holders cannot also have judicial proceedings filed against them for the same or similar conduct. Similar to the jurisdictional requirements set out in the RAA, the requirement to submit to a mandatory administrative proceeding means that the Registered Name Holder cannot dispute the UDRP provider’s ability to hear a dispute that is otherwise properly brought under the UDRP.
The Policy on Transfers of Registrations between Registrars provides that Registered Name Holders have the right to transfer domain name registrations among registrars. The transfer policy imposes time limits on when the Registrar must respond to a transfer request. The right to transfer is not absolute – there are ICANN and Registry policies that may set limits on the transfer right, including: limitations on when a domain name may be transferred (measured from dates of creation or earlier transfer); and the Registered Name Holder providing of required authorization and documentation for Registrar review. The Registrar of Record may only deny a transfer in the following instances:
1 A graphic representation of the life cycle of a typical gTLD Registered Name is located at http://www.icann.org/en/registrars/gtld-lifecycle.htm. This diagram may be useful to refer to for more information on the post-expiration status of domain names.
2 There are formal technical names for domain name statuses, arising out of the community-based Internet draft Request for Comments. The statuses required here are set by the Registrar. When a registration is in one of these statuses, the domain cannot be deleted and the registration cannot be modified. The Registrar must alter the status in order for any modification to occur.
3 There are many other potential ways to “infringe the legal rights” of others, and potential Registered Name Holders are encouraged to seek independent advice if they are concerned that the registration or use of a domain name may violate someone else’s rights.
4 There could be other jurisdictions that are able to decide a dispute about the use of a registered name, but those additional jurisdictions are not specified in the RAA.
All registrars must follow the Uniform Domain-Name Dispute-Resolution Policy (often referred to as the “UDRP“). Under the policy, most types of trademark-based domain-name disputes must be resolved by agreement, court action, or arbitration before a registrar will cancel, suspend, or transfer a domain name. Disputes alleged to arise from abusive registrations of domain names (for example, cybersquatting) may be addressed by expedited administrative proceedings that the holder of trademark rights initiates by filing a complaint with an approved dispute-resolution service provider.
To invoke the policy, a trademark owner should either (a) file a complaint in a court of proper jurisdiction against the domain-name holder (or where appropriate an in-rem action concerning the domain name) or (b) in cases of abusive registration submit a complaint to an approved dispute-resolution service provider (see below for a list and links).
The following documents provide details:
- Uniform Domain Name Dispute Resolution Policy – This policy is followed by all registrars.
- Rules for Uniform Domain Name Dispute Resolution Policy – These rules are followed by all dispute-resolution service providers, with supplementation by each provider’s supplemental rules.
- Archived Rules – Prior version of Rules in effect for proceedings filed on or before 28 February 2010
- List of Approved Dispute-Resolution Service Providers
- Information Concerning Approval Process for Dispute-Resolution Service Providers
- Staff Report on Implementation Documents for the Uniform Dispute Resolution Policy (29 September 1999)
- Second Staff Report on Implementation Documents for the Uniform Dispute Resolution Policy (24 October 1999)
Proposed Implementation Documents (form posted for public comment September 29, 1999)
- Draft Uniform Domain Name Dispute Resolution Policy (29 September 1999)
- Draft Rules for Uniform Domain Name Dispute Resolution Policy (29 September 1999)
Public Comments Submitted (comment period September 29-October 13, 1999)