DNS (Domain Name System): 

DNS (Upside-Down Tree): To be able to reach to a destination existed on the internet through dns, we need to pass through multiple stages until we reach to the destination 

1. We need to ask one of your ROOT domains “based on the location” about the existed top level domains in query 

2. Request will be sent to top level domain about the second level domain 

3. We will find our needed answer for the subdomain inside the second level domain 

FQDN: Complete domain name for a specific host on the internet  

Client/Stub Resolver: The term “stub resolver” refers to the piece of software code that sends the simple DNS question, usually built-in as part of the Operating System. 

Recursive Query: Asking a DNS server that supports recursion, a client wants the asked dns server to complete the path until it gets an answer back to client 

Iterative Query: Queries between DNS servers and each other’s, used when the dns server that initiates the query can follow the referral to get the answer  

Recursive Resolver: Accepts recursive queries and fulfills them by executing iterative queries in the background to track down answers.  

Authoritative Name Server: DNS server that is able to give an authoritative answer to the asking client from its internal Zone DB 

Resource Record: Resource Record represents an individual piece of information you want to get out of DNS 

Zone: Zone is a collection of resource records with the same domain name suffix, and it exists on authoritative name servers, as a text file or in database. 

DNS Message Format: 

• We have two types of the DNS messages 

  1. Query 

     • Question section 

  2. Response 

     • Question section 

     • Answer section 

     • Authoritative section 

     • Additional section 

A: An A record is a domain name to IPv4 address mapping 

AAAA: An AAAA (pronounced quad-A2) record is a domain name to IPv6 address mapping.  

PTR (Pointer): PTR represents a domain name pointer record, which is an IP address (v4 or v6) back to a domain name.  

CNAME (Canonical Name): A CNAME record is a name that points to another CNAME or A record.  

MX (Mail Exchange): The information field has two parts, first is the numeric “preference” field followed by the name of the mail exchange server. Client software prefers the lower preference numbers.  

SOA (Start Of Authority): Of all of the resource records, SOA record is the most important one: not only does every zone need to have one, it also must be the very first resource record.  

NS (Name Server): A NS record specifies the names of the name servers that are authoritative for the domain.  

SRV (Service): SRV records provides a mechanism to help clients locate services within a domain.  

TXT (Text): TXT record holds any arbitrary string for up to 255 characters. This string can be either read by a human or machine 

TTL (Time To Live): TTL value is the timer that tells recursive name servers how long they may keep this particular answer in cache. Once the TTL reaches zero, recursive servers need to go back to the authoritative name servers to get the answer again 

Zone Transfer:  

• A way of synchronization between the primary and secondary name servers to keep the authoritative data in sync between all existed name servers 

• Works on port TCP 53 

• Zone transfer is happening according to the timers existed on the SOA record for the primary name server zone 

Subzone: 

• A collection of records collected together for ease of administrative purposes 

• The subzone administrator can control the subzone but also the full zone administrator can control full subzones inside the container 

Delegation: 

• Delegation is similar to subzone, except the authority of the subzone is held by another entity 

• This means that the parent zone administrators can’t change any data for the delegated zone , it’s managed by another administrator 

• In this case the authority of this subzone will be delegated to another new dns servers  

• Delegation requires the parent and child zone to work closely together. The parent zone needs to have the NS records for the child’s new authoritative servers (primary and secondary), so it may refer other recursive resolvers 

• Glue records are A or AAAA records in the parent zone that accompany delegated sub zone NS records 

DNS Header: 

Response Codes: 

Response Flags: 

Truncation: When a DNS message is too large to fit into a single UDP packet (default size 512 bytes), the DNS server responds with the TC flag, requesting retransmission over TCP 

Resolution: 

Forwarding: 

• Forwarding simply means sending the recursive queries to another dns server to act it’s role. So only Recursive Servers can be used to do forwarding 

• By default the recursive dns server is using the root servers as forwarders unless you change this behavior 

• The main reason to configure default forwarders on your recursive resolver is to control the querying behavior 

Forwarding conditions: 

DNS Views: 

• Called “Split Horizon/Split Brain DNS” 

• A feature that enables DNS server to give different answers according to each view 

• Kind of access control list 

• It is common for DNS administrators to have two or three DNS views, such as Internal, External, and Dev 

