Netzwerkspezi Mikrotik/Pihole/Unbound: DNS-SRV als A?

[Jens M. (schuchkleisser)]

Hallo,
ich bräuchte mal die Hilfe eines Netzwerkspezis:
Gegeben ist ein LAN, in dem ein spezielles "antikes" Gerät benutzt 
werden soll. Der Hersteller gibt keine Updates mehr, aber aus 
Kostengründen möchte ich es weiterbenutzen.
Dieses Gerät muss sich zu einem Server verbinden und fragt dazu eine IP 
via DNS an und benutzt den A-Eintrag.
Dummerweise hat der zu nutzende Dienst aber nur noch SRV-Einträge aktiv, 
d.h. das Gerät bekommt keine A-IP mehr und kann sich nicht mehr 
verbinden.

Gebe ich einen Dienst an, der noch A-Einträge hat, klappt alles, aber es 
muss eben dieser spezielle Dienst sein.
Ich könnte nun manuell mal einen SRV abfragem und den ersten Eintrag als 
Adresse eintragen, zu dem gibt es einen A-Eintrag und die Sache klappt 
auch.
Aber: der Witz des SRV ist ja, das sich die Einträge ändern können...

Jetzt ist die Frage:
Ich habe einen Mikrotik-Router, da es mehrere logische getrennte Netze 
vor Ort hat, und in dem Netz läuft ein Odroid mit Dietpi/PiHole/Unbound.
Kann mir jemand sagen, ob ich z.B. mit einem Mikrotikscript, dem Pihole 
oder einer Unbound-Trickserei z.B. eine Fantasiedomain intern im Gerät 
eintrage, der DNS merkt das, holt einen passenden SRV, schaut den ersten 
funktionierenden Server nach und antwortet das als A an das Gerät?
Angeblich soll das mit einem Unbound-Trick gehen, aber ich kann gerade 
so das Dietpi installieren und dann via Webseite den Pihole einrichten, 
Linus ist jetzt nich so meins. Nachmachen geht, wenn ich ein Tutorial 
habe.

Danke für jede Idee...

[Εrnst B. (ernst)]

Jens M. schrieb:
> Gegeben ist ein LAN, in dem ein spezielles "antikes" Gerät benutzt
> werden soll.

Internet-Radio?

vielleicht hilft das weiter:
https://github.com/milaq/YCast

[Jens M. (schuchkleisser)]

Nee, eine Telefonanlage.
Die letzte Firmware ist von 2019, und die hat mal 3000€ gekostet.
Würde ich nur ungern alles rausreißen und neumachen für nix, weil tut 
ausreichend und man kennt sich aus. Bloß das eben der Provider sein DNS 
umgestellt hat (noch geht's, aber bald ist schluss) und das der einzige 
Grund wäre für einen Austausch.
Eine Fritze davorschalten und die Anlage als Nebenstellen der 
Fritzanlage machen ginge auch ist aber irgendwie bah.
Ein Providerwechsel würde evtl helfen, aber es ist abzusehen das alle 
auf SRV umsteigen, zudem ist das nicht gewünscht wg. spezieller Tarife.
Ob man über die Leitung überhaupt an andere Server RTP und SIP 
rausbekommt steht noch auf einem anderen Blatt.

[Εrnst B. (ernst)]

Jens M. schrieb:
> Nee, eine Telefonanlage.

Ok, aber muss die soviele verschiedene Server erreichen?
Wenn's nur ein paar Trunks sind, würde ich die domains im unbound als 
override konfigurieren.

Das unbound-config-file dazu kann man dann automatisch per Script 
erstellen lassen,

for DOMAIN in sipgate.de easybell.com trunk.vodafone.de t-offline.de ; do
  SRV=$(dig +short _sip._udp.$DOMAIN SRV)
  IFS=" " read -r priority weight port target <<< "$SRV"
  IP=$(dig +short $target A)

# Config-File schreiben
  echo -e "local-zone: \"$DOMAIN\" redirect\nlocal-data: \"$DOMAIN A $IP\"" > /etc/unbound/overrides.d/${DOMAIN}.conf
done

(unbound kann einzelne Files / alles in einem Ordner includen, d.H. dein 
Script kann die Datei jedesmal from Scratch frisch schreiben, oder auch 
eine Datei pro Domain)
und dann ein
unbound-control reload oder systemctl reload unbound


Das Script ist nur ein grobes Beispiel, ohne Fehlerbehandlung falls ein 
"dig" fehlschlägt oder was unerwartetes liefert!

[Jens M. (schuchkleisser)]

Ah,ich glaube du hast mich verstanden, aber ich dich leider nur 
teilweise. ;)

