Recommended
More Related Content
Similar to 3_dns_overview.pptx
Similar to 3_dns_overview.pptx (20)
Recently uploaded
Recently uploaded (20)
3_dns_overview.pptx
- 2. Scenario • How can the client computer contact www.gmail.com? • In the internet, IP addresses will work, not names • How to know the IP addresses of gmail.com?
- 3. Scenario • DNS can resolve internet names into IP address • First, the client will contact DNS asking for the IP address of www.gmail.com • DNS then replies with the requested IP address • Finally, DNS cache in the client will be updated
- 4. Domain Name System (DNS) • DNS = Domain Name System • Hierarchical and decentralized service • Names are human friendly • IP Addresses are router friendly • Names or IP addresses – Unique • FQDN – Fully Qualified Domain Name • myhost.example.com. • myhost.ugm.ac.id. • Translate hostnames into host addresses • Name servers – Client Server Model
- 5. Domain Hierarchy Partitioned Into Zones
- 6. Hierarchy of Name Servers
- 7. DNS name resolution: iterated query Example: host at engineering.nyu.edu wants IP address for gaia.cs.umass.edu Iterated query: contacted server replies with name of server to contact “I don’t know this name, but ask this server” requesting host at engineering.nyu.edu gaia.cs.umass.edu root DNS server local DNS server dns.nyu.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server Application Layer: 2-7
- 8. DNS name resolution: recursive query requesting host at engineering.nyu.edu gaia.cs.umass.edu root DNS server local DNS server dns.nyu.edu 1 2 3 4 5 6 authoritative DNS server dns.cs.umass.edu 7 8 TLD DNS server Recursive query: puts burden of name resolution on contacted name server heavy load at upper levels of hierarchy? Example: host at engineering.nyu.edu wants IP address for gaia.cs.umass.edu Application Layer: 2-8
- 9. DNS records DNS: distributed database storing resource records (RR) type=NS name is domain (e.g., foo.com) value is hostname of authoritative name server for this domain RR format: (name, value, type, ttl) type=A name is hostname value is IP address type=CNAME name is alias name for some “canonical” (the real) name www.ibm.com is really servereast.backup2.ibm.com value is canonical name type=MX value is name of SMTP mail server associated with name Application Layer: 2-9
- 10. identification flags # questions questions (variable # of questions) # additional RRs # authority RRs # answer RRs answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) 2 bytes 2 bytes DNS protocol messages DNS query and reply messages, both have same format: message header: identification: 16 bit # for query, reply to query uses same # flags: • query or reply • recursion desired • recursion available • reply is authoritative Application Layer: 2-10
- 11. identification flags # questions questions (variable # of questions) # additional RRs # authority RRs # answer RRs answers (variable # of RRs) authority (variable # of RRs) additional info (variable # of RRs) 2 bytes 2 bytes DNS query and reply messages, both have same format: name, type fields for a query RRs in response to query records for authoritative servers additional “ helpful” info that may be used DNS protocol messages Application Layer: 2-11
Editor's Notes
- Today, Mr. Alfian can't come because he has to go out of town, so I will accompany you in today's practicum. Previously, you could access the material at Elok. Mr Alfian has uploaded it there
- Today, Mr. Alfian can't come because he has to go out of town, so I will accompany you in today's practicum. Previously, you could access the material at Elok. Mr Alfian has uploaded it there
- Normally, To allow a client computer to contact www.gmail.com using IP addresses, you can follow these steps: DNS Resolution: The client computer needs to resolve the domain name www.gmail.com into an IP address. This is typically done through the Domain Name System (DNS). Here's how it works: The client computer sends a DNS query to a DNS server. This server can be configured manually or provided by the Internet Service Provider (ISP). The DNS server will check its local cache to see if it already knows the IP address for www.gmail.com. If it does, it will respond immediately. If the DNS server doesn't have the IP address in its cache, it will recursively query other DNS servers in the hierarchy until it finds the authoritative DNS server for gmail.com. The authoritative DNS server is responsible for storing and providing the IP address for gmail.com. Once the authoritative DNS server is found, it will respond to the query with the IP address associated with www.gmail.com. Use the Obtained IP Address: After obtaining the IP address of www.gmail.com, the client computer can use this address to establish a connection. This typically involves the following steps: The client computer will initiate a TCP (Transmission Control Protocol) connection to the IP address of www.gmail.com on port 80 for HTTP or port 443 for HTTPS (encrypted) communication. It will send an HTTP or HTTPS request to the IP address, asking for the web page associated with www.gmail.com. The server at that IP address (which is Gmail's server in this case) will receive the request and respond with the Gmail login page or any other requested content. The client computer will then display the Gmail login page to the user. It's important to note that IP addresses for popular websites like Gmail may change periodically for load balancing, redundancy, or other reasons. Therefore, DNS resolution is dynamic and subject to updates. To manually find the IP address of a domain like gmail.com, you can use the following methods: Command Line (Windows or macOS): Open a terminal or command prompt and use the nslookup command: Copy code nslookup gmail.com This will display the IP address associated with gmail.com. Online Tools: There are various online DNS lookup tools and websites where you can enter a domain name (e.g., gmail.com) to obtain its IP address. Examples include https://www.whatsmydns.net or https://dnschecker.org/. Keep in mind that for accessing websites, using domain names is more convenient as they abstract the underlying IP addresses, which can change. DNS resolution handles this translation between domain names and IP addresses automatically.
- Certainly, let's break down the various aspects of the Domain Name System (DNS) as described in your query: DNS - Domain Name System: DNS stands for Domain Name System. It is a critical part of the internet infrastructure responsible for translating human-friendly domain names (like www.example.com) into router-friendly IP addresses (like 192.168.1.1). This translation is essential for computers to locate and communicate with each other on the internet. Hierarchical and Decentralized Service: DNS operates as a hierarchical and decentralized system. It is hierarchical because it organizes domain names in a tree-like structure, with the root at the top and subdomains below. It is decentralized because various DNS servers around the world collectively manage and distribute DNS information, reducing the burden on any single entity. Names are Human-Friendly: Domain names are designed to be human-friendly and easy to remember. They provide a convenient way for people to access websites and online services without needing to remember numerical IP addresses. IP Addresses are Router-Friendly: IP addresses, on the other hand, are numeric and router-friendly. They are used by routers and computers to route data packets across networks efficiently. DNS bridges the gap between human-readable domain names and IP addresses. Names or IP Addresses - Unique: Each domain name and IP address should be unique on the internet. This uniqueness is maintained to avoid conflicts and ensure that when you type a domain name, you reach the intended destination. FQDN - Fully Qualified Domain Name: A Fully Qualified Domain Name (FQDN) is a domain name that includes the complete hierarchy of domain labels from the root domain to the specific subdomain or host. For example, "myhost.example.com." is an FQDN because it specifies the host "myhost" within the subdomain "example" under the top-level domain "com." Translate Hostnames into Host Addresses: One of the primary functions of DNS is to translate hostnames (like "www.example.com") into host addresses (IP addresses). This translation is crucial for establishing connections over the internet. Name Servers - Client-Server Model: DNS operates on a client-server model. DNS clients, often provided by internet service providers (ISPs) or configured on your computer or network, send DNS queries to DNS servers. These servers, known as DNS resolvers, find and return the IP address associated with a given domain name. DNS servers are organized hierarchically as well, with root name servers at the top, followed by TLD name servers, authoritative name servers for specific domains, and caching/recursive DNS servers that assist in resolving queries efficiently. In summary, DNS is a hierarchical and decentralized system that translates human-friendly domain names into router-friendly IP addresses. It plays a crucial role in enabling internet communication by bridging the gap between names that are easy for humans to remember and the numerical addresses that computers use to locate each other on the internet. DNS operates on a client-server model and ensures the uniqueness of names and IP addresses.
- A Domain Hierarchy Partitioned into Zones is a fundamental concept in the Domain Name System (DNS), a system used to translate human-readable domain names (like www.example.com) into IP addresses (like 192.168.1.1). This partitioning into zones is a key aspect of how DNS is organized for efficient and distributed domain name resolution. Here's an explanation of this concept: Domain Hierarchy: DNS operates as a hierarchical and decentralized system. The hierarchy starts with the root domain at the top (represented by a dot, "."), followed by top-level domains (TLDs) like ".com," ".org," ".net," country code TLDs like ".uk," and then subdomains and sub-subdomains beneath them. Zones: In DNS, a "zone" is a portion of the DNS namespace or hierarchy. It's a domain and all of its subdomains. Each zone represents a distinct administrative boundary, meaning it is managed and controlled by a particular organization or entity responsible for maintaining the DNS records within that zone. Partitioning into Zones: The DNS hierarchy is partitioned into zones primarily for administrative and scalability reasons. Each zone can have its own set of DNS records, including authoritative name servers, mail servers, and other DNS information specific to that zone. For example, if a company owns the domain "example.com," they may create a zone for "example.com" and manage all DNS records for that domain within that zone. This allows them to control the DNS records for their domain independently of other domains. Authority and Delegation: Zones are associated with authoritative name servers that are responsible for maintaining and providing DNS information for that zone. These authoritative name servers are designated in the DNS configuration for the domain. When a DNS query is made for a domain within a particular zone, the DNS resolver knows which authoritative name servers to contact for that zone. If the resolver receives a query for a subdomain within the zone, it knows to contact the authoritative name servers for that specific subdomain. Delegation of Subdomains: Within a zone, the organization responsible for that zone can further delegate subdomains to other authoritative name servers. For example, if "example.com" wants to delegate control of "subdomain.example.com" to a different organization, they can set up authoritative name servers for "subdomain.example.com" and delegate this subdomain. Caching and Efficiency: The partitioning of DNS into zones helps improve the efficiency of DNS resolution. DNS resolvers can cache the results of queries, reducing the need to repeatedly query authoritative name servers for the same domain. In summary, a domain hierarchy partitioned into zones is a way of organizing and managing DNS information in a hierarchical and distributed manner. It allows for efficient administration, delegation of subdomains, and scaling of the DNS system while maintaining the integrity and control of individual domains by their respective administrators. This architecture is crucial for the functioning and scalability of the global DNS infrastructure.
- The hierarchy of name servers is a fundamental concept in the Domain Name System (DNS), The hierarchy of name servers helps organize and efficiently manage the DNS infrastructure. Here's an explanation of this concept: Root Name Servers: At the top of the hierarchy are the Root Name Servers. There are 13 sets of root name servers distributed worldwide, each represented by a single-letter label (A through M). These servers hold information about the top-level domains (TLDs) such as ".com," ".org," ".net," and country code TLDs like ".uk." They don't store information about individual domain names but provide referrals to TLD name servers. Top-Level Domain (TLD) Name Servers: Below the root, there are TLD Name Servers. These servers are responsible for specific top-level domains. For example, there are TLD name servers for ".com," ".org," ".net," and so on. TLD name servers store information about second-level domains (like "example.com") and provide referrals to authoritative name servers responsible for those domains. Authoritative Name Servers: Authoritative Name Servers are responsible for individual domains or subdomains. These servers hold the DNS records (A records, MX records, CNAME records, etc.) for specific domain names. They are maintained by the owners or administrators of those domains. There can be multiple authoritative name servers for a single domain to ensure redundancy and availability. Caching/Recursive Name Servers: Caching or Recursive Name Servers are the ones most commonly used by end-users and client computers. When a user requests a domain name resolution, these servers take on the task of finding the IP address associated with the domain. They recursively query the DNS hierarchy starting from the root or a higher-level DNS server, moving down to the authoritative name servers for the requested domain. They also cache the results of their queries to speed up future requests and reduce DNS query traffic. The hierarchy of name servers works in a hierarchical, decentralized, and distributed manner to ensure efficient and fault-tolerant DNS resolution: When a user's device needs to resolve a domain name (e.g., www.example.com), it sends a query to its local recursive name server. The local recursive name server checks its cache for the IP address. If it doesn't have the information or the cache has expired, it starts the DNS resolution process. The local recursive name server queries the root name servers to find the TLD name server responsible for ".com." It then queries the TLD name server for "example.com" to find the authoritative name servers for that domain. Finally, it queries the authoritative name servers for "www.example.com" to obtain the IP address. The hierarchical structure of DNS allows for efficient and distributed DNS resolution, load distribution, and redundancy. It also helps in delegating control over specific domains to their respective administrators while maintaining a globally coherent system for translating domain names into IP addresses.
- DNS name resolution using an iterated query is a method by which a DNS resolver systematically queries multiple DNS servers to find the IP address associated with a given domain name. This process involves a step-by-step approach, starting with root name servers and proceeding down the DNS hierarchy. Here's a detailed explanation of how DNS name resolution through an iterated query works: In an iterative query, the DNS resolver (typically your computer or a DNS server) contacts multiple DNS servers to resolve a domain name. Here's a step-by-step explanation of how an iterated query might work in eight steps: User Input: A user enters a URL or clicks a link, like "www.example.com," into their web browser. Local DNS Cache: The user's device checks its local DNS cache first to see if it already knows the IP address associated with "www.example.com." If the information is found in the cache and it's not expired, the process ends here, and the browser connects to the IP address directly. Root DNS Server: If the IP address is not in the local cache or has expired, the user's device contacts a configured DNS resolver (usually provided by the ISP or a public DNS server like Google's 8.8.8.8). The resolver begins the resolution process by sending a request to a root DNS server. The root DNS server doesn't have information about specific domain names but can direct queries to the appropriate top-level domain (TLD) DNS servers. TLD DNS Server: The root DNS server responds with a referral to the TLD DNS server responsible for the top-level domain of the requested domain name. For example, if the request is for "www.example.com," the root DNS server would refer the resolver to the ".com" TLD DNS server. Authoritative DNS Server: The TLD DNS server responds with a referral to the authoritative DNS server for the second-level domain, in this case, "example.com." This authoritative DNS server is responsible for knowing the specific IP address associated with "www.example.com." Authoritative DNS Server Query: The DNS resolver sends a query to the authoritative DNS server for "example.com," asking for the IP address of "www.example.com." Authoritative DNS Server Response: The authoritative DNS server for "example.com" responds with the IP address associated with "www.example.com." DNS Resolver Response: The DNS resolver now has the IP address it was looking for, and it stores this information in its local cache. It then sends this IP address back to the user's device. User Device Action: With the IP address in hand, the user's device can now establish a connection to the web server associated with "www.example.com." It uses this IP address to make a request for the web page, and the web server responds by sending the requested page data back to the user's device. This iterative process continues until the DNS resolver obtains the IP address for the requested domain name. Each step in the process involves querying a different DNS server, starting from the root and working down to the authoritative server for the specific domain, which ultimately provides the IP address needed for communication. In summary, an iterated DNS query involves a series of queries to different levels of DNS servers, starting from the root and progressing down the hierarchy until the IP address associated with the desired domain name is found. This method allows the DNS resolver to systematically locate the authoritative name server for the domain and retrieve the necessary DNS information for resolution.
- DNS name resolution using a recursive query is one of the primary methods by which DNS resolvers find the IP address associated with a given domain name. Unlike an iterated query, which involves querying multiple DNS servers in a step-by-step manner, a recursive query simplifies the process for the client by handling the entire resolution process on behalf of the client. Here's how DNS name resolution through a recursive query works: Here's a step-by-step explanation of how a recursive query might work in eight steps: User Input: A user enters a URL or clicks a link, like "www.example.com," into their web browser. Local DNS Cache: The user's device checks its local DNS cache first to see if it already knows the IP address associated with "www.example.com." If the information is found in the cache and it's not expired, the process ends here, and the browser connects to the IP address directly. Recursive DNS Resolver: If the IP address is not in the local cache or has expired, the user's device contacts a configured DNS resolver (usually provided by the ISP or a public DNS server like Google's 8.8.8.8). The resolver begins the resolution process. Root DNS Server: The DNS resolver sends a query to a root DNS server. The root DNS server doesn't have information about specific domain names but can direct queries to the appropriate top-level domain (TLD) DNS servers. TLD DNS Server: The root DNS server responds with a referral to the TLD DNS server responsible for the top-level domain of the requested domain name. For example, if the request is for "www.example.com," the root DNS server would refer the resolver to the ".com" TLD DNS server. Authoritative DNS Server: The TLD DNS server responds with a referral to the authoritative DNS server for the second-level domain, in this case, "example.com." This authoritative DNS server is responsible for knowing the specific IP address associated with "www.example.com." Authoritative DNS Server Query: The DNS resolver sends a query to the authoritative DNS server for "example.com," asking for the IP address of "www.example.com." Authoritative DNS Server Response: The authoritative DNS server for "example.com" responds with the IP address associated with "www.example.com." DNS Resolver Response: The DNS resolver now has the IP address it was looking for, and it returns this IP address to the user's device. User Device Action: With the IP address in hand, the user's device can now establish a connection to the web server associated with "www.example.com." It uses this IP address to make a request for the web page, and the web server responds by sending the requested page data back to the user's device. In this recursive process, the DNS resolver takes on the responsibility of contacting various DNS servers, starting from the root and working down to the authoritative server for the specific domain, and ultimately provides the IP address needed for communication. The user's device interacts only with the DNS resolver, simplifying the resolution process for the end-user. In summary, a recursive DNS query simplifies the DNS resolution process for the client by handling all the necessary queries and information retrieval. The recursive DNS resolver starts from the root and works its way down to the authoritative name server, collecting and caching information along the way. This method provides convenience for end-users and reduces the complexity of DNS resolution, making it a common approach for resolving domain names to IP addresses.
- DNS (Domain Name System) records are essential components of the DNS infrastructure used to map human-readable domain names to numerical IP addresses. They provide critical information about how a domain's resources, such as websites, email servers, or other services, are configured. DNS records are stored on authoritative DNS servers, and when a DNS query is made for a specific domain, these records are retrieved and returned to the requesting client. Here are some common types of DNS records and their purposes: A Record (Address Record): The A record maps a domain name to an IPv4 address. It is commonly used for pointing a domain to a web server's IP address. AAAA Record (IPv6 Address Record): The AAAA record performs the same function as the A record but for IPv6 addresses. It maps a domain name to an IPv6 address. CNAME Record (Canonical Name Record): The CNAME record is used to create an alias for an existing A or AAAA record. It allows one domain to point to the same IP address as another domain. For example, you can create a CNAME record to point "www" to your domain's root, so both "example.com" and "www.example.com" resolve to the same IP address. NS Record (Name Server Record): NS records specify the authoritative name servers for a domain. These records indicate which DNS servers are responsible for maintaining the DNS records for a specific domain. They play a crucial role in the DNS delegation process. MX Record (Mail Exchanger Record): MX records specify the mail servers responsible for receiving email messages on behalf of a domain. They include a priority value that determines the order in which mail servers are used. When someone sends an email to an address associated with the domain, the MX record points to the mail server that should handle the email.
- DNS (Domain Name System) protocol messages are the format and structure used for communication between DNS clients (requesters) and DNS servers (responders). These messages are essential for querying and retrieving information from the DNS infrastructure. DNS messages are designed to convey queries and responses to resolve domain names to IP addresses and perform other DNS-related tasks. Here's an explanation of DNS protocol messages: DNS messages consist of two types of messages: DNS queries and DNS responses. DNS Queries: Header Section: The header section of a DNS query message contains essential information, including: Identification (ID): A 16-bit number assigned by the DNS client to match responses with queries. Query/Response Flag (QR): A single bit indicating whether the message is a query (0) or a response (1). Operation Code (OPCODE): A 4-bit field indicating the type of DNS query (e.g., standard query, reverse query, etc.). Authoritative Answer (AA): A 1-bit flag indicating whether the responding server is authoritative for the domain being queried. Truncation (TC): A 1-bit flag indicating whether the message was truncated due to size limitations. Recursion Desired (RD): A 1-bit flag indicating whether the DNS server should attempt to resolve the query recursively. Recursion Available (RA): A 1-bit flag indicating that the DNS server can perform recursive queries. Z and RCODE: Flags reserved for future use and response codes indicating the status of the query (e.g., no error, name error, server failure, etc.). Question Count: A 16-bit field specifying the number of questions in the query section. Answer, Authority, and Additional Counts: 16-bit fields specifying the number of resource records in each section of the response. Question Section: The question section of a DNS query message contains one or more query resource records (QNAME, QTYPE, QCLASS). It represents the domain name being queried, the type of query (e.g., A record, MX record), and the query class (usually IN for internet). DNS Responses: DNS responses are structured similarly to DNS queries, with a header section and resource record sections. Header Section: The header section of a DNS response message includes the same fields as a query message but with different values: Identification (ID): The same ID used in the corresponding query for matching. Query/Response Flag (QR): Set to 1 to indicate that it's a response. Authoritative Answer (AA): Set to 1 if the responding server is authoritative. Recursion Desired (RD): Copied from the query message. Recursion Available (RA): Set to 1 if the server can perform recursive queries. Z and RCODE: Flags indicating the response status. Question Count: The number of questions (usually copied from the query message). Answer, Authority, and Additional Counts: The number of resource records in each section of the response. Resource Record Sections: These sections contain the actual DNS resource records (RRs) that provide the information requested in the query. Resource records include data such as IP addresses (A and AAAA records), domain aliases (CNAME records), mail server information (MX records), and more. In summary, DNS protocol messages are structured into queries and responses, each containing a header section, question section (for queries), and resource record sections. These messages allow DNS clients to request information about domain names and DNS servers to respond with the requested data, enabling the resolution of domain names to IP addresses and other DNS-related tasks
- DNS query and reply messages have a similar format, consisting of a header section, a question section, and potentially additional resource record (RR) sections. However, they serve different purposes and contain distinct information. Here are the key differences between DNS query and reply messages: DNS Query Message: QR Flag (Query/Response Flag): In a DNS query message, the QR flag is set to 0, indicating that it is a query, not a response. This flag informs the recipient that the message is a request for information. Question Section: The question section of a DNS query message contains the query itself. It includes the following information: QNAME: The domain name being queried (e.g., www.example.com). QTYPE: The type of resource record being requested (e.g., A record, MX record). QCLASS: The class of the query (usually IN for internet). Header Flags: The header flags in a DNS query message may have specific bits set to indicate the desired behavior, such as the "Recursion Desired (RD)" flag, which is typically set to 1 to request recursive resolution from the DNS server. DNS Reply Message: QR Flag (Query/Response Flag): In a DNS reply message, the QR flag is set to 1, indicating that it is a response to a query. This flag tells the recipient that the message contains the requested information. Resource Record Sections: DNS reply messages include multiple sections, each containing RRs with different types of information: Answer Section: Contains RRs that answer the query and provide the requested information. Authority Section: Contains RRs that specify authoritative DNS servers for the domain. Additional Section: Contains RRs that provide additional information, often used for caching and optimization. Header Flags: The header flags in a DNS reply message convey the status and details of the response. For example: Authoritative Answer (AA): Set to 1 if the responding server is authoritative for the domain. Recursion Desired (RD): Indicates whether the client requested recursive resolution in the original query. Recursion Available (RA): Set to 1 if the server can perform recursive queries. Response Code (RCODE): Specifies the result of the query, indicating success, errors, or other conditions. Question Section: While DNS reply messages typically do not include a question section, they may sometimes echo the original question from the query for reference. In summary, DNS query and reply messages share a similar format, but they serve opposite roles in the DNS resolution process. Queries are requests for information, and replies are the responses that provide that information. The QR flag and the presence of resource record sections containing answers, authorities, and additional data are the key differentiators between the two message types