DNS. Refers to the Domain Name System as specified in RFCs 1034, 1035, and related RFCs.
DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF), including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1123, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. DNS labels may only include hyphens in the third and fourth position if they represent valid IDNs (as specified above) in their ASCII encoding (e.g., “xn-‐-‐ndk061n”).
DNS. LightEdge operates a geographically redundant DNS platform for Customer use. LightEdge will assist in the registration or modification and migration of domain registration records to LightEdge Primary and Secondary Domain Name servers. LightEdge will provide Primary and Secondary hosting of such DNS records.
DNS. LightEdge operates "resolving" or "caching" DNS servers that Customer may use for domain name look-ups by Customer's in-house systems (PCs, mail servers, etc.) that are connected to Service. This domain name look-up Service is only available if LightEdge is providing primary DNS or primary and secondary DNS to Customer and if Customer does not have its own DNS server(s), and it may not be used by Customer’s spam detection software for querying spam block lists. Customers running their own DNS Servers or relying on third parties to host their domain names must use their own servers or the third party’s DNS Servers for this purpose. These servers may not be configured to forward DNS queries to LightEdge’s DNS Servers. Customers may not make more than 150 DNS queries per minute averaged over 30 minutes and/or more than 600 DNS queries per minute during any 5-minute interval. LightEdge will provide reverse DNS at the request of Customer for all IP addresses statically routed to Customer as part of Service.
DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966. For domain names which are either not registered, or the registrant has not supplied valid records such as NS records for listing in the DNS zone file, or their status does not allow them to be published in the DNS, the use of DNS wildcard Resource Records as described in RFCs 1034 and 4592 or any other method or technology for synthesizing DNS Resources Records or using redirection within the DNS by the Registry is prohibited. When queried for such domain names the authoritative name servers must return a “Name Error” response (also known as NXDOMAIN), RCODE 3 as described in XXX 0000 and related RFCs. This provision applies for all DNS zone files at all levels in the DNS tree for which the Registry Operator (or an affiliate engaged in providing Registration Services) maintains data, arranges for such maintenance, or derives revenue from such maintenance. Registry Operator shall sign its TLD zone files implementing Domain Name System Security Extensions (“DNSSEC”). During the Term, Registry Operator shall comply with RFCs 4033, 4034, 4035, 4509 and their successors, and follow the best practices described in RFC 6781 and its successors. If Registry Operator implements Hashed Authenticated Denial of Existence for DNS Security Extensions, it shall comply with RFC 5155 and its successors. Registry Operator shall accept public-key material from child domain names in a secure manner according to industry best practices. Registry shall also publish in its website the DNSSEC Practice Statements (DPS) describing critical security controls and procedures for key material storage, access and usage for its own keys and secure acceptance of registrants’ public-key material. Registry Operator shall publish its DPS following the format described in XXX 0000.
DNS. Registry Operator shall comply with relevant existing RFCs and those published in the future by the Internet Engineering Task Force (IETF) including all successor standards, modifications or additions thereto relating to the DNS and name server operations including without limitation RFCs 1034, 1035, 1982, 2181, 2182, 2671, 3226, 3596, 3597, 4343, and 5966.
DNS. LightEdge operates "resolving" or "caching" DNS servers that Customer may use for domain name look-ups by Customer's in-house systems (PCs, mail servers, etc.) that are connected to Service. This domain name look-up Service is only available if LightEdge is providing primary DNS or primary and secondary DNS to Customer and if Customer does not have its own DNS server(s), and it may not be used by Customer’s spam detection software for querying spam block lists. Customers running their own DNS Servers or relying on third parties to host their domain names must use their own servers or the third party’s DNS Servers for this purpose. These servers may not be configured to forward DNS queries to LightEdge’s DNS Servers. Customers may not make more than 150 DNS queries per minute averaged over 30 minutes and/or more than 600 DNS queries per minute during any 5-minute interval.
DNS. LightEdge will assist in the registration or modification and migration of domain registration records to LightEdge Primary and Secondary Domain Name servers. LightEdge will provide Primary and Secondary hosting of such DNS records.
DNS. DNS is the Internet address system which allows a customer to reach --- the the new store via the desired URL such as xxx.xxxxx.xxx. This needs to be ------------- hanged at least one week prior to the expected store launch so that the changes have been propagated to all DNS servers on the Internet. Our policy is to support your existing store ip address on our servers, so that even after the DNS has been updated to point to our servers, your existing site will still be reachable until we have launched the new store.
DNS. Company uses DNS-based global load balancing to direct search traffic to one of the several facilities that serve Company's search traffic. Microsoft servers will adhere to the TTL in the Company name server resolution response (no more than [*]), periodically querying the Company DNS servers to determine the IP address of the Company site where the Microsoft servers must direct their query traffic. Company will not be responsible for satisfying requirements for Availability Response Times if TTLs exceed [*].
