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

DNS stamps specification: optional user:password #31

Open
ameshkov opened this issue Sep 22, 2023 · 2 comments
Open

DNS stamps specification: optional user:password #31

ameshkov opened this issue Sep 22, 2023 · 2 comments

Comments

@ameshkov
Copy link
Contributor

Why? With DoH it is possible to use HTTP basic authentication on top of

DNS stamps follow the URL format so they kind of already support passing basic authentication using the standard approach:
sdns://user:password@stamp

We're planning to implement support for this in AdGuard products in the future and I wanted to ask what do you think about it? Would you like to add support for it to dnscrypt-proxy?

@jedisct1
Copy link
Member

Sure, why not!

The format also allows specifying both a server and its relay, with sans://<relay>/<server>. I don't remember if dnscrypt-proxy handles this yet, but the parsing part was already done to prepare for it.

So, for ODoH and DOoH, what would user:password@ apply to? The server or the relay?

@ameshkov
Copy link
Contributor Author

ameshkov commented Sep 23, 2023

I think semantically it would be correct to apply it to the relay.

Also, I actually think that in the case of ODoH etc. it would be more flexible to put the server data in a query parameter and not in the path as otherwise it does not allow extending the spec further: sdns://<relay>/?server=<server>.

Here's how I see the semantics of sdns://<stamp>/<path_and_query>:

  • sdns:// -- protocol, lets the application know how to deal with the URL.
  • <stamp> -- basically, this is an encoded host address, lets the application know where to connect.
  • <path_and_query> -- this is a space for "extending" the spec. Today the only thing that can be placed there is the server for "oblivious" protocols, but who knows what else could be placed there in the future?

What do you think about it? Or maybe this ship has already sailed and <relay>/<server> is commonly used?

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

No branches or pull requests

2 participants