Static CNAME DNS Entry has to be flattened
The first is with the DNS Server, reported in MikroTik SUP-192131, “is identified and will be addressed in further RouterOS releases.”
git.kernel.org. resolves as the following in my region…
kexybiscuit@ProArtB550-CREATOR [ linux@master ] $ dig git.kernel.org
; <<>> DiG 9.20.4 <<>> git.kernel.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31730
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 6, ADDITIONAL: 6
;; QUESTION SECTION:
;git.kernel.org. IN A
;; ANSWER SECTION:
git.kernel.org. 1686 IN CNAME geo.source.kernel.org.
geo.source.kernel.org. 600 IN CNAME sg2.source.kernel.org.
sg2.source.kernel.org. 1686 IN A 172.236.150.65
…
However, I’d like geo.source.kernel.org. to be resolved to sea.source.kernel.org., since sg2.source.kernel.org. is unusable in my region due to international link congestion.
So I added the following static entry… looks fine?
/ip dns static add cname=sea.source.kernel.org name=geo.source.kernel.org type=CNAME
However, after adding the entry, resolving git.kernel.org. results into a failure.
kexybiscuit@ProArtB550-CREATOR [ linux@master ] $ dig git.kernel.org
; <<>> DiG 9.20.4 <<>> git.kernel.org
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62647
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;git.kernel.org. IN A
……
Since it’s a SERVFAIL, my first thought was to check the DNS settings, and I found out that the Dnyamic Servers list was empty, which was supposed to be DNS Servers from PPPoE and DHCPv6 Clients.
Even if I readded static DNS servers manually, while other resolving works fine, git.kernel.org. still resolves to the same result as I didn’t add the static entry.
For now, I have to flatten the CNAME chain, add a CNAME entry sea.source.kernel.org directly for git.kernel.org instead of geo.source.kernel.org, which also means I have to do the same thing for all domains which resolves to geo.source.kernel.org. like lore.kernel.org. and so, since they’re still resolving to the server on the congested link. Also, hoping that no domain will have a CNAME to git.kernel.org., or it’ll crash the RouterOS DNS Server again.
Bridge Hardware Offloading and IGMP Snooping enabled together breaks IPv6 Router Solicitations
The second one is just submitted through the service desk, so I’ll just copy the content from there. MikroTik SUP-193239.
Symptom
- On RB5009UG+S+, Enable IGMP Snooping on a bridge whose ports are Hardware Offloaded.
- Create a static MDB entry (Bridge IGMP/MLD snooping - RouterOS - MikroTik Documentation) for Link-Local scope All Routers Address (ff02::2) on all VLANs and ports (including the bridge interface itself) on the bridge.
- Connect devices to the bridge, devices send Router Solicitation Messages to the all-routers multicast address (ff02::2), but never receive solicited Router Advertisement Messages. Packet sniffing shows Router Solicitation Messages are never forwarded to the bridge port of the router, even with the static MDB entry in place. IPv6 SLAAC is half-broken by now, since only unsolicited Router Advertisement Messages are sent out from time to time.
- Disable Hardware Offload on the port which will receive Router Solicitation Messages from the devices. Now Router Solicitation Messages will be forwarded to the bridge port of the router, and solicited Router Advertisement Messages are sent out. IPv6 SLAAC is working by now.
It seems that the problem has been reported previously, like Enabling IGMP snooping destablizes my network - #6 by gfunkdave .
The workaround for now seems to be disable Bridge Hardware Offloading when enabling IGMP Snooping.
This issue appears only after I switched to RB5009UG+S+ from RB4011iGS+, mainly caused by the RTL8367 switch chip on RB4011iGS+ doesn’t support Bridge Hardware Offloading with IGMP Snooping enabled.
. On my RB5009 I tried everything for the past couple of years and already gave up. You’ll need an external device (a smart switch maybe) that can act as querier, or just disable IGMP Snooping for now if you also use IPv6 and VLANs.