Practical UNIX Security Full Time Course Work 1

The role and function of Bind/DNS within a distributed network

- From an administration and security perspective

STUDENT NUMBER: xxxxxxxx

Module Code: SY4S04 Module Title: Practical UNIX Security Lecturer: Dr. Andrew Blyth Submission Date: 28th April 2008

Student number: xxxxxxxx

Page 1

I. Abstract
Computers that communicate on the Internet use IP addresses (Internet Protocol addresses) to find the correct system to talk to. An IP address is a 32 bit numerical address that looks like this: 64.233.183.991. Many network system administrators probably read IP addresses as easy as the computers do, but for the average user it is a lot easier to remember and to use addresses like www.google.com. We therefore need a technology that maps the easy-to-remember-human addresses with the IP addresses used by the computers. DNS do just that. Through out this report we will focus on the UNIX implementation of DNS the Berkeley Internet Name Domain (BIND), its role and functions in a distributed network, its security issues from an administrators point of view and we will discuss possible solutions and compare it with other systems.

II. Table of content

I. ABSTRACT II. TABLEOFCONTENT III. INTRODUCTION IV. ANALYSIS A. AFUNCTIONINGSERVICE
B . C . D . I. II. III. E . I. II.

2 2 3 4 4 5 8 10 10 11 14 15 15 18 20 22 22 22

POISONINGTHEDNSCACHE DNSSPOOFINGATTACKS AVOIDINGCACHEPOISONINGANDDNSSPOOFING SPLITDNS DNSSECURITYEXTENSION SECURINGZONETRANSFERS SAFEGUARDINGYOURINFORMATION LOGGINGTHEDATATRANSFERS SECURINGTHEINFORMATION

V. SUMMARYANDCONCLUSIONS VI. REFERENCES

A . B .

BOOKS WEBSITES

J. D. Wegner and Robert Rockell, (2000), Chapter 1, IP Addressing and Subnetting, including IPv6, Syngress Media

Student number: 07238959

Page 2

III. Introduction
The Domain Name System2 was first written in 1983 and one can read about the original specifications in RFC882. DNS is a hierarchical naming scheme that relies on levels of authority. This means that there is no one server that handles all such mappings on the Internet but levels of authority handles requests within their own zone3. The first UNIX implementation of DNS was written in 1984 and was called Berkeley Internet Name Daemon later changed to Berkeley Internet Name Domain, BIND. The BIND servers provide about 80% of all DNS services4. People assume, and rely on, that this technology will do exactly what it is supposed to do, and as long as that is true, everyone is happy. But what happens when it doesnt? In the past we have seen several examples of what can happen when the technology doesnt provide what its supposed to, for instance the East Timor incident5 and several attacks on the root DNS servers6. Throughout this report, I will discuss various vulnerabilities surrounding the configuration and use of BIND / DNS emphasising on poisoning and spoofing7 attacks, securing information and logging data transfers.

Wikipedia contributors. (2008, March 10). Domain Name System. Retrieved 11 March 2008, from: http://en.wikipedia.org/wiki/Domain_name_system 3 th Paul Albitz and Cricket Liu, (2006), Chapter 2, DNS and BIND, 5 Edition, OReilly, section 2.4 4 Jupitermedia Corporation. (2007, December 27). Berkeley Internet Name Domain. Retrieved 11 March 2008, from: http://webopedia.com/TERM/B/Berkeley_Internet_Name_Domain.htm 5 WSWS.ORG. (1999, March 3). Hackers shut down East Timor Internet addresses. Retrieved 12 March 2008, from: http://www.wsws.org/articles/1999/mar1999/hack-m03.shtml 6 ICANN.ORG. (2007, March 1). Root server attack on 6 February 2007. Retrieved 12 March 2008, from: http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf 7 DNS Spoofing is the art of making a DNS entry to point to another IP than its supposed to point to. (2002, January 23). DNS spoofing techniques. Retrieved 12 March 2008, from: http://www.securesphere.net/download/papers/dnsspoof.htm

Student number: xxxxxxxx

Page 3

IV. Analysis
In order for BIND / DNS to function as it should, there are several points we need to consider: We need to ensure that the information our name servers give out are correct. We need to ensure that the information our name servers retrieve from other name servers are correct. We need to ensure that the service in it self is resistant to attempts on gaining unauthorised information or access. We need to ensure that we can transfer data both name-to-IP mappings and zone transfers, in a safe and secure manner. We need to ensure that we can log any data transfer performed to and from our name servers.

