Amazon

Monday, 25 February 2019

Securing DNS Practical

Implementing DNSSEC (DNS Securing)

In DNSSEC infrastructure, Key Master i.e. primary server must serve key management and key generation service to the environment. Key Master is responsible for distributing private keys, KSK, zone signing key rollovers and zone signing for a specific zone. it also make sure that child zones ad signed delegation are sync and up to date. Key Master can be configured on any authoritative DNS server hosting the copy of primary zone. As long as the server hosts the primary zone, that server can be designated as Key Master for Multiple zones. Key Master is automatically configured when you initially create the DNSSEC Zone.

Configuring DNSSEC

Open Server Manager, click Tools and open DNS manager, in the DNS Manager, browse to your Domain name the right click domain name, click DNSSEC and then click Sign the Zone.


In the Zone signing Wizard interface, click next



On the signing options interface, click Customize zone signing parameters and the click next.




If appeared
On the Key Master interface, ensure that "The DNS server LON-DC1 is selected as the Key Master" and then click next


On the Key Signing Key (KSK) interface, click next



On the Key Signing Key (KSK) interface, click Add.



On the New key Signing Key (KSK) interface, keep all setting as default and click Ok.



On the Key Signing Key (KSK) interface, click next.



On the Zone Signing Key (ZSK) interface, click Next.



On the Zone Signing Key (ZSK) interface, click Add.



On the New Zone Signing Key (ZSK) interface, keep all setting as default and click Ok.



On the Zone Signing Key (ZSK) interface, click next.



On the next Secure (NSEC) interface, keep all the setting as default and click next.



On the Trust Anchors (TAs) interface, check the Enable the distribution of trust anchors for this zone check box and then click Next.
A trust anchor is an authoritative entity that is represented by a public key. The TrustAnchors zone stores preconfigured public keys that are associated with a specific zone.



On the Signing and Polling Parameters interface, keep all the setting as default and click Next.



On the DNS Security Extensions (DNSSEC) interface, click Next.



On the Singing the Zone, click Finish.



In the DNS console, expand Trust Points, expand com and then click your domain name.
Ensure that the DNSKEY resource records display and that their status is valid.



Now Open Group Policy Management, expand Forest: eihtech.com, expand Domains, expand eihtech.com, right click Default Domain Policy, and the Click Edit.



In the Group Policy Management Editor interface, under Computer Configuration, expand Policies, expand Windows Setting and then click Name Resolution Policy.

In the right pane, under Create Rules, in the Suffix box, type eihtech.com to apply the rule to the suffix of the namespace.

Select both the Enable DNSSEX in this rule check box and the Require DNS clients to check that the name and address data has been validated by the DNS server check box and then click Create.



Output


Sunday, 24 February 2019

Securing DNS Theory

The Domain Name System is an essential component of the functionality of most Internet services. It provides a distributed solution for services such as resolving host names to IP address and vice versa. DNS was designed around the early 1980s without any security consideration. This was mainly because at that time networks were quite small. All the hosts in the network were known beforehand and trustworthy.
There was no need for authenticity.
But as the network grew and Internet was born DNS remained unchanged. This resulted in lots of threats that target DNS due to the lack of authenticity and integrity checking of data held within the DNS. In 1994, the Internet Engineering Task Force (IETF) started working to add security extensions known as Domain Name System Security Extensions (DNSSEC) to the existing DNS protocol.
However you can protect the DNS Server by including Several options such as DNS cache locking, DNS socket pool and DNSSEC.

