While I was looking for free public DNS servers the other day, I happened to come across the Google Public DNS. Reading the FAQ I gathered that it was not based upon BIND or NSD but was a proprietary DNS server written by Google.

When you connect to your ISP, most of the time you get an IP address and DNS servers from your ISP’s Dynamic Host Configuration Protocol (DHCP) server.

As per their website, Google Public DNS is a recursive DNS resolver, similar to other publicly available services, but it is not any of the following:

• A top-level domain (TLD) name service. Google is not an operator of top-level domain servers (generic or country-code)
• Google Public DNS is not a third-party DNS application service provider, such as DynDNS, that hosts authoritative records for other domains.
• Google Public DNS servers are not authoritative for any domain. Google maintains a set of other nameservers that are authoritative for domains it has registered, hosted at ns[1-4].google.com.
• A malware-blocking service. Google Public DNS does not perform blocking or filtering of any kind.

To use Google Public DNS, you need to explicitly change the DNS settings in your operating system or device to use the Google Public DNS IP addresses below.

The Google Public DNS IP addresses are as follows:

8.8.8.8
8.8.4.4

You can follow the steps below to change DNS settings in the TCP/IP properties window for the required network connection. (Example below is for Windows XP)

1. Navigate to the Control Panel.
2. Click Network and Internet Connections, then Network Connections.
3. Select the connection for which you want to configure Google Public DNS. For example:
- To change the settings for an Ethernet connection, right-click Local Area Connection, and click Properties.
- To change the settings for a wireless connection, right-click Wireless Network Connection, and click Properties.
4. Under the General Tab. Under This connection uses the following items, click Internet Protocol (TCP/IP), and then click Properties.
5. Click Advanced and select the DNS tab. Note down any DNS server IP addresses already listed there and then remove all of them from this window.
6. Click OK.
7. Select the option Use the following DNS server addresses. If there are any IP addresses listed in the Preferred DNS server or Alternate DNS server, write them down for future reference.
8. Replace those addresses with the IP addresses of the Google DNS servers: 8.8.8.8 and 8.8.4.4.
9. Restart the connection you selected.

I tried to gather more information about the service and noted down the following:

- Servers spread about around the globe (obviously)
- The service uses anycast routing to direct requests to the nearest DNS server
- Google Public DNS can respond to requests for IPv6 addresses (AAAA requests), but it does not yet support native IPv6 transport and cannot talk to IPv6-only authoritative nameservers. Clients should use IPv4 network connections to use Google Public DNS. This is likely to change as the service evolves.
- Google Public DNS is an independent service with no cross product dependencies.
- No technical support is provided by google directly and the only available form of support is Google groups, a Twitter channel and telephone support.
- The service is not bound by SLA at this time. 

The benefits mentioned by Google while using their DNS server are:

- Speed up your browsing experience
- Improve your security
- Get the results you expect with absolutely no redirection

I tried the new DNS settings and was satisfied (without a few domain names not resolving), I have yet to try to calculate the difference in latency of my old DNS servers versus Google Public DNS. I expect the product to improve much more in the long run.

When a device on a TCP/IP network starts up and is not configured for a static IP address, it needs to receive an IP address before it can communicate with other devices on the network. A standard computer with a hard disk can be enabled for static configuration but a diskless device that does not have any storage, only has an option to acquire an IP address from the network. This process of getting a new machine up and running is commonly referred to as bootstrapping. To provide this functionality, the TCP/IP Bootstrap Protocol (BOOTP) was created. 

The Bootstrap Protocol, or BOOTP, is a network protocol used by a network client to obtain an IP address from a configuration server. In order to get an IP address the network clients contact other devices on the network. Initially (ages ago) a boot floppy disk had to be inserted to establish the initial network connection, but later on Network Interface card manufacturers embedded the protocol in the ROM of the interface card as well as on motherboards that have onboard network adapters, thereby avoiding the need for floppy disks and allowing for direct network booting.

During the bootstrap process when a computer is starting up, the BOOTP protocol is used. A BOOTP server assigns an IP address to each client from a pool of addresses and based on the configuration of the server. BOOTP generally uses the User Datagram Protocol (UDP) as the transport protocol. Earlier, BOOTP has also been used for diskless workstations to obtain the network location of their boot image in addition to an IP address using protocols like PXE, and also by enterprises to roll out pre-configured client installations to newly installed PCs.

Although BOOTP provides a very important function, it is not used frequently today and has been superseded by DHCP (Dynamic Host Configuration Protocol) which is a more advanced protocol for the same purpose. Most DHCP servers also offer BOOTP support and are the most prevalent method used today to assign IP addresses to diskless workstations and clients that require IP addresses.

Booting your host from the network without the need to rely on the local operating system or hard disks is a technology that is not used very often in the corporate environment today with some people never having heard that such a thing is possible. With the way things are moving today with virtual machines, virtual storage, dynamic infrastructure, I feel that the trend would be reversed with few folks storing data on local hard drives and more moving to virtual environments and booting from remote storage at least as far as the backend infrastructure is concerned because of the advantages of flexibility, backup, deployment, etc.

