Ge0rGIs it possible to test XEP-0368 Direct TLS without actually creating the DNS records? You can't put SRV into hosts files :(
jonaswGe0rG, test the implementation at the client or at the server?
Ge0rGjonasw: test a server deployment
KevGe0rG: dnsmasq running locally.
jonaswmost clients allow to specify a port
jonaswand a host to connect to explicitly
jonaswso you’d use that
Ge0rGYeah, I once enabled it in Gajim with a dozen clicks or so.
zinidguys, what string should be put in SNI in the case of IDN domain? original or pynnycoded?
jonaswzinid, interesting question, that I’d like to know too :-)
zinidah, found in RFC6066
zinid"HostName" contains the fully qualified DNS hostname of the server,
as understood by the client. The hostname is represented as a byte
string using ASCII encoding without a trailing dot. This allows the
support of internationalized domain names through the use of A-labels
defined in [RFC5890].
zinidso should be punnycoded
Ge0rGI wonder if I should move the yax.im A records to point to the XMPP server instead of the web server, so that clients that fail SRV will still properly connect.
Ge0rGIt looks like 15% of client connections ignore SRV for yax.im
edhelasHi, I'd like to know the state of this PR ? https://github.com/xsf/xeps/pull/500
jonaswedhelas, I think some council votes are pending, I haven’t processed last council meetings minutes yet, sorry
jonaswedhelas, most efficient will be if you ping me on the PR, I’ll take care of it when I get home
edhelasI'm also planning to do other PR on 0060, maybe today
edhelasjonasw what is your github account nickname ?
edhelasI'm also planning to do another PR on 0060, but I'd like to get some feedbacks here before
edhelasI'd like to expose the access_model of the nodes in their metadata
edhelasI'm wondering if this could brings issues
edhelasbasically adding pubsub#access_model there https://xmpp.org/extensions/xep-0060.html#entity-metadata
daniel> It looks like 15% of client connections ignore SRV for yax.im
Would be interesting to know what clients those are and whether or not they are using Tor
danielconversations.ims numbers are equally high. Maybe even closer to 20%
Ge0rGI'll do some version logging for the next days.
jonaswGe0rG, how are you going to track that?
jonaswalso, I’ve seen clients fall back to A/AAAA if they try to connect before DNS is up
Ge0rGjonasw: modified mod_query_client_ver in prosody. Non-SRV connections to yax.im all come through a NAT on the web server
jonaswthe SRV lookup fails (and they cannot necessarily distinguish the reason) and go on with A/AAAA, which may then pass :/
Ge0rGI've had very often "Connection refused" errors from my own yaxim instance for a week or so, and then I realized the NAT rule got reset.
jonaswI think that the A/AAAA fallback may be doing more harm than good
jonaswI’ve had very confusing certificate errors for weeks until I realized that A/AAAA pointed to a test instacne which wasn’t supposed to be live where the certificates had expired. I don’t even want to know what happened *before* the certificates expired ...
Ge0rGjonasw: it's clearly a bug, the question is just _where_.
jonaswthe root cause is probably that applications cannot (do not?) distinguish between "network errors" and "records don’t exist"
jonaswwith validating resolvers, you’ll also always rather see a generic validation error in favour of a NXDOMAIN if the backedn experienced network errors
jonaswso that isn’t going to go away
jonaswwell, okay, that actually improves things.
jonaswif the API exposes the difference
Ge0rGIt looks like most Non-SRV connections are from yaxim, followed by Conversations. And then some Pidgin and Cackle.
Ge0rGHowever, the stats are skewed because I query on new connections, and those happen far more often on mobile
jonaswand your userbase is probably also skewed
Ge0rGNo way! I'm a neutral server operator!
jonaswthat may be, but are you also a neutral app developer? ;-)
danielcackle is just a Conversations fork though
Ge0rGThere also was one MAXS.
Ge0rGdaniel: did you change the DNS records for conference.siacs.eu around noon on Saturday? My prosody wasn't able to resolve the server in the morning, then came up with an old(?) IP aroung 11:15, and then failed to resolve again.
danielGe0rG, we switched over on friday at ~23:45
danieli don't think i've touched the records since
Ge0rGdaniel: I'm sure this was a weirdness in prosody's DNS code, but I wanted to be 100% sure with that.
Ge0rGdaniel: and 184.108.40.206 was the old IP?
danielsounds about right
Ge0rGdaniel: I'll quote you on https://prosody.im/issues/issue/1001 if that's ok.
danieli just created srv records. but that doesn't seem to help
danielor maybe it did and just takes some time to propagate https://status.conversations.im/reverse/conference.siacs.eu/
daniellet's wait and see what happens
Ge0rGprosody has some strange bugs in handling CNAMEs.
danielcreating the srv record did in fact fix it
Ge0rGdaniel: ...worked around ;)
Ge0rGThe XSF is 90% about semantics.
dwdCNAMEs are really odd. They shouldn't work (but might) in combination with SRV records, for a start.
Ge0rGYeah, but they don't even work without SRV.
dwdGe0rG, Arguably they shouldn't - RFC 6120 § 3.2.2 only says A or AAAA. That probably implies CNAME (and DNAME), though.
jonaswDNAME is entirely DNS-server-side anyways, isn’t it?
dwdGe0rG, You *can* - in principle - use CNAMEs for, say, _xmpp-server._tcp.example.org. Just not for whatever the hostname it looks up to is.
dwdjonasw, There's a fallback to do that, but I think there's an EDNS0 flag for handling them client-side.
Ge0rGdwd: but the service name is a CNAME, and it doesn't resolve
dwdGe0rG, What do you mean by the service name?
conference.siacs.eu. 300 IN CNAME xmpp-hosting.conversations.im.
xmpp-hosting.conversations.im. 300 IN A 220.127.116.11
dwdSo that only works is the process looking up decides it'll use gethostbyname/getaddrinfo, or else do DNS directly but follow CNAMEs.
dwdNeither is spelt out in RFC 6120 § 3.2.2.
Ge0rGI'm not sure RFC6120 is the right place to define how DNS should work.
Ge0rGHowever, with the wording you referenced, I could blame daniel for not following the RFC, instead of blaming prosody for having a broken CNAME lookup mechanism.
jonaswgiven that we have SRV, I don’t see the reason for CNAMEs in any case.
jonasw(as mentioned earlier, I think the A/AAAA fallback does more harm than good)
Ge0rGjonasw: SRVs happen to be black magic from the future for many DNS providers.
HolgerSo the Prosody people broke their CNAME caching in order to strictly follow RFC 6120?
Ge0rGjonasw: with some DNS operators, you can't add SRV entries.
MattJHolger, just for the record... no :)
jonaswGe0rG, I understood, but I am horrified
zinidso these providers don't follow RFC6120?
zinidwe need to notify them
Ge0rGzinid: oh, they do.
Ge0rGit's the others that don't.
Holgerjonasw: You might have the CNAME record for other services anyway. Apart from that you might want to maintain the SRV targets in a single record and have multiple CNAMEs pointing to that.
Holgerdwd: I agree with Ge0rG that 6120 sounds like the wrong place to specify such things. But if it's the right place, then missing CNAME support sounds like an obvious 6120 bug to me.
dwdHolger, I don't think it is specifying how DNS works. I do think it ought not to be quite so precise in the lookups involved.
HolgerJust sounds wrong to me that each and every protocol that uses DNS names should specify "yes we also resolve CNAMEs like everyone else".
HolgerAs opposed to just specifying the parts that are *specific* to this protocol.
jonaswI bet there’s some wording in the document defining CNAME that resolvers (including stub resolvers) MUST follow CNAMEs transparently or so
Flow> [14:07:11] jonasw: (as mentioned earlier, I think the A/AAAA fallback does more harm than good)
Given the amount of DNS implementations not supporting SRV RRs, I doubt that this is true
Flowwhat Holger said
zinidjust let's use NAPTR to break things completely :)
jonaswFlow, is there a list of such popular services?
jonaswand IM services hosted there? they should apply some pressure.
Flowjonasw: I'm not only talking about services, more about all things DNS
jonaswthe issue with the fallback is that it forces services using SRV records to also have valid A/AAAA records or at least it constraints what you can do with the A/AAAA of the domain.
Flowjonasw: It doesn't force them
Flowbut yes, for maximum connectivity you want to have your XMPP domain also resolve A/AAAA
jonaswFlow, no, if there are intermittent issues which makes the client believe that the SRV records don’t exist, they fall back to A/AAAA
jonaswand that’s an issue
Flowit's an issue if there are no A/AAAA records
jonaswor if the records point to something which isn’t the XMPP service you wanted to connect to
Flowbut how would not having the A/AAAA fallback improve the situation
jonaswif there are no A/AAAA records, it is more or less obvious to clients that they should re-try later because it’s most likely network
jonasw(or a configuration error)
jonaswbut if end up in the fallback (e.g. on a transparent stream-managmeent reconnect) and the fallback is not the XMPP service you’re looking for, a lot of funny stuff can happen, from certificate errors, over stream errors to authentication failed
jonaswall of which will probably nuke the clients state
jonaswthat’s what I mean by "harm"
jonasw(I had that once with an unfortunately configured A/AAAA record which pointed to another XMPP service)
jonasw(took me weeks to figure out what the reason for those errors were)
Flowjonasw: I see, but without the fallback you wouldn't even be able to connect as soon as SRV breaks for some reason
jonaswFlow: yes, and treating it as a network error would do the right thing (retry soon)
Flowjonasw: Not if it's your resolver lib not being able to perform SRV lookups
Flowor you home router resolver
jonaswbut you can't distinguish a wrong A/AAAA you should never have seen from incorrect credentials or something
Flowincorrect credentials should return a well defined error, no?
Flowbut, yes, the situation is not ideal
jonaswFlow: sure it does, but you can get such an error when connecting to the wrong xmpp service due to A/AAAA lookup
Ge0rGWhen I send a MUC join and lose my connection, so that it will be closed by a 0198 timeout, prosody will send error responses to all queued stanzas, including individual MUC participants. Is that good / bad / ugly / all of the above?
jonaswGe0rG, I think MUCs won’t route error messages back. sending back error presences is the right thing.
Ge0rGExcept that some funny MUC implementation will also kick all my MSNs
Ge0rGor is that NMSs?
jonaswsure, but that are broken MUC implementations then
jonaswnot sending unavailable presence would be desastrous
Ge0rGjonasw: it's okay to send presence-unavailable to my own nickname, but to all the participants?
Ge0rGor rather, presence-error.
jonaswto the participants doesn’t seem right to me
dwdGe0rG, I'm not sure I understand what the problem you're describing is.
Ge0rGit's right from the 0198 session destruction context, though.
HolgerWhat's the downside with just dropping all presence stanzas on 0198 timeout?
HolgerHow does the error stanza help anyone?
MattJIf you send presence to someone, do you expect an error if they don't ever receive it?
dwdGe0rG, So you have an existing local session connected to a local MUC, in a 198-detached state, and then this times out?
HolgerMattJ: I don't.
HolgerMattJ: Because how would I handle that error?
dwdHolger, Giant modal dialog box of course.
dwdHolger, I'm surprised you had to ask.
Ge0rGdwd: I'll try again:
1. I send a join presence to a MUC
2. I disappear into the void
3. The MUC sends everything that's sent on join to my 0198 cache
4. my 0198 session gets destroyed, so my server sends an error response for each individual stanza in the cache, including all the participant presences.
dwdGe0rG, Ah, OK. And what's wrong with that?
Ge0rGdwd: the flood of presence errors to MUC participants.
dwdGe0rG, Ah, OK. And what's wrong with *that*?
Ge0rGdwd: that was the point of my question. Is it wrong or just ugly.
dwdHolger, Useless is OK, or at least it's nothing bad, surely?
HolgerIt's nothing bad.
jonaswI’m not sure
jonaswsending presences to other MUC participants is at least weird
dwdGe0rG, I think it's right. Although I don't think the MUC should be broadcasting presence errors - it should juts error you out fo the MUC and broadcast that.
jonaswbecause that’s normally how you join/change nicknames
Ge0rGdwd: I don't know what the MUC does with the flood, to be honest
dwdGe0rG, If it just absorbs it, that's fine. I think.
Ge0rGdwd: sounds reasonable to me.
dwdGe0rG, The problem is that to stop it, we'd need to track not just the stanzas, but the semantics of those stanzas.
dwdAnd that's really the MUC entity's job, I think.
jonaswshouldn’t all MUC presences have an <x/> in them which makes it easy to find?
dwd(At least, wherever possible)
Ge0rGjonasw: and <x/> specific code in 0198 as well, now?
HolgerMy question was: My not just silently drop *all* presence stanzas on 0198 timeout?
Ge0rGLet's fix 0045 first.
HolgerNo matter whether MUC-related or not?
HolgerIs there a single use case where the originator of the presence would handle the error message in any other way than ignoring it?
dwdHolger, I don't think that's needed, or desirable. If an error would be generated immediately on session close, then it should be generated on 198-closure.
HolgerIt would not be generated without 0198, no?
jonaswdoes one get presence-errors when sending a presence to an unavailable entity?
HolgerThis is a 0198 (mis)feature.
dwdjonasw, Ah, that's a "sort of". You get a presence error if your sending the presence causes an error to be detected.
dwdSpeaking of 198, what are people setting the timeout to these days?