DNS Cache Locking
Whenever a DNS server does not have the answer to a query within its cache, the DNS server can pass the query onto another DNS server on behalf of the client. If the server passes the query onto another DNS server that has incorrect information whether placed there intentionally or unintentionally, then cache poisoning can occur. DNS cache poisoning, is a form of computer security hacking in which corrupt Domain Name System data is introduced into the DNS resolver's cache, causing the name server to return an incorrect IP address.
For example, suppose there is a name server, known as dns.eihtech.com, servicing a network of computers as shown in figure 3.1. An application on a client system , client1, make a DNS query that is sent to dns.eihtech.com. Then dns.eihtech.com examines its cache to see if it already has the answer to the query. Unfortunately, dns.eihtech.com is not authoritative for DNS name in the query nor does it have the answer to the query in its cache. It must send the query to another server, called unknowndns.external.org. The information on unknowndns.external.org happens to be incorrect, most commonly due to misconfiguration and the response sent back to dns.eihtech.com contains misleading information. Since dns.eihtech.com is caching responses, it caches

image 

this misleading information and sends the response back to client1. As long as this information exists in the cache of dns.eihtech.com, all clients, not just client1, are now susceptible to receiving this misleading information make the network and network computers vulnerable.
DNS Cache locking is a Windows Server  Security feature that helps to mitigate cache poisoning. It lacks the entries in the cache. So, if someone tries to poison the cache with a replacement record, the DNS server will ignore it and thus maintain the integrity of the cache content. DNS Cache locking adds an additional layer f protection onto those entries exist in the cache by preventing them from being overwritten for a percentage of time of the entire TimeToLive value. By default, the server Cache Locking Percent is set to 100%. For checking the cache locking percent you can using the dnscmd command.
dnscmd /info /cachelockingpercent

To use DNS Cache Locking, you set a percentage of the TTL of records that the cache content is  locked for. For example, a setting of 75 means that cached records can't be overwritten until 75 percent of their TTL has passed. The default value is 100, which means records can't be updated until the TTL has expired. You can configured cache locking by using the dnscmd command
dnscmd /Config /CacheLockingPercent <percent>

After executing it restart the DNS server service to apply the changes.
Also you can configure the cache locking by using PowerShell cmdlet.
Set-DnsServerCache -LockingPercent <value>

DNS socket pool
DNS socket pool functions as a security feature that allows a DNS server to use source port randomization when it is performing queries. So instead of sending out a query on a specific source port, it will randomize which source port is being used and this protects against cache poisoning attacks. It is enabled by default on Windows Server 2016.
When a DNS server or a DNS client is making a request to a DNS server, that server or client makes the request typically over an existing well known port. That port is most commonly TCP/53 and UDP/53.
If the DNS Server i.e. SRV1 is attempting to make a request on DNS Server i.e. SRV2, it is going send that request on TCP/53. Now on SRV1 the source port could've been the same port as of SRV2 and because of that, it became far too easy for some attacker to actually inject the wrong answer into that port.
Now, what DNS socket pooling does, it tells the server to go ahead and randomize the source port from where the actual request is coming. So, it maybe 2 or 1000 possible ports from there the actual request could come. When you have that many possible ports that the request could come from, it makes it much more difficult for the attacker to actually send the wrong information back into the listening port. You have to know the port number and more information about the exact transaction that's occurring. DNS socket pool is enabled by default i.e. 2500 socket pool size. Increasing the size of the socket pool allows the DNS server to increase the source port randomization. It's also possible to decrease the size of the socket pool to 0, in which case the DNS server uses a single socket for remote DNS query operations. You can modify to DNS Socket Pool size using the dnscmd.exe command line utility. For example, to set the socket pool size of 3000, issue the following command from an elevated command prompt on the computer that hots the DNS server role:
dnscmd /config /socketpoolsize 3000

DANE

The DNS-based authentication of Name Entities (DANE) protocol is a new feature available in the Windows Server 2016 DNS Server role. DANE support is specified in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 6394 and 6698. DANE allows you to use TLSA (Transport Layer Security Authentication) records to provide information to DNS clients that state what Certification Authority (CA) they should expect a certificate from for you domain name. This prevents man-in0the-middle attacks where someone might corrupt the DNS cache to point to their website, and provide a certificate they issues from a different CA.
For example, suppose that your organization hosts a secure website using HTTPS at www.eihtech.com by using a certificate from a well-known authority named IINNorth. Someone might still be able to get a certificate for www.eihtech,.com from a relatively unknown, different certificate authority name INEast. At that point, an entity hosting the fake www.eihtech.com website might be able to corrupt the DNS cache of a client r server to point www.eihtech.com over to its fake site. The end user is presented a certificate from INEast, and might unknowingly acknowledge it and connect to the fake site. With DANE, the client makes a request to the DNS server for eihtech.com asking for the TLA record, and discovers that the certificate for www.eihtech.com was issued by INNorth. If offered a certificate from another CA, the connection I terminated.

