bind9 unter SuSE 8.1

[robertw]

herzlichen dank an alle, die halfen das eigentliche problem ist gelöst. dennoch bitte diesen thread erhalten!

1. wohin kann ich die finalversion posten, um anderen zu helfen? die vorlagen funktieren so nur zum teil (habe alles dokumentiert - und sei es nur für mich selbst :) )

ich würde gerne
a. mein komplettes firewallscript für alle anbieten
b. meine config plus howto für den dns-server irgendwo sehen...

Schau mal hier: http://www.rootforum.org/forum/viewtopic.php?t=8934

2. welche ports muss ich in der firewall beachten (iptables), damit der dns-server auch von aussen erreichbar ist...

udp port 53
$IPTABLES -A INPUT -p udp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT


gibt es sosnt noch irgendwelche (ich hoffe das ist nicht zu sehr o.t.)...

Wenn Du schon eine Firewall installieren willst (die Meinung nach der Sinnfälligkeit einer solchen sind hier sehr geteilt), dann solltest Du nur tcp/53 freischalten. Resolver müssen per Standard beide Protokolle unterstützen, da UDP aber verbindungslos ist, ist es unter Firewallgesichtspunkten zu unsicherer.

(Jetzt hier bitte Diskussion über den Sinn oder Unsinn einer Firewall, darüber wurde im Forum schon ausgibigst diskustiert - benutz die Suchen-Funktion!)

3. wie ist die einfachste möglichkeit, ein script bei jedem start zu starten... einfach ins rc.d verzeichnis schmeissen - oder gibt es da noch was einfacheres?

Ich starte meine Script, so wie Du es beschreibst: zwei Links unter /etc/init.d/rc3.d/ gesetzt, einen zum Starten, einem zum Killen.

Robert

[predismo]

ist jetzt so gelöst...
udp muss ich ja zulassen, da sonst ein lokaler lookup für was externes nicht mehr klappt (ping http://www.rootforum.org/)

Code: Select all

$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT

[dodolin]

Wenn Du schon eine Firewall installieren willst (die Meinung nach der Sinnfälligkeit einer solchen sind hier sehr geteilt), dann solltest Du nur tcp/53 freischalten. Resolver müssen per Standard beide Protokolle unterstützen, da UDP aber verbindungslos ist, ist es unter Firewallgesichtspunkten zu unsicherer.

Käse! Ich hatte den entsprechenden RFC schon mal zitiert. Ein DNS MUSS UDP unterstützen und SOLLTE TCP unterstützen. Basta.

Code: Select all

$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT 
$IPTABLES -A INPUT -p tcp --sport 53 --dport 7531 -j ACCEPT 
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT 

Wenn das alles ist und er Rest REJECTed wird, dann gute Nacht, wenn du einen öffentlichen DNS betreiben willst.

[robertw]

Käse! Ich hatte den entsprechenden RFC schon mal zitiert. Ein DNS MUSS UDP unterstützen und SOLLTE TCP unterstützen. Basta.

Und ich habe Dir darauf schon mehrfach geantwortet, denke ich.

Den von Dir beschriebenen RFC möchte ich gerne sehen. DNS wurde mit RFC882 und RFC883 eingeführt (1983), zur Zeit gültig ist RFC1035 von 1987.

Zitat aus RFC883:

Appendix 3 - Internet specific field formats and operations

Message transport

The Internet supports name server access using TCP [10] on server
port 53 (decimal) as well as datagram access using UDP [11] on UDP
port 53 (decimal). [...]

Zitat aus RFC1035:

4.2. Transport

[...]
The Internet supports name server access using TCP [RFC-793] on server
port 53 (decimal) as well as datagram access using UDP [RFC-768] on UDP
port 53 (decimal).

"as well as" heisst im deutchen: sowohl als auch. Eine Klassifizerung in "muss" UDP und "kann" TCP gibt es nicht und gab es in einem RFC auch nie.

Wenn ich dabei für meine Firewall ableite, dass ich UDP 53 blocke, dann verhalte ich mich damit zwar nicht RFC-konform, es dürfte aber keine Auswirkungen haben, wenn ich TCP 53 durchlasse.

Robert

[predismo]

Wenn ich dabei für meine Firewall ableite, dass ich UDP 53 blocke, dann verhalte ich mich damit zwar nicht RFC-konform, es dürfte aber keine Auswirkungen haben, wenn ich TCP 53 durchlasse.

also ich habe (wie ja schon gepostet) das in der firewall
1.

Code: Select all

$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT

in der hoffenung, dass ich keinen müll erzähle "fehlt" wohl eigentlich
2.

Code: Select all

$IPTABLES -A INPUT -p udp --sport 53 --dport 7531 -j ACCEPT

richtig.

kann irgendwer (der das auch im betrieb hat) bestätigen dass die 1.
lösung ohne den 2. - teil läuft und auch ordentlich läuft? wer hat dazu einfach nur mal ein hü oder hott? tausend dank...

[captaincrunch]

Wenn ich dabei für meine Firewall ableite, dass ich UDP 53 blocke, dann verhalte ich mich damit zwar nicht RFC-konform, es dürfte aber keine Auswirkungen haben, wenn ich TCP 53 durchlasse.

Meinst du ? Wenn du unter "keine Auswirkungen" verstehst, dass du durch TCP (das für diese Aufage vollkommen überzogen ist) zusätzlichen Overhead erzeugst, weil
a) sämtliche DNS-Server, die ich kenne es erstmal per UDP probieren, und
b) ein TCP-Paket unerheblich größer ist als ein UDP-Paket ist
stimmt deine Aussage. Ob diese Aussage Sinn macht, steht dann aber auf einem anderen Blatt ...

