search

TechnitiumSoftware / DnsServer

Technitium DNS Server
https://technitium.com/dns/
GNU General Public License v3.0
4.25k stars 418 forks source link

Local technitium trying very hard to talk to upstream VPS technitium via h3 url scheme (DOH), but fails #1050

Open zs311521 opened 2 days ago

zs311521 commented 2 days ago

So works great for https url scheme, as soon as it's switched to H3, I get the following 'errors' It tries to talk though,m but to no avail:

3040 181.845767329 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=41366c5df22eb052, PKN: 0, CRYPTO, PADDING 3041 181.860062710 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=41366c5df22eb052, PKN: 1, CC, PADDING 3042 181.879554084 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=548d36a7b4dc104fea, PKN: 0, ACK, CC, PADDING 3043 181.935555400 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=dd4e44666e8000df, PKN: 0, CRYPTO, PADDING 3044 181.969547377 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=c9857d61c7bfd99a61, PKN: 0, ACK, CC, PADDING 3045 182.064602105 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=1ecb3539fad14685, PKN: 0, CRYPTO, CC, PADDING 3046 182.098473854 Server_IP → Client_IP1 QUIC 1304 Initial, SCID=b589a180c8a76b1393, PKN: 0, ACK, CC, PADDING 3047 201.087865224 Client_IP1 → Server_IP TCP 56 [TCP Keep-Alive] Client_Port1 → 443 [ACK] Seq=692 Ack=578 Win=131136 Len=0 3048 201.087908784 Server_IP → Client_IP1 TCP 68 [TCP Keep-Alive ACK] 443 → Client_Port1 [ACK] Seq=578 Ack=693 Win=64640 Len=0 TSval=Server_Timestamp1 TSecr=Client_Timestamp1 3049 209.083513395 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=cc313fd6d84f17a3, PKN: 0, CRYPTO, PADDING 3050 209.118212003 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=f0e70afe2689e74dbb, PKN: 0, ACK, CC, PADDING 3051 209.170881546 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=245b03b49b8589df, PKN: 0, CRYPTO, PADDING 3052 209.204789026 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=9c3a3b65b3293c0085, PKN: 0, ACK, CC, PADDING 3053 209.256964894 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=9fd1bc98ae8781ba, PKN: 0, CRYPTO, PADDING 3054 209.290764111 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=50cb903a7be69a7fff, PKN: 0, ACK, CC, PADDING 3055 209.338548147 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=acdf98d1e7fd5ea0, PKN: 0, CRYPTO, PADDING 3056 209.372593556 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=88ed9889e16cd78dec, PKN: 0, ACK, CC, PADDING 3057 209.433712668 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=69603abb8f452b69, PKN: 0, CRYPTO, PADDING 3058 209.469279927 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=709ccba2bd979bc359, PKN: 0, ACK, CC, PADDING 3059 209.520935431 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=a66031b6ccef78ed, PKN: 0, CRYPTO, PADDING 3060 209.557877046 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=cc09246953417c5f37, PKN: 0, ACK, CC, PADDING 3061 217.549450237 Client_IP2 → Server_IP TCP 56 443 → Client_Port2 [SYN, ACK] Seq=0 Ack=1 Win=26646 Len=0

I switch back to https URL scheme, and quickly switch to h3. TLSv1.3 packets show the successful https, but not http3 3911 320.101093894 Server_IP → Client_IP1 TLSv1.3 107 Application Data 3912 320.101400588 Server_IP → Client_IP1 TCP 68 443 → Client_Port1 [FIN, ACK] Seq=16889 Ack=10313 Win=56960 Len=0 TSval=Server_Timestamp1 TSecr=Client_Timestamp1 3913 320.108583534 Client_IP1 → Server_IP TCP 68 Client_Port1 → 443 [ACK] Seq=10313 Ack=16889 Win=45056 Len=0 TSval=Client_Timestamp2 TSecr=Server_Timestamp1 3914 320.113114550 Client_IP1 → Server_IP TCP 68 Client_Port1 → 443 [FIN, ACK] Seq=10313 Ack=16889 Win=45056 Len=0 TSval=Client_Timestamp2 TSecr=Server_Timestamp1 3915 320.113114680 Client_IP1 → Server_IP TCP 68 Client_Port1 → 443 [ACK] Seq=10314 Ack=16890 Win=45056 Len=0 TSval=Client_Timestamp2 TSecr=Server_Timestamp1 3916 320.113126360 Server_IP → Client_IP1 TCP 68 443 → Client_Port1 [ACK] Seq=16890 Ack=10314 Win=56960 Len=0 TSval=Server_Timestamp2 TSecr=Client_Timestamp2 3917 324.017755574 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=ab6b08f934593122, PKN: 0, CRYPTO, PADDING 3918 324.051089566 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=2c7a30e51a4572d200, PKN: 0, ACK, CC, PADDING 3919 324.107309225 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=4775e5b8cdc448eb, PKN: 0, CRYPTO, PADDING 3920 324.141272366 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=c1ab6a92eacc47ccbd, PKN: 0, ACK, CC, PADDING 3921 324.192332173 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=50dbcb69b09ef574, PKN: 0, CRYPTO, PADDING 3922 324.226432146 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=9c93bc2b5fe8dfc603, PKN: 0, ACK, CC, PADDING 3923 324.299831007 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=9f9fd3ea4f5e6a53, PKN: 0, CRYPTO, PADDING 3924 324.333471363 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=e5b72e74871a5671f3, PKN: 0, ACK, CC, PADDING 3925 324.449742370 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=f72638767f82fad5, PKN: 0, CRYPTO, PADDING 3926 324.483951834 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=48848976044406d0d4, PKN: 0, ACK, CC, PADDING 3927 324.556112441 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=6b30d3eef3a93374, PKN: 0, CRYPTO, PADDING 3928 324.589698357 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=cdcfe915a17da775e5, PKN: 0, ACK, CC, PADDING 3929 324.648158323 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=36b705e3f7ab12e6, PKN: 0, CRYPTO, PADDING 3930 324.653027212 Client_IP1 → Server_IP QUIC 1264 Initial, DCID=36b705e3f7ab12e6, PKN: 1, CC, PADDING 3931 324.681792350 Server_IP → Client_IP1 QUIC 1264 Initial, SCID=01a29432a9426227e2, PKN: 0, ACK, CC, PADDING

