DOCSLIB.ORG

Afilias Managed DNS Frequently Asked Questions Frequently Asked

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Afilias Managed DNS Frequently Asked Questions Frequently Asked Afilias Managed DNS Frequently Asked Questions Frequently Asked Questions 1 Specific Questions about Afilias Managed DNS 2 1.1 What is the Afilias DNS network? . 2 1.2 How long has Afilias been working within the DNS market? . 2 1.3 What are the names of the Afilias name servers? . 2 1.4 How does my configuration get propagated to DNS and how long does it take? . 2 1.5 How can I confirm that changes I make to my domains are being resolved on the Afilias network?............................................. 2 1.6 For secondary DNS service, what happens if there is a failure when transferring the zone file from my primary server? . 2 1.7 How easy is it to move domains over from another DNS provider and will there be any downtime? . 3 1.8 What support does Afilias provide? . 3 1.9 Does the Afilias network support IPv6? . 3 1.10 What resource records does Afilias support? . 3 1.11 Can I do bulk changes? . 3 2 General DNS Questions 3 2.1 What is DNS? . 3 2.2 Where can I get more information about DNS? . 4 2.3 What is DNSSEC? . 4 2.4 When will DNSSEC be available? . 4 2.5 What is BIND? . 4 2.6 What is the difference between a domain and a zone? . 4 2.7 What is a \glue record"? . 4 2.8 What is the difference between Primary, Secondary, Master and Slave DNS? . 4 3 Questions about Security 5 3.1 What is a distributed denial of service attack, or DDoS? . 5 3.2 What is a \botnet"? . 5 3.3 What is spam? . 5 3.4 What is \phishing"? . 5 3.5 What is \pharming"? . 5 3.6 What is malware? . 5 3.7 What does the term \Fast Flux" refer to? . 6 4 Questions about Internet and DNS Administration 6 4.1 What is ICANN? . 6 4.2 What is SSAC? . 6 4.3 What is RSSAC? . 6 5 Questions about Site Certain 6 5.1 What is SiteCertain? . 6 5.2 How do I add a URL for SiteCertain Monitoring? . 7 5.3 How do I add an IP address to SiteCertain Monitoring? . 7 5.4 How many IP addresses can I add? . 7 5.5 How do I set up script monitoring? . 7 5.6 How will I be notified of a failover? . 7 Issue 3 c Afilias Limited 2009 1 Afilias Managed DNS Frequently Asked Questions 6 Questions About Billing 7 6.1 What are the wiring instructions for Afilias Managed DNS service? . 7 6.2 To whom should checks be made payable? . 7 6.3 Where should checks be sent? . 8 Issue 3 c Afilias Limited 2009 2 Afilias Managed DNS Frequently Asked Questions 1 Specific Questions about Afilias Managed DNS 1.1 What is the Afilias DNS network? Afilias manages a global network of dedicated high performance servers that provides supe- rior response times to all DNS lookups and queries. This network was developed to support all the top level domains (TLD, gTLD, ccTLD) managed by Afilias registry services. Afilias Managed DNS now provides premium DNS service for other customers on this network. 1.2 How long has Afilias been working within the DNS market? Afilias has been a leader in the DNS market since 2000 when it won the ICANN bid to provide new registry services for the .info top level domain (TLD). It developed its premium DNS network in 2005. 1.3 What are the names of the Afilias name servers? The name servers for Afilias Managed DNS are shown on the SOA screen of each primary domain configuration. They are: • a.service.afiliasdns.info • b.service.afiliasdns.org • c.service.afiliasdns.net • d.service.afiliasdns.com • e.service.afiliasdns.info • f.service.afiliasdns.net 1.4 How does my configuration get propagated to DNS and how long does it take? Your primary (master) DNS configuration is stored in a database. Whenever you make changes, the serial number is automatically incremented. This triggers a notify message that is sent to the Afilias network. An Afilias server then does a DNS zone transfer to copy your changes and distribute them across the Afilias DNS network. This process is completed within a few minutes. 1.5 How can I confirm that changes I make to my domains are being re- solved on the Afilias network? There are detailed examples in the User Guide of how to use dig and nslookup to verify your changes on the Afilias network and on the Internet. 1.6 For secondary DNS service, what happens if there is a failure when transferring the zone file from my primary server? There is currently no mechanism to deliver error messages on zone transfers (AXFR/IXFR) to the Afilias secondary service. You should run dig/nslookup (as shown in the Verification section of the User Guide) to confirm that the serial number of the zone on the Afilias network matches the serial on your primary server. If there is a mismatch, and you suspect the transfer has failed, you can send in a ticket using the Support screen on the web portal or call the Afilias Customer Service Center for further analysis of the problem. Issue 3 c Afilias Limited 2009 3 Afilias Managed DNS Frequently Asked Questions 1.7 How easy is it to move domains over from another DNS provider and will there be any downtime? If your domain is small, you can simply create it using the Afilias Managed DNS web portal. For a larger domain, if your current DNS provider has an export option, you can use this to create a file that can be imported. Once your primary domain is set up and you have verified it is resolving correctly on the Afilias network, you simply reconfigure the name servers on your other provider to point to the Afilias name servers. Providers generally take from 15 minutes to 1 day to complete this change. Some providers terminate DNS service as soon as name servers are configured to point off their network. You can increase the TTL on such providers in advance of making the change to mitigate downtime by increasing the time that caching DNS servers retain your domain information. Please see the Afilias Managed DNS User Manual for for more information. 1.8 What support does Afilias provide? Afilias maintains a Customer Service Center that is staffed 24 hours a day, 7 days a week. You can contact them by phone at the number shown on the top of every web portal screen. You can also send in a request via the Support page on the web portal. This request will create a \ticket" that will be handled by a support analyst who will reply by email. 1.9 Does the Afilias network support IPv6? Yes. The Afilias network is fully IPv6 compliant and can handle DNS queries from machines running IPv6 and allows you to add AAAA records to your zones. 1.10 What resource records does Afilias support? For secondary service, Afilias zone transfers from your primary DNS will support all records supported by BIND 9. For primary DNS service, the records you can enter are: A, AAAA, CNAME, MX, NS, TXT, PTR, SRV. Subsequent release will add support for other record types such as NAPTR, DNAME. 1.11 Can I do bulk changes? Via the API, you are able to define up to 10,000 secondary zones for creation, deletion, or update in a single operation. Via the API you may update as much of the content of a primary zone as you wish in a single operation. There is currently no API support for bulk management of more than one primary zone. 2 General DNS Questions 2.1 What is DNS? Computers on the Internet are identified by a unique numeric address, an IP address. The Domain Name System (DNS) makes using the Internet easier by allowing applications to use names instead of IP addresses. Instead of having to type 206.153.158.4 in a web browser, a person can simply type www.somewhere.info. The web browser will \resolve" the name and translate it to the necessary IP address by sending a query to a DNS server to do the lookup and translation. DNS also enables email addresses to be used with names instead of IP addresses. Issue 3 c Afilias Limited 2009 4 Afilias Managed DNS Frequently Asked Questions 2.2 Where can I get more information about DNS? There are many good books that provide in depth descriptions of DNS. There are also many good tutorials and other articles about DNS on the Internet. The ultimate definition of the DNS protocol and best practices for managing DNS is provided by the RFC publications of the IETF, the Internet standards body. 2.3 What is DNSSEC? DNSSEC (DNS Security Extensions) is an enhancement to the DNS protocol. It allows zone administrators such as the IANA to sign their zone files using public key cryptography. DNS users can then use these signatures to verify that the information they receive from DNS servers, such as the root name servers, is authentic. This prevents manipulation of the data during storage on servers and during transmission. 2.4 When will DNSSEC be available? DNSSEC will be available for primary zones in the second half of 2011. 2.5 What is BIND? BIND stands for Berkeley Internet Name Daemon. This was one of the first implementa- tions of a DNS server. It is a standard component of most Unix and Linux systems and runs as the process \named".
Load more

