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