>>164977Das Hauptproblem ist, wie Felix nun gerade mit Erschrecken feststellen musste, dass es nicht auf Port 53 laufen darf. Wobei es ohnehin TCP und nicht UDP ist.
>...unless it has mutual agreement with its server to use a port other than port 853 for DNS over TLS. Such another port MUST NOT be port 53
>This recommendation against use of port 53 for DNS over TLS is to avoid complication in selecting use or non-use of TLS and to reduce risk of downgrade attacks.
>The first data exchange on this TCP connection MUST be the client and server initiating a TLS handshake using the procedure described in [RFC5246].
>There are significant security issues in mixing protected and unprotected data, and for this reason, TCP connections on a port designated by a given server for DNS over TLS are reserved purely for encrypted communications.
Das mit dem "ihr dürft Port 53 nicht verwenden" ist sehr unsinnig. Anstatt das Sinnvolle zu machen und zu sagen: Wenn ihr DoT auf einem Port anbietet, dürft ihr darauf nichts anderes anbieten (was eigentlich fickend immer so ist).
Beim "mixing protected and unprotected data" muss man bedenken, dass DNS auf _UDP_ läuft, DoT hingegen auf _TCP_. Da muss schon eine Menge schiefgehen, wenn man annimmt, dass plötzlich die ungeschützten Daten statt auf einen UDP-Port nun an einen TCP-Port gehen. Aber Felix hat es mal weiter gesponnen.
Felix hat mit der DNS- und DoT-Paketstruktur rumgespielt, und ein _gutartiges_ DNS-Paket könnte ein Client Hello bis Byte 5 replizieren, wird aber dann immer spätestens bei Byte 8 abgelehnt. Ein _bösartiges_ DNS-Paket kann natürlich identisch wie ein DoT-Paket aussehen. Sowieso klar: Der DoT-Servierer muss eben ordentlich, auch gegen bösartige Anfragen, implementiert sein (auch z.B. getestet via Fuzzing).
Aber Felix versteht dann doppelt nicht, warum "da können aber auch DNS-Pakete reinkommen" da noch irgendwie relevant sein sollte. Es gibt hierbei schlicht keine "security issues in mixing protected and unprotected data", und auch keine "downgrade attacks", die über TLS hinausgehen (wie die dort auch in Abschnitt 8 schreiben), und die man mit einem schlichten "Downgrade auf unter TLS 1.2 verboten" (und erst recht "Downgrade auf DNS verboten" und "Umbiegen von TCP auf UDP verboten") nicht beheben könnte. Man trägt ja gerade einen DoT-Servierer bei sich ein, weil man weiß, dass der DoT kann. Auf dem Port 53 wird dann schlicht _nur_ DoT angeboten und nie etwas runtergradiert.
Warum steht das überhaupt was von "downgrade"? Mal in die Evolution vom Standard schauen:
>7. Design Evolution
>Earlier draft versions of this document proposed an upgrade-based approach to establish a TLS session. The client would signal its interest in TLS by setting a "TLS OK" bit in the Extensions Mechanisms for DNS (EDNS(0)) flags field. A server would signal its acceptance by responding with the TLS OK bit set.
>Since we assume the client doesn't want to reveal (leak) any information prior to securing the channel, we proposed the use of a "dummy query" that clients could send for this purpose. The proposed query name was STARTTLS, query type TXT, and query class CH.
>The TLS OK signaling approach has both advantages and disadvantages. One important advantage is that clients and servers could negotiate TLS. If the server is too busy, or doesn't want to provide TLS service to a particular client, it can respond negatively to the TLS probe. An ancillary benefit is that servers could collect information on adoption of DNS over TLS (via the TLS OK bit in queries) before implementation and deployment. Another anticipated advantage is the expectation that DNS over TLS would work over port 53. That is, no need to "waste" another port and deploy new firewall rules on middleboxes.
>However, at the same time, there was uncertainty whether or not middleboxes would pass the TLS OK bit, given that the EDNS0 flags field has been unchanged for many years. Another disadvantage is that the TLS OK bit may make downgrade attacks easy and indistinguishable from broken middleboxes. From a performance standpoint, the upgrade-based approach had the disadvantage of requiring 1xRTT additional latency for the dummy query.
>Following this proposal, DNS over DTLS was proposed separately. DNS over DTLS claimed it could work over port 53, but only because a non-DTLS server interprets a DNS-over-DTLS query as a response. That is, the non-DTLS server observes the QR flag set to 1. While this technically works, it seems unfortunate and perhaps even undesirable. DNS over both TLS and DTLS can benefit from a single well-known port and avoid extra latency and misinterpreted queries as responses.
Joooooooo es war also eine alte Version vom Standard, in der man upgraden/downgraden konnte. Und das Verbot an anderer Stelle im Standard, DoT nicht auf Port 53 anzubieten, ist dann einfach drin geblieben, obwohl der Grund weggefallen ist.
Aber hey, die erwähnten DNS over DTLS, das benutzt UDP! Sehr gut, das gefällt Felix direkt noch besser, und auch noch weniger Bloat! Schauen wir doch dort mal rein...
>Such another port MUST NOT be port 53
https://datatracker.ietf.org/doc/html/rfc8094#section-3.1
Verfickt nochmal! Die habens einfach rüberkopiert! Kein Wunder, dass dieser Kack nirgends Anschluss findet, weil die am Leben vorbeirennen.