Nein, die Anlage muss nicht "so viele" Server erreichen, aber der eine 
Registrar wird eben bald nicht mehr via A erreichbar sein.
Er (bzw. der DNS dazu) liefert jetzt schon SRV mit einer Liste aus je 
nach Versuchszeit 5-10 anderen Servern, die sich auch immer stark 
unterscheidet, da wird wohl Loadbalancing gemacht.
Und gewisse Server tauchen immer mal wieder auf, die hab ich einfach mal 
manuell benutzt, da bekomme ich ein A und es funzt.
Nur weiß ich eben nicht, ob das so bleibt, bzw. bin ich recht sicher das 
es nicht so bleibt, dazu ist SRV ja da...

Helf mir kurz:

for DOMAIN in sipgate.de easybell.com trunk.vodafone.de t-offline.de ; do
  SRV=$(dig +short _sip._udp.$DOMAIN SRV)
  IFS=" " read -r priority weight port target <<< "$SRV"
  IP=$(dig +short $target A)

# Config-File schreiben
  echo -e "local-zone: \"$DOMAIN\" redirect\nlocal-data: \"$DOMAIN A $IP\"" > /etc/unbound/overrides.d/${DOMAIN}.conf
done

1. Führe für jede Domain in der Liste die Schleife aus, mit dem 
Domainnamen in $DOMAIN
2. Hole die SRV-Einträge für SIP aus der Domain nach $SRV
3. Bitte? Bin kein Linuxer, was ist das? Bringt irgendwie die Server aus 
der $SRV nach $TARGET
4. Holt zum ersten (?) $TARGET die A-IP
7. erzeugt eine sipgate.de.conf die so aussieht:

local-zone: sipgate.de redirect
local-data: sipgate.de A 1.2.3.4

Ähnlich dann mit easybell.com, vodafone und telekom.
So reime ich mir das zusammen, DOS-Batches kann ich einigermaßen, ich 
nehme an das ist bash o.ä.
Das müsste ich dann vmtl. als "x.sh" auf meinem Odroid speichern und via 
cron z.b. 1x täglich aufrufen lassen?

Das geht schon in die Richtung in die ich will.
Vielen Dank schonmal für die Anregung!

[Εrnst B. (ernst)]

Jens M. schrieb:
> 1. Führe für jede Domain in der Liste die Schleife aus, mit dem
> Domainnamen in $DOMAIN

exakt.

> 2. Hole die SRV-Einträge für SIP aus der Domain nach $SRV

Genau. der SRV-Eintrag schaut dann z.B. so aus: "0 0 5060 sipgate.de."
an der Stelle könnte man ein

test -z "$SRV" && continue

ergänzen, und mit dem nächsten Eintrag weitermachen wenn kein SRV Record 
vorhanden ist.

> 3. Bitte? Bin kein Linuxer, was ist das? Bringt irgendwie die Server aus
> der $SRV nach $TARGET

"IFS" setzt den "Internal Field Seperator" auf ein Leerzeichen, das 
braucht das "read" um die einzelnen Felder in der $SRV-Variable 
auseinanderzutrennen.

> 4. Holt zum ersten (?) $TARGET die A-IP

Ja, nur der erste.

> 7. erzeugt eine sipgate.de.conf die so aussieht:

genau.

Mach dir keine Sorgen wegen den ständig rotierenden SRV-Records für das 
Load-Balancing. Neuere Telefonanlagen fragen den auch nicht ständig 
frisch ab, sondern verwenden eine einmal aufgelöste IP auch für eine 
längere Zeit weiter.

Problem wäre allerdings, wenn einer der Server im SRV ausfällt, dann 
würde dieses Setup den offline-server weiter versuchen, und nicht die 
anderen probieren.
Evtl, aber das darfst du selber nachschauen, lassen sich auch mehrere 
A-Records im unbound hinterlegen, dann könntest du nicht nur den ersten, 
sondern alle SRV-Einträge nutzen.

Jens M. schrieb:
> Das müsste ich dann vmtl. als "x.sh" auf meinem Odroid speichern und via
> cron z.b. 1x täglich aufrufen lassen?

Kannst du auch stündlich oder noch häufiger machen. Die paar 
DNS-Abfragen per dig machen keinen signifikanten Traffic.


Ach ja, potentielle Falle: Das dig in der "x.sh" sollte natürlich nicht 
den unbound selber befragen.
Also "dig +short _sip._udp.sipgate.de SRV @1.1" oder "@192.168.1.1" oder 
"@8.8.8.8" oder so....

[Jens M. (schuchkleisser)]

Wenn das klappt bist du mein Held...
Komme leider dies WE nicht zum spielen, aber das werde ich auf jeden 
Fall testen müssen...

Εrnst B. schrieb:
> Ach ja, potentielle Falle: Das dig in der "x.sh" sollte natürlich nicht
> den unbound selber befragen.

Soweit ich verstehe fragt der Odroid selbst den im OS eingetragenen DNS 
ab, weil bei Updates des Pihole eben dieser beendet wird und das Netz 
dann kurz offline ist, der Odroid kann aber seine Updates ziehen weil er 
ja selber "raus kann".
Der Unbound ist m.W. nur die Quelle für den Pihole, der dann ja auch den 
DNS-Server stellt. Das Dietpi-Linux dagegen ist ja Client und fragt 
Upstream den Router.

Εrnst B. schrieb:
> Evtl, aber das darfst du selber nachschauen, lassen sich auch mehrere
> A-Records im unbound hinterlegen, dann könntest du nicht nur den ersten,
> sondern alle SRV-Einträge nutzen.

Soweit mir bekannt ist genau das das Problem: der Client kann damit 
nicht umgehen.
Daher muss ich ihm ja einen (am besten: einen funktionierenden) A-Record 
aus der SRV-Liste vorgaukeln.
Soweit mir bekannt wird ein nicht bereiter Server aber nicht mehr per 
SRV ausgeliefert, d.h. die SRV-Liste enthält funktionierende Server in 
der Reihenfolge der Leistungsbereitschaft. "Der Erste" ist also 
eigentlich genau richtig.

Εrnst B. schrieb:
> Problem wäre allerdings, wenn einer der Server im SRV ausfällt, dann
> würde dieses Setup den offline-server weiter versuchen, und nicht die
> anderen probieren.

In dem Fall würde ich einfach alle 30 Minuten aktualisieren, dann geht 
das halt mal "kurz" nicht. Keine Ahnung wie oft die Anlage selbst den 
Registrar kontaktiert...
Gibts vielleicht eine Möglichkeit, die Abfrage von "server.com" als 
Trigger zu benutzen? So von wegen das Script wird angestupst wenn die 
Anlage fragt, was neben einer eventuellen zeitgesteuerten Aktualisierung 
ja auch passiert wenn die Anlage merkt "ey, der tut nicht mehr"...

[Εrnst B. (ernst)]

Jens M. schrieb:
> Soweit mir bekannt ist genau das das Problem: der Client kann damit
> nicht umgehen.

