jdev - 2020-01-16

lovetox, MattJ: actually webfolk are implementing a "srv2" RFC currently called httpsvc to support esni and http3 and such

So we'll need a xep0368 successor to let us use it, but we can put more stuff in there, should be interesting

"http"svc :/

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! :)

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".

Maybe xsf should officially advocate for one of the better alternatives?

Is there a comparison with SRV? What's the difference/why it's not suitable

ok they add optional key=value pairs to the record and port is now optional

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

There doesn't seem to be a weight anymore either

For xmpp we can have this be 1 lookup and include direct TLS, regular, quic, likely Bosh and websocket too

Hmm why would you want weight when you can just pay a CDN

Too bitter? :)

hmm?

I personally avoid CDNs like the plague

But I don't understand the comment anyway

Http rfcs seem to be dominated by browsers and cdns

You mean CDN would do load balancing themselves so no need for weight?

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

One does wonder when does capitalism ever stop..

Anyway.. this doesn't seem completely useless, the xsf should certainly keep an eye on it

Especially if we want esni and QUIC, which we do :)

pep.: ah https://tools.ietf.org/html/draft-nygren-dnsop-svcb-httpssvc-00#page-29

> 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.

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

Especially for a new protocol

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.

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"..

Maybe that was for xsf@, meh. that's where I got the link

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

Clients MUST ignore SVCB RRs where the "alpn" SvcParamValue is unknown or unsupported.

hm if a user sets a proxy lets say socks5, does he expect DNS resolution via proxy?

i know TOR users would not like if i dns resolve not via proxy, basically leaking the DNS request

lovetox, tor users would say yes

lovetox, I think the answer is that some do and some do not

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

ok but is this some special case, or would you say this is should be followed always

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)

ah no flow proxys support only very limited DNS resolution

only A/AAAA

which is probably still fine for socks5

lovetox, IIRC socks5 supports udp?

but for example its impossible to connect via websocket, without leaking the dns request

at least at the protocol layer, not sure about the implementations

so you could perform the lookup via udp over the proxy using a well known dns resolver

of course you could do a dns resolution via socks5, but you have to impl the whole dns resolution protocol

not really something i want to do to be honest

some dns resolver libraries allow you to specify the IP or even the network link (for tunnels) to be used for the lookups

flow, my question was rather why do specs also not use MUST for the writer side ("Thou SHALL not use unsupported values")

So they can remain extensible

A future spec might add a new value, for example

Which I don't understand, as I said above

and it's good to specify what legacy clients should do

MattJ, then the future spec would say "scrap that, you can use a new value here"

Correct

So.. as the SHOULD is going to be overriten anyway by new specs, that's not an argument for extensibility imo

Maybe also certain deployment-specific stuff would go there

and it's good to know that clients that don't implement it will still have a defined behaviour

sure, because it says the reader should ignore it, that's fine

MUST

actually

It's just the fact that it's not symmetrical that confuses me

Because the person doing the sending gets to make the choice what value they put there

The reader doesn't get the option to explode if it sees an unknown value

That's totally sensible if you ask me

What's the point of sending stuff that's "allowed by the spec" (SHOULD) that nobody can read (MUST) ?

Extensions would redefine both anyway

But old clients wouldn't update

So you still want their behaviour to be known

Rather than undefined

receiving old clients?

Sending old clients would still be fine with MUST/MUST anyway

Receiving old clients are also fine with MUST/MUST anyway

From what I understand

If you can find me a case where it doesn't work anymore with MUST/MUST I'll be happy to oblige :p

Of course it would *work*

It just means the spec doesn't restrict stuff that it doesn't have to

Spec A defines list of types X, everyone implements it, everyone is happy

Spec B adds new type for that field

In a MUST/MUST world, anyone who complies with Spec B suddenly stops being compliant with Spec A

and that's just unnecessary

No, they would implement Spec A + Spec B

Or rather.. they'd implement Spec B

They can't implement both because Spec A expressly forbids them from implementing Spec B

And they'd use spec B with compatible devices?

I'm not sure how much there is that I haven't said that isn't obvious

I have a meeting I'm prepping for, so need to disappear for a bit

Defining something obvious isn't generally helping

Have fun