Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Antworten
Fourty2
Beiträge: 104
Registriert: 06 Jan 2005, 13:56

Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Beitrag von Fourty2 »

Hallo,

beim Aufräumen der DNS Einträge im Router wollte ich für die unnötigen doppelten Einträge im LC1783 (FW 10.40) einfach den internen DNS (im LAN) abfragen. Problem: das funktioniert aus der DMZ nicht, egal, was ich (bisher) anstelle...

Es gibt u.a. die Netze LAN = 1001 (VLAN/ARF) und DMZ = 1003 (VLAN/ARF).
Im LAN (1001) ist das Forwarding ok, der Ziel-DNS wird abgefragt.

Aus der DMZ passiert Folgendes:

Code: Alles auswählen

[DNS] 2020/08/11 11:26:28,079
DNS Rx (DMZ): Src-IP 192.168.3.2, RtgTag 1003
Transaction ID: 0xb7e6
Flags: 0x0100 (Standard query, No error)
Queries
  _http._tcp.hpa.***.de: type SRV, class IN

STD SRV for _http._tcp.hpa.***.de
DnsGetDest: Match found: forwarding _http._tcp.hpa.***.de to 192.168.1.1,192.168.2.1
Not found in local DNS database => forward to next server

[DNS] 2020/08/11 11:26:28,080 [info] :
create new destination map entry for 192.168.1.1,192.168.2.1 with routing tag 1003
DestinationMapEntry for 192.168.1.1,192.168.2.1 with routing tag 1003 created
DNS servers: 192.168.1.1 Rtg-Tag: 1003, 192.168.2.1 Rtg-Tag: 1003
create new source map entry for 192.168.3.2
using DNS server 192.168.1.1
transport could not be created: route to null
DestinationMapEntry for 192.168.1.1,192.168.2.1 with routing tag 1003 destroyed

[DNS] 2020/08/11 11:26:28,080 [info] :
no dns server available on 192.168.1.1,192.168.2.1
Firewall-Regel richten nichts aus, das "transport could not be created: route to null" bleibt.
Der Server ist aus der DMZ per Regel erreichbar. Nur der LC Resolver mag nicht.
Bug, oder habe ich was übersehen?

Stefan
Nach oben
GrandDixence
Beiträge: 1061
Registriert: 19 Aug 2014, 22:41

Re: Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Beitrag von GrandDixence »

Wenn der LANCOM-Router-interne DNS-Forwarder die anzusprechenden DNS-Server (Forwarder: IP 192.168.1.1 und 192.168.2.1) nicht über Routing-Tag (RtgTag) 1003 oder 0 ansprechen kann, so bleiben die DNS-Anfragen aus "DMZ = 1003 (VLAN/ARF)" unbeantwortet.

Die IP-Adressen der zu verwendenden DNS-Forwarder lassen einen über das lokale Netzwerk erreichbaren DNS-Server vermuten, welcher über LAN-x angesprochen werden kann. In diesem Fall sollte die Konfiguration:

Code: Alles auswählen

LCOS-Menübaum > Setup > DNS > DNS-Weiterleitungen

Domainname (Domäne):   *
Rtg-Tag (Tag):   1003
Gegenstelle:  192.168.1.1@1001
aus der Patsche helfen => LANCOM-Router interner DNS-Forwarder frägt für DNS-Anfragen aus der DMZ (Routing-Tag 1003) den DNS-Server 192.168.1.1 per Routing-Tag 1001 an.

Bei Umkonfigurationen im DNS-Bereich immer einen Kaltstart des LANCOM-Routers durchführen, bevor man den ersten Test durchführt!
Nach oben
Fourty2
Beiträge: 104
Registriert: 06 Jan 2005, 13:56

Re: Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Beitrag von Fourty2 »

Genau das wars, was mir partout nicht wieder einfallen wollte:

"192.168.1.1@1001".

Das "@" schwirrte im Kopf rum, aber das Lancom wollte es da nicht, wo ich es probiert hab.
Immerhin macht jetzt das dnsmasq entsprechendes. Mal sehen, was bleibt.
:-)

