search

DNS-OARC / services

Project and issue tracking for DNS-OARC services
https://www.dns-oarc.net/oarc/services
36 stars 6 forks source link

TCP test doesn't seem to actually use TCP? #25

Closed thomaseizinger closed 2 weeks ago

thomaseizinger commented 2 weeks ago

First off, thank you for making this great tool! It is pretty much exactly what I need to test my resolver! I did however notice that the TCP test seems to be not quite working? In particular, it doesn't seem to force TCP and when reproducing the query locally with dig, it just succeeds over UDP.

image

The UDP queries prior to that one also succeed and don't seem to have the TC bit set.

jelu commented 2 weeks ago

What you have highlighted is the EDNS0 buffer size, not what transport it used. It's sometimes referred to as "UDP size", "UDP message size" etc.

You can see transport under "proto".

thomaseizinger commented 2 weeks ago

Okay, something is still not quite working though. I am only just now implementing TCP support for my resolver and wanted to test that.

If I run check-my-dns on my Android phone with the VPN that I am developing active (that cannot yet do DNS over TCP), I expected all the TCP queries to fail. But they don't. Check-my-DNS says it is working. This is on Firefox for Android.

If I use this app to test it and forcs TCP DNS, it times out (as expected).

Is this a limitation for Firefox for Android not respecting the DNS servers? Any clues?

jelu commented 2 weeks ago

Have you checked that Firefox doesn't use DoH servers?

In the screenshot you can also see where the queries comes from and those IPs look like Google's DNS resolver cluster.

Check My DNS can only test the last resolver on your path, if your resolver forwards queries then it's not your resolver that gets tested.

jelu commented 2 weeks ago

BTW: I highly recommend NOT developing your own resolver :) DNS is not as easy as you may think, better to use getdnsapi, libunbound or other libraries.

thomaseizinger commented 2 weeks ago

Have you checked that Firefox doesn't use DoH servers?

I'll check.

In the screenshot you can also see where the queries comes from and those IPs look like Google's DNS resolver cluster.

Check My DNS can only test the last resolver on your path, if your resolver forwards queries then it's not your resolver that gets tested.

My resolver does forward queries, yes! Every DNS server on the system gets replaced with a proxy IP and then the VPN app intercepts the DNS queries sent to them, answered some and forwards other to the original resolver.

How does Check My DNS test TCP queries? By forcing a fallback with the truncated bit?

jelu commented 2 weeks ago

How does Check My DNS test TCP queries? By forcing a fallback with the truncated bit?

It sets the TC bit yes, but you will never see that if you forward since then the upstream resolver will do all the work.

thomaseizinger commented 2 weeks ago

How does Check My DNS test TCP queries? By forcing a fallback with the truncated bit?

It sets the TC bit yes, but you will never see that if you forward since then the upstream resolver will do all the work.

Well, but the response is still truncated, right? So shouldn't it set the TC bit in the UDP response back to me?

jelu commented 2 weeks ago

So shouldn't it set the TC bit in the UDP response back to me?

No, that's not how DNS works.

In this context, your "resolver" is a client and it asks the upstream to resolve for it.

thomaseizinger commented 2 weeks ago

So shouldn't it set the TC bit in the UDP response back to me?

No, that's not how DNS works.

In this context, your "resolver" is a client and it asks the upstream to resolve for it.

Right and I guess the final response served to my resolver fits into a UDP packet, and thus the TC bit isn't set?

So to force the very first client to retry over TCP, the response to the initial query needs to exceed the UDP size, thus forcing the resolver that is serving my resolver to set the TC bit.

Would it make sense for Check My DNS to support such a scenario?

jelu commented 2 weeks ago

Right and I guess the final response served to my resolver fits into a UDP packet, and thus the TC bit isn't set?

No.

First off, you do not have a resolver. You have only made a forwarder.

You forward your query to the upstream resolver and it will try it utmost to give you an answer - that's its job!

So to force the very first client to retry over TCP, the response to the initial query needs to exceed the UDP size, thus forcing the resolver that is serving my resolver to set the TC bit.

Would it make sense for Check My DNS to support such a scenario?

No, because the upstream resolver will retry over TCP to get the answer and it will construct an answer back to your forwarder that fit within that transport.

It's job is to give you an answer, not a carbon copy of what ever it received.

thomaseizinger commented 2 weeks ago

Thank you for explaining this. I have one more question if you don't mind :)

The thing that doesn't want to click for me is:

If that is the case, wouldn't it be possible to construct such records and thus force TCP DNS all the way to client?

jelu commented 2 weeks ago

If you're aim is to ensure TCP is used for every communication in every layer, no - you can't do that as a forwarder.

If you are looking to ensure you have an authenticated answer you need to implement DNSSEC and do client side validation.

thomaseizinger commented 2 weeks ago

My aim is for my forwarder to be correct and as transparent as possible whilst being able to intercept some queries. I was looking for a tool to test that with and thought Check My DNS kind of fits the bill here!

I guess my question now is, do you think it makes sense to extend the tests that Check My DNS is making such that it also tests whether the end-user client correctly falls back to TCP for truncated responses?

If I understand correctly, that is what this situation can be reduced too. The presence of my forwarder doesn't really matter, because even if it is not active, the way Check My DNS is currently implemented means that TCP DNS is only tested upstream from the resolver that I am using, but never between my client and the configured resolver. Is that correct?

jelu commented 2 weeks ago

On Wed, 9 Oct 2024, 22:14 Thomas Eizinger, @.***> wrote:

I guess my question now is, do you think it makes sense to extend the tests that Check My DNS is making such that it also tests whether the end-user client correctly falls back to TCP for truncated responses?

No.

If I understand correctly, that is what this situation can be reduced too. The presence of my forwarder doesn't really matter, because even if it is not active, the way Check My DNS is currently implemented means that TCP DNS is only tested upstream from the resolver that I am using, but never between my client and my resolver. Is that correct?

Yes.