DNS Query

How does DNS work?

When you visit a domain such as dyn.com, your computer follows a series of steps to turn the human-readable web address into a machine-readable IP address

Step 1: Request information

The process begins when you ask your computer to resolve a hostname, such as visiting http://dyn.com. The first place your computer looks is its local DNS cache, which stores information that your computer has recently retrieved.

If your computer doesn’t already know the answer, it needs to perform a DNS query to find out.

Step 2: Ask the recursive DNS servers

If the information is not stored locally, your computer queries (contacts) your ISP’s recursive DNS servers. These specialized computers perform the legwork of a DNS query on your behalf. Recursive servers have their own caches, so the process usually ends here and the information is returned to the user.

Step 3: Ask the root nameservers

If the recursive servers don’t have the answer, they query the root nameservers. A nameserver is a computer that answers questions about domain names, such as IP addresses. The thirteen root nameservers act as a kind of telephone switchboard for DNS. They don’t know the answer, but they can direct our query to someone that knows where to find it.

Step 4: Ask the TLD nameservers

The root nameservers will look at the first part of our request, reading from right to left — www.dyn.com — and direct our query to the Top-Level Domain (TLD) nameservers for .com. Each TLD, such as .com, .org, and .us, have their own set of nameservers, which act like a receptionist for each TLD. These servers don’t have the information we need, but they can refer us directly to the servers that do have the information.

Step 5: Ask the authoritative DNS servers

The TLD nameservers review the next part of our request — www.dyn.com — and direct our query to the nameservers responsible for this specific domain. These authoritative nameservers are responsible for knowing all the information about a specific domain, which are stored in DNS records. There are many types of records, which each contain a different kind of information. In this example, we want to know the IP address for www.dyndns.com, so we ask the authoritative nameserver for the Address Record (A).

Step 6: Retrieve the record

The recursive server retrieves the A record for dyn.com from the authoritative nameservers and stores the record in its local cache. If anyone else requests the host record for dyn.com, the recursive servers will already have the answer and will not need to go through the lookup process again. All records have a time-to-live value, which is like an expiration date. After a while, the recursive server will need to ask for a new copy of the record to make sure the information doesn’t become out-of-date.

Step 7: Receive the answer

Armed with the answer, recursive server returns the A record back to your computer. Your computer stores the record in its cache, reads the IP address from the record, then passes this information to your browser. The browser then opens a connection to the webserver and receives the website.

This entire process, from start to finish, takes only milliseconds to complete.

 

 

 

A single DNS server can be a primary server for one of its configured zones, and a secondary server for another zone.

The information is kept in a primary zone file is stored in the registry, and also a copy of the zone information is located in the path windows\system32\dns by default.

 

Tools for Trouble shooting DNS:

DNS Console, NSLOOKUP, DNSCMD, IPCONFIG, Logs, PM.

Where does a Host File Reside?
c:\windows\system32\drivers\etc.

 

What is scavenging?
Finding and deleting unwanted records.

By default, aging and scavenging of resource records is disabled.

 

How to enable Dynamic updates in DNS?
Start>Program>Admin tools> DNS >Zone properties.

