Exploratory Lab Report 3DNS

Joshua Bancroft10/31/2007

Professor Bill StackpoleNoah Leaf

Part A BIND

Activity 1 Creating a second level domain

Q1.1. After reading through the ENTIRE LAB, how would this domain structure fit into the current global hierarchical structure if it were to be registered with a top level registrar? (Include a diagram with your answer.)

The .exp domain would be a top level domain right below the root servers. The .exp would act similar to the .com domain. The ballers.exp domain is an SLD or second-level domain underneath the top level domain of .exp. There are also two sub-domains underneath ballers.exp. One of them is yourco.ballers.exp and the is mgmt.ballers.exp. The final hierarchy of how the .exp domain fits in to the global hierarchical structure can be seen in Figure 1.1.1

Q1.2. Explain, in detail, why you are able to simply create a fictitious top-level domain without disturbing the global domain structure?

The main reason a fictitious top-level domain can be created is because in the lab we are using our own domain servers. If the root server was queried for our top level domain it would respond with non-existent domain. This is because the root servers do not know about the .exp domain and the name servers that are masters of it.

Q1.3. Theoretically, will any conflicts result from connecting your finalized domain structure to the Internet? Would a Registrar likely take action against this?

No there would be no conflicts since there is not a top level domain of .exp. The reason that creating this top level domain would not disturb the internet is because the root servers who know of all the top level domain servers would not know about our .exp server. A list of top level domains that are known by the root servers is shown in Figure 1.3.1. This means that if an individual was actually trying to connect to .exp they would have to know the IP address of the .exp server. (This is the one we created in lab) The Registrar would not take action against us because they do not even know the .exp domain exists. If we were conflicting with another top-level domain or trying to edit the lookup files of a top level or root server then they would take action, but not for creating a fictitious top-level domain that the root servers do not even know about.

Figure 1.3.1 A list of top-level domains recognized by the root servers. NOTE: this list does not include all of the country domains

Activity 2 Reverse lookup domain

Q2.1. How can you definitively prove that your domain is working as intended? (Support your answer with a clear developed explanation, including configurations AND captures.)

To prove that the domain is working properly, tests were conducted to resolve names and IP address locally on the machine along with inside the domain and also in the global scale. Resolution was made when trying to resolve both forward and reverse lookups inside the domain along with in the global hierarchy. The files that were needed on the primary ballers.exp name server can be seen below.

Named.conf file

@ IN SOA ns1.ballers.exp. root.ballers.exp (2007101601; serial120 ; refresh60 ; retry3M; expire8M; min TTL

) IN NS ns1.ballers.exp.1 IN PTR localhost.0.0.127.in-addr.arpa file

@ IN SOA ns1.ballers.exp. root.ballers.exp (6 ; serial900 ; refresh (15 minutes)600 ; retry (10 minutes)86400 ; expire (1 day)3600 ; minimum (1 hour)

) IN NS ns1.ballers.exp.10 IN PTR mail111 IN PTR mail23 IN PTR ns11 IN PTR comp14 IN PTR comp472.110.10.in-addr.arpa file

Ballers.exp forward lookup file

Reverse lookups inside ballers.exp domain

Activity 3 Creating sub-domain

Q3.1. Why is a PTR record for mgmtNS.mgmt.myco.exp on mycoNS.myco.exp needed?

A pointer record is need on ns1.ballers.exp to point to ns1.mgmt.ballers.exp because it allows the domain to communicate with the sub-domain. By adding this line it does not allow for queries to occur from a host on the ballers.exp domain to a host on mgmt.baller.exp. Instead the record just points to the name server on that sub-domain. With the pointer though, communication from one domain to another can be accomplished.

Q3.2. What is the functional difference between this PTR record and the other PTR records on mgmtNS.mgmt.myco.exp?

A pointer record is used to match an IP address to a specific name. In most cases the pointer record points to a host, but in this case the pointer record points to the name server of the sub-domain. This record is needed in order to link an IP address to the name server of the sub-domain

Q3.3. Why, even though your two servers are both in the same second level domain, is it not possible to resolve names from one domain to another?

The reason that the two sub-domains cannot communicate is that on each domain there are separate name servers. In each of these name servers they contain resolution for the domain they control but do not resolve any names in the upper domains. If a name server does not know a host or domain it gets sent to the root servers. Since our domain is not a registered with the root servers they will not know about the domain and not return an address. Another possible solution to allow the two sub-domains to communicate is to create a top level domain that know about each of the domains. The cache.dns file would also have to be altered to point to the top level domain instead of the root servers. This then in essentially make the top level domain a pseudo root server.

Q3.4 Insert sufficient screen and/or packet captures to illustrate which forward and reverse domain lookups are working properly, and which are not for both domains.

Reverse lookup from ballers.exp