DNS Security Extensions (DNSSEC)
DNS Security Extension (DNSSEC) isn't a proprietary Microsoft technology but rather an Internet-standard extension to DNS defined in RFCs 4033, 4034, and 4035 that Microsoft has implemented as part of the Server 2016 DNS role.
DNSSEC assure the integrity of the DNS infrastructure through technologies that verify the authenticity of received data, including authenticated denial-of-existence responses. Assurance is enabled through public key cryptography, which enables the use of digital signatures on all DNS responses. A successful digital signature validation means that the received is genuine and can be trusted. The digital signature is generated using the DNS zone's private key which is kept secret and the content of the record and can be validated with the public key. If a packet is generated from a malicious source, its digital signature will fail; if a packet has been modified, the signature will no longer match the content.
DNS is implemented by the use of several resource records. To implement DNSSEC, several new DNS record type were created or adapted to use with DNSSEC.

RPSIG (resource record signature): Contains the DNSSEC signature for a record set. DNS resolvers verify the signature with a public key, stored in a DNSKEY-record.
DNSKEY: contains the public key that a DNS resolver uses to verify DNSSEC signature in RRSIG-records.
DS (delegation signer): Holds the name of a delegated zone. You place the DS record in the parent zone along with the delegating ND-records. It references a DNSKEY-record in the sub-delegated zone.
NSEC (next secure record): Contains a link to the next record name in the zone and lists the record types that exist for the record's name. DNS Resolvers use NSEC records to verify the non-existence of a record name and type as part of DNSSEC validation.
NSEC3 (next secure record version 3): Contains links to the next record name in the zone (in hashed name sorting order) and lists the record types that exist for the name covered by the hash value in the first label of the NSEC3 -record's own name. These records can be used by resolvers to verify the non-existence of a record name and type as part of DNSSEC validation. NSEC3 records are similar to NSEC records, but NSEC3 uses cryptographically hashed record names to avoid the enumeration of the record names in a zone.
NSEC3PARAM (next secure record version 3 parameters): Authoritative DNS requests use this record to calculate and determine which NSEC3-records to include in responses to DNSSEC requests for non-existing names/types.

The critical element is the trust. The client must trust the zone's public key because the public key is used to authenticate the response by decrypting the signature, which was created using the private key. Ensuring that clients trust only the "real" authoritative DNS zone owner is achieved through chains of trust.
In an ideal world, this PKI hierarchy would be self-contained in the DNS hierarchy in that the root of DNS -"." - would be DNSSEC -enabled and globally trusted by all clients, Then, the root could sign the top-level domain name (e.g. com,net,org), which could then sign their subordinate domains (e.g. company.com), thereby creating a trust path. This means that clients would need only to trust the root zone, since the root zone is used to authenticate all the other child zones.

Trust anchors
A trust anchors is an authoritative entity that is represented by a public key. The Trust Anchor zone stores preconfigured public keys that are associated with a specific zone. In DNS, the trust anchor is the DNSKEY or DS resource record. Client computers use these records to build trust chains. You must configure a trust anchor from the zone on every domain DNS server to validate responses from that signed zone. If the DNS server is a domain controlled, Active Directory-integrated zones can distribute the trust anchors.

Name Resolution Policy Table (NRPT)
Name Resolution Policy Table (NRPT) contains rules that control the DNS client behavior for sending DNS queries and processing the responses from those queries. For example, a DNSSEC rule prompts the client computer to check for validation of the response for a particular DNS domain suffix. As a best practice, Group Policy is the preferred method of configuring the NRPT. If no NRPT is present, the client computer accepts responses without validating them.