Preboot eXecution Environment (PXE) or ‘pixie’ as it is popularly called is one of the many technologies that helps in booting hosts using a Network Interface with the help of images stored remotely. PXE consists of a suite of protocols like IP, UDP, DHCP, TFTP and concepts like Globally Unique Identifier (GUID) and Universal Network Device Interface (UNDI). The firmware of the PXE client is extended with the help of API’s. The PXE client refers to any hardware host device (server, notebook, PC) that is included with the PXE boot code.

PXE is an open industry standard developed by a number of software and hardware vendors. It was initially designed by Intel, with input from several other vendors including 3Com, HP, Dell, Compaq, and Phoenix Technologies. PXE works with a USB adapters and network interface card (NIC) in the PC, making the PC boot over the network.

Hosts that support booting from PXE, have a firmware that tries to locate a PXE redirection service (Proxy DHCP) to get a list of PXE boot servers that are available. After going through the reply, the firmware software will request an appropriate boot server for the file path of the network bootstrap program (NBP) like xxx and download it on the local Random Access Memory (RAM) using TFTP generally, verify and execute it.

If a common NBP is used by all PXE clients it could be specified by BOOTP thereby not needing a proxy DHCP, but the TFTP server is still required.

PXE Protocol

The PXE protocol is a combination of modified versions of DHCP and TFTP. DHCP is used to locate the appropriate boot servers and TFTP is used to download the bootstrap program and other files to the PXE client. Initiation of a PXE bootstrap session is done by the PXE firmware broadcasting a DHCPDISCOVER packet with PXE options (extended DHCPDISCOVER) to port 67 UDP (DHCP Server port). The PXE options identify the firmware of the sending host as capable of PXE, but this message is ignored by standard DHCP servers. If the PXE client receives DHCPOFFERS from such servers, it may request for one of the offered configurations.

PROXY DHCP

When a PXE redirection service (Proxy DHCP) receives an extended DHCPDISCOVER, it replies by sending back a broadcast called an extended DHCPOFFER (DHCPOFFER with extended PXE options) to port 68/UDP (DHCP client port). The reason this packet is broadcasts back because the IP address of the PXE client is not included in DHCPDISCOVER message. The client is mainly identified by its GUID/UUID

Extended DHCPOFFER contains mainly:

 - PXE Discovery Control field to decide whether Multicasting, Broadcasting, or Unicasting is to be used for contacting PXE boot servers
- List of IP addresses of each available PXE Boot Server Type
- PXE Boot Menu with each entry representing a PXE Boot Server Type
- PXE Boot Prompt telling the user to press <F8> to see the boot menu
- Timeout to launch the first boot menu entry if it expires.

The Proxy DHCP service may also be run on the same host as the standard DHCP service. Since both services cannot share port 67/UDP, the Proxy DHCP runs on port 4011/UDP and expects the extended DHCPDISCOVER packets from PXE Clients to be DHCPREQUESTs. The standard DHCP service has to send a special combination of PXE options in its DHCPOFFER, so the PXE client knows to look for a Proxy DHCP on the same host, port 4011/UDP.

Boot Server

To contact any PXE Boot Server the firmware must have an IP address and has to consider all information from exactly one extended DHCPOFFER. After choosing an appropriate PXE Boot Server Type the firmware multicasts or unicasts a DHCPREQUEST packet extended with PXE-specific options (extended DHCPREQUEST) to port 4011/UDP or broadcasts it to port 67/UDP. This packet mainly contains the PXE Boot Server Type and the PXE Boot Layer, allowing to run many boot server types with one boot server daemon (or ‘program’). The extended DHCPREQUEST may also be a DHCPINFORM.

If a PXE Boot Server receives an extended DHCPREQUEST as described above and if the boot server is configured for the requested PXE Boot Server Type and client architecture, it must respond by sending back an extended DHCPACK to the source port of the extended DHCPREQUEST.

Extended DHCPACK contains mainly:
- The complete file path to download the NBP via TFTP.
- PXE Boot Server Type and PXE Boot Layer the boot server answered to
- Multicast TFTP configuration, if MTFTP as described in the PXE specification should be used

Additionally the PXE firmware extension was designed as an Option ROM for the IA-32 BIOS so you can get a personal computer (PC) PXE-capable by installing a NIC that provides a PXE Option ROM as can be seen in the figure below

The PXE Client/Server Protocol was designed so:

- It can be used in the same network as an existing DHCP environment without interference
- It can be integrated completely into standard DHCP services

For those of you who have heard of Address Resolution Protocol (ARP) and think that Reverse Address Resolution Protocol (RARP) is its complement, they are totally off track. RARP is a computer networking protocol used by a host computer to request for an IPV4 address from another host computer if it does not have one used (not statically assigned), the Network Interface that is connected to the network would already have a Layer 2 MAC address (hardware address).

This might very well sound like DHCP which is very popular and does the same thing. In fact RARP has been rendered obsolete by two of its successors, the Bootstrap Protocol (BOOTP) and the newer Dynamic Host Configuration Protocol (DHCP), which have better features than RARP.

