Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[DoH] dnsdist accepts all sub-paths of the configured URL path #8573

bortzmeyer opened this issue Nov 23, 2019 · 3 comments · Fixed by #8760

[DoH] dnsdist accepts all sub-paths of the configured URL path #8573

bortzmeyer opened this issue Nov 23, 2019 · 3 comments · Fixed by #8760


Copy link

@bortzmeyer bortzmeyer commented Nov 23, 2019

  • Program: dnsdist
  • Issue type: Bug report

Short description

When used for DoH, dnsdist apparently accepts as a valid URL every path which is below the configured path.


  • Operating system: ArchLinux
  • Software version:
  • Software source: 1.4.0 compiled my myself

Steps to reproduce

  1. addDOHLocal("", "/etc/dnsdist/server-doh.pem", "/etc/dnsdist/server-doh.key", "/")
  2. curl https://doh-server/somethingwhichdoesnotexist

Expected behaviour


Actual behaviour


Example with an actual server:

* Connected to (2001:41d0:302:2200::180) port 443 (#0)
> GET /doesnotexistshouldnotwork?dns=AAABAAABAAAAAAAACnRydWNtYWNoaW4CZnIAABwAAQ HTTP/2
> Host:
> User-Agent: curl/7.58.0
> Accept: */*
< HTTP/2 200 
< server: h2o/dnsdist
< content-type: application/dns-message
< content-length: 88

Other information

Same thing with POST instead of GET.

@Habbie Habbie added the dnsdist label Nov 23, 2019
Copy link

@rgacogne rgacogne commented Nov 25, 2019

Thanks for reporting this! I think this is the behavior @ahupowerdns intended, but I agree this might make more sense to do exact path matching only.
It should be possible to prevent this behavior in 1.4.0 using a response map, via DOHFrontend.setResponsesMap() and newDOHResponseMapEntry().

@rgacogne rgacogne added this to the dnsdist-1.4.x milestone Nov 25, 2019
Copy link

@bortzmeyer bortzmeyer commented Nov 26, 2019

It seems to me that accepting /dns-query/something/somethingelse, although legal, violates the principle of least astonishment. I guess that most webmasters would be surprised.

It can also be a (very small) security issue, if someone blocks "^/dns-query$", they may be surprised that "/dns-query/foobar" works.

Copy link

@rgacogne rgacogne commented Nov 27, 2019

I fully agree so unless someone chimes in with a good reason to keep the existing behavior, I'll likely move our behavior to exact path matching only in 1.4.1.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet

Successfully merging a pull request may close this issue.

3 participants