Implementing DNSSEC
In DNSSEC infrastructure, Key Master i.e. primary server must server key management and key generation service to the environment. Key Master is responsible for distributing private keys, KSK, zone signing key rollovers and zone signing for a specific zone. It also make sure that child zones and signed delegation are sync and up to date. key Master can be configured on any authoritative DNS server hosting the copy of primary zone. As long as the server hosts the primary zone, that server can be designated as Key Master for Multiple zones. key Master is automatically configured when you initially create the DNSSEC Zone.

Saturday, 23 February 2019

Domain Name System - Theory

Introduction to DNS
The DNS is a protocol and a service which is used for IP address to Hostname resolution and vice versa. The DNS protocol uses port number 53. Basically the DNS server is used to store the database of a network containing IP addresses and their Hostname which are used to map each other. The DNS server can be configured in only Server Operating System. It cannot be configured in client Operating System.
In addition to resolving hostname to IP addresses, you can also use DNS to do the following task.
  • Locate domain controllers and global catalog servers. This is used when signing in to AD DS.
  • Resolve IP addresses to host names. This is useful when a log file contains only IP address of a host.
  • Locate network services that register their names to DNS.
DNS Hierarchy


DNS maintains database using a hierarchical structure of domains. The naming structure used in DNS is called the DNS namespace. It begins with a root domain at its apex, then maintains Top Level Domain or parent domains, and then below that it holds child domains. In our example hostname is champ.eihtech.com. Here, COM is the parent domain, EIHTECH is the child domain and CHAMP is the NetBIOS name of the computer. champ.eihtech.com is called Fully Qualified Domain Name (FQDN).
On the internet, there are 13 root server clusters named A-M with servers in over 380 locations. They are managed by 12 different organizations that report to the Internet Assigned Number Authority (IANA), such as Verising. All of the servers are copies of one master server run by IANA. These root server holds the locations of all of the top level domains. (TLDs). There are two types of TLDs, country codes (ccTLDs) run by government organizations, and generic (gTLDs) such as .com, .net, .edu. and .gov. These are distributed and managed by Internet Corporation for Assigned Names and Numbers (ICANN). To participate in the Internet DNS namespace, a domain name must be registered with a DNS registrar. For example 'eihtech' domain is registered with '.com' gTLD. This ensures that no two organizations attempt to use the same domain name. If hosts that are located on the Internet do not need to resolve names in your domain, you can host a domain internally, without registering it. However, you must ensure that the domain name is unique from Internet domain names, or connectivity to Internet resources might be affected. A common way to ensure uniqueness is to create an internal domain in the .local domain. The .local domain is served for internal use in much the same way that private IP addresses are reserved for internal use.

DNS name resolution process

In DNS name resolution process; there are two types of queries i.e. Recursive Query and Iterative Query. In figure 1.1, the DNS client request the www.eihtech.com webpage. So the DNS client sends the query for the webpage to the DNS server. This query is known as Recursive query i.e. the queries made by the DNS clients to the DNS servers are known as Recursive queries. In recursive query, the DNS client expects that the DNS server should provide it required answer or say that page cannot be found.
Then the DNS server queries the webpage to root DNS server which is root level domain. This root server cannot find the webpage but it knows about com server. So it tells the DNS server to send the query to the .com server. The .com server also does now know about the webpage but has the knowledge about the eihtech.com domain and then tells the DNS server to make the query to the eihtech.com domain. The DNS server then sends query to the eihtech.com domain which has the knowledge about the www.eihtech.com webpage. It sends the positive response to the DNS server and redirects it directly to the webpage of www.eihtech.com. Now the DNS server makes the same query to number of DNS servers continuously. This query is known as iterative query which is performed at iterations. So the query sent from a DNS server to another DNS server is known as Iterative query.