zs311521 commented 2 days ago

Queries have now dropped to TLS1.2 after a while, but no sure if that means anything.

ShreyasZare commented 1 day ago

Thanks for the post. This seems to be the same issue we discussed in issue #1041. It could be an issue with the router or could be an issue with the libmsquic library, which is still in preview mode.

zs311521 commented 22 hours ago

Thanks for the post. This seems to be the same issue we discussed in issue #1041. It could be an issue with the router or could be an issue with the libmsquic library, which is still in preview mode.

Thank you.

I have investigated further and the below may help. Does its just sound like a library issue?

Interestingly, when I tshark packet inspect it gets the APLN negotiation as I posted before. But interestingly, over DOH, it sometimes at a point downgrades from TLs 1.3 to TLS1.2 and stay there until a restart. But, the H3 url scheme generates the below error in my local resolver:

DNS Server failed to resolve the request 'example.apple.com. HTTPS IN' using forwarders: h3://example-dns-server/dns-query (X.X.X.X). System.Net.Http.HttpRequestException: Application layer protocol negotiation error was encountered. (example-dns-server:443) ---> System.Security.Authentication.AuthenticationException: Application layer protocol negotiation error was encountered. at System.Net.Quic.QuicConnection.HandleEventShutdownInitiatedByTransport(_SHUTDOWN_INITIATED_BY_TRANSPORT_e__Struct& data) at System.Net.Quic.QuicConnection.HandleConnectionEvent(QUIC_CONNECTION_EVENT& connectionEvent) at System.Net.Quic.QuicConnection.NativeCallback(QUIC_HANDLE* connection, Void* context, QUIC_CONNECTION_EVENT* connectionEvent) --- End of stack trace from previous location --- at System.Net.Quic.QuicConnection.FinishConnectAsync(QuicClientConnectionOptions options, CancellationToken cancellationToken) at System.Net.Quic.QuicConnection.<ConnectAsync>g__StartConnectAsync|2_0(QuicClientConnectionOptions options, CancellationToken cancellationToken) at System.Net.Http.ConnectHelper.ConnectQuicAsync(HttpRequestMessage request, DnsEndPoint endPoint, TimeSpan idleTimeout, SslClientAuthenticationOptions clientAuthenticationOptions, CancellationToken cancellationToken) --- End of inner exception stack trace --- at System.Net.Http.ConnectHelper.ConnectQuicAsync(HttpRequestMessage request, DnsEndPoint endPoint, TimeSpan idleTimeout, SslClientAuthenticationOptions clientAuthenticationOptions, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.GetHttp3ConnectionAsync(HttpRequestMessage request, HttpAuthority authority, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.TrySendUsingHttp3Async(HttpRequestMessage request, CancellationToken cancellationToken) at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken) at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken) at System.Net.Http.HttpClient.<SendAsync>g__Core|83_0(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationTokenSource cts, Boolean disposeCts, CancellationTokenSource pendingRequestsCts, CancellationToken originalCancellationToken) at TechnitiumLibrary.Net.Dns.ClientConnection.HttpsClientConnection.QueryAsync(DnsDatagram request, Int32 timeout, Int32 retries, CancellationToken cancellationToken) in Z:\Technitium\Projects\TechnitiumLibrary\TechnitiumLibrary.Net\Dns\ClientConnection\HttpsClientConnection.cs:line 291 ...

ShreyasZare commented 22 hours ago

Thanks for the details. I am not really sure what could be the cause. The DoH client uses the HTTPClient that is available in .NET runtime so is the DoH/3 server which is Kestrel web server from ASP.NET runtime. Both DoH/3 code in .NET runtime and the DNS-over-QUIC code in DNS server uses the same libmsquic library so any issue with library or network should affect both of them in same manner.

zs311521 commented 22 hours ago

That makes sense, thank you. I’m sure a QUIC update will be pushed in the future that magically fixes this. Will wait patiently for this.

in the meantime is there a way to force h2 in the absence of h3 working? Eg h2 URL so it doesn’t fallback to http1.1?

thank you.

ShreyasZare commented 22 hours ago

in the meantime is there a way to force h2 in the absence of h3 working? Eg h2 URL so it doesn’t fallback to http1.1?

If you use "https" scheme, it will automatically prefer to use h2. You do not need to do anything for it.

thank you.

You're welcome.