Understanding of DNS

Understanding of DNS

August 22, 2021 Active Directory 0

Domain Naming Service (DNS)

Records are all communication log. DNS is a client/server service.

A DNS server, or name server, is used to resolve an IP address to a hostname or vice versa.
Before DNS, local host file help this DNS operation. DNS was developed in 1983
BIND stands for Berkeley Internet Name Domain which is the most commonly used Domain Name System (DNS) server on the Internet.
NS Record required to resolve the name.

DNS _msdcs.lab.com – it’s major part of Domain configuration

DNS servers use Port 53 by default (UDP). Incoming and outgoing packets should be allowed on port 53. Also allow connections on port 921 if you configure a lightweight resolver server.

Domain Name System, DNS is an Internet service that translates domain names into IP addresses. Because domain names are alphabetic, they’re easier to remember.

Forward lookup : it converts Domain name to IP address
Reverse lookup: it converts IP address to Domain name.

Nslookup.exe is a command-line administrative tool for testing and troubleshooting DNS servers. This tool is installed along with the TCP/IP protocol through Control Panel.

DNSSEC, Domain Name System Security Extension. DNS traffic is not encrypted so can be modified. DNSSEC proves data has not changed.

Recursive and Iterative Query, Recursive from client to local DNS Server. DNS Server take responsibility for resolution. Will contact other DNS Server as required.
Iterative from local DNS to Root Servers. Respond from cache or another Server.

Overall Steps for Name resolution,
Local DNS -> Conditional forward (If any exact IP to re-route) -> Forwarder -> Root hints

Root Hint Server, Limit to 13 server configured. Forwarder needs to be configured or DNS record should be present in order to resolve the query if no Root Hint.

Recursive and Iterative Query Resolution

A user types something like www.google.com or clicks on a hyperlink for google.com on a browser.
If the local DNS server does not know the IP address of www.google.com,
it queries a root DNS server asking for the location of the .com DNS servers.
After getting a response from a root DNS server, the local DNS server queries a .com DNS server requesting the location of the google.com DNS servers.
Once the .com DNS server has responded, the local DNS server contacts the google.com
DNS server asking for the IP address of www.google.com.
After the google.com DNS server provides that information, the local DNS server returns www.google.com’s IP address back to the user computer to make it possible for that computer to complete a connection to www.google.com

Caching Once the local DNS server learns that information, it caches the results for a few hours. From that point on, any new name resolution query for the same name will be served off the DNS server cache. This speeds up the name resolution process.

DNS Zones and Records

The DNS data is kept in a database that can be stored in a text file or in the active directory database when the DNS service is configured on a domain controller.

The DNS data is organized into zones; each zone is a specific portion of DNS namespace that is stored in a separate file or as a unit of replication when stored in active directory.

If AD-Integrated DNS – Secondary DNS Server is also writable, Not able to write In case of Stand-alone Secondary DNS Server.

Primary DNS Replication will not happen when No AD. Replication happen only on AD or Primary DNS to Secondary DNS
Primary-Primary Replication happen only on AD-Integrated

DNS zones contain different resource records. Resource records specify a resource type, and the IP address to locate the resource. DNS zones can resolve names to IP addresses or IP addresses to names for devices running the TCP/IP protocol like workstations, servers, routers, switches, etc.

A Record A (Address) records assign IP addresses to domain names of computers. The IP address cannot have a dot at the end.
Pointer Record (PTR) is used to translate an IP address into a domain name.
MX Records specify the mailing server of the domain. An MX record shows to which computer a mail of a particular domain should be sent. The MX record also includes a priority number, which can be used to determine several computers where the mail for the domain can be sent. The first attempt is to deliver the mail to the computer with the highest priority (lowest value). If this attempt fails, the mail goes to the next computer (with a higher priority value), and so on.test.com IN SOA ……mail test.com IN SOA ……mail IN A IN HINFO AlphaServer UNIX IN TXT my server IN MX 30 mail2.nextstep4it.com IN MX 20 mail3.nextstep4it.com IN MX 10 mail2.nextstep4it.com
TXT Records HINFO and TXT records are for information only. An HINFO record has two items in its data part. The first item is information about hardware, and the second one is information about software. A TXT record contains a general data string in its data part. Example :test.com IN SOA ……mail IN A HINFO My_Server UNIXIN TXT my server.
Start of Authority (SOA) record determines the name server that is an authoritative source of information for the particular domain. There is always only one SOA record in the file, and it is placed at the beginning of the file of authoritative resource records.
Name Server keeps information for the translation of domain names to IP addresses and IP addresses to domain names. The name server is a program that performs the translation at the request of a resolver or another name server.
CNAME Record Synonyms to domain names can be created using CNAME records. This is often referred to as ‘creating aliases for computer names’.

Information on domain names and their IP addresses, as well as all the other information distributed via DNS is stored in the memory of name servers as Resource Records (RR)