You can change the name resolution process in several ways, but common options that you can use are as follows, 
Caching: Once a local NDS server resolves a DNS name, it will be saved in cache for approximately 24 hours. Next query for same DNS name will be resolved with the information in cache.
Forwarding: Some times Forwarders are configured on local DNS server. So the queries will not be directed to Root servers. Instead those queries will be guided to another DNS server specified in Forwarders.
Host File: Windows operating system also contain a Hosts file in the %SystemRoot%\System32\Drivers\Etc directory. The file can contain mappings for host names to IP addresses.
DNS resolver cache: DNS client machine facilitates the caching of recently resolved queries locally.

DNS infrastructure components

DNS server: It maintains the database of hostname and their IP addresses. It resolves the query from client machines. It holds the information in cache temporarily. If a query cannot be resolved by DNS Server, that query will be forwarded to Root Servers or another DNS serve.
query will be forwarded to Root Servers or another DNS server.
DNS zones: In addition to dividing your Domain Name System (DNS) namespace into domains, you can also divide your DNS namespace into zones that store the information about one or more DNS domains. A zone is the authoritative source for information about each DNS domain name is included in that zone. You can relate zones with logical subnets created in a single network for better management. Multiple zones can be stored in one server or multiple servers can hold database of single zone. Zone records are maintained using two types of lookup zones. Forward lookup zones hold mapping of host names to IP addresses and Reverse lookup zones hold mapping of IP addresses to host names.
DNS forwarders: When an authorized server cannot resolve the query from its client with tits database or caching information it will be forwarded to another DNS server specified in Forwarded option.
DNS delegation: When DNS namespace database of an organization is difficult to manage under one logical domain, some database management is delegated to downstream DNS servers. Those servers are called delegated DNS Servers.
Root Hints: The information about internet Rootservers is stored in Root Hints. It is used to forward the unresolved query to the Internet clusters of Rootservers.
Resource records: The entries in the DNS database that are used to answer queries are called resource records. Some typical record types are as follows,
     A: This record is used for resolving hostnames into IPv4 addresses.
     AAAA: This record is used for resolving hostname into IPv6 addresses.
     CNAME: This record is used to resolve one name (alias) into another, fully qualified name, such        as www into champ.eihtech.com
     SRV: This record is used to find servers providing specific services, such as domain controllers.
     PTR: This record is used in reverse lookup zones for resolving IP addresses into fully qualified          host name.
     Mail exchanger (MX): This record is used to identify Simple Mail Transport Service (SMTP)            servers.
     Start of authority (SOA): This record is used to identify the Primary DNS server for a zone.
     Name server (NS): This record is used to identify all DNS server in a zone.

Dynamic update: Dynamic updates are information's regarding changes made to resources in the domain. They will be registered in the DNS database without manual intervention. The registration occurs during the following events.
  • When the client starts and the DHCP client service is started.
  • When an IP address is configured, added, or changed on any network connection.
  • When an administrator executes the Windows PowerShell cmdlet Register-DNSClient or runs the ipconfig /registerdns at a command prompt.
We can select Dynamic secure or non-secure option or Manual update option during DNS configuration.

Prerequisites of DNS server
For deploying DNS server role following are the recommended requirements,
  • Computer system with Windows Server 2016.
  • Properly configured Time Zone.
  • Computer must have static IP address.
  • Computer name should be properly assigned.
  • Administrator password should be complex to avoid security loophole.
DNS Zone Types