Recommended publications
  • Characterizing Certain Dns Ddos Attacks
    CHARACTERIZING CERTAIN DNS DDOSATTACKS APREPRINT Renée Burton Cyber Intelligence Infoblox [email protected] July 23, 2019 ABSTRACT This paper details data science research in the area of Cyber Threat Intelligence applied to a specific type of Distributed Denial of Service (DDoS) attack. We study a DDoS technique prevalent in the Domain Name System (DNS) for which little malware have been recovered. Using data from a globally distributed set of a passive collectors (pDNS), we create a statistical classifier to identify these attacks and then use unsupervised learning to investigate the attack events and the malware that generates them. The first known major study of this technique, we discovered that current attacks have little resemblance to published descriptions and identify several previously unpublished features of the attacks. Through a combination of text and time series features, we are able to characterize the dominant malware and demonstrate that the number of global-scale attack systems is relatively small. 1 Introduction In the field of Cyber Security, there is a rich history of characterizing malicious actors, their mechanisms and victims, through the analysis of recovered malware1 and related event data. Reverse engineers and threat analysts take advantage of the fact that malware developers often unwittingly leave fingerprints in their code through the choice of libraries, variables, infection mechanisms, and other observables. In some cases, the Cyber Security Industry is able to correlate seemingly disparate pieces of information together and attribute malware to specific malicious actors. Identifying a specific technique or actor involved in an attack, allows the Industry to better understand the magnitude of the threat and protect against it.
    [Show full text]
  • DNS Zones Overview
    DNS Zones Overview A DNS zone is the contiguous portion of the DNS domain name space over which a DNS server has authority. A zone is a portion of a namespace. It is not a domain. A domain is a branch of the DNS namespace. A DNS zone can contain one or more contiguous domains. A DNS server can be authoritative for multiple DNS zones. A non-contiguous namespace cannot be a DNS zone. A zone contains the resource records for all of the names within the particular zone. Zone files are used if DNS data is not integrated with Active Directory. The zone files contain the DNS database resource records that define the zone. If DNS and Active Directory are integrated, then DNS data is stored in Active Directory. The different types of zones used in Windows Server 2003 DNS are listed below: Primary zone Secondary zone Active Directory-integrated zone Reverse lookup zone Stub zone A primary zone is the only zone type that can be edited or updated because the data in the zone is the original source of the data for all domains in the zone. Updates made to the primary zone are made by the DNS server that is authoritative for the specific primary zone. Users can also back up data from a primary zone to a secondary zone. A secondary zone is a read-only copy of the zone that was copied from the master server during zone transfer. In fact, a secondary zone can only be updated through zone transfer. An Active Directory-integrated zone is a zone that stores its data in Active Directory.
    [Show full text]
  • Privacy Policy V1.1
    CENTRALNIC LTD REGISTRY PRIVACY POLICY Version 1.1 September 2018 CentralNic Ltd 35-39 Moorgate London EC2R 6AR Table of Contents TABLE OF CONTENTS ......................................................................................................................... 2 AMENDMENT ISSUE SHEET ................................................................................................................. 3 INTRODUCTION ................................................................................................................................ 4 DATA PROTECTION RIGHTS ................................................................................................................. 5 RELATIONSHIP WITH REGISTRARS ......................................................................................................... 6 WHAT INFORMATION CENTRALNIC COLLECTS .......................................................................................... 6 INFORMATION CENTRALNIC DOES NOT COLLECT ....................................................................................... 8 HOW INFORMATION IS STORED ............................................................................................................ 8 HOW WE USE INFORMATION ............................................................................................................... 8 HOW INFORMATION IS PROTECTED ..................................................................................................... 13 HOW INFORMATION IS DELETED ........................................................................................................
    [Show full text]
  • Configuring DNS
    Configuring DNS The Domain Name System (DNS) is a distributed database in which you can map hostnames to IP addresses through the DNS protocol from a DNS server. Each unique IP address can have an associated hostname. The Cisco IOS software maintains a cache of hostname-to-address mappings for use by the connect, telnet, and ping EXEC commands, and related Telnet support operations. This cache speeds the process of converting names to addresses. Note You can specify IPv4 and IPv6 addresses while performing various tasks in this feature. The resource record type AAAA is used to map a domain name to an IPv6 address. The IP6.ARPA domain is defined to look up a record given an IPv6 address. • Finding Feature Information, page 1 • Prerequisites for Configuring DNS, page 2 • Information About DNS, page 2 • How to Configure DNS, page 4 • Configuration Examples for DNS, page 13 • Additional References, page 14 • Feature Information for DNS, page 15 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to www.cisco.com/go/cfn. An account on Cisco.com is not required.
    [Show full text]
  • Reverse DNS What Is 'Reverse DNS'?
    Reverse DNS Overview • Principles • Creating reverse zones • Setting up nameservers • Reverse delegation procedures What is ‘Reverse DNS’? • ‘Forward DNS’ maps names to numbers – svc00.apnic.net -> 202.12.28.131 • ‘Reverse DNS’ maps numbers to names – 202.12.28.131 -> svc00.apnic.net 1 Reverse DNS - why bother? • Service denial • That only allow access when fully reverse delegated eg. anonymous ftp • Diagnostics • Assisting in trace routes etc • SPAM identifications • Registration • Responsibility as a member and Local IR In-addr.arpa • Hierarchy of IP addresses – Uses ‘in-addr.arpa’ domain • INverse ADDRess • IP addresses: – Less specific to More specific • 210.56.14.1 • Domain names: – More specific to Less specific • delhi.vsnl.net.in – Reversed in in-addr.arpa hierarchy • 14.56.210.in-addr.arpa Principles • Delegate maintenance of the reverse DNS to the custodian of the address block • Address allocation is hierarchical – LIRs/ISPs -> Customers -> End users 2 Principles – DNS tree - Mapping numbers to names - ‘reverse DNS’ Root DNS net edu com arpa au apnic in-addr whoiswhois RIR 202202 203 210 211.. ISP 6464 22 .64.202 .in-addr.arpa Customer 2222 Creating reverse zones • Same as creating a forward zone file – SOA and initial NS records are the same as normal zone – Main difference • need to create additional PTR records • Can use BIND or other DNS software to create and manage reverse zones – Details can be different Creating reverse zones - contd • Files involved – Zone files • Forward zone file – e.g. db.domain.net • Reverse zone file – e.g. db.192.168.254 – Config files • <named.conf> – Other • Hints files etc.
    [Show full text]
  • Web Portal User Manual For
    Web Portal User Manual for ©Copyright 2009 Afilias Limited Afilias Managed DNS – Web Portal User Manual Contents 1. Introduction ................................................................................................................ 1 1.1 About Afilias Managed DNS Service ........................................................................ 1 1.2 Afilias Managed DNS Service Website Help ............................................................. 1 1.3 Support .................................................................................................................. 2 2. DNS Portal Login Screen ............................................................................................... 4 3. MyAccount Screen ....................................................................................................... 5 3.1 Users & Groups ...................................................................................................... 5 3.1.1 User Details Tab ...................................................................................................... 6 3.1.2 User Password Tab .................................................................................................. 7 3.1.3 Users Tab ................................................................................................................. 8 3.1.4 Groups Tab .............................................................................................................. 9 3.2 Add User ...............................................................................................................
    [Show full text]
  • Proactive Cyberfraud Detection Through Infrastructure Analysis
    PROACTIVE CYBERFRAUD DETECTION THROUGH INFRASTRUCTURE ANALYSIS Andrew J. Kalafut Submitted to the faculty of the Graduate School in partial fulfillment of the requirements for the degree Doctor of Philosophy in Computer Science Indiana University July 2010 Accepted by the Graduate Faculty, Indiana University, in partial fulfillment of the requirements of the degree of Doctor of Philosophy. Doctoral Minaxi Gupta, Ph.D. Committee (Principal Advisor) Steven Myers, Ph.D. Randall Bramley, Ph.D. July 19, 2010 Raquel Hill, Ph.D. ii Copyright c 2010 Andrew J. Kalafut ALL RIGHTS RESERVED iii To my family iv Acknowledgements I would first like to thank my advisor, Minaxi Gupta. Minaxi’s feedback on my research and writing have invariably resulted in improvements. Minaxi has always been supportive, encouraged me to do the best I possibly could, and has provided me many valuable opportunities to gain experience in areas of academic life beyond simply doing research. I would also like to thank the rest of my committee members, Raquel Hill, Steve Myers, and Randall Bramley, for their comments and advice on my research and writing, especially during my dissertation proposal. Much of the work in this dissertation could not have been done without the help of Rob Henderson and the rest of the systems staff. Rob has provided valuable data, and assisted in several other ways which have ensured my experiments have run as smoothly as possible. Several members of the departmental staff have been very helpful in many ways. Specifically, I would like to thank Debbie Canada, Sherry Kay, Ann Oxby, and Lucy Battersby.
    [Show full text]
  • ICANN Registry Request Service
    ICANN Registry Request Service Ticket ID: X8T8C-0S4B2 Registry Name: Public Interest Registry gTLD: .org Status: ICANN Review Status Date: 2013-06-04 22:05:48 Print Date: 2013-06-04 22:06:10 Proposed Service Name of Proposed Service: Technical description of Proposed Service: Technical Description of Proposed Service: Background: BTAPPA will be beneficial in situations where one ICANN-accredited registrar purchases (the "Gaining Registrar"), by means of a stock or asset purchase, merger or similar transaction, a portion, but not all, of another ICANN accredited registrar's domain name portfolio ("Losing Registrar") in the .ORG top-level domains ("TLDs") or where a Gaining Registrar receives a request from a registrant to transfer a significant number of its domain names from a Losing Registrar to such Gaining Registrar. Unless an entire portfolio of domain names is being transferred, Gaining Registrars must request that each domain name be transferred individually. Gaining Registrars must meet the following requirements: oGaining Registrar must be ICANN accredited for the .ORG TLD. oGaining Registrar must be in good standing and be under a Registry-Registrar Agreement with PIR. oGaining Registrar must provide PIR with evidence (i.e., affidavit, sale documents) that sets forth the transfer date or, if an acquisition, the target closing date. oIf domain names are to be transferred from multiple Losing Registrars, then they must be Registrar Affiliates. A Registrar Affiliate is a registrar entity that controls, is controlled by or is under common control with, another the Losing Registrar. oTransfers of domain names to multiple Gaining Registrars will not be permitted, regardless of familiar relationship.
    [Show full text]
  • Afilias Limited Request 28 January 2020
    Registry Services Evaluation Policy (RSEP) Request January 17, 2020 Registry Operator Afilias Limited Request Details Case Number: 00941695 This Registry Services Evaluation Policy (RSEP) request form should be submitted for review by ICANN org when a registry operator is adding, modifying, or removing a Registry Service for a TLD or group of TLDs. The RSEP Process webpage provides additional information about the process and lists RSEP requests that have been reviewed and/or approved by ICANN org. If you are proposing a service that was previously approved, we encourage you to respond similarly to the most recently approved request(s) to facilitate ICANN org’s review. Certain known Registry Services are identified in the Naming Services portal (NSp) case type list under “RSEP Fast Track” (example: “RSEP Fast Track – BTAPPA”). If you would like to submit a request for one of these services, please exit this case and select the specific Fast Track case type. Unless the service is identified under RSEP Fast Track, all other RSEP requests should be submitted through this form. Helpful Tips • Click the “Save” button to save your work. This will allow you to return to the request at a later time and will not submit the request. • You may print or save your request as a PDF by clicking the printer icon in the upper right corner. You must click “Save” at least once in order to print the request. • Click the “Submit” button to submit your completed request to ICANN org. • Complete the information requested below. All fields marked with an asterisk (*) are required.
    [Show full text]
  • Service (SRV) Records
    Service (SRV) Records You deploy multiple DNS SRV records in different locations on your enterprise DNS structure. Understand which records you should provision on which name servers. Review examples of SRV records to ensure a successful deployment. • Deploy SRV Records, page 1 • SRV Records, page 4 Deploy SRV Records The client queries name servers for records in the services domain. The services domain is determined as described in How the Client Discovers Available Services. You must deploy SRV records in each DNS zone for those service domains if your organization has multiple subsets of users who use different service domains. Deploy SRV Records in a Separate Domain Structure In a separate name design there are two domains, an internal domain and an external domain. The client queries for SRV records in the services domain. The internal name server must serve records for the services domain. However in a separate name design, a zone for the services domain might not exist on the internal name server. If the services domain is not currently served by the internal name server, you can: • Deploy records within an internal zone for the services domain. • Deploy records within a pinpoint subdomain zone on the internal name server. Use an Internal Zone for a Services Domain If you do not already have a zone for the services domain on the internal name server, you can create one. This method makes the internal name server authoritative for the services domain. Because it is authoritative, the internal name server does not forward queries to any other name server.
    [Show full text]
  • Taxonomy and Adversarial Strategies of Random Subdomain Attacks
    Taxonomy and Adversarial Strategies of Random Subdomain Attacks Harm Griffioen and Christian Doerr Delft University of Technology, Cybersecurity Group Van Mourik Broekmanweg 6, Delft, The Netherlands fh.j.griffioen, [email protected] Abstract—Ever since the introduction of the domain name new type of attack gained some visibility when source code system (DNS), attacks on the DNS ecosystem have been a steady triggering it was discovered in a forensic analysis of the Mirai companion. Over time, targets and techniques have shifted, Internet-of-Things malware in 2016 [?], since then a number and in the recent past a new type of attack on the DNS has of actors have picked up this particular technique. emerged. In this paper we report on the DNS random subdomain attack, querying floods of non-existent subdomains, intended to Until now, very little is known how these attacks are cause a denial-of-service on DNS servers. Based on five major executed and exactly using which means. This paper intends to attacks in 2018 obtained through backscatter measurements in address this gap. Based on backscatter measurements through a a large network telescope, we show the techniques pursued by large network telescope, we observed the emergence of random adversaries, and develop a taxonomy of strategies of this attack. subdomain attacks over a period of three years and will in this paper make the following two contributions: Keywords—cyber threat intelligence, random subdomain attack, DNS, DDoS • We show the spectrum of different types of random subdomain attacks in use in the wild today based on I. INTRODUCTION five exemplary case studies, and use this to develop a taxonomy of random subdomain attacks.
    [Show full text]
  • ICANN, Ipv6 and the Root
    ICANN, IPv6 and the Root John L. Crain Chief Technical Officer Beijing, China April 12, 2007 1 12 APRIL 2007 In the beginning . 2 12 APRIL 2007 Internet’s unique identifiers were coordinated through the Internet Address Naming Authority JonJon PostelPostel 19431943––19981998 3 12 APRIL 2007 Need for change circa 1996–97 • Globalisation of Internet • Commercialisation of Internet • Lack of competition in domain name space • Trademark–domain name conflicts • Need for a new model of governance 4 12 APRIL 2007 ICANN mission statement • To coordinate, overall, the global Internet's system of unique identifiers, and to ensure stable and secure operation of the Internet's unique identifier systems. In particular, ICANN coordinates: 1. Allocation and assignment of the three sets of unique identifiers for the Internet: • Domain names (forming a system called the DNS) • Internet protocol (IP) addresses and autonomous system (AS) numbers • Protocol port and parameter numbers 2. Operation and evolution of the DNS root name server system 3. Policy development reasonably and appropriately related to these technical functions 5 12 APRIL 2007 Principles of operation 1. Contribute to stability and security of the unique identifiers system and root management 2. Promote competition and choice for registrants and other users 3. Forum for multi-stakeholder bottom-up development of related policy 4. Ensuring on a global basis an opportunity for participation by all interested parties 6 12 APRIL 2007 The Secretariat (People doing the day to day work) 58 Staff from 26 Countries 7 12 APRIL 2007 • The secretariat’s work is administration and aiding policy processes. • We do not set policy, that is the job of the community.
    [Show full text]