[dodolin]

Käse! Ich hatte den entsprechenden RFC schon mal zitiert. Ein DNS MUSS UDP unterstützen und SOLLTE TCP unterstützen. Basta.

Und ich habe Dir darauf schon mehrfach geantwortet, denke ich.

Den von Dir beschriebenen RFC möchte ich gerne sehen. DNS wurde mit RFC882 und RFC883 eingeführt (1983), zur Zeit gültig ist RFC1035 von 1987.

Dann kennst du wohl einer der wichtigsten RFCs nicht, die es überhaupt gibt! Tipp: Versuche es mal mit RFC 1123, Requirements for Internet Hosts - Applications and Support.

6.1.3.2 Transport Protocols

[...]

DNS servers MUST be able to service UDP queries and SHOULD be able to service TCP queries.

Es steht dort noch viel viel mehr und alle Nachteile deiner "Lösung" werden ebenso benannt bzw. sollten dann durch Nachdenken klar werden.

[predismo]

laut http://www.linux-mag.com/2002-07/tech_support_01.html

sollte meine version richtig sein.

udp und tcp werden (in der reihenfolge genutzt).
dort steht es zwar etwas anders, aber meines sollte eigentlich tun (omm)...

damit man nicht blättern muss:

Code: Select all

# Erlauben von DNS
$IPTABLES -A INPUT -p udp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT

[dodolin]

# Erlauben von DNS
$IPTABLES -A INPUT -p udp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 1024: --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --sport 53 --dport 7531 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --sport 1024: --dport 53 -j ACCEPT

Dein Server sitzt auf Port 7531? Und wird immer von Port 53 aus abgefragt? Dann ist er ein wenig komisch, finde ich... Ich verstehe immer noch nicht, warum man dazu einen Paketfilter braucht, aber diese Diskussion wollen wir ja nicht noch mal aufrollen. Aber eines ist sicher: Wenn man keine Ahnung hat, was man da mit Paketfiltern treibt und die darunterliegenden Ã?bertraguns- und Applikations-Protokolle nicht versteht, sollte man seine Finger davon lassen. Man richtet sonst mehr Schaden an, als dass es nutzt. Sorry für die deutlichen Worte, aber das musste jetzt mal sein.