In an RARP setup, one or more server hosts maintain a database of mappings of Link Layer addresses to their respective protocol addresses (similar to an IP to MAC mapping in Ethernet networks). Media Access Control (MAC) addresses needed to be individually configured on the servers by an administrator (this is where DHCP rules and RARP got kicked out). RARP was limited to serving only IP addresses.

Another misnomer is that Reverse ARP is the same as Inverse Address Resolution Protocol (InARP). But InARP was designed to get the IP address associated with another host’s MAC address. InARP is actually just the reverse of ARP in functionality.

The are many special types of IP address that we seldom come across as they are only used in special cases. We will go through each of them in the overview below:

1. Limited Broadcast IP address

In this type of an IP address all the 32 bits of the IP address are set to 1′s. The address is 255.255.255.255. Routers never forward packets destined to this address because routers are by default designed to stop traditional broadcasts. This address is seen quite often in the routing tables of many systems.

This address is normally used when the host does not know its IP address (like when a Windows PC starts up and wants an IP address) like during an automated configuration process such as Boot Protocol (BOOTP) or DHCP because initially it does not know the IP address of the DHCP server. For example, with DHCP, a DHCP client must use the limited broadcast address for all traffic sent until the DHCP server acknowledges the IP address lease.

2. Loopback IP address

This IP address represents the local host and has the network part of the IP address as 127. A common loopback address is 127.0.0.1 and they range from 127.0.0.0 – 127.255.255.255. When a packet is destined to a loopback address whether via a ping or other utility it is actually addressed to the same local machine from where it originated. They are normally used to test connectivity of the Network Interface card of the host. These address do not leave the host nor will they traverse an external network interface.

A loopback address is also used to simulate a telnet or connection to an address of a device acting as a terminal server which is actually on the same host. This scenario is used for example, in Dynamips (Cisco Router Simulator) where a Microsoft Loopback address is created. This is not the same as the built in loopback of Windows (localhost or 127.x.x.x)

More on how a Microsoft loopback adapter can be created can be found here http://support.microsoft.com/kb/839013

3. Zeros IP address

The zeros IP address is normally 0.0.0.0 but actually range from 0.0.0.0 – 0.255.255.255. These address are most seen in system log files and are reserved for the default network. Sometimes while fingerprinting a target system using an ARP Scan, packets sent with a source of 0.0.0.0 are received. The response to these type of non-standard ARP packet differs depending on the operating system. So if you see packets with a source of 0.0.0.0 in the logs of a system, it implies that the system is the target of a fingerprint attack.

The detailed RFC 1700 concerning zeros IP address and Loopback address is available at the IETF website http://tools.ietf.org/html/rfc1700

4. Network Directed Broadcast IP address

This IP address is made of the host bits of all 1′s and the network part is the same as that of the network that it belongs to. An example of a network broadcast address for the classful network ID 140.101.0.0/16 is 140.101.255.255. Routers usually forward packets addressed to a network directed broadcast address. This type of a packet is sent when the entire network needs to receive the packet in a type of a broadcast which is very rarely the case and only a few applications might follow this kind of behaviour.

IP Directed broadcasts can be used to launch ICMP smurf attacks if hardware devices are not configured properly. They do this by using spoofed source IP addresses. For example, in Cisco devices prior to IOS 12.0 you would need to add the no ip directed-broadcast command or put in specific Access lists to deny this type of behaviour.

5. Subnet Directed Broadcast IP address

Here the host part of the address is represented by 1′s, while the subnet part of the address is the actual subnet. An example of a subnet directed broadcast address for the nonclassful network ID 140.101.46.0/24 is 140.101.46.255. For a classful network, there is no subnet broadcast address, only a network broadcast address. For a nonclassful network, there is no network broadcast address, only a subnet broadcast address.

This feature is useful in Wake up on LAN (WOL) implementations where a packet might want to be destined to an entire subnet if the IP addresses of devices in the subnet are not static and the source does not exactly know which destination to wake up. Apart from the WOL advantage, the disadvantage is that an attacker might launch a smurf attack to keep all other hosts in the subnet awake and respond to his ICMP packet.

6. All Subnets Directed Broadcast IP address

Both the host and the subnet part of the address bits are 1′s. The subnet mask of the network must be known wherever such an address is being used or it does not make any sense. An example of an all-subnets-directed broadcast address for the subnetted network ID 140.101.46.0/24 is 140.101.255.255. The all-subnets-directed broadcast is the network broadcast address of the original classful network ID.

7. Multicast IP addresses

These IP address are used when a needs to send a multicast to a group. IP multicast addresses are used for single-packet one-to-many delivery. The source host sends a packet with the destination from the class D range which signifies the group number and to route the packet the unicast routing table is used. Every node on the path of the source internetwork that has been configured with a multicast routing protocol and is therefore listening for multicast traffic receives and processes the packet. Unlike broadcast packets, routers forward IP multicast packets and only the hosts listening for the IP multicast traffic are disturbed. IP multicast addresses can be used only as the destination IP address.. They fall into the class D space and addresses in the range 224.0.0.0 – 239.255.255.255 are reserved for multicast.