BT Smart Hub IPv6 Stateless forced DNS options

[paulby]

@licquorice Automomy is achieved inv4 using RFC 1918 addressing of your choice which will never change as the BT Hub will perform PAT/NAT to the Global v4 address on the provider side of the router.

To remove the IPv6 RDNSS delivery, the only choice you have is to cut your own legs off and "hope" that the /56 GUA v6 prefix that's delivered to your BT Hub never changes (which by right it could/should/might) otherwise you'll find your home v6 GUA that's self-managed in the "off" state on v6 on the router completely cut off from the Internet.

For the sake of broad speech and the majority, all operating systems are dual-stack and default to v6. So without turning v6 off, one is unable to control your DNS settings.

Interesting point made by @ptrduffy about the precedence, though as a general statement "determism is better than probablism", I would suggest the better policy/traffic engineering outcome would be for that ICMPv6 RDNSS offer _not_ to be present alongside and DHCPv6 offers and to be reasonably controlled by any of the previously suggested mechanisms.

I will with time next week look to see how a host behaves with both the ICMPv6 RDNSS offer and the DHCPv6 offer to see if any precedence is taken as a matter of curiousity and feedback.

So, @NeilO any thoughts from the Hub Team yet?

Have a great weekend
Regards

Paul

[paulby]

Afternoon @NeilO . Bumping this into your attention stream. The posts ebbing and flowing in the thread I think give a useful context of the request. Looking forward to hearing from you.

Paul

[licquorice]

With all due respect, I really don't see BT putting expenditure and resource into a so called problem that will affect at the very most 0.0001% of the customer base. In fact I very much suspect you are in a minority of 1.

The Home Hub is a mass produced cheap and cheerful device aimed at a mass market.

[paulby]

@licquoricewith all due respect, I'll await a response from @NeilO and if this isn't the right forum to raise the configuration for consideration, I'll happily redirect it to a more appropriate forum.

[ptrduffy]

@paulby were you able to test behaviour when the host gets both the RDNSS option and a DHCP offered server?

[paulby]

As yet, no. I’ll give it a try and report. I’d torn dnsmasq down and considered life with inconsistent DNS state before posting. It’ll take me a week to spin that all up again, so in the meantime I hope that’s not a blocker to the Hub Team considering the option. 

[licquorice]

From rfc 8106

 In the case where the DNS information of RDNSS and DNSSL can be
   obtained from multiple sources, such as RAs and DHCP, the IPv6 host
   SHOULD keep some DNS options from all sources.  Unless explicitly
   specified for the discovery mechanism, the exact number of addresses
   and domain names to keep is a matter of local policy and
   implementation choice as a local configuration option.  However, in
   the case of multiple sources, the ability to store a total of at
   least three RDNSS addresses (or DNSSL domain names) from the multiple
   sources is RECOMMENDED.  The DNS options from RAs and DHCP SHOULD be
   stored in the DNS Repository and Resolver Repository so that
   information from DHCP appears there first and therefore takes
   precedence.  Thus, the DNS information from DHCP takes precedence
   over that from RAs for DNS queries.  On the other hand, for DNS
   options announced by RAs, if some RAs use the Secure Neighbor
   Discovery (SEND) protocol [RFC3971] for RA security, they MUST be
   preferred over those that do not use SEND.  Also, DNS options
   announced by RAs via SEND MUST be preferred over those announced by
   unauthenticated DHCP [RFC3118].  Refer to Section 7 for a detailed
   discussion of SEND for DNS RA options.

[ptrduffy]

@licquorice thanks for the RFC text - I was fairly certain that the RFC suggested precedence be given to DHCP delivered addresses, but good to see it in black and white.

The issue, as ever with RFCs (and standards in general), is that this is specified in a SHOULD clause as opposed to a MUST clause, which leaves us potentially in an implementation-dependent situation.  I'm interested to see what @paulby finds when he gets dnsmasq up and running again.

[mhoam]

@licquorice 

If you switch off the DHCP services on the BT Hub then you can use a different device to provide IP4 addresses to your local network. This INCLUDES the provision of the required IP4 DNS server, so all your internal devices can pick up the DNS servers you wish to use.

In Stateless mode, IP6, according to the standard you MAY recommend IP6 DNS servers but one cannot turn this off in the BT Home HUB. ALL my IP6 devices receive IP6 DNS servers from the BT hub, even though that is NOT what I want.

I support the original request

[sw25481]

This is outrageous.  I can't believe more people are not up in arms about it.

I have a device on my network that protects my children from going to unsavory sites by blocking them from looking them up in DNS.  I have been using it for years.  I have my DHCP give out the device as an IPv4 DNS server.  Today I realized that all my Windows devices had learned the BT Home Hub as a DNS server and are bypassing the controls.

And you can not turn this off on the BT Home Hub 

You can't turn off IPv6 at all anymore and you can't stop it advertising itself as an IPv6 DNS server

I only realized when I tried to look up a fully qualified domain name on my own network.  The BT Hub has learned all the devices on my network and had been busy responding to short name queries so I had been fooled into thinking I was using my own DNS server.