Wingate's DHCP Server assigning wrong DNS servers

[Darr]

It seems Wingate's DHCP Service does not pay attention to the Preferred Order the DNS servers are listed, in the Global Options of DHCP Settings.
e.g. this is the order in which they're entered

DNS Preference Order entered in Wingate

DHCP-GlobalOptions-DNS.PNG (6.82 KiB) Viewed 5908 times

But this is the order in which they're actually assigned (via MAC reservation, and yes - I checked that there is no DNS setting overriding the Global Options in the Reservation's Options)

Actual DNS Preferences Assigned

TivoNetworkStatus.png (213.63 KiB) Viewed 5908 times

Extra info...
8.8.8.8 and 8.8.4.4 are google's free DNS servers
68.28.154.91 and 68.28.146.91 are Sprint's 3G DNS servers
4.2.2.4 is one of Comcast's DNS servers
192.168.222.250 is my 3G router's LAN address, which would typically relay DNS requests to the DNS server[s] its WAN port is assigned when it gets an IP from Sprint.

The only machine I use the Sprint DNS servers on is the laptop that I use most, and I override the Global Options shown above by using the DNS server option in that laptop's DHCP reservations (I have one for its ethernet MAC and another for its wireless MAC). The sprint DNS servers are inaccessible so often that I added the google DNS servers (which I have never found to be inaccessible), but keep the Sprint DNS servers on my laptop just so I can document when they're down in order to have specific dates/times when I complain to Sprint about it. Everything else here I want to use Google's DNS servers by default.
Almost everything goes straight to the router's LAN IP as the gateway, since I only have a 6-node license... when I want to track or limit a node's bandwidth, then I change that node's Router option in DHCP to point to the wingate machine's IP as the Gateway and force it through wingate's NAT. Only rarely do I disable wingate's NAT entirely and force a node to use its proxy server settings in order to see the exact URL the node is connecting to rather than only the sockets (IP:port) that Gatekeeper displays when in NAT mode.

I do not generally use wingate's DNS relay, though I do have all 6 of those DNS server IPs entered in the DNS/WINS Resolver Configuration 'Name Servers' field (not in the same order as DHCP's Global Options, but not in the order shown on that Tivo system information screen, either).

So, is that enough info to reproduce this, or do you need more?

Thanks.

[adrien]

Hi

Actually we store all DHCP option data in the registry in binary format, and preserve order.

So those DNS servers will be going back to the DHCP client in the order you defined.

One way to tell for sure would be to do a packet capture (e.g. Wireshark) and see what goes over the wire.

Is it possible the client is ignoring the order? What is the client device?

Regards

Adrien

[Darr]

Hi
One way to tell for sure would be to do a packet capture (e.g. Wireshark) and see what goes over the wire.

Good idea, I'll have a look at it with the BOOTP 'view' filter applied.

Is it possible the client is ignoring the order? What is the client device?

The client in the screen grab is a Tivo Premiere XL, which is their newest model, and it has the newest firmware.
I assumed it could only use what it was given, but according to wireshark, wingate is in fact offering them in the order I have entered

DHCP Response, DNS Options

TIVO-XL-BOOTP.png (34.62 KiB) Viewed 5899 times

So I guess my next stop will be support.tivo.com to ask them why it's not using them in the order given.

Thanks for the quick response.

[labull]

We've seen sort of the same problem here when the equipment manufacturer only allows a Class C address. They assume the device will only be on a home network and that's all they allow for.

Don't know if it's the same problem but it sounds like it.

[Darr]

We've seen sort of the same problem here when the equipment manufacturer only allows a Class C address. They assume the device will only be on a home network and that's all they allow for.

Don't know if it's the same problem but it sounds like it.

Well, except that none of the DNS servers I have spec'd are class C besides the router's LAN, and that's not one of the three the Tivo chose to accept, anyway.

CIDR has been in use on the internet for nearly 20 years now, so enforcing classes at all is as bad as microsoft's handling of class C IPs with masks smaller than /24. In that case, with versions prior to Vista SP2 and server 2008 SP1, they use and listen for the wrong broadcast address.
e.g. given 192.168.0.0 /22 (255.255.252.0), the broadcast address should be 192.168.3.255, but in windows NT/95/98/2000/XP/vista and server 2000/2003/2008 (win3.x didn't have the problem because its TCP stack was not supplied by microsoft), the broadcast address used and listened for is 192.168.0.255, as if the mask is still 255.255.255.0, so they often don't play nice on class C networks with linux/mac/java/et al devices.
I have a feeling that's why Apple uses 10.x.x.x /24 by default on their home networking equipment.