On 19.12.2017 01:24, Olemis Lang wrote:
On 12/18/17, Alberto José García Fumero <albe...@ettpartagas.co.cu> wrote:
El sáb, 16-12-2017 a las 06:31 -0500, Alejandro Hernández Pastora
escribió:
[...]
Estoy buscando alternativas a la delegación de dominio, porque:
1) realmente no la necesito para la poca carga y servicios de aquí
2) administrar no es lo único que hago aquí; debemos ser unos
jack-for-everything, si me entienden.
[...]
<joke> Encontramos al sysadmin del año . Fumero lo q les hace falta no
es un informático, son unas vacaciones . </joke>
Yo recuerdo haber hecho algo como esto alguna vez (inter-domain
federation for xmpp, presence service) y me da la impresión que el
método del /etc/hosts no va a funcionar. Hay que publicar el record
SRV en el DNS . No tuve tiempo de buscarles una página con la
explicación. El enlace por IPs es sub-óptimo , en mi opinión.
El tema con los registros SRV y ETECSA es q se pueden utilizar para
SIP y VoIP . Si un TXT resulto ser un problema ... bueno ...
Sorry, no me fijé que era de s2s el asunto. Por eso [1]
A compliant server implementation MUST support both TLS and SASL for
inter-domain communications. For historical reasons, a compliant
implementation SHOULD also support Server Dialback.
Because service provisioning is a matter of policy, it is OPTIONAL for
any given domain to communicate with other domains, and server-to-server
communications MAY be disabled by the administrator of any given
deployment. If a particular domain enables inter-domain communications,
it SHOULD enable high security.
Administrators may want to require use of SASL for server-to-server
communications in order to ensure both authentication and
confidentiality (e.g., on an organization's private network). Compliant
implementations SHOULD support SASL for this purpose.
Inter-domain connections MUST NOT proceed until the DNS hostnames
asserted by the servers have been resolved. Such resolutions MUST first
attempt to resolve the hostname using an [SRV] Service of "xmpp-server"
and Proto of "tcp", resulting in resource records such as
"_xmpp-server._tcp.example.com." (the use of the string "xmpp-server"
for the service identifier is consistent with the IANA registration;
note well that the "xmpp-server" service identifier supersedes the
earlier use of a "jabber" service identifier, since the earlier usage
did not conform to [SRV]; implementations desiring to be backward
compatible should continue to look for or answer to the "jabber" service
identifier as well). If the SRV lookup fails, the fallback is a normal
IPv4/IPv6 address record resolution to determine the IP address, using
the "xmpp-server" port 5269, registered with the IANA.
Server dialback helps protect against domain spoofing, thus making it
more difficult to spoof XML stanzas. It is not a mechanism for
authenticating, securing, or encrypting streams between servers as is
done via SASL and TLS, and results in weak verification of server
identities only. Furthermore, it is susceptible to DNS poisoning attacks
unless DNSSec [DNSSEC] is used, and even if the DNS information is
accurate, dialback cannot protect from attacks where the attacker is
capable of hijacking the IP address of the remote domain. Domains
requiring robust security SHOULD use TLS and SASL. If SASL is used for
server-to-server authentication, dialback SHOULD NOT be used since it is
unnecessary.
1- https://xmpp.org/rfcs/rfc3920.html
______________________________________________________________________
Lista de correos del Grupo de Usuarios de Tecnologías Libres de Cuba.
Gutl-l@jovenclub.cu
https://listas.jovenclub.cu/cgi-bin/mailman/listinfo/gutl-l