[[tom]]

Wenn du unter "keine Auswirkungen" verstehst, dass du durch TCP (das für diese Aufage vollkommen überzogen ist) zusätzlichen Overhead erzeugst, weil
a) sämtliche DNS-Server, die ich kenne es erstmal per UDP probieren, und
b) ein TCP-Paket unerheblich größer ist als ein UDP-Paket ist

c) einige Resolver erst gar nicht TCP versuchen (SHOULD, nicht MUST)

[TOM]

[captaincrunch]

c) einige Resolver erst gar nicht TCP versuchen (SHOULD, nicht MUST)

Danke, hatte ich in der Aufregung verpennt ...

[robertw]

@dodolin, CaptainCrunch

Natürlich kenne ich dieses RFC. Ich denke allerdings, er passt nicht in den Kontext, über den wir hier diskutiert haben. Im RFC und in Euren Diskussionen geht es ausschliesslich um Traffic und Protokoll-Overhead.

Diesen Punkt kann ich komplett nachvollziehen und gehe auch mit den im RFC1123 geführten Diskussionen konform. Unter diesem Gesichtspunkt ist UDP klar TCP vorzuziehen.

Nun ist der RFC allerdings von 1989 und seit dem hat sich das Internet doch sehr verändert. War damals Bandbreite noch extrem wichtig und jedes Byte teuer, hat man heutzutage soviele Ã?berkapazitäten, dass Firmen daran pleite gehen und Sicherheit ist viel, viel wichtiger als damals.

Unsere Diskussion hier wurde angeregt durch die Frage nach einer Firewall. Und unter Sicherheitsaspekten ist TCP grundsätzlich UDP vorzuziehen, vollkommen egal, über welchen Dienst wir reden (da werden mir wohl hoffentlich alle zustimmen).

Die Protokolldefinition RFC1035 sieht für DNS beides gleichberechtigt vor und dies von Anfang an. Später (eigentlich sogar im gleichen Jahr) hat eine andere Gruppe unter den damaligen Gesichtspunkten UDP den Vorrang gegeben.

Eigentlich müsste dieses RFC1123 unter den heutigen Bedingungen neu diskutiert werden.

@[TOM]
Einen solchen Resolver habe ich noch nicht kennengelernt. Ich habe größere Netzwerke mit Firewalls konzipiert und immer nur TPC53 (eingehend!) freigegeben. Von Problemen ist mir nie etwas zu Ohren gekommen. Sonst würde ich dies hier nicht so stark verteidigen. :-)

Und "SHOULD" heisst ja schliesslich nicht "NOT NECESSARY".

:-)

Robert

P.S. Ist immer wieder schön hier so etwas zu diskutieren. Drei Leute, vier Meinungen. Gut das es eben doch noch etwas zwischen 1 und 0 gibt. :-)

[predismo]

ok...
warum der obere port da freigegebn war, weiss ich auch nicht mehr so (dns-proxy?)

so sieht es jetzt aus:

Code: Select all

$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT

[[tom]]

Die Protokolldefinition RFC1035 sieht für DNS beides gleichberechtigt vor und dies von Anfang an. Später (eigentlich sogar im gleichen Jahr) hat eine andere Gruppe unter den damaligen Gesichtspunkten UDP den Vorrang gegeben.

Und das ist auch gut so. Abgesehen von dem Hardwareboost, der für die Root-NS notwendig wäre, kann man mit halboffenen TCP Connects einen NS ganz schön ausbremsen. BTW: Latenzzeiten für DNS sind auch heute noch wichtig.

Eigentlich müsste dieses RFC1123 unter den heutigen Bedingungen neu diskutiert werden.

Wegen TCP? Seh ich nicht so.

