DOCSLIB.ORG

How to Configure DNS Zones

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

Barracuda CloudGen Firewall How to Configure DNS Zones https://campus.barracuda.com/doc/12198234/ The Barracuda NG Firewall DNS configuration object contains two predefined zones: _template and '.' To be able to edit and specify DNS zones within the Barracuda NG Firewall DNS configuration, you must create a DNS service. For more information, see How to Activate the DNS Server. In this article: Zone 1: _template This zone contains the general template, which is used as model for all newly created zones. The procedure for creating and modifying template settings is identical to the procedure for creating and editing settings in another zone. Note that only template settings will be inherited that already existed before the zone was created. To access the _template zone, proceed with the following steps: 1. Log into the Barracuda NG Firewall 2. From the Config Tree, expand Box > Virtual Servers > your server > Assigned Services > DNS. 3. Expand the DNS service and open the DNS Template Zone by double clicking it. 4. Double click the entry (_template) to create or modify settings for SOA, primary server, nameserver, etc. 5. Right-click into the main window to create new hosts, mail exchangers, etc. Every setting made here will be clearly arranged in a separate row within the main window and can be selected for further modification or deletion. Zone 2: '.' The initial set of root-servers is defined using a hint zone. When the server starts up it uses the hint zone file to find a root name server and get the most recent list of root name servers. The "." zone is short for this root zone and means any zone for which there is no locally defined zone (slave or master) or cached answer. Do NOT modify the root server settings unless you exactly know what you are doing. How to Configure DNS Zones 1 / 13 Barracuda CloudGen Firewall Add a New Zone To introduce a new zone, right-click your DNS server and select Lock Server. Optionally, you may lock the DNS server already in the config tree. The configuration can now be modified. Select Add New Zone from the context menu and configure the following options: Parameter Overview Parameter Description ⚬ Master - Every domain configuration change takes place on the master. From here the information is propagated to the secondary servers. A master zone requires at least a Start of Authority (SOA) record and a Name Server (NS) record. Be sure to examine the security settings of the master zone, since a corrupt master zone can cause a lot of problems. ⚬ Slave - A slave zone is a replica of a master zone. The masters list specifies one or more IP addresses that the slave contacts to update its copy of the zone. DNS slave zones do not require much configuration; just enter the IP addresses of the master server (or servers) and examine the security settings. Be sure to set a transfer-source-IP, otherwise the slave zone will not be accepted by the DNS server. Type ⚬ Forward - A forward zone is used to direct all queries in it to other servers. The specification of options in such a zone will override any global options declared in the options statement. A forward zone does not need a transfer-source-IP. Be sure to check the security settings. ⚬ Hint - The initial set of root name servers is specified using a hint zone. When the server starts up, it uses the root hints to find a root name server and get the most recent list of root name servers. The Barracuda NG Firewall DNS server already has a hint zone (Zone ".") pre-configured, so normally there is no need to introduce another hint zone. Depending on the selected types the necessary settings may be slightly different. Such settings are marked with (optional) in the following. Origin Enter the domain name you wish to create here (for example, Domain Name barracuda.com). This section is used for defining whether the zone should perform Forward or Reverse lookup. DNS forward lookup provides IP addresses for known host Lookup names, while reverse lookup provides host names for known IP addresses. The Barracuda NG Firewall DNS server is able to provide DNS reverse lookup only for 8-bit networks (like 213.47.10.0/24). (optional) This field is available when type Slave is selected. Enter the master Masters IP addresses here. (optional) This field is available when type Forward is selected. Enter the Forwards forward IP addresses here. By clicking the advanced button a new window appears containing additional settings: Parameter Description How to Configure DNS Zones 2 / 13 Barracuda CloudGen Firewall Allows the administrator to select whether the DNS server should notify slave DNS servers about zone changes. Possible values for selection are notify yes/no/explicit. If explicit is selected enter the explicit IP in the also notify field below. Here you may enter a list of IPv4 or IPv6 hosts that should be notified about zone changes although these machines are not registered slaves also notify of the DNS server. Separate multiple entries with a semicolon and space (like 10.0.0.53; 10.0.0.67; 192.168.0.10; 2001:db8:85a3:0:0:8a2e:370:7334). This field is only available for type Slave. It defines the IP address the slave has to use when contacting its master DNS server. The following options are available: ⚬ service-default transfer-source-ip ⚬ server-first ⚬ server-second ⚬ explicit Slave zones must have transfer-source-ip to work. Advanced Settings – Section Security This section offers detailed security options for the DNS service. Each pull-down field can take one the value none or any. allow notify - This field is only available for type Slave. It defines if the slave accepts notifications about updates from its master. allow query - Lists the IPv4 or IPv6 hosts that are allowed to query the DNS server. By default all hosts are allowed to query the DNS server. allow update - Lists the IPv4 or IPv6 hosts that are allowed to update the database of the DNS server. allow transfer - Lists the IPv4 or IPv6 hosts that are allowed to fetch the DNS database from the DNS server. Edit/Add a New Start of Authority At creation time of the Barracuda NG Firewall DNS Server a standard template is created which is automatically inherited by newly generated zones. This template may freely be deleted or modified. In case you have deleted it, and have thereafter created a new zone, proceed as follows to comprehend the following instructions: 1. Select the newly created domain lacking a SOA record in the tree view, right-click the main window and choose Add a New Start of Authority (SOA). 2. If the SOA record already exists, double-click an existing entry with type NS or SOA and select the Start of Authority (SOA) tab. How to Configure DNS Zones 3 / 13 Barracuda CloudGen Firewall DNS Server - SOA Configuration Enter a serial number here. - Clicking Update will increase the serial number by one. The serial number of the master has to be higher than the serial number Serial saved on the slave, otherwise the slave will stop fetching information updates from its master. Select the primary name server of the domain here. - By clicking Pickup already Primary Sever created entries can be selected. Use this field to define a person responsible for this host/zone. The syntax that Responsible has to be used is username.domain (for example ernestexample.test.org). - By person clicking Pickup, already created entries can be selected. This interval tells the slave how often it has to check whether its data is up to Refresh after date. When the slave fails to reach the master server after the refresh period (Refresh Retry after after), then it starts trying again after this set time interval. When the slave fails to contact the master server for the expire period, the slave Expire after expires its data. Expiring means that the slave stops giving out answers about the data because the data is too old to be useful. How to Configure DNS Zones 4 / 13 Barracuda CloudGen Firewall (standard) This value sets the Time To Live of cached database entries of this Minimum TTL zone. - The format for TTL is days:hours:minutes:seconds. This value sets the Time To Live of cached database entries of this zone until it is Expire (TTL) considered as expired. - The format for TTL is days:hours:minutes:seconds. Edit/Add a New Name Server 1. To introduce a new Name Server (NS), right-click the right part of the window and select New Name Server (NS). 2. If a nameserver has already been created, open an existing entry with type SOA or NS and click the Nameserver (NS) tab. A new nameserver can only be entered if the SOA has already been generated. How to Configure DNS Zones 5 / 13 Barracuda CloudGen Firewall Name Server Configuration This is a read-only field. It displays the name of the domain the Superordinate domain nameserver will be responsible for. To add name servers, click Add. • Servername - This is the name of the name server. Add/Modify/Delete • IP Address - This is the IPv4 or IPv6 address of the name server. • Expire (TTL) - This is the globally defined length of life, future name server records are expected to have. The format for the Time to Live (TTL) is days:hours:minutes:seconds. Add a New Host To introduce a new host, right-click the main window and select New Host. Entries made in the individual tabs will be saved in separate rows of type A, TXT, HINFO and WKS within the main configuration window.
Recommended publications
  • XEP-0347: Internet of Things - Discovery

    XEP-0347: Internet of Things - Discovery

    XEP-0347: Internet of Things - Discovery Peter Waher mailto:peterwaher@hotmail:com xmpp:peter:waher@jabber:org http://www:linkedin:com/in/peterwaher Ronny Klauck mailto:rklauck@informatik:tu-cottbus:de xmpp:TBD http://www-rnks:informatik:tu-cottbus:de/~rklauck 2018-11-03 Version 0.5.1 Status Type Short Name Deferred Standards Track iot-discovery This specification describes an architecture based on the XMPP protocol whereby Things can be in- stalled and safely discovered by their owners and connected into networks of Things. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
  • A Survey of DNSSEC Deployment in the US R&E Community

    A Survey of DNSSEC Deployment in the US R&E Community

    A survey of DNSSEC deployment in the U.S. R&E community Shumon Huque; University of Pennsylvania Bill Owens; NySERNET Joint Techs Conference, Stanford University, July 16th 2012 http://events.internet2.edu/2012/jt-stanford/ 1 Abstract: DNSSEC (DNS Security Extensions) is a system to verify the authenticity of DNS data using public key signatures. Although a small number of institutions in the R&E community have been at the forefront of DNSSEC deployment, the adoption rate in the larger community is still quite low. This talk will present some results of an ongoing project to survey the status of DNSSEC deployment in the US Research & Education and a few other communities. It also surveys the status of several other DNS capabilities, such as availability of the service over IPv6 transport, TCP transport, EDNS0 support, etc. [Joint Techs, Stanford University, Jul 2012] 2 Agenda • DNSSEC deployment monitoring project overview • Live demo of the website • New uses of DNSSEC by applications (DANE/TLSA etc) • (time permitting) [Joint Techs, Stanford University, Jul 2012] 3 DNSSEC at a glance • “DNS Security Extensions” • A system to verify the authenticity of DNS “data” using public key signatures • Specs: RFC 4033, 4034, 4035, 5155 (and more) • Helps detect DNS spoofing, misdirection, cache poisoning .. • Additional benefits: • Ability to store and use cryptographic keying material in the DNS, eg. SSHFP, IPSECKEY, CERT, DKIM, TLSA, etc .. [Joint Techs, Stanford University, Jul 2012] 4 Other surveys • SecSpider • http://secspider.cs.ucla.edu/
  • XEP-0156: Discovering Alternative XMPP Connection Methods

    XEP-0156: Discovering Alternative XMPP Connection Methods

    XEP-0156: Discovering Alternative XMPP Connection Methods Joe Hildebrand Peter Saint-Andre Lance Stout mailto:jhildebr@cisco:com mailto:xsf@stpeter:im mailto:lance@andyet:com xmpp:hildjj@jabber:org xmpp:peter@jabber:org xmpp:lance@lance:im http://stpeter:im/ 2020-07-07 Version 1.3.1 Status Type Short Name Draft Standards Track alt-connections This document defines an XMPP Extension Protocol for discovering alternative methods of connecting to an XMPP server using two ways: (1) DNS TXT Resource Record format; and (2) Web Host Metadata Link format. Legal Copyright This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF). Permissions Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the ”Specification”), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specifi- cation, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or sub- stantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or pub- lisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation. Warranty ## NOTE WELL: This Specification is provided on an ”AS IS” BASIS, WITHOUT WARRANTIES OR CONDI- TIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE.
  • ICANN, Ipv6 and the Root

    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.
  • Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology

    Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology

    Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Identifier System Attack Mitigation Methodology Introduction This document is part of ICANN’s effort to contribute to enhancing the Stability, Security, and Resiliency (SSR) of the Internet’s system of unique identifiers (“Internet Identifiers”) by working with the Community to identify and increase awareness of related attacks and to promote broader adoption of attack mitigation practices. This effort also addresses Recommendation #12 of the Security, Stability & Resiliency (SSR) Review Team (SSR-RT) by creating an Identifier System Attack Mitigation Methodology. Specifically, this document identifies and prioritizes types of attacks against the Identifier System, providing a stepping-off point for ICANN to coordinate with the Community to develop a series of short technical documents (“Tech Notes”) on actual high-impact attacks and emerging high-risk vulnerabilities. This document will be periodically updated to reflect evolution of both the Identifier System and the cybercrime landscape, supporting on-going efforts within both ICANN and the Community to mitigate attacks that pose the greatest risk to Identifier System SSR. Authors: Lisa Phifer and David Piscitello Page 1 Identifier System Attack Mitigation Methodology DATE: 13 February 2017 Attack Mitigation Methodology ICANN is proposing a new Identifier System Attack Mitigation Methodology to: • Identify, prioritize, and periodically refresh a list of top Identifier System attacks; • Develop guidance on actual high-impact attacks and emerging high-risk vulnerabilities; • Describe corresponding attack mitigation practices that are commonly considered useful; and • Encourage broader adoption of those practices via contracts, agreements, incentives, etc. This document represents the first component of this methodology.
  • 1912 the Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational

    1912 the Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational

    Network Working Group D. Barr Request for Comments: 1912 The Pennsylvania State University Obsoletes: 1537 February 1996 Category: Informational Common DNS Operational and Configuration Errors Status of this Memo This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Abstract This memo describes errors often found in both the operation of Domain Name System (DNS) servers, and in the data that these DNS servers contain. This memo tries to summarize current Internet requirements as well as common practice in the operation and configuration of the DNS. This memo also tries to summarize or expand upon issues raised in [RFC 1537]. 1. Introduction Running a nameserver is not a trivial task. There are many things that can go wrong, and many decisions have to be made about what data to put in the DNS and how to set up servers. This memo attempts to address many of the common mistakes and pitfalls that are made in DNS data as well as in the operation of nameservers. Discussions are also made regarding some other relevant issues such as server or resolver bugs, and a few political issues with respect to the operation of DNS on the Internet. 2. DNS Data This section discusses problems people typically have with the DNS data in their nameserver, as found in the zone data files that the nameserver loads into memory. 2.1 Inconsistent, Missing, or Bad Data Every Internet-reachable host should have a name. The consequences of this are becoming more and more obvious.
  • CS4700/CS5700 Fundamentals of Computer Networks

    CS4700/CS5700 Fundamentals of Computer Networks

    CS4700/CS5700 Fundamentals of Computer Networks Lecture 17: Domain Name System Slides used with permissions from Edward W. Knightly, T. S. Eugene Ng, Ion Stoica, Hui Zhang Alan Mislove amislove at ccs.neu.edu Northeastern1 University Human Involvement • Just like your friend needs to tell you his phone number for you to call him • Somehow, an application needs to know the IP address of the communication peer • There is no magic, some out-of-band mechanism is needed – Word of mouth – Read it in the advertisement in the paper – Etc. • But IP addresses are bad for humans to remember and tell each other • So need names that makes some sense to humans Alan Mislove amislove at ccs.neu.edu Northeastern2 University Internet Names & Addresses • Names: e.g. www.rice.edu – human-usable labels for machines – conforms to “organizational” structure • Addresses: e.g. 128.42.247.150 – router-usable labels for machines – conforms to “network” structure • How do you map from one to another? – Domain Name System (DNS) Alan Mislove amislove at ccs.neu.edu Northeastern3 University DNS: History • Initially all host-addess mappings were in a file called hosts.txt (in /etc/hosts) – Changes were submitted to SRI by email – New versions of hosts.txt ftp’d periodically from SRI – An administrator could pick names at their discretion – Any name is allowed: eugenesdesktopatrice • As the Internet grew this system broke down because: – SRI couldn’t handled the load – Hard to enforce uniqueness of names – Many hosts had inaccurate copies of hosts.txt • Domain Name System (DNS) was born Alan Mislove amislove at ccs.neu.edu Northeastern4 University Basic DNS Features • Hierarchical namespace – as opposed to original flat namespace • Distributed storage architecture – as opposed to centralized storage (plus replication) • Client--server interaction on UDP Port 53 – but can use TCP if desired Alan Mislove amislove at ccs.neu.edu Northeastern5 University Naming Hierarchy root edu com gov mil org net uk fr etc.
  • DNS) Deployment Guide

    DNS) Deployment Guide

    Archived NIST Technical Series Publication The attached publication has been archived (withdrawn), and is provided solely for historical purposes. It may have been superseded by another publication (indicated below). Archived Publication Series/Number: NIST Special Publication 800-81 Revision 1 Title: Secure Domain Name System (DNS) Deployment Guide Publication Date(s): April 2010 Withdrawal Date: September 2013 Withdrawal Note: SP 800-81 Revision 1 is superseded in its entirety by the publication of SP 800-81-2 (September 2013). Superseding Publication(s) The attached publication has been superseded by the following publication(s): Series/Number: NIST Special Publication 800-81-2 Title: Secure Domain Name System (DNS) Deployment Guide Author(s): Ramaswamy Chandramouli, Scott Rose Publication Date(s): September 2013 URL/DOI: http://dx.doi.org/10.6028/NIST.SP.800-81-2 Additional Information (if applicable) Contact: Computer Security Division (Information Technology Lab) Latest revision of the SP 800-81-2 (as of August 7, 2015) attached publication: Related information: http://csrc.nist.gov/ Withdrawal N/A announcement (link): Date updated: ƵŐƵƐƚϳ, 2015 Special Publication 800-81r1 Sponsored by the Department of Homeland Security Secure Domain Name System (DNS) Deployment Guide Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose i NIST Special Publication 800-81r1 Secure Domain Name System (DNS) Deployment Guide Sponsored by the Department of Homeland Security Recommendations of the National Institute of Standards and Technology Ramaswamy Chandramouli Scott Rose C O M P U T E R S E C U R I T Y Computer Security Division/Advanced Network Technologies Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899 April 2010 U.S.
  • DNS: Domain Name System a Scalable Naming System for the Internet

    DNS: Domain Name System a Scalable Naming System for the Internet

    Introduction Queries and Caching Protocol History and Growth DNS: Domain Name System A Scalable Naming System for the Internet Daniel Zappala Brigham Young University Computer Science Department 1/26 Introduction Introduction Queries and Caching Protocol History and Growth Domain Name System • people like to use names for computers (www.byu.edu), but computers need to use numbers (128.187.22.132) • the Domain Name System (DNS) is a distributed database providing this service • a program send a query a local name server • the local name server contacts other servers as needed • many DNS services • host name to IP address translation • host aliasing (canonical name versus alias names) • lookup mail server for a host • load distribution - can provide a set of IP addresses for one canonical name Demonstration: dig 3/26 Introduction Queries and Caching Protocol History and Growth Names • domain name: top-level domain (TLD) + one or more subdomains • example: cs.byu.edu • host name: a domain name with one or more IP addresses associated with it • TLDs • ccTLD: country codes (.us, .uk, .tv) • gTLD: generic (.com, .edu, .org, .net, .gov, .mil) { see full list at Wikipedia • iTLD: infrastructure (.arpa) • may be 127 levels deep, 63 characters per label, 255 characters per name 4/26 Introduction Queries and Caching Protocol History and Growth DNS Hierarchy • root, top-level domain (TLD), and local name servers • each level represents a zone • what zone is BYU in charge of? 5/26 Introduction Queries and Caching Protocol History and Growth Root Name
  • Analyzing and Mitigating Privacy with the DNS Root Service

    Analyzing and Mitigating Privacy with the DNS Root Service

    Analyzing and Mitigating Privacy with the DNS Root Service Wes Hardaker USC/Information Sciences Institute [email protected] Keywords privacy, dns, root, analysis, leakage ABSTRACT Processing of all DNS requests start at the root of the DNS tree and make use of either cached data from previous re- quests, or by traversing the DNS tree for the missing in- formation. When QNAME minimization is not in use, queries forwarded to the parental nodes in the DNS tree may leak private DNS query data. In this paper we examine 31 days during the month of January 2017 of queries sent from two recursive resolvers placed in two residential networks to the DNS root server operated by USC/ISI’s, analyzing Figure 1: Domain Name System Resolution Process the leaked QNAMEs for an impact on the network’s privacy. We then compare a few DNS privacy preserving techniques against the privacy analysis against these networks. Finally, client query. The architecture of this query process is we introduce a new solution called\LocalRoot" that enables depicted in Figure 1. The leakage of DNS requests to users to entirely mitigate privacy concerns when interacting the Root Server System is the focus point of this paper. with the DNS root server system, while other solutions fail Most DNS recursive resolvers today send the entire to completely protect users from all privacy analysis meth- requested DNS name (e.g. www.example.com) unen- ods. crypted to all the servers it needs to correspond with, as it is unknown to them where in the name the dif- 1.
  • Dns Applications and Resource Records

    Dns Applications and Resource Records

    10 DNS APPLICATIONS AND RESOURCE RECORDS 10.1 INTRODUCTION DNS inherently lends itself well to “translating” a given piece of information into another related piece of information. This resolution process is the very reason for DNS’s invention, and it has been extended beyond resolving hostnames into IP addresses and vice versa to support a broad variety of applications. Virtually any service or application that requires translation of one form of information into another can leverage DNS. Each resource record configured in DNS enables this lookup function, returning a resolution answer for a given query. The DNS server parses the query from the Question section of the DNS message,* seeking a match within the corresponding domain’s zone file for the query’s QNAME, QCLASS, and QTYPE. Each resource record has a Name (aka Owner) field, Class (Internet class is assumed if not specified), and Type field. The RData field contains the corresponding answer to the query. The resource record type defines the type and format of the question (owner/name field) and corresponding answer (RData field). In some instances, multiple resource records may match the queried name, type, and class. In such cases, all matching records, called a Resource Record Set (RRSet), are returned in the Answer section of the response message. * Refer to Figure 9.12. IP Address Management: Principles and Practice, by Timothy Rooney Copyright Ó 2011 the Institute of Electrical and Electronics Engineers, Inc. 10.1 INTRODUCTION 177 Most, but not all, new applications require new resource record types to enable definition of application-specific information, and these new resource record types are standardized via the IETF RFC process.
  • Wow, That's a Lot of Packets

    Wow, That's a Lot of Packets

    Wow, That’s a Lot of Packets Duane Wessels, Marina Fomenkov Abstract—Organizations operating Root DNS servers re- an authoritative answer. If the application does not know port loads exceeding 100 million queries per day. Given the where to send a query it asks the servers in the parent design goals of the DNS, and what we know about today’s In- zone. In the example above, not knowing anything about ternet, this number is about two orders of magnitude more ucsd.edu, the application should send a query to the au- than we would expect. thoritative server for the edu zone. If the application does With the assistance of one root server operator, we took a edu 24-hour trace of queries arriving at one of the thirteen root not know about the zone, it queries the “root zone.” servers. In this paper we analyze these data and use a simple This process is called recursive iteration. model of the DNS to classify each query into one of nine cat- The DNS root zone is served by 13 name servers (not to egories. We find that, by far, most of the queries are repeats be confused with the 13 generic top-level domain servers) and that only a small percentage are legitimate. distributed across the globe. Thirteen is the maximum We also characterize a few of the “root server abusers,” number of root servers possible in the current DNS archi- that is, clients sending a particularly large number of tecture because that is the most that can fit inside a 512- queries to the root server.