Standard primary and standard secondary zone information stored in txt file format (Location -c: \systemroot\system32\dns

Active directory integrated DNS information stored in NTDS.DIT File

Standard primary and standard secondary zone are less secure but active directory integrated DNS is more secure.

 

DNS server Backup and restoration:

Mycomputer\HKEY_LOCAL_MACHINE\SYSTEM\Currentconsoleset\Services\DNS

%systemroot%\system32\dns

 

 

DNS Refresh Interval 15 Minutes

Retry Interval                  10 Minutes

Expires after                   1 day

Minimum Default TTL 1 Hour

 

DNS Commands:

ipconfig / all –                       Display full configuration information.

ipconfig /flushdns  - purges the DNS resolver cache.

ipconfig /registerdns  -        Refresh all DHCP leases and reregister DNS names.

ipconfig /displaydns –          Display the content of the DNS resolver cache.

ipconfig /all  -                        Display full configuration information

ipconfig / renew –                Renew the IP address for the specified adapter.

ipconfig /release –                Release the IP address for the  specified adapter.

Ipconfig / Showclassid –      Displays all DHCP class IDs allowed for the adapter.

Ipconfig / setclassid –           modifies the DHCP class ID.

Dnscmd /clearcache

Dnsmgmt.msc,

Net stop DNS

Net start DNS

Netdiag /fix (Only foe DC - NetDiag is a command-line, diagnostic tool that helps isolate.networking and connectivity problems by performing a series of tests to determine the state of your network client and whether it is functional.)

NslookupSet type=nsType fqdn

 

Use support tools:

C:\dnslist /d yahoo.com /test_tcp

DNS Round robin:

Active Directory integrated method:

Primary server scenario:

Secondary Server Scenario:

 

 

Query: Query is a request to find an address of the DNS

There are 2 types of queries.

1. Recursive queries
2. Iterative queries

Recursive Queries: When a client start a query, query is passed onto local DNS for resolution if a query cannot find the solution then the DNS on behalf of client forwards the query to another DNS, And to another DNS and so on until it finds the mapping information or an answer.

Iterative Query: Query raised by the client to the DNS. If the DNS cannot resolve it sends a negative response to the client, then the client has to contact another DNS and so on.
In this case the DNS is not forwarding the query but the client itself is contacting other DNS.

--------------------------------

DNS: Types of attack

1.  Attacks not specifically directed at the DNS

Some attacks may look to exploit the administrative side of domain names rather than directly targeting the infrastructures and DNS servers:

Cybersquatting involves registering a domain name with the deliberate intent of undermining and profiting from a third party’s rights or in some way harming that third party. There are many cybersquatting techniques, and the general aim is to steal the victim’s identity and/or divert traffic away from the victim’s website.

Name-jacking" or theft by appropriating the domain name (updating the holder’s field and/or contacts) or taking control by technical means to divert traffic, such as by modifying the name servers hosting the site.

Other non-DNS attacks are "social" (convincing a careless employee to give their password to a stranger) or involve such techniques as SQL injections, which were used to attack several registries and registrars early 2009

2.Attacks specifically directed at the DNS

Attacks on DNS infrastructures are mainly technical, using mass attacks or techniques that corrupt the information exchanged between the resolvers and DNS servers:

DNS cache poisoning dupes the resolver into believing that the "pirate" server is an authoritative server in place of the original server. These attacks capture and divert queries to another website unbeknownst to users, the danger being that users might divulge personal data on what they believe to be a bona fide site. The "Kaminsky flaw" discovered during the summer of 2008 is one such attack that poisons DNS resolvers.

Denial of service (DoS) attacks are attempts to make a given service impossible or very hard to access. Attacks sometimes use brute force (saturating servers by flooding them with simultaneous queries) or go for a more subtle approach by exhausting a rare resource on the server. Attacks made against the DNS root system in February 2007 were mainly DoS attacks.

Distributed denial of service (DDoS) attacks are an elaborate form of DoS that involve thousands of computers generally as part of a botnet or robot network: a network of zombie computers that the attacker commandeers from their unwitting owners by spreading malware from one machine to another.

Reflected attacks send thousands of requests with the victim’s name as the source address. When recipients answer, all replies converge on the official sender, whose infrastructures are then affected

Reflective amplification DoS: if the size of the answer is larger than the question, an amplification effect is caused. The same technique as reflected attacks is used, except that the difference in weight between the answer and question amplifies the extent of the attack. A variant can exploit the protective measures in place, which need time to decode the long replies; this may slow down query resolution.

Fast flux: In addition to falsifying their IP address, attackers can hide their identity by using this technique, which relies on fast-changing location-related information to conceal where the attack is coming from. Variants exist, such as single flux (constantly changing the address of the web server) and double flux (constantly changing the address of the web server and the names of the DNS servers).

A real-life example:

The February 2007 attack against the root system

The following chart highlights the impact of the attack on 6 February 2007 against 13 servers hosting the DNS root system.

The chart clearly shows that some servers are much more affected than others, especially M, L and G. However, they only form a minority with the strong impact registered between 10 am and 4 pm, following which resolution times progressively return to normal. Despite the resources ploughed into the attack, the repercussions were actually not critical, since most web users around the world did not experience any poor service performance.

Although it is relatively easy to affect the DNS or server performance, trying to prolong the attack for any length of time without being spotted is much harder. As a result, infrastructures are designed to sustain considerable peak loads in activity over short periods.

The DNS system may be exposed to attacks, but on the whole it is robustly designed, not only capable of supporting a more intensive and varied use of the Internet, but also withstanding mass attacks. This does not mean that better security systems are not required, since the individual measures taken by each player could be easier to break than the DNS system as a whole. Any company on the web must ensure that its presence is not unwittingly built on overly fragile foundations.

Other real-life example:

Attack against a Brazilian bank in April 2009 (the only well-documented case of a Kaminsky attack)

Cache-poisoning attack snares top Brazilian bank

Google Adsense spoofed

Posted in Security, 22nd April 2009 00:32 GMT

One of Brazil's biggest banks has suffered an attack that redirected its customers to fraudulent websites that attempted to steal passwords and install malware, according to an unconfirmed report.

According to this Google translation of an article penned in Portuguese, the redirection of Bradesco was the result of what's known as a cache poisoning attack on Brazilian internet service provider NET Virtua.

DNS cache poisoning attacks exploit weaknesses in the internet's domain name system. ISPs that haven't patched their systems against the vulnerabilities are susceptible to attacks that replace the legitimate IP address of a given website with a fraudulent number. End users who rely on the lookup service are then taken to malicious websites even though they typed the correct domain name into their browser.

"That's pretty serious when you're talking about a banking organization," said Paul Ferguson, a security researcher with anti-virus provider Trend Micro. "If people are trying to log in to their account and they get rejected, they'll try again and again with the same user name and password."

DNS cache poisoning has been around since the mid 1990s, when researchers discovered that DNS resolvers could be flooded with spoofed IP addresses for sensitive websites. The servers store the incorrect information for hours or days at a time, so the attack has the potential to send large numbers of end users to fraudulent websites that install malware or masquerade as a bank or other trusted destination and steal sensitive account information.

In 1998, Eugene E. Kashpureff admitted to federal US authorities that on two occasions the previous year he used cache poisoning to divert traffic intended for InterNIC to AlterNIC, a competing domain name registration site that he owned.

Makers of DNS software were largely able to prevent the attacks by adding pseudo-random transaction ID numbers to lookup requests that must be included in any responses. Then, last year, IOActive researcher Dan Kaminskyrevealed a new way to poison DNS caches, touching off a mad scramble by the world's ISPs to fix the vulnerability before it was exploited.

The article from Globo.com cited a Bradesco representative who said that about 1 percent of the bank's customers were affected by the attack. It went on to suggest that customers who were paying attention would have noticed Bradesco's secure sockets layer certificate generated an error when they were redirected to the fraudulent login page.

Interestingly, it also said that a domain used for Google Adsense was redirected to a site that used malicious Javascript to install malware redirected machines. The attacks have since been resolved, the article stated.

It's still not clear exactly how the caches were tainted. Representatives for the ISP and the bank hadn't responded to requests for comment at time of publication. ®

Various types of DNS attacks:

DNS cache poisonings foist malware attacks on Brazilians (7 November 2011)

Comcast (finally) brings security extensions to DNS (24 February 2010)

Bug puts net's most popular DNS app in Bind (24 November 2009)

RSA Turks hijack Kiwi MSN via DNS cracks (22 April 2009)

Caching bugs exposed in second biggest DNS server (28 February 2009)

DNS inventor blames wrangling for insecure interweb (12 November 2008)

One in ten DNS servers still vulnerable to poisoning (10 November 2008)

Patched DNS servers still vulnerable to cache poisoning (11 August 2008)

DNS lords expose netizens to 'poisoning' (15 April 2008)

Most DNS servers 'wide open' to attack (24 October 2005)

 

https://technet.microsoft.com/en-us/library/cc771677.aspx

 

http://blogs.technet.com/b/networking/archive/2008/03/19/don-t-be-afraid-of-dns-scavenging-just-be-patient.aspx

 

http://www.youtube.com/playlist?annotation_id=annotation_295348&feature=iv&list=PLC9871494B7C83582&src_vid=-92V95F-Hsg

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

https://pubs.vmware.com/vsphere-51/index.jsp#com.vmware.vsphere.solutions.doc/GUID-0A264828-3933-4F4F-82D7-B5006A90CDBA.html

http://www.iis.net/configreference/system.applicationhost/sites/site/ftpserver/logfile

https://support.microsoft.com/en-us/kb/255905

 

http://www.tracker-software.com/knowledgebase/373-How-do-I-distribute-software-through-a-GPO

 

 

https://support.microsoft.com/en-us/kb/323428

http://blogs.technet.com/b/nepapfe/archive/2013/03/01/it-s-simple-time-configuration-in-active-directory.aspx

http://www.idg.tv/video/30228/lock-trend.html?utm_source=taboola&utm_medium=AXmodule

 

http://www.msserverpro.com/configuring-dns-backup-and-recovery-in-windows-server-2012-r2/

https://technet.microsoft.com/en-us/library/cc738755(WS.10).aspx