I would like to put more information into the IPv6 router advertisement packets: several DNS servers (and especially the IP of the router itself) into the rdnss field, several domain names into the dnssl field etc. Where do I edit and add those fields?
Currently you can’t, it’s not much configurable yet. DNS servers are simply taken from “/ip dns”, but you don’t want to add router’s own address there.
You can combine it with DHCPv6. If you add server without pool, it will function in stateless mode and only provide info (you’ll have to enable “Other Configuration” in “/ipv6 nd” for clients to use it). There you can add any option you like.
7.1beta has support for DNS in RA, until then use DHCPv6 option 23
Can you kindly provide an example, with 2 DNS servers?
Glad to see they finally implemented that, but it is missing the DNS search list option.
Sure I don’t want to, but putting the router’s own IPv6 address into router advertisements (if a DNS server is enabled on the router of course) would be a good idea, don’t you think?
Can I both have DHCPv6 server enabled and keep advertise-dns=yes in “/ipv6 nd”? Is this a supported configuration?
RouterOS does it a bit odd.
If “Advertise DNS” flag is enabled in ND, it will advertise all/any IPv6 addresses set in the IP>DNS fields, whereby the client devices would directly be communicating with said addresses bypassing RouterOS’s stub resolver completely. If the flag is disabled, the client devices will end up using the stub resolver on RouterOS.
You can confirm this with connection tracking, packet sniffing etc. Or simply look for “IPv6 DNS” in your client devices.
How would they know to use it?
What do you mean “how”? If the flag is disabled, client devices will automatically fall back to the IPv4 DNS address that was originally advertised with DHCP, so that would be the Router’s IP address unless you use PiHole like I do or some other DNSSinkhole.
Flag enabled = Direct IPv6 to IPv6 (public internet) for the DNS queries based on any/all IPv6 addresses inside IP>DNS.
Flag disabled = fallback to native IPv4 DNS “server” which can be the router’s IP or some other public or local IPv4 address that you’ve configured on IP>DNS/IP>DHCP Server.
Ah, I thought you meant “will end up using the stub resolver on RouterOS over IPv6”, so I was surprised how they would learn it.
I see.
Yeah, so really, there is no problem with RouterOS’s approach to IPv6 DNS, you can use the stub resolver, or you can use direct public resolvers on a per-client basis or even like I do… Simply re-direct to a DNSSinkhole and use a custom stub resolver/DNS forwarded/recursive DNS server.
Well, if the clients are IPv6 only, there will be no fallback to IPv4 DNS for them.
I hate the practice of intercepting or modifying clients’ DNS traffic. It’s basically an attack. I hope this practice will die off naturally as soon as more domains and hosts adopt DNSSEC (or DoH, whichever first).
I fail to understand why some people choose to use IPv6 for internal networking, stick with IPv4 for internal networking (which includes the DNS stub resolver), I mean IPv6 was created to restore the end to end principle and not as an alternative to IPv4 internal networking.
It depends on the practice use/objective. What I do is run a Pi-Hole instance for filtering/blocking ads/malware domains, which is a DNS Sinkhole, now for the actual DNS queries, all of them are redirected from the client to Pi-Hole and then from Pi-Hole(DNS forwarder) to dnscrypt-proxy (DNS stub resolver) and then finally DoH on Cloudflare.
You got the right idea. Using IPv6 for internal networking has exactly this purpose: to restore the end to end principle. Not all protocols work well through NAT, and some require ugly kludges to work through NAT (like SIP).
Sure, I also have to use SkyDNS to filter sites in a classroom because traffic filtering for minors is required by Russian law, but it does not prevent me from hating this practice.
What? IPv6 was designed with SLAAC in mind, there’s absolutely no NAT or ugly hacks needed with a proper prefix delegation from the upstream provider. Unless you have an upstream provider like mine who blocks ICMPv6 and breaks MTU along with a garbage single /64 prefix.
DNS for IPv6 should be handled either with your idea of the public to public query or an IPv4 stub resolver, even then, ALL public IPv4 DNS resolvers can resolve AAAA queries.
What “what”? 
You said you fail to understand why some people choose to use IPv6 for internal networking (your words?). I explained that some people choose to use IPv6 for internal networking to avoid NAT and its ugly hacks, because IPv6 restores the end to end principle. What is it that you don’t agree with?
Why not an IPv6 caching resolver in the router?
IPv6 internal networking = Killing SLAAC as you implied with your “IPv6 only clients”, why wouldn’t they have IPv4 internal addresses aka RFC1918? Dude with IPv6 we have SLAAC, we use IPv4 for INTERNAL use. IPv6 with SLAAC will automatically delegate publicly routable prefixes to each individual client. Where in the hell does NAT come into the picture with native IPv6 SLAAC?
IPv6 caching resolver in RouterOS is already possible with “Advertise DNS” set to off, how many times do I need to say this?
Few points:
-
IPv6 is supposed to eventually replace IPv4, so IPv6-only networks make sense. Only when you do it now, you may be a little bit too ahead. Most of the internet is still IPv4-only, so you need NAT64 + DNS64, which is not exactly nice (mainly the DNS64 part). That said, it’s not wrong, you can build clean IPv6-only internal network like this.
-
With RouterOS v7 you can freely configure DNS for both DHCPv6 and RA. But you probably don’t want v7 in production yet. RouterOS v6 can do it only for DHCPv6.
-
Whether DHCPv6 is enough depends on clients. Android is known for boycotting it for addresses, but I’m not sure if it applies also to additional info (when network has “Other Configuration” in ND).
-
While it would be possible (for v6) to put router’s own address in IP->DNS, and it would advertise it, it’s probably not good idea. I assume that router would be sending queries to itself and it wouldn’t work well. Perhaps if you used only IPv4 upstream resolvers (in order to not give any other IPv6 resolvers to clients) and if you’d block queries to itself using firewall, it could work, but it wouldn’t be nice solution.