Danke,
Stefan
Nach oben
GrandDixence
Beiträge: 1061
Registriert: 19 Aug 2014, 22:41

Re: Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Beitrag von GrandDixence »

Beim Einsatz von DNSMasq sollte aus Sicherheitsgründen die Unterstützung von DNSSEC eingeschaltet werden:
https://community.upc.ch/t5/Sicherheit/ ... 15357#M250

Sobald DNSSEC eingesetzt wird, dürfen keine DNS-Anfragen mehr über den LANCOM-Router internen DNS-Forwarder laufen!

DNS-Anfragen mit DNSSEC funktionieren nur einwandfrei, wenn alle DNS-Forwarder "DNS over TCP" (RFC 7766) und EDNS unterstützen. Und das aktuelle LCOS unterstützt kein "DNS over TCP" (RFC 7766)! Siehe auch:

lancom-feature-wuensche-f22/dns-transpo ... 16059.html

https://en.wikipedia.org/wiki/Extension ... ms_for_DNS

aktuelle-lancom-router-serie-f41/dns-tls-t18007.html

Die DNSSEC-Unterstützung kann man wie folgt testen:

Code: Alles auswählen

Positiv-Test
------------------------------------------------------------------------
# dig +multili +dnssec www.nic.ch
=> status: NOERROR
=> flags: ad
=> EDNS: version: 0, flags: do;
=> SERVER: 127.0.0.1


# dig +multili +dnssec www.nic.cz
=> status: NOERROR
=> flags: ad
=> EDNS: version: 0, flags: do;
=> SERVER: 127.0.0.1


Negativ-Test
-----------------------------------------------------------------------
# nslookup www.rhybar.cz
=> Got SERVFAIL reply from 127.0.0.1

Ausführlicher Test:
# dig +multili +dnssec www.rhybar.cz
=> status: SERVFAIL


TCP-Test
--------------------------------------------------------------------------------
# dig +multili +dnssec ux.cnlab.ch

=> Truncated, retrying in TCP mode.

=> status: NOERROR
=> flags: ad
=> EDNS: version: 0, flags: do;
=> SERVER: 127.0.0.1
oder ganz einfach mit dem Aufruf der Webseite:
https://dnssec.vs.uni-due.de/

Daumen hoch?

Der Einsatz von DNSMasq erhöht zudem dank dem DNS-Cache die Performance bei DNS-Anfragen. Der LANCOM-Router-interne DNS-Forwarder verfügt über keinen DNS-Cache. Für mehr Informationen zum Thema "DNS-Cache" siehe die "Gute Performance Regel Nr. 23" unter:
https://community.upc.ch/t5/Internet-mi ... 3388#M8849

Die Performance des DNS-Cache von DNSMasq kann mit dem Eintrag:

Code: Alles auswählen

cache-size=10000
in der DNSMasq-Konfigurationsdatei /etc/dnsmasq.conf weiter verbessert werden.
Zuletzt geändert von GrandDixence am 19 Nov 2020, 21:46, insgesamt 2-mal geändert.
Nach oben
Fourty2
Beiträge: 104
Registriert: 06 Jan 2005, 13:56

Re: Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Beitrag von Fourty2 »

Auf der Website kommt "Daumen hoch". Ja.

Das dig liefert:

Code: Alles auswählen

root@Dana:~# dig +multili +dnssec www.nic.ch

; <<>> DiG 9.11.5-P4-5.1+deb10u1-Debian <<>> +multili +dnssec www.nic.ch
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 17581
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
; COOKIE: 969f0271de493d5c0db95ad35f32b904cb8679ea503e6abc (good)
;; QUESTION SECTION:
;www.nic.ch.            IN A

;; ANSWER SECTION:
www.nic.ch.             3600 IN A 130.59.31.80
www.nic.ch.             3600 IN RRSIG A 13 3 3600 (
                                20200903001615 20200806113002 16948 ch.
                                fxySDRNh+Os/IgkDNzYe2it71BzjZfagZZo1TH/BKPMV
                                rkZNwpYNtZKGGhqqCpMNy4o5Rb79/JoUFoF1GEHfQg== )

