-
moparisthebest
lovetox, MattJ: actually webfolk are implementing a "srv2" RFC currently called httpsvc to support esni and http3 and such
-
moparisthebest
So we'll need a xep0368 successor to let us use it, but we can put more stuff in there, should be interesting
-
pep.
"http"svc :/
-
moparisthebest
This might be the recent one https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00 basically allows extra stuff like I was trying to cram into HACX, just implement some more DNS records they are cheap! :)
-
moparisthebest
pep.: Before you get too worked up: > The specific name for this RR type is an open topic > for discussion. "SVCB" and "HTTPSSVC" are meant as placeholders as > they are easy to replace. Other names might include "B", "SRV2", > "SVCHTTPS", "HTTPS", and "ALTSVC".
-
moparisthebest
Maybe xsf should officially advocate for one of the better alternatives?
-
pep.
Is there a comparison with SRV? What's the difference/why it's not suitable
-
pep.
ok they add optional key=value pairs to the record and port is now optional
-
moparisthebest
pep.: Look at the psuedo example up top, you can't cram stuff like "use http3" or "here are the esni keys" in regular SRV
-
pep.
There doesn't seem to be a weight anymore either
-
moparisthebest
For xmpp we can have this be 1 lookup and include direct TLS, regular, quic, likely Bosh and websocket too
-
moparisthebest
Hmm why would you want weight when you can just pay a CDN
-
moparisthebest
Too bitter? :)
-
pep.
hmm?
-
pep.
I personally avoid CDNs like the plague
-
pep.
But I don't understand the comment anyway
-
moparisthebest
Http rfcs seem to be dominated by browsers and cdns
-
pep.
You mean CDN would do load balancing themselves so no need for weight?
-
moparisthebest
I wildly assume since weight kind of let's you do your own load balancing, maybe the cdns didn't want to because it could cut on their business
-
pep.
One does wonder when does capitalism ever stop..
-
pep.
Anyway.. this doesn't seem completely useless, the xsf should certainly keep an eye on it
-
moparisthebest
Especially if we want esni and QUIC, which we do :)
-
moparisthebest
pep.: ah https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00#page-29
-
moparisthebest
> Some other similar mechanisms such as SRV have a weight in-addition > to priority. That is excluded here for simplicity. It could always > be added as an optional SVCB parameter.
-
pep.
https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00#section-6.1 I never understand why one SHOULDs the type of value that a sender can use, and MUSTs receivers not to read it if it doesn't correspond to that type
-
pep.
Especially for a new protocol
-
pep.
What's the goal behind? Allow custom stuff on top of that? Somebody implementing something custom would have a say on both writer and reader, they would be breaking the spec anyway.
-
pep.
And if it's to allow extensions, one would need to say "In this case you can set the value as XXX" alongside "you can read the value as XXX"..
-
pep.
Maybe that was for xsf@, meh. that's where I got the link
-
flow
pep., it's not really "doesn't correspond to that value". It says receivers have to ignore the whole entry if they do not understand the value
-
flow
Clients MUST ignore SVCB RRs where the "alpn" SvcParamValue is unknown or unsupported.
-
lovetox
hm if a user sets a proxy lets say socks5, does he expect DNS resolution via proxy?
-
lovetox
i know TOR users would not like if i dns resolve not via proxy, basically leaking the DNS request
-
flow
lovetox, tor users would say yes
-
flow
lovetox, I think the answer is that some do and some do not
-
flow
i.e. if you just use the socks5 proxy to be able to "reach the internet", but local dns resolves fine, then you are probably fine with dns lookups not using the socks5 proxy
-
lovetox
ok but is this some special case, or would you say this is should be followed always
-
flow
well if you implement support for dns lookups via the proxy, then I would probably simply always do it, and not make it configurable (or at least, only make it an advanced configuration option)
-
lovetox
ah no flow proxys support only very limited DNS resolution
-
lovetox
only A/AAAA
-
lovetox
which is probably still fine for socks5
-
flow
lovetox, IIRC socks5 supports udp?
-
lovetox
but for example its impossible to connect via websocket, without leaking the dns request
-
flow
at least at the protocol layer, not sure about the implementations
-
flow
so you could perform the lookup via udp over the proxy using a well known dns resolver
-
lovetox
of course you could do a dns resolution via socks5, but you have to impl the whole dns resolution protocol
-
lovetox
not really something i want to do to be honest
-
flow
some dns resolver libraries allow you to specify the IP or even the network link (for tunnels) to be used for the lookups
-
pep.
flow, my question was rather why do specs also not use MUST for the writer side ("Thou SHALL not use unsupported values")
-
MattJ
So they can remain extensible
-
MattJ
A future spec might add a new value, for example
-
pep.
Which I don't understand, as I said above
-
MattJ
and it's good to specify what legacy clients should do
-
pep.
MattJ, then the future spec would say "scrap that, you can use a new value here"
-
MattJ
Correct
-
pep.
So.. as the SHOULD is going to be overriten anyway by new specs, that's not an argument for extensibility imo
-
MattJ
Maybe also certain deployment-specific stuff would go there
-
MattJ
and it's good to know that clients that don't implement it will still have a defined behaviour
-
pep.
sure, because it says the reader should ignore it, that's fine
-
pep.
MUST
-
pep.
actually
-
pep.
It's just the fact that it's not symmetrical that confuses me
-
MattJ
Because the person doing the sending gets to make the choice what value they put there
-
MattJ
The reader doesn't get the option to explode if it sees an unknown value
-
MattJ
That's totally sensible if you ask me
-
pep.
What's the point of sending stuff that's "allowed by the spec" (SHOULD) that nobody can read (MUST) ?
-
pep.
Extensions would redefine both anyway
-
MattJ
But old clients wouldn't update
-
MattJ
So you still want their behaviour to be known
-
MattJ
Rather than undefined
-
pep.
receiving old clients?
-
pep.
Sending old clients would still be fine with MUST/MUST anyway
-
pep.
Receiving old clients are also fine with MUST/MUST anyway
-
pep.
From what I understand
-
pep.
If you can find me a case where it doesn't work anymore with MUST/MUST I'll be happy to oblige :p
-
MattJ
Of course it would *work*
-
MattJ
It just means the spec doesn't restrict stuff that it doesn't have to
-
MattJ
Spec A defines list of types X, everyone implements it, everyone is happy
-
MattJ
Spec B adds new type for that field
-
MattJ
In a MUST/MUST world, anyone who complies with Spec B suddenly stops being compliant with Spec A
-
MattJ
and that's just unnecessary
-
pep.
No, they would implement Spec A + Spec B
-
pep.
Or rather.. they'd implement Spec B
-
MattJ
They can't implement both because Spec A expressly forbids them from implementing Spec B
-
pep.
And they'd use spec B with compatible devices?
-
MattJ
I'm not sure how much there is that I haven't said that isn't obvious
-
MattJ
I have a meeting I'm prepping for, so need to disappear for a bit
-
pep.
Defining something obvious isn't generally helping
-
pep.
Have fun