Primary zone: When we deploy the first DNS server in the domain, it has to be Primary DNS zone. It is the first source of domain information. All other Name Servers will receive updates about the changes in the domain from Primary DNS zone. In Primary DNS, database file is stored in the %windir%\System32\Dns folder. When the zone is not stored in AD DS, the primary zone server is the only DNS server that has a writable copy of the database. When Primary zone is online we will be able to resolve the query as well as make changes in the database.
Secondary zone: It is read only replicated copy of the Primary DNS database. The updates cannot be directly written to Secondary zone. Any modification in the domain, will be first written on Primary zone database file and then updated information will be passed on the Secondary zone. Secondary zone is able to resolve the queries but in the absence of Primary zone records cannot be modified in DNS database.
Stub zone: Stub zone contains only those resource records necessary to identify that zone's authoritative DNS servers. Stub zones will not be able to resolve the query. Stub Zone can only forward the query to authorized DNS servers.
Active Directory-integrated zone: Domain Name System (DNS) servers running on domain controllers can store their zones in Active Directory Domain Services (AD DS). In this way, it is not necessary to configure a separate DNS replication topology that uses ordinary DNS zone transfers because all zone data is replicated automatically by means of Active Directory replication. This simplifies the process of deploying DNS and provides the following advantage.
Multiple masters are created for DNS replication. Therefore, any domain controller in the domain running the DNS Server service can write updates to the Active Directory-integrated DNS zones for the domain name for which they are authoritative. A separate DNS zone transfer topology is not needed. 
Secure dynamic updates are supported. Secure dynamic updates allows an administrator to control what computers updates what names and prevent unauthorized computers from overwriting existing name in DNS.




Tuesday, 5 February 2019

DHCP Theory

Requirement of Dynamic IP address assignment
At first, most TCP/IP networks were relatively small and static. Manual IP address management techniques were sufficient for them. Each station kept its own IP address somewhere in its secondary storage. Once the address had to be changed, it required manual administrative action. as more complex networks were established, as more and more underlying network devices were used for TCP/IP communication networks, manual administration became difficult. as thin client workstations without secondary storage came into network, a need for centralized administration of IP addresses configuration bindings became essential.

Evolution of Dynamic host Configuration Protocol (DHCP)
A special protocol Reverse Address Resolution Protocol (RARP) was designed for such bindings. It allowed a machine on a network segment to learn its own IP address and then to begin normal TCP/IP operation. Another protocol, BOOTP, was also developed to allow dislikes stations retrieve all the TCP/IP configuration parameters needed to start functioning normally after a startup. BOOTP defines a concept of BOOTP relay agent which specifies how BOOTP traffic is forwarded between multiple segment. So dynamic IP address assignment was possible over Multiple subnetworks with BOOTP. The BOOTP extension mechanism was later on used and developed by BOOTP's descendant, Dynamic Host Configuration Protocol (DHCP).
There are two primary different between DHCP and BOOTP. First, DHCP defines mechanisms through which clients can be assigned a network address for a finite lease, allowing for serial reassignment of network address to different clients. Second, DHCP provides the mechanism for a client to acquire all of the IP configuration parameters that it needs in order to operate. DHCP is base on BOOTP, adding the capability of automatic allocation of reusable network address and additional configuration options. DHCP captures the behavior of BOOTP relay agents, and DHCP participants can interoperate with BOOTP participants.

Benefits of DHCP implementation
Reliable IP address configuration: DHCP minimizes configuration errors caused by manual IP address configuration, such as typographical errors or address conflicts caused by the assignment of an IP address to more than one computer  at the same time.
Reduced network administration: DHCP includes the following features to reduce network administration
  • The ability to define TCP/IP configuration from a central location.
  • The ability to assign a full range of additional TCP/IP configuration values by means of DHCP option such as the subnet mask, DNS servers and default gateway.
  • The efficient handling of IP address changes for clients that must be updated frequently, such as those for portable computer that move to different location on a wireless network.
  • The forwarding of initial DHCP message by using a DHCP relay agent, thus eliminating the need to have a DHCP server on every subnet.
IP address assignment process of DHCP
DHCP allocated IP addresses on a dynamic basic, otherwise known as lease. Although you can set the lease duration anywhere from a few minutes to unlimited, you will typically set the duration for not more than a few hours or days. The default lease time is eight days for wired clients and three days for wireless clients. IP address are handed out to requesting network clients from  a pool of addresses that you define. When a client requests an IP address, the DHCP server offers the next available IP address from the pool. It is possible to reserve particular IP addresses for specific clients based on the media access control (MAC) address of the client's network interface.
Let us discuss the communication between DHCP server and client.

