pfSense

While this is convenient to you as you have a dynamic prefix, there are some situations where this might not be desired.

RDNSS and DNSSL in RA are optional configurations as per the RFC. It’s up to the network administrator to configure these as necessary, depending on the network.

In pfSense 2.4.4, using Managed mode (M flag set) or Stateless DHCP (O flag set), there was no way of not configuring RDNSS. Even if the DNS servers fields in RA configuration were left blank pfSense would advertise either the Interface address of the DNS Forwarder or Resolver (if enabled) or fallback to the system DNS server.

This also violates the RFC you specified as it doesn’t give the network administrator the option to disable RDNSS or DNSSL. When these fields are not configured or intentionally left blank in the RA configuration, IMHO, pfSense should allow RDNSS or DNSSL to be disabled (if that is desired by the network administrator).

As per RFC 8106, section 1.1 states that RDNSS in RA is not a MUST:

RA-based DNS configuration is a useful alternative in networks where an IPv6 host's address is autoconfigured through IPv6 SLAAC and where either 
(i) there is no DHCPv6 infrastructure at all or 
(ii) some hosts do not have a DHCPv6 client. 
The intention is to enable the full configuration of basic networking information for hosts without requiring DHCPv6. However, for networks that need to distribute additional information, DHCPv6 is likely to be employed. In these networks, RA-based DNS configuration may not be needed.

You need to read to the end of RFC 8106. Section 1 is the rational why RDNSS was added to the Router Announcements.

It states in Section 1.2 that Hosts that conform to RFC 4861 Neighbor Discovery for IP version 6:

"MUST extract DNS information from RA messages, unless static DNS
configuration has been specified by the user. If there is DNS
information available from multiple RAs and/or from DHCP, the host
MUST maintain an ordered list of this information as specified in
Section 5.3.1."

RDNSS and DNSSL in RA are not optional. This has been the case since at least 2017 when IPv6 was standardized in RFC 8200 (STD: 86) Internet Protocol, Version 6 (IPv6) Specification.

See also RFC 8504, Best Current Practice 220, IPv6 Node Requirements.

Chapter 8. Configuring Non-address Information, specifically 8.3

"8.3. IPv6 Router Advertisement Options for DNS Configuration - RFC 8106

Router Advertisement options have historically been limited to those
   that are critical to basic IPv6 functionality.  Originally, DNS
   configuration was not included as an RA option, and DHCP was the
   recommended way to obtain DNS configuration information.  Over time,
   the thinking surrounding such an option has evolved.  It is now
   generally recognized that few nodes can function adequately without
   having access to a working DNS resolver; thus, a Standards Track
   document has been published to provide this capability [RFC8106].

Implementations MUST include support for the DNS RA option [RFC8106]."

I think the real issue is making certain that the RDNSS DNS Server is the correct DNS. Currently it can be manually set by the network administrator. The wording is pretty clear. Leave blank to use the system default DNS servers - this interface's IP if DNS Forwarder or Resolver is enabled, otherwise the servers configured on the General page.

The extract that you've posted is in Section 1.2 which immediately follows Section 1.1 (which describes how RDNSS in RA is a useful alternative and may not be needed in some cases).

Section 1.2 explains the case where DNS information is present in BOTH RA and DHCPv6 Options. In such a case, then IPv6 host MUST extract the DNS information from the RA messages along with the information from DHCPv6. However, the author does not mention that RDNSS and DNSSL are mandatory Options in IPv6 ND messages.

In Section 4, it is also suggested that an "IPv6 host CAN configure one or more RDNSSes via RA messages" and that "RA options for RDNSS and DNSSL CAN be used". "MUST" is not used.

The existing ND message (i.e., RA) is used to carry this information. 
An IPv6 host can configure the IPv6 addresses of one or more RDNSSes via RA messages. 
Through the RDNSS and DNSSL options, along with the Prefix Information option based on the ND protocol [RFC4861] [RFC4862], an IPv6 host can perform the network configuration of its IPv6 address and the DNS information simultaneously without needing DHCPv6 for the DNS configuration. 
The RA options for RDNSS and DNSSL can be used on networks that support the use of ND.

Regarding [RFC 8504]

Implementations MUST include support for the DNS RA option [RFC8106]

This can be interpreted as "having the ability to process/understand DNS RA option when being received", rather than mandating it to be set in the RA.

We are just going to have to disagree then because multiple RFC's say the same thing. I have been writing and reading specs for 30 years and requirements words have specific meanings. The word CAN in an overview paragraph does not make it optional. "MAY" is optional, "CAN" is equivalent to "is able to". If they wanted it to be optional they would have said MAY configure.

"2. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119]."

These are the words that establish requirements. Everything else is explanation and clarification.

Regardless, what is your goal with this change? What is it you are trying to accomplish in your pfsense configuration that you can't now?

The only outcome of this change is that you will have a router that will prevent ipv6 compliant hosts on your network from being able to receive the DNS server you want. The result will be that these hosts will just use Google DNS. IPv6 hosts are not required to support DHCP and many of them do not.

I think paragraph 8.3 of RFC 8106 states it best. Router Advertisements are limited to critical functionality, and now DNS is considered to be part of that.