a. A functioning service
Various implementations of name servers may do tasks in different ways, but one could divide their tasks in to two major components: Handle request from applications to map domain names to IP addresses Handle request from other name servers to map domain names to IP addresses When a request comes in, the name server does one of three things depending on implementation and configuration: If the IP address for the requested domain is already known (in the DNS Cache) it replies with the address in question. If the IP address for the requested domain is not known, it will forward the request to a name server with authority in a higher hierarchy level (see figure 1). If the requested domain name is invalid or does not exist, it will reply with an error.

Figure 1: Example of a forward lookup query (T.D)

Student number: 07238959

Page 4

There are several tools one can use to perform a query. In Linux, the most used ones are host:

Screen shot 1 And dig

Screen shot 2 Looking at Figure 1, there is five name servers involved in this query, and we need to believe that they do what they are supposed to. Nevertheless, the fact is that there is ways to make any of the five servers spread false information.

b. Poisoning the DNS cache

One of the ways is by poisoning the DNS cache. A name server will save the information it obtains temporarily in case other clients on the network asks for the same domain name.

Student number: xxxxxxxx

Page 5

Figure 2: Example of a DNS cache poisoning (T.D) In Figure 2, an attacker has control over the domain hacker.domain where he has set up a name server. By using tools such as host, dig or nslookup he could then find the name servers for a site and add records of these name servers in his own DNS zone. Of course, these records will have mappings to IP addresses of the attackers own choice. The following steps will now poison your DNS cache: The attacker tricks you into querying his name server for www.hacker.domain for instance by sending you an email with a link.

Screen shot 3 You click on the link, and your DNS will issue a query to ns.hacker.domain. ns.hacker.domain will respond, and in addition to the records for www.hacker.domain, the records of bank.com will be in that response.

Student number: 07238959

Page 6

Screen shot 4

Screen shot 5 Your DNS will cache this information for later use, and hand the information to you upon request. So you type in www.bank.com to make a large transaction, and you end up in www.hacker.domain. Of course you are required to type in username and password, and suddenly the attacker controls your bank account. Daniel J. Bernstein pointed out this problem early8, along with the solution to the problem: Dont allow name servers to cache information other than the ones queried about.

Daniel J. Bernstein: Notes on the Domain Name System. Retrieved 16 March, 2008 from: http://cr.yp.to/djbdns/notes.html#poison

Student number: xxxxxxxx

Page 7

This solution was adopted by BIND in version 4.9.6, but according to Computer Emergency Readiness Team, best practice then was to upgrade to version 8.1.1 if there was no need for the shared object client subroutine library9. As we can see in the screen shot below (Screen shot 6), the Additional Section in this request does not contain any pointers to www.bank.com even though present in the zone file

Screen shot 6

c. DNS spoofing attacks

The effect on the decision to drop all other information than the ones queried about was that attackers needed another way of distributing false records through name servers. The solution was to spoof (impersonate) legitimate responses to queries issued. An ordinary DNS query is sent by way of the UDP protocol to port 53 on the name server. One of the efforts to stop attackers from being able to spoof DNS responses is to use random source port numbers. Since the source port field in an UDP packet is 16 bits10, one should think that the efficiency of this method is higher than it actually is. Also, the DNS packet itself contains a 16-bits transaction ID field to authenticate answers to a query (see Figure 3).

CERT. (1997, August 13) CERT Advisory CA-1997-22 BIND - the Berkeley Internet Name Daemon. Retrieved 18 March, 2008 from: http://www.cert.org/advisories/CA-1997-22.html Wikipedia contributors. (2008, March 18). User Datagram Protocol. Retrieved 18 March 2008, from: http://en.wikipedia.org/wiki/User_Datagram_Protocol
10

Student number: 07238959

Page 8

Figure 3: The structure of a DNS packet11 Unfortunately, the UDP source port is determined when the daemon starts thus can be fairly easy picked up by anyone with a packet sniffer12. In addition to this, the transaction ID was discovered not to be random but sequential, making it possible for attackers to guess the next ID number13.

Figure 4: Example of DNS spoofing (T.D)

Eric Pace Birkholz, (2003), Chapter 8, Special OPS Host and Network Security for Microsoft, UNIX and Oracle, Syngress Publishing, p399-400 12 Wikipedia contributors. (2008, March 15). Packet sniffer. Retrieved 18 March 2008, from: http://en.wikipedia.org/wiki/Packet_sniffer 13 SecureWorks.com (2007, August 13). DNS Cache Poisoning The Next Generation. Retrieved 18 March, 2008 from: http://www.secureworks.com/research/articles/dns-cachepoisoning

11

Student number: xxxxxxxx

Page 9

In the situation shown in figure 4, the following takes place: The attacker starts by sending the target a mail with a link to www.example.com The target queries the local name server for the IP mapping The local name server sends a DNS request to ns.example.com The attacker now floods the local name server with response to the query, guessing the source UDP port and Transaction ID. If one of the responses from the attacker has the correct source port (which can be picked up by a network analyser), the correct Transaction ID (which is guessable) and reaches the local name server before the legitimate response from ns.example.com, the local name servers cache is now corrupted.

d. Avoiding cache poisoning and DNS spoofing

i. Split DNS
With BIND version 9, the transaction ID is made random and not sequential. One can also use a technique called split DNS14-15.

Screen shot 7

Screen shot 8

Split DNS means that one uses two separate servers containing a BIND DNS each that serves different purposes: one for serving internal computers with remote DNS records, and the other for serving external computers with public DNS records about the internal network. 15 Brian Hatch and James Lee, (2003), chapter 7, Hacking Linux Exposed, second edition, McGraw Hill, p289

14

Student number: 07238959

Page 10

ii. DNS Security Extension

Since all DNS servers are vulnerable to spoofing in one way or another, its suggested to use DNSSEC16. DNSSEC is depending on the fact that both sites (requesting server and authoritative zone source) involved in data transfer must support DNSSEC. The authoritative name server signs its zone data and becomes SEP - Secure Entry Point. The receiving name server must then be configured to support a security service and thus be called security aware17.

Figure 5: DNSSEC uses private / public keys (T.D) The authoritative name server signs its zone file with a private key, and the receiving server must than have access to the public key of that zone to authenticate the zone information it receives. This method of digitally signing documents for authenticity has been done since Whitfield Diffie split the crypto keys in May 197518. However it would be impossible for every name server on the Internet to send every other name server on the Internet its public key, so we need to make sure that the receivers can obtain this public key in a secure manner. There is two ways of handling this problem19: Publish the key using DNSKEY RR in the zone file Obtain the key through email, telephone or some other acceptable process The method using DNSKEY RR in the zone file creates a chicken-and-egg situation: In order to get the key for validating responses in a secure manner, we need the key we are asking for to securely validate the response containing the key that we need to
16

IETF.org, (2005, March), The DNS security introduction and requirements, Retrieved 25 March from: http://www.ietf.org/rfc/rfc4033.txt 17 Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND, Apress, p283-284 18 Steven Levy, (2001), Public Key, Crypto - How the Code Rebels Beat the Government Saving Privacy in the Digital Age 19 Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND, Apress, p285

Student number: xxxxxxxx

Page 11

validate the response... Therefore, DNSSEC uses the second method20. The second method is often referred to as creating an island of security. The signing of the zone is not validated by a secured parent and stands alone in a sea of unsecured domains, hence an island of security.21 To create an island of security in BIND, one must first create a key-pair:

Screen shot 9 We also need, as stated in RFC3757, SEP keys. SEP is short for Secure Entry Point, and these keys should only be used to verify your zone-signing keys.22 There is no support for this in BIND 8, so its wise to upgrade to BIND 9.

Screen shot 10 Here (Screen shot 12), we are using the KSK option to generate key-signing-keys. One should differ between the two because if one has separate zone and key-signing keys, its easier to re-sign zone after update without involving parent zone administrators.23 The files are stored in the same folder they are generated in, and they are named key (public) and private (private)

Screen shot 11

Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND, Apress, p285 RIPE NCC, (2004, December), DNSSEC HOWTO A Tutorial in disguise, Retrieved 27 March, from: https://www.ripe.net/projects/disi//dnssec_howto/dnssec_howto-v1.6.html 22 IETF.org, (2004, April), Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag, Retrieved 25 March from: http://www.ietf.org/rfc/rfc3757.txt 23 th Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and BIND 5 edition, OReilly, section 11.4.9
21

20

Student number: 07238959

Page 12

After the signing-keys are generated, we need to sign our zone (not much use otherwise...). This is done in two steps: Add DNSKEY records to the zone file:

Screen shot 12 Sign the zone file with the dnssec-signzone command:

Screen shot 13 The zone is now signed; the dnssec-signzone checks the SEP field in the DNSKEY records, to find out which key to use.24 The result is another zone file named secured.domain.zone.signed and one needs to remember to re-sign the zone every time the zone is updated.

Screen shot 14

Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and BIND 5 edition, OReilly, section 11.4.10.2

24

th

Student number: xxxxxxxx

Page 13

Screen shot 15 Running dig should also produce RRSIG records and such

Screen shot 16 The discussion around the use of DNSSEC has been long and is ongoing. The resistance claims the process is too lengthy and weak, and there is also vulnerabilities to DNSSEC in it self. (Ref: CVE-2007-0494 ) The likers says if everyone implemented DNSSEC, every zone could validate their childs. The toplevel domain .se has implemented DNSSEC and claims it works fine.25

iii. Securing zone transfers

When there is more than one name server for a zone (and there should be) it is required that these servers have the same information stored about their zone. To accomplish this, they perform zone transfers. Earlier versions of DNS supported only full zone transfer (AXFR), which means that the whole zone file in all its glory is
25

.SE, .SE-DNSSEC, Retrieved 31 March, from: http://www.iis.se/domains/sednssec

Student number: 07238959

Page 14

copied between the servers. In BIND 9, incremental zone transfers (IXFR) are on by default. The incremental zone transfer only copies the actual changes in the zone, so its much more efficient.26 Any zone transfer is a liability, so one needs to secure these transfers of zone information. This can be done partly through network design and partly by transaction signatures TSIG.27 The message digest is computed over the entire DNS message, so altering a single bit would result in a message digest mismatch. The time of signing is also included in a TSIG record, to prevent so called replay attack, where an attacker intercepts the transaction and replays it later.28

Screen shot 17 Creating shared key for master and slave in secured.domain (Screen shot 20) is done with the same command used to create the zone signing keys: dnssec-keygen. Its common to name the key after the two servers in question, and after transferring the key to both servers one can restrict zone transfers to those signed with the correct key:

Screen shot 18

e. Safeguarding your information

Logging means recording sequential data, often chronological29, and this is done to monitor and discover network bottlenecks, unusual patterns and such, to predict a possible attack. BIND supports logging to syslog, which has been the de facto standard for forwarding log messages in an IP network until recently.30 Logging can
Paul Albitz and Cricket Liu, (2006), chapter 10, DNS and BIND 5 edition, OReilly, section 10.4 27 TSIG is a method of authenticating DNS messages, including zone transfers, using shared secrets and one-way hash functions. Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and th BIND 5 edition, OReilly, section 11.1 28 Wikipedia contributors. (2008, March 25) Replay Attack, Retrieved 1 April, from: http://en.wikipedia.org/wiki/Replay_attack 29 Wikipedia contributors. (2008, March 28) Data logging. Retrieved 2 April, from: http://en.wikipedia.org/wiki/Data_logging 30 Wikipedia contributors. (2005, March 25) Syslog. Retrieved 2 April, from: http://en.wikipedia.org/wiki/Syslog
26 th

i. Logging the data transfers

Student number: xxxxxxxx

Page 15

be divided into channels and categories, where categories tells us what is going to be logged, and channels where to log it. The channels and categories in BIND 9 are discussed in the table below31:

Table 1 Channels also allow you to filter the messages by severity:

Screen shot 19 Its important to know that syslog is not only used by BIND, and with no configurations at all, default messages will pile up in /var/log/messages:

Paul Albitz and Cricket Liu, (2006), chapter 7, DNS and BIND 5 edition, OReilly, section 7.5.2 - 7.5.3

31

th

Student number: 07238959

Page 16

Screen shot 20

Screen shot 21

Screen shot 22 As we can see, the applications that use syslog can be chatty, so for the sake of better overview and easier troubleshooting, its suggested dividing the messages by category:

Screen shot 23 The messages are now logically divided, and when needed, it is much easier to make some sense of what is going on:

Screen shot 24 There is also a security issue with syslog in that it uses UDP for transport and is therefore easily spoofed and altered with. Be aware also that log files can be deleted or tampered with in several ways. IETF (Internet Engineering Task Force) has put

Student number: xxxxxxxx

Page 17

down a work group to look at these issues32, and other logging tools, such as syslogng and metalog to mention two of them. Either way, you need to centralise and automate the process of watching log files. There are many different tools out there to accomplish this; you will have to evaluate them to fit your needs.

ii. Securing the information

In my opinion there is two sides of securing information. The first is to make sure nobody can break into your server and grab information directly. The second is to make sure your server gives up as little information as possible to the outside world. It goes without saying that the servers need to be secured both physically and by maintaining good password practises and good security related routines. BIND should run in a so-called jailed environment33. To make sure your server does not give out unnecessary information to potential attackers, you need to know what information is given to anyone who asks. The use of simple tools such as whois can often provide attackers with useful information, but as we can see in screen shot 25, not all organisations give away information for free.

Screen shot 25 Other techniques involves asking the name server it self. host can be used to get some answers, and with the c switch, one can query the chaos class:

Screen shot 26

IETF.org, (March 13, 2008), Security Issues in Network Event Logging (syslog), Retrieved April 22, 2008 from: http://www.ietf.org/html.charters/syslog-charter.html 33 This means that BIND runs in a folder of its own, with no possibilities of reading or writing outside this folder. In practical terms, if the application runs in /var/bind and accesses a file called /etc/bind/named.conf, the actual path would be /var/bind/etc/bind/named.conf. Ronald G. F. Aitchison, (2006), chapter 10, Pro DNS and BIND, Apress, p251

32

Student number: 07238959

Page 18

One can put in an option in named.conf to make it say something else:

Screen shot 27 Several administrators make things easy for themselves by using descriptions and such. The information they provide for themselves also goes out to potential attackers

Screen shot 28

Screen shot 29 But then again, not all organisations are that informative

Screen shot 30

Screen shot 31 Dig is also a nice tool for diagnostics, and therefore a good tool for hackers to gather information

Student number: xxxxxxxx

Page 19

Screen shot 32

V. Summary and conclusions

It is easier for most humans to read and remember addresses based on names than on numbers, so in my opinion the need for a technology to convert, or map name based addresses to number based addresses is non-negotiable. The question is how to make this a reliable and trustworthy technology for people outside the small circle of computer geeks. So-called experts is arguing in public forums34, meanwhile most people surfs the net in ignorance. Mr. Dan Bernstein says that his focus for the djbdns will be nym-based35 approach (implementing a fingerprint of a computers public key in the actual DNS name) and Mr. Paul Vixies BIND has support for DNSSEC. The nym-based approach requires long host names, and even though Mr. Bernstein claims that users happily will use bookmarks to handle long host names, I dont think it will stop attackers from leading users in a wrong direction. The DNSSEC requires every zone to be associated with a public key, and then signs messages with corresponding private key. In order to validate the public keys of a zone, the parent zone signs the keys, all the way to the root name servers. The root zones public key should be widely known and distributed among all the DNSSEC supporting name servers36. This of course, requires that everyone acknowledges DNSSEC to be the right way to go, and implements it all the way, and that is not something likely to happen in very near future.

CircleID.com, (2004, October 11), Thoughts about Protecting Against BIND, Retrieved 6 April, from: http://www.circleid.com/posts/thoughts_about_protection_against_bind/ 35 Dan J. Bernstein, DNS forgery, Retrieved 6 April, from: http://cr.yp.to/djbdns/forgery.html 36 th Paul Albitz and Cricket Liu, (2006), chapter 11, DNS and BIND 5 edition, OReilly, section 11.4.5

34

Student number: 07238959

Page 20

Keeping ones systems updated and well patched, signing up for newsletters concerning the tools and systems one uses, keeping track of information one handles and shares and watching over ones logs seems to be the only real alternative at the moment. Of course when or if the experts agrees on one technology, whether its DNSSEC or the nym-based approach, or any ground-shaking new approach, we can all start building secure DNS services. Until then, better play it safe, and upgrade to BIND version 9.4.237.

37

ISC.org, Newest release - http://www.isc.org/index.pl?/sw/bind/index.php

Student number: xxxxxxxx

Page 21

VI. References
All screen shots are taken from my own test systems. I have constructed all figures but figure 3, with Microsoft Visio. Figure 3 is collected from the book Special OPS Host and Network Security for Microsoft, UNIX and Oracle by Eric Pace Birkholz

a. Books
J. D. Wegner and Robert Rockell, (2000), Chapter 1, IP Addressing and Subnetting, including IPv6, Syngress Media Paul Albitz and Cricket Liu, (2006), Chapter 2, DNS and BIND, 5 Edition, OReilly, section 2.4 Eric Pace Birkholz, (2003), Chapter 8, Special OPS Host and Network Security for Microsoft, UNIX and Oracle, Syngress Publishing, p399-400 Brian Hatch and James Lee, (2003), chapter 7, Hacking Linux Exposed, second edition, McGraw Hill, p291 Ronald G. F. Aitchison, (2006), chapter 11, Pro DNS and BIND, Apress, p283-284 Steven Levy, (2001), Public Key, Crypto - How the Code Rebels Beat the Government Saving Privacy in the Digital Age
th

b. Websites
Wikipedia contributors. (2008, March 10). Domain Name System. Retrieved 11 March 2008, from: http://en.wikipedia.org/wiki/Domain_name_system Jupitermedia Corporation. (2007, December 27). Berkeley Internet Name Domain. Retrieved 11 March 2008, from: http://webopedia.com/TERM/B/Berkeley_Internet_Name_Domain.htm WSWS.ORG. (1999, March 3). Hackers shut down East Timor Internet addresses. Retrieved 12 March 2008, from: http://www.wsws.org/articles/1999/mar1999/hack-m03.shtml ICANN.ORG. (2007, March 1). Root server attack on 6 February 2007. Retrieved 12 March 2008, from: http://www.icann.org/announcements/factsheet-dns-attack-08mar07.pdf DNS Spoofing is the art of making a DNS entry to point to another IP than its supposed to point to. (2002, January 23). DNS spoofing techniques. Retrieved 12 March 2008, from: http://www.securesphere.net/download/papers/dnsspoof.htm Daniel J. Bernstein: Notes on the Domain Name System. Retrieved 16 March, 2008 from: http://cr.yp.to/djbdns/notes.html#poison CERT. (1997, August 13) CERT Advisory CA-1997-22 BIND - the Berkeley Internet Name Daemon. Retrieved 18 March, 2008 from: http://www.cert.org/advisories/CA-1997-22.html

Student number: 07238959

Page 22

Wikipedia contributors. (2008, March 18). User Datagram Protocol. Retrieved 18 March 2008, from: http://en.wikipedia.org/wiki/User_Datagram_Protocol Wikipedia contributors. (2008, March 15). Packet sniffer. Retrieved 18 March 2008, from: http://en.wikipedia.org/wiki/Packet_sniffer SecureWorks.com (2007, August 13). DNS Cache Poisoning The Next Generation. Retrieved 18 March, 2008 from: http://www.secureworks.com/research/articles/dns-cachepoisoning IETF.org, (2005, March), The DNS security introduction and requirements, Retrieved 25 March from: http://www.ietf.org/rfc/rfc4033.txt RIPE NCC, (2004, December), DNSSEC HOWTO A Tutorial in disguise, Retrieved 27 March, from: https://www.ripe.net/projects/disi//dnssec_howto/dnssec_howto-v1.6.html IETF.org, (2004, April), Domain Name System KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) Flag, Retrieved 25 March from: http://www.ietf.org/rfc/rfc3757.txt SE, .SE-DNSSEC, Retrieved 31 March, from: http://www.iis.se/domains/sednssec Wikipedia contributors. (2008, March 25) Replay Attack, Retrieved 1 April, from: http://en.wikipedia.org/wiki/Replay_attack Wikipedia contributors. (2008, March 28) Data logging. Retrieved 2 April, from: http://en.wikipedia.org/wiki/Data_logging Wikipedia contributors. (2005, March 25) Syslog. Retrieved 2 April, from: http://en.wikipedia.org/wiki/Syslog IETF.org, (March 13, 2008), Security Issues in Network Event Logging (syslog), Retrieved April 22, 2008 from: http://www.ietf.org/html.charters/syslog-charter.html CircleID.com, (2004, October 11), Thoughts about Protecting Against BIND, Retrieved 6 April, from: http://www.circleid.com/posts/thoughts_about_protection_against_bind/ Dan J. Bernstein, DNS forgery, Retrieved 6 April, from: http://cr.yp.to/djbdns/forgery.html ISC.org, Newest release - http://www.isc.org/index.pl?/sw/bind/index.php

Student number: xxxxxxxx

Page 23