;; Query time: 29 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Di Aug 11 17:28:04 CEST 2020
;; MSG SIZE  rcvd: 181
Erstmal zwecks Test den bisher laufenden pdnsd ersetzt. DNSSec ist nicht bewußt aktiv. Hat welche Vorteile / Nachteile?
(Vom DNS-Eintrag stammt vom erhofften Erzeuger abgesehen)

Weil, ich habe ja bisweilen eine andere Vorstellung von "sicher", daher bricht unser Squid auch SSL auf:

Code: Alles auswählen

==> /var/log/squid/access.log <==
Aug 11 15:37:31    442 192.168.1.3 TCP_MISS/200 1058 GET https://api.twitter.com/2/badge_count/badge_count.json? - HIER_DIRECT/104.244.42.66 application/json
Aug 11 15:37:31    661 192.168.1.3 TCP_MISS/200 5150 GET https://api.twitter.com/2/guide.json? - HIER_DIRECT/104.244.42.66 application/json
Aug 11 15:37:32    752 192.168.1.3 TCP_MISS/200 1309 GET https://api.twitter.com/2/notifications/all.json? - HIER_DIRECT/104.244.42.66 application/json
Aug 11 15:37:32    373 192.168.1.3 TCP_MISS/400 874 POST https://api.twitter.com/1.1/live_pipeline/update_subscriptions - HIER_DIRECT/104.244.42.66 application/json
Aug 11 15:37:34    239 192.168.1.3 NONE_NONE/200 0 CONNECT api.twitter.com:443 - HIER_DIRECT/104.244.42.66 -
Grüße,
Stefan
Nach oben
GrandDixence
Beiträge: 1061
Registriert: 19 Aug 2014, 22:41

Re: Probleme mit Weiterleitungen des DNS Forwarders aus DMZ

Beitrag von GrandDixence »

Fourty2 hat geschrieben: ↑11 Aug 2020, 17:49 Auf der Website kommt "Daumen hoch". Ja.
Nein! => Wegen dem fehlenden "ad"-Flag sollte der Mann auf dieser Webseite "heulen".
daher bricht unser Squid auch SSL auf:
Da wird mir höchstens zum Heulen zu mute. Wer im Jahr 2020 noch nicht begriffen hat, dass jeglicher privater Datenaustausch aus Sicherheitsgründen End-to-End verschlüsselt erfolgen sollte und der Einsatz von Proxys nur für unverschlüsselte Netzwerkverbindungen sinnvoll ist, dem ist nicht zu helfen...
https://de.wikipedia.org/wiki/Ende-zu-E ... %BCsselung

Wenn man mit einem SSL-Proxy die End-to-End-Verschlüsselung aufbricht, untergräbt man ja bewusst den Sicherheitsvorteil, welcher eine End-to-End-Verschlüsselung bringt. Und all diese SSL-Proxys bringen bei skeptischen Hinschauen unter dem Strich weniger Sicherheit, als Ihr Verkäufer mit all seinen tollen Argumenten zu Überwachungs-, Antivirus-, SPAM- und Malware-Schutzfunktionen des zu verkaufenden SSL-Proxys vorgaukelt.

In der IT-Security-Branche lässt sich mit dem Unwissen der Kunden gutes Geld verdienen, die garnieren gerne mit dem Angebot von "supertollen" SSL-Proxys ab.

=> Geheimdienste werden SSL-Proxys lieben!

Da zum Glück immer mehr Daten verschlüsselt übertragen werden, ist das Proxy-Zeitalter (zum Glück) definitiv vorbei...

Oben genannte Aussagen gelten auch sinngemäss für "Application Layer Firewall":
https://de.wikipedia.org/wiki/Firewall# ... _Firewall)
Nach oben
Antworten

Zurück zu „Fragen zur LANCOM Systems Routern und Gateways“