DNS/dig-abfrage und Firewall

[nikord]

Hallo Forum,
ich habe auf meinem Rootserver einen DNS-Server laufen und jetzt probeweise die Suse-Yast2-Firewall installiert. Zusätzlich zu den normalen Diensten habe ich Port 53 und 1023 (ohne jeden Zusatz) für den DNS-Server freigegeben.
Nach der Aktivierung der Firewall kann ich aber trotzdem den DNS-Server von _aussen_ nicht mehr per dig abfragen (zeitüberschreitung).
Bedeutet das, dass der DNS-Server generell nicht mehr von aussen erreichbar ist und damit ja nicht mehr seine Funktion ausüben kann oder ist das ein Problem dass nur dig betrifft?

Niko

[sascha]

Das bedeutet dass dein Nameserver generell nicht mehr von aussen erreichbar ist. Ich kenne die SuSE Firwall nicht aber hast du daran gedacht den Port 53 für UDP freizugeben?

[nikord]

Hallo Sascha,

hast du daran gedacht den Port 53 für UDP freizugeben?

Genau das ist das Problem, es gibt keine Möglichkeit das näher zu bestimmen. Man kann lediglich einen Port (als einfache Zahl) bzw. einen Dienst freigeben - und das habe ich gemacht.
Dann ist das Teil wohl doch nicht für mich geeignet.

Vielen Dank für die Info!

Niko

[[tom]]

Ich kenn Deine Firewall nicht, aber schreib doch

Code: Select all

53/TCP

und

Code: Select all

53/UDP

[TOM]

[robertw]

Das bedeutet dass dein Nameserver generell nicht mehr von aussen erreichbar ist. Ich kenne die SuSE Firwall nicht aber hast du daran gedacht den Port 53 für UDP freizugeben?

DNS-Abfragen funktionieren sowohl über TCP, also auch über UDP. Es reicht daher, wenn nur eines der beiden IP-Protokolle auf der Firewall freigeschaltet ist. Dabei ist auf einer Firewall TCP eindeutig vorzuziehen, da verbindungsabhängig.

Leider kenne ich die Suse-Firewall nicht und kann daher nur raten: Du musst sowohl eingehende, als auch ausgehende Verbindungen für diesen Port freischalten.

Robert

[dodolin]

DNS-Abfragen funktionieren sowohl über TCP, also auch über UDP.

ACK.

Es reicht daher, wenn nur eines der beiden IP-Protokolle auf der Firewall freigeschaltet ist.

Quark mit Sosse!

Ich empfehle, RFC 1123 zu verinnerlichen. Ja, der ist lang... - aber wichtig!

Zu diesem Thema Kapitel 6.1.3.2 Transport Protocols (Anm.: bzgl. DNS).

DNS resolvers and recursive servers MUST support UDP, and
SHOULD support TCP, for sending (non-zone-transfer) queries.
Specifically, a DNS resolver or server that is sending a
non-zone-transfer query MUST send a UDP query first. If the
Answer section of the response is truncated and if the
requester supports TCP, it SHOULD try the query again using
TCP.

DNS servers MUST be able to service UDP queries and SHOULD
be able to service TCP queries. A name server MAY limit the
resources it devotes to TCP queries, but it SHOULD NOT
refuse to service a TCP query just because it would have
succeeded with UDP.

Truncated responses MUST NOT be saved (cached) and later
used in such a way that the fact that they are truncated is
lost.

DISCUSSION:
UDP is preferred over TCP for queries because UDP
queries have much lower overhead, both in packet count
and in connection state. The use of UDP is essential
for heavily-loaded servers, especially the root
servers. UDP also offers additional robustness, since
a resolver can attempt several UDP queries to different
servers for the cost of a single TCP query.

It is possible for a DNS response to be truncated,
although this is a very rare occurrence in the present
Internet DNS. Practically speaking, truncation cannot
be predicted, since it is data-dependent. The
dependencies include the number of RRs in the answer,
the size of each RR, and the savings in space realized
by the name compression algorithm. As a rule of thumb,
truncation in NS and MX lists should not occur for
answers containing 15 or fewer RRs.

Whether it is possible to use a truncated answer
depends on the application. A mailer must not use a
truncated MX response, since this could lead to mail
loops.

Responsible practices can make UDP suffice in the vast
majority of cases. Name servers must use compression
in responses. Resolvers must differentiate truncation
of the Additional section of a response (which only
loses extra information) from truncation of the Answer
section (which for MX records renders the response
unusable by mailers). Database administrators should
list only a reasonable number of primary names in lists
of name servers, MX alternatives, etc.

However, it is also clear that some new DNS record
types defined in the future will contain information
exceeding the 512 byte limit that applies to UDP, and
hence will require TCP. Thus, resolvers and name
servers should implement TCP services as a backup to
UDP today, with the knowledge that they will require
the TCP service in the future.

By private agreement, name servers and resolvers MAY arrange
to use TCP for all traffic between themselves. TCP MUST be
used for zone transfers.

A DNS server MUST have sufficient internal concurrency that
it can continue to process UDP queries while awaiting a
response or performing a zone transfer on an open TCP
connection [DNS:2].

A server MAY support a UDP query that is delivered using an
IP broadcast or multicast address. However, the Recursion
Desired bit MUST NOT be set in a query that is multicast,
and MUST be ignored by name servers receiving queries via a
broadcast or multicast address. A host that sends broadcast
or multicast DNS queries SHOULD send them only as occasional
probes, caching the IP address(es) it obtains from the
response(s) so it can normally send unicast queries.

DISCUSSION:
Broadcast or (especially) IP multicast can provide a
way to locate nearby name servers without knowing their
IP addresses in advance. However, general broadcasting
of recursive queries can result in excessive and
unnecessary load on both network and servers.

Dabei ist auf einer Firewall TCP eindeutig vorzuziehen, da verbindungsabhängig.

Ja, es macht schon Sinn, sich gegen "MUST" aus RFCs zu widersetzen. :twisted: Das soll aber bitte jeder selbst entscheiden und wenigstens über die Folgen informiert sein... Zudem würde dann alles verzögert sein, da so ziemlich jeder Client zuerst mal UDP versucht und erst nach dem Timeout auf TCP umsteigt (s.o.). Nuja... Und warum man sich als Default für UDP und nicht für TCP entschieden hat, ist ja im obigen Zitat erklärt...

[[tom]]

Es reicht daher, wenn nur eines der beiden IP-Protokolle auf der Firewall freigeschaltet ist.

Quark mit Sosse!

FULL ACK

Zudem würde dann alles verzögert sein, da so ziemlich jeder Client zuerst mal UDP versucht und erst nach dem Timeout auf TCP umsteigt (s.o.).

Wenn überhaupt! Ein 3-Hand-Handshake TCP Connect mit kompletten Header macht für DNS wenig Sinn.

[TOM]