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.

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