Vista keeps name server options from previous lease

Benjamin Wiechman benw at meltel.com
Sat Sep 22 01:34:22 UTC 2007


Where did you come up with this workaround? 

 

Ben Wiechman

Wisper High Speed Internet

Office: 866.394.7737

Direct: 320.256.0184

Cell: 320.247.3224

ben at wisper-wireless.com

  _____  

From: dhcp-users-bounce at isc.org [mailto:dhcp-users-bounce at isc.org] On Behalf
Of Randall C Grimshaw
Sent: Saturday, September 15, 2007 9:09 AM
To: dhcp-users at isc.org; dhcp-users at isc.org
Subject: RE: Vista keeps name server options from previous lease

 

 

see bottom

-----Original Message-----
From: dhcp-users-bounce at isc.org on behalf of Frank Sweetser
Sent: Sat 9/15/2007 9:19 AM
To: dhcp-users at isc.org
Subject: Re: Vista keeps name server options from previous lease

Kirsten Petersen wrote:
>> What we are
>> seeing with Vista clients is this: the client picks up a lease from the
>> wireless network and gets the options for the main campus name servers.
>> Then, the user plugs into a wired port in the residence hall and gets a
>> new lease from the dhcp server on that network.  However, their name
>> server option does not get updated.  Thus, they don't get redirected to
>> the registration page, because they are talking to the wrong nameservers.

>This sounds like you're running into an issue that's been brought up a
couple
>of times, so far with no resolution.  If you search through the list
archives
>for a thread with a subject of "dhcpinform request from Vista gets wrong
Name
>servers" you'll see all the details, but the short version is that the dhcp
>server uses a slightly different set of logic to calculate what options
should
>be returned to DHCPINFORM requests than DHCPDISCOVER ones.

-------------------------------------------------------------------------

There is a workaround that works much of the time but not all. Vista always
does a dhcpinform request but does not always include the nameserver option
in the request. It seems that the trigger for including the nameserver
option is a failure to resolve IPv6 tunnel coordination server names. The
workaround is to define the servers in your captive DNS. It may not always
be required that they are reachable. As an aside, I was not amuzed to look
up how destructive a teredo is.

; these are the vista workarounds
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.136
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.138
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.140
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.142
teredo.ipv6.microsoft.com.wherever.edu.      IN      A       65.54.227.144
teredo.ipv6.microsoft.com.              IN      A       65.54.227.136
teredo.ipv6.microsoft.com.              IN      A       65.54.227.138
teredo.ipv6.microsoft.com.              IN      A       65.54.227.140
teredo.ipv6.microsoft.com.              IN      A       65.54.227.142
teredo.ipv6.microsoft.com.              IN      A       65.54.227.144
6to4.ipv6.microsoft.com.wherever.edu.        IN      A       192.88.99.1
6to4.ipv6.microsoft.com.                IN      A       192.88.99.1
time.windows.com.wherever.edu.               IN      A       207.46.130.100
time.windows.com.                       IN      A       207.46.130.100
dns.msftncsi.com.wherever.edu.               IN      A       131.107.255.255
dns.msftncsi.com.                       IN      A       131.107.255.255

<><Randy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.isc.org/pipermail/dhcp-users/attachments/20070921/15832205/attachment.html>


More information about the dhcp-users mailing list