DNSSEC (A Protocol towards securing the Internet Infrastructure)
Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Computer Science Clay
Active In SP

Posts: 712
Joined: Jan 2009
14-06-2009, 12:51 AM

Seminar Report On
(A Protocol towards securing the Internet Infrastructure)
Submitted by
In partial fulfillment of requirements of the award of
Master of Technology (M-Tech)
Software engineering
COCHIN-682022Page 2

This is to certify that the seminar and presentation report entitled DNSSEC “ A Protocol towards securing the
Internet Infrastructure submitted by Saheer H, in partial fulfillment of the requirements of the
award of M-Tech Degree in Software Engineering, Cochin University of Science and Technology, is a
bonafide record of the seminar and presentation presented by him during the academic year 2008-2009.
Dr. Sumam Mary Idicula
Dr. Paulose Jacob
Course Coordinator
Head of the Department
Place: Cochin
Date: 10-11-08
2Page 3

I express my deep sense of gratitude to D.r. K.Poulose Jacob, HOD, Department of Computer
Science, CUSAT, for providing an opportunity to present this seminar and presentation.
My profound gratitude to Dr. Sumam Mary Idicula for her valuable guidance and timely support
she offered. I also express my sincere thanks to all other teaching staff especially, Mr.Santhosh
Kumar and all non-teaching staff, for their generous help and guidance. I also express my
friendly gratitude to my batch mates for their kind co-operation and good wishes.
Finally, I thank the Almighty, without whose blessings nothing starts good or ends well.
3Page 4

Unlike spam, worms, viruses, and phishing”all of which confront end users directly”
infrastructure attacks occur outside their normal frame of reference and control. But attacks on the
Domain Name System (DNS), an engine of the Internet infrastructure, appear to be increasing in length
and severity, affecting DNS information associated with financial services institutions, Internet service
providers, and major corporations in the travel, health, technology, and media/ entertainment sectors.
Such attacks can result in, say, dropped or intercepted email messages or users unknowingly redirected
to fraudulent sites where they inadvertently hand over personal information.
The ultimate casualty in a serious infrastructure attack is public trust. The Internet technical
community has responded to threats to the DNS infrastructure by developing the DNS Security
Extensions (DNSSEC) protocol standard. DNSSEC-enabled systems run primarily in only a few early-
adoption and experimental zones.
DNSSEC introduces security at the infrastructure level through a hierarchy of cryptographic
signatures attached to DNS records. In the context of DNSSEC, users are assured that the source of the
data is verifiable as the stated source, and the mapping of a name to an IP address is accurate. DNSSEC
- capable name servers also provide denial of- existence; that is, they tell a user that a name does not
4Page 5

5Page 6

Attacks on the Domain Name System, an engine of the internet infrastructure affect DNS
information associated with ISPs, financial services institutions and other primary services.
Such attacks can result in dropped or intercepted email messages or users unknowingly
redirected to fraudulent sites.
Ultimate causality in a serious infrastructure attack is public trust.
The Internet technical community has responded to threats to the DNS infrastructure by
developing the DNS Security Extensions (DNSSEC) protocol standard. DNSSEC introduces
security at the infrastructure level through a hierarchy of cryptographic signatures attached to
DNS records. In the context of DNSSEC, users are assured that the source of the data is
verifiable as the stated source, and the mapping of a name to an IP address is accurate.
6Page 7

