Skip to main content



Conventional name resolution transforms a DNS name into an IP address. At the highest level, this process can be considered to have two phases. In the first phase, we locate a DNS name server that has the information we need: the address that goes with a particular name. In the second phase, we send that server a request containing the name we want to resolve, and it sends back the address required.

Absolute (Fully-Qualified) and Relative (Partially-Qualified) Domain Name Specifications

We simply start at the root node and follow the sequence of subdomains down to the node in question, listing each level's labels separated by a dot. When we do this, we get single name that uniquely identifies a particular device.

Fully-Qualified Domain Names (FQDNs)
Technically, if a top-level domain “A” contains a subdomain “B” that in turn contains subdomain “C”, the full domain name for “C” is “C.B.A.”. This is called the fully-qualified domain name (FQDN) for the node. Here, the word “qualified” is synonymous with “specified”. The domain name “C.B.A.” is fully-qualified because it gives the full location of the specific domain that bears its name within the whole DNS name space.

Fully-qualified domain names are also sometimes called absolute domain names. This term reflects the fact that one can refer unambiguously to the name of any device using its FQDN from any other portion of the name space. Using the FQDN always instructs the person or software interpreting the name to start at the root and then follow the sequence of domain labels from right to left, going top to bottom within the tree.

Partially-Qualified Domain Names (PQDNs)
There are also some situations in which we may refer to a device using an incomplete name specification. This is called a partially-qualified domain name (PQDN), which means that the name only partially specifies the location of the device. By definition, a PQDN is ambiguous, because it doesn't give the full path to the domain. Thus, one can only use a PQDN within the context of a particular parent domain, whose absolute domain name is known. We can then find the FQDN of a partially-specified domain name by appending the partial name to the absolute name of the parent domain. For example, if we have the PQDN “Z” within the context of the FQDN “Y.X.”, we know the FQDN for “Z” is “Z.Y.X.”

Why bother with this? The answer is convenience. An administrator for a domain can use relative names as a short-hand to refer to devices or subdomains without having to repeat the entire full name. For example, suppose you are in charge of the computer science department at the Thapar University. The domain name for the department as a whole is “” and the individual hosts you manage are named after fruit.

In the DNS files you maintain you could refer to each device by its FQDN every time; for example, “”, “” and so on. But it's easier to tell the software “if you see a name that is not fully qualified, assume it is in the ‘’ domain”. Then you can just call the machines “apple”, “mango”, etc. Whenever the DNS software sees a PQDN such as “kiwi” it will treat it as “”.

Key Concept: A fully-qualified domain name (FQDN) is a complete domain name that uniquely identifies a node in the DNS name space by giving the full path of labels from the root of the tree down to that node. It defines the absolute location of a domain. In contrast, a partially-qualified domain name (PQDN) only specifies a portion of a domain name. It is a relative name that has meaning only within a particular context; the partial name must be interpreted within that context to fully identify the node.

Differentiating FQDNs and PQDNs in DNS
Trailing dot for the null root domain is usually omitted. This is true in common parlance, and when users specify a domain name in an application; you don't use the trailing dot in your Web browser for instance,but browser do it automatically while sending request. However, within DNS itself, the dot is used to clearly distinguish a FQDN from a PQDN within DNS master files. This allows us to use both FQDNs and PQDNs together. In the example above, “apple” would refer to “”, but “” would refer to the fully-qualified domain name for Apple Computer, Inc. You have to be careful about watching the dots here, because “” (no trailing period) would be a PQDN, and would refer to “”, and not the domain of Apple Computer.


Popular posts from this blog

Hacking Windows 10 UWP App: DLL Injection & common Vulnerabilities

I recently started working on  widows 10 Apps( Apps not Applications) security. Before diving deep in hacking terms lets try to understand what's new in Windows 10 UWP( Universal Platform) as compared to old Apps. Lets begin with how apps actually work on windows 10(desktop/tablet). Now windows 10 comes with a container only for running apps inside the isolated environment. By default, /APPCONTAINER(Linker Flag) is off. This option modifies an executable to indicate whether the app must be run in the appcontainer process-isolation environment. Specify /APPCONTAINER for an app that must run in the appcontainer environment—for example, a Windows Store app. (The option is set automatically in Visual Studio when you create a Windows Store app from a template.) For a desktop app, specify /APPCONTAINER:NO or just omit the option. The /APPCONTAINER option was introduced in Windows 8. Now there is no registry entry concept for these app in the System HIVE rather they install they own hiv

Animated Cursor Vulnerability

Step1: create two file on attacker side 1) default index.html and 2) cursor file to load Now save the proof of concept in a txt file(cursor.txt). use above command to cut down the hex part from proof of concept and paste it in buffer.ani Step2 :upload the above two files in your apache webserver.  Step3: Try to open index.html from window-xp and analyse the behavior of IE using ollydgb in order to find the offset address where EIP will get over written. Attach IE in ollydgb and put malicious url in it. As we can see now that EIP is overwritten with 42424242 that means this place is our offset. Now we will put the address of jump instruction in place of 42424242 which we will get from user32.dll by searching for command JUMP DWORD [EBX],now we jumped at ebx because it contain the malicious .ani file address. Just go into view=>executable=>user32.dll , press enter. Now try to find a jump [ebx] instruction in user32.dll by pressing ctrl

Assignment 01(Enroll TO Offensive-Security Course)

Steps 1:download the page. 2:open fc4.js in your favourite editor and add following lines in it or just replace it with vode given below. 3:then open the download html file in browser and fill the form with your email and a garbage value string. 4:thats it? it will show you the real security string?? yeah but  ...theirs another challenge waiting for you ... :D function fc4me(srvstr) {    if(! || !document.pleazfc4me.securitystring.value) {       alert("Please fill in all the required fields!");       return false;    }    else {       document.pleazfc4me.submit();     }    var t=hexMD5("\x74\x72\x79\x68\x61\x72\x64\x65\x72"+srvstr) alert(t) document.write(t) } Finally Got In :-)