In the case of Active Directory domain services, a special type of DNS record (SRV) is used to locate domain controllers and global catalog servers. The two types of common DNS zones configured on most DNS implementations are forward lookup and reverse lookup zones.

Service record (SRV record) is a specification of data in the DNS defining the location, i.e. the hostname and port number, of servers for specified services.

Forward lookup zones resolve host names to IP addresses, and they answer to name queries by replying with the corresponding IP addresses that match the names in those queries.
Forward lookup zones host common resource records including IPV4 host (A), IPv6 host (AAAA), alias (CNAME), service (SRV), mail exchanger (MX), start of authority (SOA), and name server (NS) resource records. Both IPv4 and IPv6 host names can be included in the same forward lookup zone on Windows Server 2012.

Reverse lookup zones resolve IP addresses to domain names. When an IP address is part of the query, the reverse lookup zone returns the corresponding host name.
Reverse lookup zones host SOA, NS, and pointer (PTR) resource records. Separate reverse lookup zones must be created for IPv4 and IPv6 on Windows Server 2012.
Reverse lookup zones can be used to fight spam. Spammers use open relays (SMTP servers) on the internet to send their massive unsolicited emails and hide their identity.
A mail server can perform reverse lookups to try to detect open relays; this would allow the application of traffic filtering from those open relays which can prevent or minimize unwelcome spam.

Another important benefit of reverse lookup zones is that their data is frequently used to validate forward zone information. For example, if the forward lookup specifies that support.mycompany.com is resolved to, you can use a reverse lookup to confirm that is really associated with support.mycompany.com.

Root Name Server is an authoritative name server for the root domain (for the dot). Each root name server is a primary server, which differentiates it from other name servers.

Time to live (TTL) A 32-bit number indicating the time the particular RR can be kept valid in a server cache. When this time expires, the record has to be considered invalid. The value 0 keeps nonauthoritative servers from saving the RR to their cache memory.

DNS Zones Types

Primary zone. A DNS server can read and write data on a primary zone. This is possible because the DNS server stores the master copy of the zone data either in a text file or in the Active Directory database if the DNS is installed on a domain controller. If a local file is used, the file is named with the same name as the zone using a .dns extension like zone_name.dns. The zone file is saved to the %windir%\system32\dns directory by default.

When a file is used, the primary DNS server is the only one that has a writable copy of the database.

A DNS server is authoritative for the records that it holds on a primary zone. That means if the DNS server receives a name resolution query that includes the domain name on the primary zone, the DNS server will respond with a yes or no answer. The authoritative DNS will not forward that name resolution query to any other DNS server.

Secondary zone. A DNS server can read, but not write data on a secondary zone. A secondary zone is a copy of a primary zone that another DNS server hosts. The information on the secondary zone is obtained and updated via zone transfers from another server. A read-only text file is used to store the information locally; secondary zones cannot be store in the active directory database. A DNS server is authoritative for the records that it holds on a secondary zone.

Stub zone. Contains partial data from another zone. Only record to find the authoritative server. A stub zone is a limited copy of a zone that consists of the following records: start of authority (SOA) resource records, name server (NS) records, and host name (A) records. These records are used to identify the zone’s authoritative DNS servers. The DNS server holding the stub zone is not authoritative for that zone. When this DNS server receives a name resolution query, it needs to ask one of the authoritative DNS servers from the stub zone.

Active Directory Integrated zone. Active directory integrated zones can be configured only on domain controllers that are also DNS servers. This is a primary zone with its data stored in the active directory database.

There are several benefits of using active directory integrated zones, among them:

Secure dynamic updates. Dynamic updates allow DNS clients to register their resource records in the DNS database automatically without manual intervention. This feature is available on standard primary zones; however, only active directory integrated DNS zones can be configured for secure dynamic updates. This means that you can set permissions on the zone to allow only authorized computers to register in the DNS database.

Secure replication topology. There is no need to configure zone transfer on Active Directory integrated zones the way you have to do it with standard primary zones and secondary zones. With Active Directory integrated zones, the DNS data is transferred automatically as part of the active directory replication. All AD replication is encrypted by default.

Increase resilience. There is no single point of failure when you have multiple domain controllers holding active directory integrated zones. Each domain controller has a read/write copy of the DNS zone; this allows changes and automatic updates performed on any domain controller to be replicated across the domain or the forest using the powerful active directory replication engine.

Security permissions. Like any other active directory object, you can delegate administration and apply individual permissions to zones, and resource records by modifying the access control list (ACL) on the zone. See below the security tab on the properties of an active directory integrated zone:

Important Configuration Files For DNS Server is BIND uses /etc/named.conf as its main configuration file, the /etc/rndc.conf file as the configuration file for name server control utility rndc, and the /var/named/ directory for zone files and the like.

 1,073 total views,  1 views today

Leave a Reply

Your email address will not be published. Required fields are marked *