You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
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?
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?
The text was updated successfully, but these errors were encountered: