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 :)
> 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.
sonnyhas left
sonnyhas joined
debaclehas left
bhaveshsguptahas joined
moparisthebesthas left
moparisthebesthas joined
bhaveshsguptahas left
serge90has left
bhaveshsguptahas joined
serge90has joined
actupperhas joined
bhaveshsguptahas left
moparisthebesthas left
moparisthebesthas joined
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
actupperhas left
actupperhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
asterixhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
asterixhas left
asterixhas joined
paulhas left
paulhas joined
lovetoxhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
wurstsalathas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
asterixhas left
asterixhas joined
asterixhas left
asterixhas joined
bhaveshsguptahas left
lovetoxhas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
ajhas joined
lovetoxhas joined
bhaveshsguptahas left
ajhas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
lovetoxhas left
bhaveshsguptahas left
bhaveshsguptahas joined
asterixhas left
asterixhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
paulhas left
paulhas joined
asterixhas left
asterixhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
sonnyhas left
goffihas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
sonnyhas joined
bhaveshsguptahas joined
sonnyhas left
bhaveshsguptahas left
pulkomandyhas left
pulkomandyhas joined
kikuchiyohas joined
bhaveshsguptahas joined
Guushas left
Guushas joined
bhaveshsguptahas left
bhaveshsguptahas joined
madhur.garghas joined
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
sonnyhas joined
bhaveshsguptahas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
rionhas left
rionhas joined
debaclehas joined
sonnyhas left
bhaveshsguptahas left
Bartekhas joined
Bartekhas left
bhaveshsguptahas joined
bhaveshsguptahas left
bhaveshsguptahas joined
sonnyhas joined
sonnyhas left
Wojtekhas joined
pulkomandyhas left
pulkomandyhas joined
asterixhas left
asterixhas joined
lovetoxhas joined
lovetoxhas left
lovetoxhas joined
serge90has left
serge90has joined
Wojtekhas left
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
sonnyhas joined
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?
pulkomandyhas left
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