Forward lookup from ballers.exp to mgmt.baller.exp

Forward lookup from ballers.exp to mgmt.ballers.exp

Activity 4 Delegating to a sub-domain

Q4.1. At this point, what CAN you resolve when using each of the name servers as your DNS? (Validate your statements with screen captures or text from your resolver output as well as an analysis of why these resolution attempts succeed or fail based on your current configurations)

At this point all forward lookups can be done. Forward to the internal domain can be accomplished along with the sub-domain. Forward lookups to a global address such as www.google.com can be accomplished. All reverse lookups work except for doing a reverse lookup from the sub-domain (mgmt.ballers.exp) to the second level domain (ballers.exp).

Local Internal Sub-domain GlobalForward Yes Yes Yes YesReverse Yes Yes No Yes

Forward delegation from ballers.exp to sub-domain (mgmt.ballers.exp)

Forward delegation from sub-domain (mgmt.ballers.exp) to global address

Forward lookup from sub-domain to sub-domain

Reverse lookup from both sub-domain to domain and vice-versa

Q4.2. After examining a standard cache file obtained from Internic, what can you say about delegation of authority and how it is accomplished? (db.cache, root.hints, etc)

Delegation of authority is the main premise behind how DNS works. The main root servers that server DNS do not actually resolve any hosts but instead resolve other name servers of the top level domains. So the root servers for example get a query from a client for a www.google.com. The root servers first check their own delegated zones and then see that .com needs to be delegated to the .com servers. The .com servers then check to see if they have any entries for www. google.com. If not then it gets passed onto the Google name servers until they can finally resolve what the address for www.google.com is .

Activity 5 Reverse Delegation

Q5.1. Why don’t the DNS Servers have to be in the same subnet as the machines whose names they resolve?

The DNS servers do not have to be in the same subnet as the machines whose name they are trying to resolve because the DNS server never checks to the see if the host is valid. Also it can resolve a name on a different subnet because the DNS queries are done in unicast which means that they are routable.

Q5.2. What configuration changes were required to implement this capability (delegation of reverse lookups)?

To implement reverse delegation a few changes were made to the configuration files. First in the 72.110.10.in-addr.arpa file (the reverse lookup file) a CNAME was created for the address 10.110.72.70 to delegate it to the name server in the sub-domain. The file also specifies what name server that the sub-domain uses. In this case the name server is ns1.mgmt.ballers.exp as seen in Figure 5.2.1. The domain server would then go to the forward lookup file and find the addresses record for ns1.mgmt.ballers.exp and pass the query to that name server (Figure 5.2.2). The sub-domain server then looks inside it’s reverse lookup file for the host and sends the query back to the client.

Figure 5.2.1 72.110.10.in-addr.arpa file on ballers.exp

Figure 5.2.3 ballers.exp forward lookup file on ballers.exp

Q5.3. Despite having your domains properly configured, why would an ISP be unlikely to delegate the reverse lookup zone of your domain to your domain server? (If you’re not sure how to answer this question – use email or the telephone – contact an ISP that you know and ask them.)

The main reason that ISPs do not delegate reverse lookups is because it is not necessary to communicate with other hosts. Also all of the addresses would need to be entered into the zone files. This process can be done automatically but managing these files would be near impossible.

Q5.4. Insert sufficient screen and/or packet captures to support that both your forward and reverse domain lookups are working properly on both domains.

All lookups forward and reverse work properly except for a reverse lookup from the sub-domain (mgmt.ballers.exp) to the domain (ballers.exp). The reason for this not working is that the sub-domain does not know how to communicate with ballers.exp. So the query gets sent to the root servers to try and figure out the answer. The root servers though do not know that address for the .exp server so the query fails.

Forward lookups from ballers.exp to mgmt.ballers.exp

Forward lookup from mgmt.ballers.exp to ballers.exp

Reverse lookup from ballers.exp to mgmt.ballers.exp (reverse delegation)

Reverse lookup from mgmt.ballers.exp to ballers.exp

Activity 6 Redundancy

Q6.1. Do the two servers successfully backup each other up? (Show proof of a zone transfer as well as captures of the action taken by the secondary should the primary server become unavailable.)

Yes the two servers back each other up. When one of the servers is a master of a domain and the backup server is the slave a zone transfer occurs as seen in Figure 6.1.1. After the zone transfer occurs both servers should then contain the same records for that domain. In order for the servers to be redundant though a top level domain is required that points to both the primary and the backup server to resolve lookups. Another possible solution is that each of the clients have both DNS servers in there resolver file. If a client though is pointing to both DNS servers and the master of a domain goes down the slave for that domain will respond to queries directed to that domain as seen in Figure 6.1.2.

Primary DNS server (ballers.exp) being the slave of poop.exp

Poop.exp forward lookup file

Figure 6.1.1 Zone transfer

Figure 6.1.2 Poop.exp slave answering the query when the master of the domain is down

Q6.2. Would you recommend this scheme to an employer? Why or why not? (Explain in terms of redundancy and reliability.)

Yes I would recommend this to an employer, but there is one main requirements that need to be met for redundancy and reliability of the system. An upper level domain either needs to be created or needs to be aware of the backup scheme. Without this if the primary server goes down then the client will not be able to communicate with the backup since none of the upper level domain servers would know the IP address of the backup server. Other than that, a DNS system that is redundant along with reliable is key, and by using backup servers to accomplish that is the perfect solution that is if the upper domain knows about both servers.

Activity 7 Creating a top level domain

Q7.1. Is topNS.exp able to resolve any and all names in any sub-domain of .exp? (Include captures that validate the level of functionality)

Yes ns1.exp (topNS.exp) can resolve any of the sub-domains of.exp. This is the main philosophy of how DNS works. When a client tries to resolve an address it first asks its primary DNS server if it knows about the domain it is querying. In this case it would be a sub-domain of .exp. If the sub-domain is then valid, the top level domain server delegates the query to the sub-domain server. Then the process continues until the sub-domain server has an address record for the queried name.

Q7.2. Can this structure resolve names from one sub-domain to the other? (Query a machine on yourco.exp from mgmt.myco.exp?) Explain how this works?

The reason that the two sub-domains cannot communicate is that on each domain there are separate name servers. In each of these name servers they contain resolution for the domain they control but do not resolve any names in the upper domains. If a name server does not know a host or domain it gets sent to the root servers. Since our domain is not a registered with the root servers they will not know about the domain and not return an address. To get this to work the top level domain could be configured to respond to the queries instead of forwarding it to the root servers.

Q7.3. Can you find members of .exp from outside your bench domain? Why or why not? If not, what would you have to do to enable this functionality?

No we cannot because we all have separate top level domains that do not know about the other benches sub-domains of .exp. To establish this functionality a common top level domain (.exp) must be established for the entire class. Then inside this domain the address of each of the sub-domains servers need to be defined. With this the class then would be able to communicate with each of the other bench domains.

Part B DJBDNS

Q8.1. What is your server able to resolve and/or not resolve? Internal/External, forward or reverse lookups? What about other names within your lab domain structure? (Include packet captures verifying these capabilities.)

All lookups can be resolved no matter if the lookup is to the local host or if it is in the internal domain. Also lookups can be completed to domains outside our own.

Local Internal External

Forward Yes Yes Yes

Reverse Yes Yes Yes

What can be resolved or not resolved.

Forward external lookup

Reverse internal lookup

Forward internal lookup

Reverse external lookup

Reverse localhost lookup

Q8.2. Compare and contrast the differences between BIND and djbdns. (Include references to the differences in packet structure and query methodology.)

The packet structure of a BIND packet and a DJBDNS packet are very similar. Both packets have the same type of queries along with the same answer and authoritative section. This is because both the same DNS protocol that specifies the querying of a server. The major difference between a BIND and djbdns is how the querying occurs. Since djbdns is actually comprised of many smaller programs (dnscache and tinydns) each need to be set up on different interfaces or different server. When an internal address is queried such as comp4.kittens.luv tinydns takes care of it and responds on the localhost. While if a global address is queried then the query goes through dnscache and then passed onto the root servers. Bind on the other hand is an all in one package where both programs are compacted into one. If a internal domain lookup is received it responds to the query, if an external domain query is received it is passed off to the root server unless it is already cached.

Djbdns query and answer

Djbdns query

Djbdns answer

BIND queries and answer

BIND query

BIND Answer

Q8.3. At this point would you recommend FOR or AGAINST djbdns as a viable solution to the needs of a Domain Name Service? Why or why not?

(Cite both your reasons for taking this position as well as what arguments others might use to refute your statement(s). Be sure to support your answer with captures and examples. Below are a few lines to get you started.)

BIND vs. djbdns which is a better solution for a DNS. In my personal option I prefer djbdns. The biggest reason why djbdns is a better solution is security. Unlike BIND where it has every feature ever needed djbdns is barebones and an administrator adds what he/she needs. BIND also has all of these featured allowed as soon as BIND is installed, so many of those high risk features really turn into security risks. These features include and are not limited to zone transfers, running it as root in a UNIX environment and many more. djbdns on the other hand is very secure, there is even an ongoing contest to see if anyone can find any security holes in it and no one has yet to find any. Some may say that all this security there must be a downfall such as implementation, but that is not the case. Implementation of djbdns is not that bad and is very similar to BIND. The biggest difference is that djbdns is a little more crude that bind in some the files that need to be created. Djbdns is defiantly more secure then BIND and around the same skill set to implement, it should be an easy choice then which one to use.