Domain Name System can be described as an Internet service that translates domain names
into IP addresses. Because domain names are alphabetic, they're easier to remember. The
Internet however, is really based on IP addresses. Every time we use a domain name, therefore,
a DNS service must translate the name into the corresponding IP address.
The DNS was invented in 1983, shortly after TCP/IP was deployed. With the older system,
each computer on the network retrieved a file called HOSTS from a computer at SRI (now SRI
International). The HOSTS file mapped numerical addresses to names. A hosts file still exists
on most modern operating systems, either by default or through configuration, and allows users
to specify an IP address (eg. to use for a hostname (eg. http://www.example.net)
without checking DNS.
Eg: in Windows XP/2000 the hosts file resides in /windows/system32/drivers/etc/
in Windows 9X/Me - the hosts file resides in /windows/
in linux - the hosts file resides in /etc
Many of the so-called Web accelerators that are available as freeware or as part of commercial
packages make use of the hosts file. The idea is that if you can resolve IP addresses on your
own computer instead of waiting for a DNS server to do it, you can cut the time required to
find a Web site. If you have a slow connection or if the servers are very busy, you might save a
second or two off the connection time of your most used sites. Or on the rare occasion when
7Page 8

DNS servers are down, you might even be able to continue to use the Web. Perhaps the biggest
use of the hosts file is to block sites that are regarded as undesirable or to block ads. This done
by assigning the loopback IP to an URL that you wish blocked. Thus an entry might
be: http://www.unwanted.com (without quotes). Any request for such an IP address just
gets sent right back to your own computer.
However, there are several drawbacks to using a hosts file. The most obvious is its size
limitation. Only a small subset of all the registered Web addresses will be in a hosts file. This
can be useful in speeding up your homepage and other pages that you visit regularly but many
sites will still need the DNS server. Of course, many people visit only a relatively small
number of sites on any regular basis and the fractional seconds saved each time may be
attractive to them. Note that a hosts file that is much over 100 KB can actually slow up
browsing in Windows XP unless the service "DNS Client" is set to manual start. (Managing
services is discussed on another page.) In fact Windows XP SP2 is said to ignore the hosts file
entirely if the DNS Client service is running.
Another problem is that the numerical IP corresponding to a particular URL can change. This
can cause unexpected "The page cannot be displayed" error messages and inability to connect
to sites. Thus, it is necessary to make sure that the hosts file is kept up-to-date.
The growth of networking required a more scalable system that recorded a change in a host's
address in one place only. Other hosts would learn about the change dynamically through a
notification system, thus completing a globally accessible network of all hosts' names and their
associated IP Addresses.
At the request of Jon Postel, Dr.Paul V. Mockapetris invented the Domain Name system in
1983 and wrote the first implementation. The original specifications appear in RFC 882 and
RFC 883. In November 1987, the publication of RFC 1034 and RFC 1035 updated the DNS
specification and made RFC 882 and RFC 883 obsolete. Several more-recent RFCs have
proposed various extensions to the core DNS protocols.
8Page 9

The Domain Name System (abbreviated DNS) (Also referred as Domain Name Service or
Domain Name Server) is an Internet directory service. DNS is how domain names are
translated into IP addresses, and DNS also controls email delivery. If your computer cannot
access DNS, your web browser will not be able to find web sites, and you will not be able to
receive or send email.
An often-used analogy to explain the Domain Name System is that it serves as the "phone
book" for the Internet by translating human-friendly computer hostnames into IP addresses. For
example, http://www.example.com translates to ; howstuffworks.com translates to ;
cusat.ac.in translates to
Internet domain names are easier to remember than IP addresses such as (IPv4)
or 2001:db8:1f70::999:de8:7648:6e8 (IPv6). People take advantage of this when they recite
meaningful URLs and e-mail addresses without having to know how the machine will actually
locate them.
Domain Name System can be described as an Internet service that translates domain names
into IP addresses. Because domain names are alphabetic, they're easier to remember. The
Internet however, is really based on IP addresses. Every time we use a domain name, therefore,
a DNS service must translate the name into the corresponding IP address.
The DNS system consists of three components:
¢ Domain Name Space and Resource Records (RRs)
¢ Name Servers
¢ Resolvers
9Page 10

Domain Name Space and Resource Records (RRs)
The naming system on which DNS is based is a hierarchical and logical tree structure called
the domain name space .i.e. The domain name space consists of a tree of domain names. Only
one node or leaf in the tree has zero or more resource records, which hold information
associated with the domain name. The tree sub-divides into zones beginning at the root zone. A
DNS zone consists of a collection of connected nodes authoritatively served by an
authoritative nameserver. (Note that a single nameserver can host several zones.)
Administrative responsibility over any zone may be divided, thereby creating additional zones.
Authority is said to be delegated for a portion of the old space, usually in form of sub-domains,
to another nameserver and administrative entity. The old zone ceases to be authoritative for the
new zone.
Figure 1 : Domain Name Space and Resource Records
10Page 11

Name Servers
Name Servers contain information about the domainâ„¢s tree structure. The Domain Name
System is maintained by a distributed database system, which uses the client-server model. The
nodes of this database are the name servers. Each domain or subdomain has one or more
authoritative DNS servers that publish information about that domain and the name servers of
any domains subordinate to it. The top of the hierarchy is served by the root nameservers: the
servers to query when looking up (resolving) a top-level domain name (TLD).
Resolvers obtain information from name servers in response to queries from a client. The
client-side of the DNS is called a DNS resolver. It is responsible for initiating and sequencing
the queries that ultimately lead to a full resolution (translation) of the resource sought, e.g.,
translation of a domain name into an IP address.A DNS query may be either a recursive query
or a non-recursive query:
A non-recursive query is one in which the DNS server may provide a partial answer to the
query (or give an error).
A recursive query is one where the DNS server will fully answer the query (or give an
error). DNS servers are not required to support recursive queries.
The resolver (or another DNS server acting recursively on behalf of the resolver) negotiates use
of recursive service using bits in the query headers.Resolving usually entails iterating through
several name servers to find the needed information. However, some resolvers function
simplistically and can communicate only with a single name server. These simple resolvers
rely on a recursive query to a recursive name server to perform the work of finding information
for them.
11Page 12

Figure 2: Example DNS Tree
At the top of the inverted tree structure is the root (see Figure 1). Below the root are the top-
level domains (TLDs), which are divided into two primary categories: country code TLDs,
the familiar .uk, .se, .jp, and so on; and generic TLDs (gTLDs), the familiar .com, .org, .net,
and so on. A special TLD, .arpa, is reserved for infrastructure purposes. TLDs are further
subdivided into subdomains: example.org, example.com, and so on.Further subdivision of
domains occurs frequently, particularly in complex organizations, like corporations and
universities. Indeed, many of us have email addresses that include the three-level name
cs.nameofinstitution.edu or library.nameofinstitution.edu.
Eg : cs.cusat.ac.in ; which is a 4 level domain
In theory, this subdivision can go down 127 levels.But domain with more than 4 levels are rare.
The process by which these subdivisions take place is called delegation. The DNS structure
of domains and sub domains is typically expressed in one of two metaphors: leaf-and-node and
parent-child. Here, we use the parent-child metaphor to focus on the hierarchical relationships
and flow of information.
In a Logical view DNS can be considered as series of records of various types that are stored in
a hierarchical, distributed database
“ for example, the A record type provides the IP address
In an Administrative view DNS can be considered as a set of organizational relationships,
12Page 13

responsibilities, and authorities.These two views”logical and administrative”converge in the
key concept of the zone, which is managed as an independent administrative entity. This
entity is responsible for a zone file containing the subset of DNS data about that zone and the
mapping of names to IP addresses and/or delegations (such as from parent to child or parent to
children), along with other information.
Operational Perspective
From an operational perspective, DNS transactions consist of a series of queries and responses
between two programs: resolvers and name servers. The resolver poses queries on behalf of a
client and returns the desired information. The name server contains information about the
names and IP addresses in its zone and responds to queries from resolvers.
In practice, what appears to be a single transaction (such as tell me the IP address for this
name) is more complicated (see Figure 3). The userâ„¢s program, perhaps a Web browser or an
email client, contacts a stub resolver containing a list of recursive or resolving name server
addresses. The stub resolver contacts a local recursive or resolving name server that either
knows which name server has the information or redirects the query up to a zone at the next
level. If the parent zone does not have the information, or the IP address, the recursive name
server begins a search at the top of the hierarchy, or the root, querying it and then querying
down the tree through the successive zones and associated name servers until it obtains either
the information or an error.
Figure 3 : DNS Query and Response
13Page 14

This description of how the DNS operates is necessarily a highly abstracted view. In practice,
there are multiple configurations to replicate and cache the information throughout the system.
For example, a successful query rarely reaches the root. The answer is typically obtained from
a caching name server lower down in the tree, perhaps at a userâ„¢s Internet service provider.
In practice The process of DNS Query involves,
1. An application that calls for a name resolution like Internet Explorer.
2. The DNS Client installed on the computer.
3. The local DNS server.
4. The various DNS servers on the Internet.
A simple example of accessing a website on the Internet will explain the process the process of
DNS query.
1. When a user types in a website address in Internet Explorer say http://www.wikepedia.org and
clicks GO, Internet Explorer does not directly understand the domain name and wouldnâ„¢t know
where to go. Hence, picks up the website name http://www.wikepedia.org and pass it onto the DNS
client [resolver] to resolve the IP Address of the website.
2. The DNS Client also known as the DNS Resolver will try to resolve the IP address from its
local resources which includes the Name to Address mappings in the HOSTS file and its local
DNS cache. Normally, most of the DNS clients are capable of caching the previous DNS query
results. The DNS resolver will use these available local resources and if it canâ„¢t find the IP
Address will then query a DNS server that it knows to for the IP Address.
3. The DNS server will directly answer the query if it is the authoritative server for the
particular domain (here http://www.wikepedia.org) else check its local cache of the previous queries.
If it cannot find the IP Address, then it will query the DNS servers on the Internet.
14Page 15

The process it follows in contacting various DNS servers on the internet requires a bit of
understanding of how it looks at the Domain name.
For instance the website address http://www.wikepedia.org will be looked at by the DNS server as
NOTE: Make a note of the "." before org.
The above indicates that
. is the ROOT DOMAIN.
org is Sub-domain for the ROOT Domain.
wikepedia is a sub-domain for .org
www is either a node (no further sub-domains) or further a sub-domain for "wikepedia".
4. Now, the DNS Server will query one of the root servers requesting for a list of Authoritative
servers for the .org domain. The Root server will respond with the list of servers addresses
hosting the org domain.
5. The DNS server will pick one from the list and contact that server for a list of Authoritative
servers for the wikepedia domain. The server will respond with the details of the Authoritative
server for the wikepedia domain.
6. Now, that the DNS server knows the Authoritative server address for the wikepedia.org
domain and hence will directly contact the server for the IP Address of the host www which
belongs to wikepedia.org (called as A Record). The Authoritative DNS server will then
respond with the IP Address or a list of IP Address (if more than one server hosts the website
http://www.wikepedia.org) for http://www.wikepedia.org.
7. This the DNS server then returns back to the DNS client which again passes it onto the DNS
application which initially requested the IP Address information, Internet Explorer in this case.
15Page 16

8. The Application then knows where to go to fetch the website. How it fetches the correct
page etc is being taken care by the HTTP protocol using host headers etc.,
That is how a DNS Query works in its simplest terms. In any of the above when we query for a
non-existent domain or a domain or the server that hosts the domain is not available will return
an error.The process of quering the Internet DNS servers is depicted in the Figure 4.
Figure 4 : Query for http://www.wikepedia.org
So in practice, as said earlier, a successful query rarely reaches the root. The answer is typically
obtained from a caching name server lower down in the tree, perhaps at a userâ„¢s Internet
service provider. These caches can pose a potential vulnerability, since an attacker may be able
to tamper with them by inserting false information in the DNS records, a strategy known as
cache poisoning.
DNSSEC is intended to detect such attacks, enabling users and applications to defend against
their consequences. Cache poisoning is but one kind of threat to the DNS; others are explained
in RFC 3833. Although threats vary, they share the characteristic that they exploit
vulnerabilities in the DNS and result in responses that cannot or should not be trusted.
16Page 17

DNSSEC is not a security panacea. It is not a robust defense against all forms of attack against DNS
servers and clients. DNSSEC is not an exercise in encryption of DNS data.
DNSSEC introduces security at the infrastructure level through the definition of additional
DNS Resource Records that can be used by DNS clients to validate the authenticity of a DNS
response, the data integrity of the DNS response, and where the response indicates no such
domain or resource type exists, this negative information can also be authenticated.
In other words, if an attacker attempts to create a DNS response that has been altered from the
original authentic response in some fashion, and the attacker then attempts to pass the response
off as an authentic response, then a DNSSEC-aware DNS client should be able to detect the
fact that the response has been altered and that the response does not correspond to the
authoritative DNS information for that zone. In other words, DNSSEC is intended to protect
DNS clients from forged DNS data. This protection does not eliminate the potential to inject
false data into a DNS resolution transaction, but it adds additional information to DNS
responses to allow a client to check that the response is authentic and complete.
DNSSEC achieves this with a hierarchy of cryptographic signatures attached to DNS records.
With DNSSEC, users are assured that the source of the data is verifiable as the stated source,
and the mapping of a name to an IP address is accurate.
With DNSSEC a zone administrator "digitally signs" a Resource Record Set (RRSet), and
publishes this digital signature, along with the zone administrator's public key, in the DNS. In
checking a DNS response, a DNSSEC client can retrieve the related RRset digital signature and
then check this signature using the public key against the locally calculated hash value of the
RRset, and then validate the zone administrator's public key against a hierarchical signature
path that leads to a point of trust. If all these checks succeed than the client has some
confidence that the DNS response was complete and authentic.
17Page 18

DNSSEC implies different actions for different roles.
For a DNS zone administrator:
DNSSEC is essentially the process of signing RRSets with a private key, publishing these
signatures for each RRset in the zone file, and publishing the zone public key in the zone file.
In addition the zone administrator has to get the zone's public key signed by the parent zone
For a DNS client:
DNSSEC is the ability to perform a number of additional checks on a DNS response that can
result in greater trust in the authenticity and accuracy of the DNS response.
For the DNS:
DNSSEC essentially represents a number of additional Resource Records that hold digital
signatures of DNS information, as well as key information.
The specification for DNSSEC is available in RFC 1033, RFC 1034, RFC 1035.
DNSSEC Additionals
DNSSEC defines four new DNS resource records (RRs), namely the
4. DS
DNSSEC also calls for new information in the packet header. The information in the header
used by DNSSEC indicates that the response to a query passed checks on the server side.
18Page 19

Every DNSSEC secured DNS zone has an associated private and public key pair, as generated
by the zone's administrator. The private key remains the (closely guarded) secret of the zone
administrator. The associated public key for the zone is published in the zone file in the form of
a DNSKEY resource record.
An example DNSKEY record for the zone example.com is as follows [from RFC4034]:
example.com. 86400 IN DNSKEY 256 3 5 ( AQPSKmynfzW4kyBv015MUG2DeIQ3
aNvv4w== )
The Time to Live (TTL) value is 1 day (86400 seconds). The Flags value is 256, indicating that
this is a Zone Key. The protocol value is the constant value 3. The next field is the public key
algorithm, and the value 5 indicates RSA/SHA1. The RR value is the Base64 encoding of the
public key value.
A "Resource Record set" (RRset) is a collection of RRs in a DNS ZONE that share a common
name, class and type. In DNSSEC RRsets are digitally signed by the zone administrator. This
signature is generated by generating a hash of the RRset, then encrypting the hash using the
zone administrator's private key. For a zone that contains SOA, NS, A, MX, DNSKEY
resource records there are, minimally 5 distinct RRsets, and each RRSET would have its own
RRSIG Resource Record. This implies that the granularity of DNSSEC signing is not that of an
entire zone, but is aligned to a unit of a DNS query response.
An example RRSIG record for the zone example.com is as follows [from RFC4034]:
host.example.com. 86400 IN RRSIG A 5 3 86400 20030322173103 (
20030220173103 2642 example.com.
19Page 20

J5D6fwFm8nN+6pBzeDQfsS3Ap3o= )
The first four fields specify the owner name, TTL, Class, and RR type (RRSIG). The next field
is the Type Covered field, and the value of "A" indicates that this is a signing of the A RRs for
"host.example.com". next field is the signing algorithm, and the value of 5 indicates that this is
signed using RSA/SHA1. The value 3 is the number of Labels in the original owner name. The
value 86400 in the RRSIG RDATA is the original TTL value for the covered A RRset.
20030322173103 and 20030220173103 are the expiration and inception dates, indicating that
the RRset signature was created on 17:31:03 20/02/2003, and the signature expires at 17:31:03
22/03/2003. The key tag is 2642 and the signer's name is "example.com." The remainder of the
RR value is the encrypted hash of the RRset.
The DNSKEY and RRSIG records can be used to check the authenticity of a DNS response,
where there is a DNS response, but where there is no authoritative data to return then
authentication requires additional information.
The NSEC RR can be considered as a "gap spanning record" for authentication purposes. The
entire zone file is ordered in a canonical form, and then NSEC RRs are added to cover the
"gap". If the zone contained the names "alpha" and "beta", then there would be a NSEC RR for
alpha, and the RR value would be beta, indicating that there are no defined named that lie
between "alpha" and "beta". In addition, the NSEC record defines the set of RR types for this
domain name. Continuing the example, the NSEC record for "alpha", would have as a value
field the enumeration of the RR types that are defined for "alpha".
In response to a query, if the name does not exist in the zone file, or the RR type does not exist
for the name in question, then the NSEC record is returned as authenticatable evidence that the
name, or the RR type does not exist.
20Page 21

The reason for this form of spanning data, as distinct from a more generic response of "no such
name", is that the latter form of response can be used in a replay attack, falsely claming that a
does not exist, whereas the NSEC record explicitly informs the client of the "gap".
An example NSEC record for the zone example.com is as follows [from RFC4034]:
alfa.example.com. 86400 IN NSEC host.example.com. (
The first four text fields specify the name, TTL, Class, and RR type (NSEC). The entry
host.example.com. is the next authoritative name after alfa.example.com. in canonical order.
The A, MX, RRSIG, NSEC, and TYPE1234 mnemonics indicate that there are A, MX,
RRSIG, NSEC, and TYPE1234 RRsets associated with the name alfa.example.com.
The perennial issue in public key cryptography is that of the means of validation of the public
key. If an attacker manages to intercept all your traffic, signs responses using their own private
key and represents their public key as that of the party you thought you were communicating
with, then how are you to tell that the communication has been corrupted? In public key
cryptography the conventional answer is to find other parties who are willing to attest as to the
validity of a public key, and find yet more parties who are willing to attest as to the validity of
the first group of attesters, and so on until you find a link with a party that you trust. Assuming
that trust is a transitive quantity (always a risky assumption of course), then you can construct a
chain of trust from your trust point to the party whose public key you are attempting to
The issue of validation of the zone public key remains unaddressed with the first three
Resource Record types. An attacker would simply need to supply the DNSKEY and RRSIG
data to match the bogus RRset data in order to make the response look 'authentic'. So we are
back to the same public key validation question - how can a client validate the DNSKEY
The approach adopted by DNSSEC is to use a chain of trust within the hierarchical delegation
structure of the DNS itself. Apart from the root zone, every DNS zone has a parent zone. The
21Page 22

Delegation Signer (DS) RR contains the hash of the public key of the child zone. This record is
signed by the parent zone's private key with a matching RRSIG RR. To validate a zone's
DNSKEY, the associated DS, RRSIG(DS) and DNSKEY of the parent zone is retrieved. The
DS record is validated by using the DNSKEY to encrypt the RRSIG(DS) record, and then
checking that the result matches the DS record. This is the zone public key, according to the
zone's parent. This can be compared to the DNSKEY record of the zone in question. This relies
on the parent zone key, and the question is how can this key be validated? The same process
can be applied here. The process stops when the DNSSEC client encounters a "trusted" key.
The ideal "trust key" would be the DNSKEY of the root zone, but in the absence of such a trust
anchor each DNSSEC client has to configure their trust validation system with known trust
points where there is no parent validation.
An example DS record for the zone example.com is as follows [from RFC4034]:
dskey.example.com. 86400 IN DS 60485 5 1 ( 2BB183AF5F22588179A53B0A
98631FAD1A292118 )
The first four text fields specify the name, TTL, Class, and RR type (DS). Value 60485 is the
key tag for the corresponding "dskey.example.com." DNSKEY RR, and value 5 denotes the
algorithm used by this "dskey.example.com." DNSKEY RR. The value 1 is the algorithm used
to construct the digest, and the rest of the RDATA text is the digest in hexadecimal.
Two dominant Deployment Strategies
1. a process that zone operators initiate for digitally signing their own zones by
employing public-private key pairs
2. a chain of trust between parent and child that enables the system to eventually
become trustworthy.
A zone administrator who wishes to deploy DNSSEC first generates a key pair consisting of a
public key and a private key. The public key is stored in a DNSKEY record, and the private
key is stored safely. The private key is used to digitally sign the records, and the resulting
digital signature is stored in an RRSIG record. Next, a zone operator must generate NSEC
22Page 23

records and, depending on the content of the zone, one or more DS records. This makes
possible the response that no record exists.
If the zone includes delegations, then a DS record must also be added in the parent zone for a
given child. A zone that contains children must include DS records for the children.
A zone that has signed its records and added the NSEC (and, if necessary, the DS) records may
go into business as a self-signed DNSSEC-capable zone, also known as an island of
security. This island contains signed records or is considered a signed zone but is also the
child of a parent that cannot vouch for the authenticity of the childâ„¢s key. The combination of
RRSIG and the childâ„¢s public key in a DNSKEY record allows validation of the source of the
data (see Figure 5). But only the associated private key can be used to sign it in the first place.
Figure 5 : Secure DNS Query and Response (simple case)
Thus, the simplest DNSSEC sequence is to obtain the DNS information queried for, together
with the signature associated with that information (in the RRSIG), and use the public key in
the DNSKEY to perform the validation, proving the signature was made by the holder of the
private key.
However, the power of DNSSEC lies in a second step that allows the signed zone to be
23Page 24

vouched for, preferably by its parent; if not, it is vouched for by another authenticating entity.
Assume for purposes of simplicity that both parent and child are DNSSEC-capable. In this
more powerful DNSSEC sequence, the child has signed a DNSKEY record with the private
part of a second key pair and stored the public key part of that second key pair in a record (the
DS record).The child conveys the DS record to the parent. The parent signs the childâ„¢s DS
record with the private part of the parentâ„¢s key pair, placing the resulting signature in an
RRSIG record associated with the DS record. Any parent may itself be a child (except the
root), and the process is replicated between each child/parent pair. This sequence creates the
chain of trust up to the trust anchor, the starting point in the chain. A DNSSEC-aware
resolver validates the information it receives in response to a query by using the public keys to
check the signed records.
How does DNSSEC work?
When requested by the client, DNSSEC adds additional data to the DNS protocol responses
that provide additional information to allow the DNS client to authenticate the RRset data
response. From the perspective of the protocol transaction between a query agent and an
authoritative name server, the change is the addition of a RRSIG part to the data response
where there is a response that can be generated, and the use of an NSEC RR response, plus its
accompanying RRSIG record if there is no authoritative data to respond to the query. In
addition to an RRSIG response covering the RRset records in the answer section of the DNS
response there is also an RRSIG response covering the records in the authority section and one
or more RRSIG responses relating to records in the additional response section.
The client can take the RRset response and use the algorithm referenced in the RRSIG record
to generate the hash of the data. The RRSIG value can be encrypted using the DNSKEY public
key which will, in effect, decrypt the hash in the RRSIG record. To do this the client must also
have at hand the DNSKEY record for the zone. This operation allows the client to check that
the hash of the RRset data matches the decrypted RRSIG hash.
The DNSKEY would normally be provided as part of the additional section of a DNSSEC
response. If the client has not validated the DNSKEY within some locally defined period, then
the client should also validate the DNSKEY value. This entails verifying the RRSIG record on
24Page 25

the DNSKEY value, using the same procedure as for the RRset validation. However domain
zone key validation also entails the construction of a trust chain back to a trust anchor point. If
this domain key is not already a trust anchor then the client needs to query the parent zone for
the DS record of the child zone, which returns both a public key value and an RRSIG value,
and a DNSKEY RR. This public key needs to be validated using the DNSKEY of the parent
zone. This parent zone public key, in turn, must be validated. This iterative process constructs a
trust chain that, hopefully, leads back to a trust anchor. At that point the DNS response can be
considered to be validated.
Some issues associated with DNSSEC is as follows.
The average size of a DNS response message increases, due to the additional signature
records that are attached to the response. Where the message size exceeds the UDP message
size it will need to set the truncated response flag, causing the query to fall back to the use of
TCP, with its attendant higher overheads in terms of client and server state, and the number of
network messages to manage the TCP connection.
The number of DNS transactions increases due to the requirement to perform additional
queries for zone public key records when constructing trust chains. Even though caching has
some potential to reduce much of this traffic, there is still an additional query load that must be
considered with DNSSEC.
The zone file increases in size due to the addition of the additional DNSEC records. The
major contributors here are the NSEC and RRSIG records, and the zone size will increase. By
what factor depends on what is in the zone file of course, but increases by a factor of up to
seven in sizes have been noted in DNSSEC literature.
The client has to spend additional time validating the signed data and validating the public
key, potentially slowing the resolution process.
The server has to generate new signatures over all RRset changes, which places an
incremental load on the server function.
25Page 26

As noted in RFC3383 DNSSEC is complex to implement, and test bed experience to date
suggests that trivial zone configuration errors or expired keys can cause serious problems for a
DNSSEC-aware resolver.
Other protocols (such as Secure Sockets Layer) do protect both personal privacy and the
integrity of the transmission but are not applicable to store-and forward protocols (such as
DNS, with its caches). DNSSEC fills an important gap, since perfect privacy would be
meaningless if the userâ„¢s transaction is hijacked or diverted during transmission through, say,
cache poisoning. Thus, DNSSEC is part of a suite of security protocols and measures ranging
from those appropriate for individual users on small home office systems up through zone
operators of infrastructure systems.
As DNSSEC capable Zones are added, the system incrementally becomes more secure.Full
Deployment of the Protocol requires global cooperation across myriad entities in both the
public and private sectors, including those known as registries and registrars that provide DNS
services, as well as Internet service providers.
Deploying DNSSEC is a necessary step toward hardening the Internet infrastructure, the base
on which many applications and services depend. The Internet is as widely distributed as it is
precisely because the complexities of its inner workings are largely hidden from end users who
have come to trust it. The challenge is to preserve that trust.
26Page 27

[1] Amy Friedlander, Allison Mankin,W. Douglas Maughan, and Stephen D. Crocker, DNSSEC :
A protocol toward securing the internet infrastructure, Communications of the ACM, Vol. 50,
No.6,pp.44-50,June 2007
[2] http://dns.net/dnsrd/docs/whatis.html
[3] http://dnssec.org/
[4] http://ietf.org/rfc/rfc1034.txt
[5] http://ietf.org/rfc/rfc1035.txt
[6] http://en.wikipedia.org/wiki/Domain_Name_System
Use Search at http://topicideas.net/search.php wisely To Get Information About Project Topic and Seminar ideas with report/source code along pdf and ppt presenaion
Thinking To Register

22-12-2012, 02:00 PM

DNSSEC (A Protocol towards securing the Internet Infrastructure) ppt

Important Note..!

If you are not satisfied with above reply ,..Please


So that we will collect data for you and will made reply to the request....OR try below "QUICK REPLY" box to add a reply to this page
Tagged Pages: dnssec protocol seminar report, tutorial of dnsse a protocol securing toward the internet infrastructure, dnssec internet security protocol latest seminar report, dnssec protol toward secure internet infrastructure, a protocol towards securing the internet infrastructure ppt, dnssec a protocol towards secure internet infrastructure, download seminar report on dnssec,
Popular Searches: dnssec protol toward secure internet infrastructure***port project hydraulic pipe bending machine, dns seminar abstract, dnssec dyndns, securing computer data ppt, eenadu epaper guest login in not working, dccp rtp unicast, dnssec adoption,

Quick Reply
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Possibly Related Threads...
Thread Author Replies Views Last Post
  A TECHNICAL SEMINAR ON 3D INTERNET seminar projects maker 1 711 06-04-2016, 12:37 PM
Last Post: mkaasees
  Wireless Sensor Network Security model using Zero Knowledge Protocol seminar ideas 2 1,413 31-03-2015, 09:08 AM
Last Post: Guest
  seminar report on internet of things jaseelati 0 347 29-01-2015, 04:51 PM
Last Post: jaseelati
  3d internet seminar report jaseelati 0 246 11-12-2014, 02:16 PM
Last Post: jaseelati
  3d internet seminar report jaseelati 0 333 06-12-2014, 04:25 PM
Last Post: jaseelati
  Towards Reliable Data Delivery for Highly Dynamic Mobile Ad Hoc Networks seminar ideas 11 3,912 02-04-2014, 12:50 PM
Last Post: Guest
  Towards Secure and Dependable Storage Services in Cloud Computing FULL REPORT seminar ideas 5 4,112 24-03-2014, 02:51 PM
Last Post: seminar project topic
  Optical Packet Buffers for Backbone Internet Routers pdf seminar projects maker 0 403 28-09-2013, 02:48 PM
Last Post: seminar projects maker
  Open Core Protocol ( OCP ) An Introduction to Interface Specification seminar projects maker 0 522 24-09-2013, 12:29 PM
Last Post: seminar projects maker
Music SILC(Secure Internet Live conferencing) Download The Seminar Report computer science crazy 11 7,191 31-08-2013, 12:20 PM
Last Post: study tips