DHCP discovery: The DHCP client broadcast a DHCPDISCOVER packet to every computer in the subnet. The only computer that respond are computers that have the DHCP server role. Or computers or routers those are running a DHCP relay agent respond to Discovery. The DHCP relay agent forwards the message to the DHCP server. Discovery Message consists of communication details such as IP address fields for source=0.0.0.0; destination=255.255.255.255 and UDP source port=68; destination port=67 and Client MAC address and other DHCP options.

DHCP offer: When a DHCP server receives a DHCPDISCOVER message from a client, which is an IP address lease request, the server reserve an IP address for the client and makes a lease offer by sending a DHCPOFFER message to the client. This message contains the client's MAC address, the IP address that the server is offering, the subnet mask, the lease duration. Offer Message consists of communication details such as IP address field for source=172.30.10.1 (DHCPServer); destination=255.255.255.255 and UDP source port=67; destination port=68 and MAC addresses of Client and Server.

DHCP request: The client receives the DHCPOFFER packet. it might receive the packet from multiple servers. If it does, it usually select the server that made the fastest response to its DHCPDISCOVER, which typically is the DHCP server closest to the client. the client then broadcast a DHCPREQUEST that contains a server identifier. This informs the DHCP servers that which server's DHCPOFFER the client has chosen to accept Request Message consist of communication details such as IP address field source=0.0.0.0; destination=255.255.255.255 and UDP source port=68; destination port=67 and MAC addresses of client and Server.

DHCP acknowledgement: The DHCP servers receive the DHCPREQUEST. Servers use this message as the notification that the client selected a particular server's offer. The chosen server stores the IP address client information in the DHCP database and responds with a DHCPPACK message. If the DHCP server cannot provide the address that was offered in the initial DHCPOFFER, the DHCP server sends a DHCPNAK message. Acknowledgment Message consists of communication details such as IP address field source=172.30.10.1; destination=255.255.255.255 and UDP source port=67; destination port=68 and MAC address of Client and Server.



The protocol expects the DHCP client to configure its network interface with the negotiated parameters. After the client obtain an IP address, it should probe the newly received address with ARP (Address Resolution Protocol) to prevent address conflicts caused by overlapping address pools of DHCP servers.
A DHCP client may request more information than the server sent with the original DHCPOFFER. The client may also request repeat data for a particular application. For example, browser use DHCP information to obtain web proxy settings.

DHCP Server authorization
DHCP communication typically occurs before any user or computer authentication. Therefore an unknown DHCP server can provide invalid information to clients. You can avoid this by authorizing the server. The domain administrator uses a process called DHCP authorizing to register the DHCP Server in the Active Directory domain before  it can support DHCP clients. Authorizing the DHCP server is one of the post-installation tasks that you must perform after installing the DHCP server.

DHCP Configuration Option
DHCP reservation: If you want a computer or a device to obtain a specific address from the score range, you can permanently reserve that address to be assigned to that device in DHCP. Reservation are useful for tracking IP address assigned to device such as printers.

Scope Options: These options are applied to any clients that obtain a lease within that particular scope. Active scope option types always apply to all computers obtaining a lease in a given scope. You can configure many optional properties on a scope, but typically you configure the following properties
Option 003 - Router (the default gateway for the subnet)
Option 006 - DNS servers
Option 005 - DNS suffix

PXE Boot Options: PXE-enabled network cards add the DHCP option 60 to their discover packets. Normally, DHCP clients send a DHCP option 67 packet, and then DHCP servers return a DHCP 68 option offer. The ports that DHCP uses also are used by the Windows Deployment Services PXE server function. Therefore, if you deploy DHCP and a PXE server on the same machine, you must set DHCP to make offers that also include the 60 option. A DHCP server then makes the DHCP 60 offer back to the client. You need to set DHCP options 60 (PXE Client), 66 (Boot Server Host Name), and 67 (Bootfile Name)

Implementing DHCP server