Mehrere "A" Einträge für einen Hostnamen sind schon viel länger üblich 
als "SRV"-Einträge. Würde mich wundern wenn der Client damit ein Problem 
hat.
Vor allem weil das üblicherweise schon eine Ebene tiefer, im 
Betriebssystem, abgehandelt wird.

Jens M. schrieb:
> Gibts vielleicht eine Möglichkeit, die Abfrage von "server.com" als
> Trigger zu benutzen? So von wegen das Script wird angestupst wenn die
> Anlage fragt

Klar, die Antwort vom x.sh kommt da zwar zu spät für den aktuellen 
Request, für den Nächsten ist sie aber da.
Also dem unbound ein Log-File und
  log-queries: yes
konfigurieren (Wenn das bei pihole nicht eh default ist)
und dann ein y.sh:

  tail -F /var/log/unbound.log | while read line
  do
     if echo "$line" | grep -q "server.com" ; then
         x.sh
     fi
  done

Als Erweiterung macht vmlt. eine Limitierung der Aufrufhäufigkeit Sinn, 
also z.B. ein

  TIMESTAMP=$(date +%s)
  if ((TIMESTAMP - LAST_TIMESTAMP > 60)) ; then
     x.sh
     LAST_TIMESTAMP=$TIMESTAMP
  fi

Oder im x.sh das Alter der zu erzeugenden Config-Datei überprüfen, und 
nichts machen wenn die zu jung ist...

[Jens M. (schuchkleisser)]

Hammer! :D
Jede Menge Platz zum spielen!!!

Ich bastel da mal ein wenig dran rum, bin gespannt. Du hast mir 
zumindest soweit ich das mit meinem geringen Linuxwissen sagen kann 
schon sehr weitergeholfen, da kann ich viel probieren und lernen. Danke!

Εrnst B. schrieb:
> Mehrere "A" Einträge für einen Hostnamen sind schon viel länger üblich
> als "SRV"-Einträge.

Ja, ich als nicht-Netzwerkspezi frage mich warum das nicht "einfach" 
über etliche A's gemacht wird und stattdessen A komplett deaktiviert und 
nur noch SRV ausgeliefert wird.
Ginge ja auch beides gleichzeitig, A für alte Geräte, SRV für schlaue 
neue. Aber man muss ja funktionierende Hardware entsorgen, wenn man das 
Geld dieses Jahr nicht braucht bekommt man es nächstes nicht mehr.
Aber SRV soll lt. Support eben Priorisieren können, wohingegen A keine 
Reihenfolge hat.
Leider kann ich dem System nicht zukucken, aber ich vermute, das 
ebenfalls einfach der erste ankommende A benutzt wird und das wars. 
Sonst würde nicht ausdrücklich darauf hingewiesen werden, das der 
Betrieb mit "aktualisierten Dienstleistern" nicht mehr möglich ist und 
man doch bitte die nächste Generation kaufen soll.
Aber ich könnte ja testen das Skript so zu erweitern das es alle SRV in 
einen A packt, dann sollte es am besten funktioneren, sofern die Anlage 
das kann, und wenn nicht ist es eine Lernung für mich, macht es aber 
nicht schlimmer von der Funktion.

Εrnst B. schrieb:
> Klar, die Antwort vom x.sh kommt da zwar zu spät für den aktuellen
> Request, für den Nächsten ist sie aber da.

Vermutlich wird der Client nach einer Abfrage eine Verbindung aufbauen. 
Wenn die dann nicht klappt, wird m.E. noch eine Abfrage kommen, die dann 
ein aktualisiertes Ergebnis liefert, von daher wäre das Failsafe, denke 
ich.
Und wie gesagt: Wenn es überhaupt geht ist es schon mehr als wie jetzt 
wo es eben gar nicht mehr geht. Wenn dann mal ne halbe Stunde fehlt ist 
das eben so.
Zur Not startet man die Geräte neu, dann sollten sie aktualisieren...