@[TOM]
Einen solchen Resolver habe ich noch nicht kennengelernt.

Kennst du dig? Der nimmt nur UDP, wenn du ihn nicht anders zwingst. Gibt sehr viel Spass beim testen oder Troubleshooting. :-/

Und "SHOULD" heisst ja schliesslich nicht "NOT NECESSARY".

Es gibt zwei Arten von SHOULD (sollte). Das eine ist mehr am KANN angesiedelt (umgangssprachlich), das andere mehr am MUSS (juristisch oder Empfehlung).

Hier (RFC allgemein und RFC1123 im Besonderen) ist es so, dass es als Empfehlung zu sehen ist, von der nur in besonderen Fällen abgewichen werden sollt. Auf jeden Fall ist es so, dass nur UDP garantiert werden kann. Außer, es sitzt eine Firewall davor, die UDP/53 rejected. :-)

[TOM]

[robertw]

Eigentlich müsste dieses RFC1123 unter den heutigen Bedingungen neu diskutiert werden.

Wegen TCP? Seh ich nicht so.

Wegen gestiegener Sicherheitsbedürfnisse. Im ganzen RFC ist das Thema Sicherheit nur ein Randthema. So kennt der Abschnitt "REMOTE LOGIN" bisher ausschliesslich TELNET. Würdest Du Deinen Server heute noch via TELNET warten? 1989 war dies noch anders zu sehen.

Kennst du dig? Der nimmt nur UDP, wenn du ihn nicht anders zwingst. Gibt sehr viel Spass beim testen oder Troubleshooting. :-/

Natürlich keine ich dig und diese Eigentschaft - trotzdem 1:0 für Dich da das Programm technisch natürlich ein Resolver ist - ich meinte hier aber andere Programme. Und über die Möglichkeit, die Namensauflösung auf Protokollebene zu steuern, bin ich dem Programm sehr dankbar. Dies ist ein wichtiger Test für mich, ob ein Fehler bei UDP oder TCP auftritt.

Robert

@predismo:

Bei all den Diskussion hier, noch eine Bemerkung zu Deinem Script. Bei den TCP-Regeln solltest Du auch mit "Connection Tracking" arbeiten. man iptables und dann nach dem Parameter --state suchen. Genau dies ist ja der Vorteil von TCP: Verbindungssteuerung!

[dodolin]

Eigentlich müsste dieses RFC1123 unter den heutigen Bedingungen neu diskutiert werden.

Sorry, aber ich glaube nicht, dass du die Kompetenz hast, das zu beurteilen. Wenn er nicht mehr gültig wäre, wäre er von einem anderen RFC "obsoleted" worden. Und mehr möchte ich zu diesem Thema eigentlich nicht mehr sagen, um meine Nerven zu schonen.

Und "SHOULD" heisst ja schliesslich nicht "NOT NECESSARY".

Wie SHOULD in RFCs zu interpretieren ist, ist sogar in einem eigenen RFC festgehalten. Da gibt es nichts zu deuten.

Code: Select all

$IPTABLES -A INPUT -p udp --dport 53 -j ACCEPT
$IPTABLES -A INPUT -p tcp --dport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p udp --sport 53 -j ACCEPT
$IPTABLES -A OUTPUT -p tcp --dport 53 -j ACCEPT

Das letzte sollte wohl eher sport statt dport heissen. Ansonsten sieht es jetzt halbwegs ok aus.

Bei den TCP-Regeln solltest Du auch mit "Connection Tracking" arbeiten. man iptables und dann nach dem Parameter --state suchen. Genau dies ist ja der Vorteil von TCP: Verbindungssteuerung!

Auch, wenn UDP ein verbindungsloses Protokoll ist, kann iptables damit Connection Tracking und somit --state verwenden. Gerade bei DNS funktioniert das sehr gut. Bei ganz speziellen UDP Anwendungen dann allerdings vielleicht nicht mehr...