Information Technology

Note to Mac users:  If we added DNS entries to your laptop, you may remove those now.

As our students are well aware, there was an issue with the Rocklin wireless network affecting Mac users.  For those of you that are interested in the problem (and the solution), here’s the details.  I’ll break this into three parts:

Part A:  Additional Bandwidth = Network Reconfiguration

Recently we purchased an additional 10Mbit downstream connection from our ISP (Surewest).  This more than doubled our available capacity, as we previously provided a single 6Mbit connection for the entire Rocklin campus.

The 10Mbit connection is allocated solely to our students through A) the wireless network and B) the wired network jacks in the Residence Halls.  Faculty and staff users do not have access to this network segment; all traffic generated is from students.  This change was made as part of our campaign to improve the overall Internet experience for our university users.

Part B:  Network Reconfiguration = DNS Reconfiguration

Now, we’ll start to get more technical:  Several network resources (our Intranet page, Moodle, the Helpdesk ticket system) are hosted on a local web server.  When the wireless network and admin/staff shared one internet connection, clients on the wireless network could directly access those resources through our internal LAN.  Therefore, DNS was configured to provide internal IP addresses for these resources.

With the new separation of wireless traffic, wireless users must use the external IP address of our local web server.  On Monday, our network consultant made the appropriate changes enabling access to internal resources for wireless users.

Part C:  Macs Don’t Like Lots of DNS Servers!

In part B, we stepped on Mac users’ toes by telling DHCP to distribute five different DNS servers to each client.  Apparently this was not a problem for Windows-based computers.  I worked on a few Mac laptops Tuesday morning, and saw the same problem again and again.  The first three DNS servers were internal only, used to load our wireless logon page, and would not resolve external addresses (google.com, for example). 

Rather than trying the external servers specified at positions #4 and #5, the Mac would simply give up.  The user could not access any website beyond the wireless logon page.  Our solution was to eliminate all but two DNS servers in our DHCP configuration.

Thanks for your patience with us, and thanks for letting us know that there was a problem.  We’re improving our project implementation process to avoid future situations like this.  Sometimes even the best-laid plans fail… at least for Macs.