DDNS (Dynamic DNS): 

• Updating DNS records dynamically to keep it up to date 

• A way for a device to send an update to the DNS server dynamically. Since there are multiple DNS changes for entries inside DNS 

• Updating Tools Could Be Static Hosts , DHCP Client, DHCP Servers 

• DHCP clients & DHCP servers can both update DNS servers 

• DDNS Update Process: 

  1. SOA: Client wants to send an update to the DNS server will take a look into its configured DNS on its network configuration, see SOA record for this name server it wants to update 

  2. A Record: Seeing the A record for the existing name server and trying to reach it 

  3. DDNS Update: Sending the update request to the DNS 

• Updating Stages 

  1. After client forms it’s FQDN through DHCP process 

  2. It will check SOA for its DNS server to start updating 

  3. Sending an UPDATE conversation to DNS 

  4. Receiving an ACK from DNS 

• Option 81: This option enables the DHCP client to update the DNS instead of the DHCP server 

DDNS Restrictions: 

• We can limit who can update the DNS through ACLs Or ACE 

• Also we can use sign updates through TSIG Key Or GSS-TSIG 

  • Signing updates authenticates the sender and verifies the data 

   

  • TSIG: It is a way of hashing ensuring that the update message is not tampered  

  • TSIG uses pre-shared keys, meaning that both the sender of the update and the receiver, must have the same key 

   

  • GSS-TSIG: An extension to TSIG, offloads key management to a third party (Kerberos) and uses tickets for the operation  

Redundancy: 

Commands: 

• Ipconfig /all – Shows you the configured DHCP server in Windows that you pulled an address from 

• Dig @192.168.1.1 www.google.com. A – Gets the a record of www.google.com by this dns server 192.168.1.1 

• Nslookup www.google.com. – Gets the a record using nslookup “built-in in windows” 

• Ipconfig /flushdns – Clearing all the cache of client side in Windows  

IPAM (IP Address Management): 

• It is a tool used to give very intensive information about the devices assigned ip addresses on our network, this enables administrators from knowing everything is happening on the network level 

• It’s not a service or protocol, it’s just the correlating tool between DNS and DHCP 

• DNS & DHCP protocols data are integrated into most IPAM solutions, any change in this data will be transferred automatically to the IPAM.  

• Also IPAM uses some types of discovery techniques to discover devices are not discovered using DHCP or DNS automatically 

  • Network Scan: Using a tool like NMAP to discover all existed devices, could be useful in the internal LAN network, but for the remote devices it could be blocked 

  • Network Data: Asking devices for giving us information about themselves. The Simple Network Management Protocol (SNMP) was designed exactly for this purpose. it allows network operators to communicate with supported devices, either to look up information about the device itself, or ask the device to do something. 

• Metadata: Other data that is collected also not related to the IP address, but also collected by IPAM 

  • Metadata could be collected by protocols  

  • Could be entered manually by the administrators 

IPAM Searching: Techniques should at least contain the following searching techniques 

DNSSEC: Adding security layer to the DNS 

• Adds Digital signatures 

• Data Integrity 

• Protection Of Denial Of Existence 

• No Encryption Provided For Data Through DNSSEC 

• Some records will be added through DNSSEC to achieve digital signatures and hashes 

• Used Flags: 

  DO “DNSSEC-Aware”: will be sent in the query indicating that the resolver is able to verify the DNSSEC 

  AD “Authenticated Data”: a response indicates that the name server has been able to cryptographically verify ALL of the data contained within the response, the data is authentic 

  CD “Checking Disabled”: Sent with the query to tell the name server to send to answer if the DNSSEC failed 

• Signing: Two asymmetric key pairs are needed to sign a zone 

  • Zone Signing Key “ZSK”: Used to sign the zone 

  • Key Signing Key “KSK”: Used to sign zone DNSKEYs 

  • ZSK signs zone data, KSK signs ZSK 

• Records:  

  • DNSKEY: DNSKEY record contains the public key that a DNS resolver uses to verify DNSSEC signatures in RRSIG records 

  

  RRSIG: Digital signature itself for the resource records. By comparing the digital signature embedded in the RRSIG record against the computed signature of the resource records you have received you can determine whether the resource records have been tampered with in transit, if they don’t match then the data is now invalid 

  

