Anycast DNS im Mesh?

Technik
1

Moin,

gibt es Communities, die schon Erfahrungen mit Anycast DNS gemacht haben? Wenn ja, wie habt ihr das gemacht? Gab es Probleme und funktioniert es zuverlässig?

Mir fallen spontan zwei Lösungswege ein:

  • man überlässt batman-adv das Problem, so dass es effektiv eine Anycast MAC wird.
  • oder man bringt es dem auf den meisten Gateways/Supernodes laufenden Routingdaemons bei.

Schön wäre auch, wenn der DNS Server später problemlos in jeden Knoten integriert werden könnte. Daher finde ich die Option mit dem Routingdaemon geeigneter.

2

Wir nutzen bereits Anycast DNS für Rheinufer. Für V6 muss accept_dad für das Interface abgeschaltet werden. In V4 haben wir extra IPs nur für Anycast DNS.
Bei V6 nutzen wir die link-local Adresse der Gateways (fe80::1)

Klappt bis jetzt 1A :slight_smile:

2 „Gefällt mir“
3

Habt ihr das irgendwo Dokumentiert? Bzw. wie wurde das von euch realisiert? Bei IPv6 ists klar, aber bei v4?

4

So wie ich es gerade sehe haben wir für V4 das Anycast gar nicht in Verwendung.
Kann sein das es nach Tests nicht so 1A lief. Für v6 gibt es aber keine Probleme.

Dazu sollte gesagt werden das V4 im FFRL als legacy behandelt wird und so nicht viel Beachtung geschenkt wird.

1 „Gefällt mir“
5

Deswegen hatte ich gefragt :slight_smile: Kann mir irgendwie nicht vorstellen, dass das gut funktioniert mit v4 (im FF Netz).

Sehe ich auch so :slight_smile:

1 „Gefällt mir“
6

Für Anycast V4 würde ich wie folgt vorgehen:

  • MACVLAN hinzufügen (für alle server mit jeweils unterschiedlicher MAC)
ip link add link br0 br0anycast address 52:54:00:ca:ff:ee type macvlan
ip addr add 10.40.0.1 dev br0anycast
ip link set up dev br0anycast
  • Dnsmasq /DHCPD beibringen als DNS Server immer die 10.40.0.1 zu verteilen.

Habs so nicht getestet aber man kann es ja auch erst mal ohne Änderungen am DNSMasq / DHCPD ausprobieren.

7

Ich würde es eher anders realiseren:
Man nehme eine IP-Adresse (die DNS service IP) außerhalb der Mesh-Wolke und lege diese auf der Supernode auf das Loopback interface. DNS Server auf der Supernode starten und fertig ist der Anycast DNS.

Wenn man das ganze getrennt haben will: OSPF, RIP oder BGP Session zwischen Supernode und einer beliebigen Maschine (die natürlich auch im Mesh sein kann) aufsetzen, service IP zur Supernode announcen und DNS Server starten.
Wenn ich recht überlege ginge das auch mit statischen Routen auf den Supernodes…

1 „Gefällt mir“
8

An so etwas hatte ich auch gedacht. Dabei würde jedoch der Server möglicherweise auch von selbst mal jene IP als Absender-IP verwenden (preferred_lft 0 könnte dagegen helfen) und der Host selber wäre nicht im traceroute zu sehen. Vielleicht bekommt man das mit Networknamespaces und veth-Paaren schöner hin.

9

Ich hab mich dazu gerade mal mit einem batman-adv Entwickler unterhalten. Vermutlich funktioniert das nicht gut und führt dazu, dass sich die Hosts permanent gegenseitig Roamingpakete für die MAC zuschicken.

10

Dieser Fall sollte für DNS nicht eintreten, da bind ja per listen-on{}; und query-source{}; trennen kann.

11

Sowas dachte ich mir schon :frowning: Schade
Dann wird wohl die Lösung von @takt am sinnvollsten für IPv4 sein.

12

Bei KBU rennt anycast seit längerer Zeit ohne das Netz zu überlasten.

13

Ich habe nun Anycast DNS über den Routingdaemon implementiert:

Auf den Gateways ist das Interface anycast-dns mit der IPv6 2001:67c:2d50:1::a82:7fe0/128 konfiguriert. anycast-dns ist ein dummy-Interface, das lediglich dazu dient dem Host die IP zuzuweisen.

Zusätzlich ist in der Routingconfig (bird6) eine statische Route über das Interface auf die IP definiert, damit die anycast Route über das IGP zwischen den Gateways und im Mesh verteilt wird.

protocol static anycast_dns {
  route 2001:67c:2d50:1::a82:7fe0/128 via "anycast-dns";
}

Somit kann man einen der Gateways mittels ip link set down anycast-dns aus dem anycast Verbund entfernen und mit up wieder einfügen (Vorsicht: Auf Systemen mit systemd v219 aktiviert networkd das Interface sofort wieder!).

Die Routen sehen dann so aus (wenn auf allen Gateways anycast DNS aktiv ist):

[1] 23:12:25 [SUCCESS] holstentor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 dev anycast-dns
    via fe80::5054:ff:feee:5cd7 on freifunk-hl

[2] 23:12:25 [SUCCESS] huextertor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 dev anycast-dns
    via fe80::5054:ff:feee:5cd7 on freifunk-hl

[3] 23:12:25 [SUCCESS] burgtor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 dev anycast-dns
    via fe80::dcad:caff:fefe:461d on freifunk-hl

[4] 23:12:26 [SUCCESS] muehlentor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 dev anycast-dns
    via fe80::5054:ff:feee:5cd7 on freifunk-hl

Wenn man es testweise auf drei der vier Gateways deaktiviert, reagiert das Routing sofort:

[1] 23:14:05 [SUCCESS] burgtor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 dev anycast-dns

[2] 23:14:05 [SUCCESS] huextertor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 via fe80::5054:ff:feee:5cd7 on freifunk-hl 

[3] 23:14:05 [SUCCESS] holstentor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 via fe80::5054:ff:feee:5cd7 on freifunk-hl

[4] 23:14:06 [SUCCESS] muehlentor.luebeck.freifunk.net
2001:67c:2d50:1::a82:7fe0/128 via fe80::5054:ff:feee:5cd7 on freifunk-hl

Ein Client, der permanent Anfragen an die anycast Adresse sendet, bekommt davon nichts mit.

Wir haben außerdem (experimentelles) NAT64 laufen, das 2001:67c:2d50:1::10.130.64.0/114 auf 10.130.64.0/18 abbildet. Somit ist der anycast DNS auch unter 10.130.127.224 erreichbar.

1 „Gefällt mir“