Hacker News Reader

Comment by fixermark | Hacker News Reader

That default, sadly, would basically guarantee the thing doesn't work for all too many users. And as a consumer electronics product (especially in the sub-$50 price-range), the market-smart thing to do is configure the defaults to work in the saddle-point of worst-case and common scenario (i.e. badly-configured local router talking to a standards-hostile ISP's DHCP configurations).

View on HN

> That default, sadly, would basically guarantee the thing doesn't work for all too many users.

Bold claim. Citation needed.

The proper thing to do is to use the DNS settings the DHCP server provided and testing those settings by providing a server the device can lookup and connect to (with TLS). If the server proved it's authenticity, the DNS settings work. (some devices might cache this result, others might do this during startup)

If an error occurs or a reasonably short timeout expires, the device can: if it has UI the user will see, it can report the problem to the user and ask if it's ok to try a common fix (which can be explained in detail in an optional "[technical details]" popup). If the user approves, then retry with the hardcoded DNS server (or any other workaround). If the device doesn't have a UI that could realistically ask this type of question, automatically trying the fix when the DNS test fails might be appropriate.

TL;DR - don't make assumptions about the user's situation, even if you think it is "market-smart". Test for the required behavior and fail-safely by enabling the common workarounds.

> it can report the problem to the user

How? And what should the user do with that information?

This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.

> This device is not architected for users who know what DNS, DHCP, or TLS are, much less who care.

The only technical data I suggested showing the user was an optional "technical details" popup, for the rare cases when someone (perhaps you) actually was interested in that information.

> How?

Iff there is a useful UI, the same way they show anything to the user. I suggested automatically failing over to the hardcoded DNS server (or similar workarounds) automatically. (If the device is literally a lightbulb and the only "UI" is if the lightbulb is on or off, user interaction doesn't make sense; just failover.

> And what should the user do with that information?

At a minimum, the are informed that something about their network required using a workaround. However, you seem to be missing the point: the minimal amount of user interaction I'm suggesting isn't (primarily) about informing the user. It's about asking permission to use their network contrary to how their network asked to be used. You are a guest on their network..

(if the DHCP server didn't provide a DNS serer, then there is no problem; just use a known server)

More importantly, I'm mostly talking about testing and failing over to a the builtin DNS server, instead of simply assuming it's needed in "some" cases and turning it on for everyone. This shouldn't be difficult. The DHCP already happened, do the DNS lookup and check a special URL over TLS. If it fails or times out change the DNS to Cloudflare or Google's service and retry.

That seems to add a lot of logic and interaction complexity to work around a problem that is only a problem for people who already have the technical skill to remap 8.8.8.8 to their preferred DNS server anyway.

> don't make assumptions about the user's situation

Using 8.8.8.8 is exactly the opposite of an assumption. It always works in any config, that's the point.

EDIT: Besides, obviously, the OP's extremely unusual config, where he is effectively just blocking the service with his firewall. Why isn't he outraged about having to unblock all of YouTube's other IPs? What's special about 8.8.8.8?

The point that 8.8.8.8 doesn't always work. The linked article is about highlighting exactly that.

8.8.8.8 isn't a youtube IP, it's Google's DNS service. Most networks hand out their own DNS and generally expect clients on their network to be using it. While most consumer home networks are very permissive not every network is and not respecting the dns server handed to a client by DHCP is broken behavior.

I adressed these points already in other places through this thread: Why would it be any different if they just hardcoded the IP to YouTube? Would that also be "not respecting the DNS server from the DHCP client"? What if they used a proprietary protocol (not DNS) to look up the IP to YouTube?

Just because your network provides a DNS server does not mean that it makes sense to use that DNS server for every single IP address lookup in every piece of software. It's there for general internet browsing purposes, not specialized proprietary purposes like this.

Reply on news.ycombinator.com