DNSSEC Operation: 

• To verify a DNS server, we need to make sure it’s verified first using the root anchor 

• It’s like a chain of trust (like root to SLD) so without establishing this anchor we need to verify each and every public key inside the asked dns server 

• To complete the full cycle we need to have a record that could be transferred from the child zone to the parent zone, this record is called DS record “Delegation Signer” 

• Validating resolvers use DS records (hosted by the parent zone) to validate the KSK they received from the child zones 

• The DS record existed on the parent zone tells us that the child zone is signed and ready for DNSSEC 

DNSSEC Verifying Stages: 

1. Obtain the trust anchor from root server “publicly available” 

2. Inside root zone we will have DS record for the top level domains like .org, .com. DS record points to public key of KSK of top level domains. Private portion of KSK is used to sign ZSK 

3. Inside sub level domain like .com, there is a DS record pointing to the sub level domain like google. DS record points to the public key of KSK of the sub level domains. Private portion of KSK is used to sign ZSK 

4. Same process until we reach your normal records inside the actual zone 

DNSSEC Keys Roll Over: 

• We need to always to change the private keys for not to be attacked by intruders 

• Changing keys (ZSK, KSK) could break the chain of trust. Breaking the Chain of Trust or incorrect signing causes zone data to become insecure or unavailable 

• At least we need to have a RRSET signature to be trusted by the name server not to break the chain of trust 

• Double Signature: In the double signature method, the zone is simultaneously signed with both the old and new keys. Recursive clients get both signatures. Both signatures are maintained in the zone until all caches have had enough time to expire the old public key from the zone and get a copy of the new key 

• Pre-Publishing: When using the pre-publishing method, we make the new DNSKEY record available before signing any RRSET 

• We don’t need to notify the external world about the ZSK since it’s used internally for signing zones data  

• Only we need to update and notify the external world about the KSK since it’s the source of DS record.  

• To perform a KSK rollover, we must generate a new KSK, sign the zone with it, register the new KSK with the parent zone, verify that the new key is available globally 

NXDOMAIN: 

• Without DNSSEC, NXDOMAIN response could be sent to user without verification but might be a trick from the attacker 

• DNSSEC could give a negative answer to the client for verifying 

• Through two types of records (NSEC, NSEC3), NSEC3 is hashed 

• Once the DNS resolver has the NSEC record and its signature, it can cryptographically verify that the data has not been tampered with, which then indicates proof that the record we asked for does not exist 

   

  

Command & Control Servers: 

• If an executable “MALWARE” succeeded to infect a victim, this file needs to communicate with its controller that will enforce it from executing some malicious instructions into the victim’s machine. THAT’s what we call command and control server  

• This communication between the executable and the remote C2C server will happen through DNS 

• Like in the case of WANNACRY ransomware, the client after executes the infected malware it will try to search for specific domain that doesn’t exist to retrieve “NXDOMAIN” response that will encrypt all the data on the client’s data  

DNS Exfiltration: In this attack response is neglected, only request is sent through DNS which is encoded as a resource record to the destination, attacker can understand the encoded data that is sensitive 

DNS Tunneling:  

• ENCODING “ENCRYPTING”, Extracting Data Through Records, Needs Records That Can Carry The Most Data .  

• Best Records For Attackers: largest records in size are preferred “CNAME , TXT , NULL , MX” 

  • Using Null “That can carry up to 16,000 bytes” will be more obvious for DNS to be detected “KNOWN” 

  • SRV records are used internally only “KNOWN” 

  • MX records are used in mails only “KNOWN” 

  • Best is CNAME & TXT 

• Response itself could be a specific command that could be used as a command on the victim’s machine 

Lookalike Domains: 

• Domains that are appear identical or very similar to the real or known domain 

DGA (Domain Generation Algorithms): 

• DGA :- Domain Generation Algorithm (DGA) is a technique that adversary embeds in the malware binary to periodically generate a large number of pseudo-random non-existent domain names for the Command-and-Control (C&C) server. The malware then attempts to resolve these generated domain names by sending DNS queries until one of the domains resolves to the IP address of a C&C server 

• GA is employed to prevent the C&C server from being taken down and hinder blacklisting attempts 

Hijacking: 

Defense Techniques: