In Smack API, there is a configuration class for connection, described at this page
ConnectionConfiguration
I am confused about the distinction between service name and server name.
Suppose I have a computer named "mybox.mydomain.com", and I have ejabberd on it with a configured host called "myhost" (using the line {hosts, ["myhost"]}. in ejabbed.cfg),
what is the host name, server name and service name in this case?
myhost: service name (or XMPP domain)
mybox.mydomain.com: hostname and servername.
You can host an XMPP domain over any host, provided that you set the SRV records right in the DNS or if the client specifies to which host it is supposed to connect (like email).
Think of the JID you're using to log in, which contains username # domain. The domain is the logical name of the service you are using. For some services, like jabber.org, the service is run on a box that has the same name as the service. For many others, like WebEx Connect and GoogleTalk, the service domain is a starting point to figure out where to open a socket to, but not the name of the machine. If everything is set up right, you can look up the name of the machine to connect to in the DNS using an SRV record. For example, using dig:
$ dig +short -t SRV _xmpp-server._tcp.gmail.com
20 0 5269 xmpp-server4.l.google.com.
20 0 5269 xmpp-server2.l.google.com.
20 0 5269 xmpp-server1.l.google.com.
5 0 5269 xmpp-server.l.google.com.
20 0 5269 xmpp-server3.l.google.com.
If the service domain is not configured correctly in the DNS, or you're just testing things out, it's often useful to be able to specify this connect host separately from the domain. So for your example, you would use:
ConnectionConfiguration("mybox.mydomain.com",
5222,
"myhost");
If you ever want this service to be accessed by people off of your network (either client-to-server or server-to-server), it would make sense to rename your service domain to be something fully-qualified, to which you can attach SRV records for those external entities to use.
Related
Obviously I could listen on a particular IP address, but is it possible to listen on a particular hostname? Specifically, if example1.com and example2.com both point to my server with IP address (say) 12.34.56.78, is it possible to proxy connections to example1.com:5432 to my postgres db, but have connections to example2.com:5432 be rejected?
I have a feeling the hostname is not passed in the initial connection, so it would be impossible to do what can be done with HTTP(S) (e.g. Nginx server block, Caddy, etc.).
No, that is not possible. The database server never sees the host name the client used. Domain Name Service (DNS) resolution of a host name to an IP address has to happen before the server can be contacted.
You will have to use two different IP addresses, for example by defining a second, virtual IP address for the server. You don't need to have a second network card.
I am trying to figure out how the service discovery works in the Kubernetes cluster. Let's say I've got a service running in the cluster, but I don't know the IP or port. I assume the service discovery is the way to go.
Kubernetes DNS specification says that SRV record must be in the following format:
_<port>._<proto>.<service>.<ns>.svc.<zone>. <ttl> IN SRV <weight> <priority> <port-number> <service>.<ns>.svc.<zone>.
Example:
Question:
_https._tcp.kubernetes.default.svc.cluster.local. IN SRV
Answer:
_https._tcp.kubernetes.default.svc.cluster.local. 30 IN SRV 10 100 443 kubernetes.default.svc.cluster.local.
That implies the client needs to know the port (https=443) upfront to query for the port? It seems like it defeats the purpose of the SRV record. Why would the client query for SRV when the port is already known in the question and the only missing piece is the IP?
What am I missing? How to make this work when the discovering client only knows the name of the service and not the port?
SRV records facilitate service discovery by describing the protocol/s and address of certain services:
SRV Records are created for named ports that are part of normal or
Headless Services. For each named port, the SRV record would have the
form
_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example.
For a regular service, this resolves to the port number and the domain
name: my-svc.my-namespace.svc.cluster-domain.example. For a headless
service, this resolves to multiple answers, one for each pod that is
backing the service, and contains the port number and the domain name
of the pod of the form
auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example.
An SRV record usually defines a symbolic name and the transport protocol (e.g., TCP) used as part of the domain name and defines the priority, weight, port, and target for a given service. For example:
_foo._tcp.example.com. 3600 IN SRV 10 100 5060 servicerecord.example.com
_foo is the service's symbolic name
_tcp is the transport protocol used by the service
the record has a priority of 10
the record has a weight of 100
5060 is the port and servicerecord.example.com is the hostname to connect to in order to communicate with the service
That implies the client needs to know the port (https=443) upfront to
query for the port?
No, the 443 is the answer and not a part of the question.
How to make this work when the discovering client only knows the name
of the service and not the port?
If the client knows the symbolic name of the service and the protocol than the port can be discovered.
I have a domain name registered at ovh.com, let's say it's called domain.com.
This domain is pointing on my router's public IP, then I redirect the https port 443 of my router to my server port 443. So when we go to domain.com it redirects to my server:443.
To be more accurate, domain.com just redirect to my router's public IP. So for example if I use a graphic database manager, I can tell him that the server address is domain.com:[SGBD port] and It will works.
But all my applications are running on this same server. And to add a little more security, I am not using the usual port for all protocols. So let's say my port are the following :
git : 50000
SGBD : 55000
cloud : 60000
website 65000
and some others, for example some TCP ports between 40000 and 50000.
My git and my cloud have a graphical manager I can access by typing domain.com:50000 or domain.com:60000 in my web browser from everywhere. I use the same URL on all my software. domain.com:50000 for my git client, domain.com:55000 for my database client and so on.
This way is working perfectly but there are 2 problems annoying me :
The first one is that I have to tell the port number to everyone who's susceptible to use my applications. But like I said I am not using usual port number for a little more security so I don't want to share these numbers with everyone.
The second problem is more important :
When I am somewhere, for example at work, it's possible that the firewall is blocking the port numbers I am using. So my personal git isn't accessible, same for my cloud etc.
To solve these problem in one move I wanted to add subdomain on my domain and redirect these subdomain to my differents ports. For example :
website : domain.com:65000
git.domain.com ==> domain.com:50000
SGBD.domain.com ==> domain.com:55000
cloud.domain.com ==> domain.com:60000
So in my mind, with this solution I can type git.domain.com in my browser to initiate the communication by https (the https port is almost never blocked), then redirect it to my router's port 50000 from OVH then my router redirect it to the git port of my server.
But obviously this would be to good to be truth.
When creating a subdomain (at least on OVH ?) we can't specify a port. So I can't set git.domain.com is redirecting to myRouterIp:50000 but just to myRouterIp. So with a web browser, typing git.domain.com will redirect to myRouterIp:443, which is already taken by my website.
So i'm a little confused. Do I have to buy one router with a different public IP per application then making all differents subdomain pointing on a different router ? I almost sure it's a bit ridiculous. How do you think I can solve it ?
As you correctly noticed, in your DNS console you can't specify port; the reason is that DNS does not care about ports, its only purpose is to resolve hostnames to IP addresses.
Another thing important for your problem is that most (non http) application clients will, even if they use friendly hostname, resolve that name to IP address before initiating the connection to your router/server, and then use that IP address for communicating to router/server. That means that when request reaches a port on your router/server, there will be no way for router/server to determine which hostname was initially used.
The rare exception to this is HTTP, where the browser is always sending the requested hostname in Host HTTP header. That means that you can run multiple different websites on one IP address on the same port (that is how shared web hosting works, for example). Setting this up should be pretty straightforward, but is probably out of scope on SO, try SF or SU.
For other (non HTTP services), the only solution is to run them on different ports (which you already do), or to have multiple public IP addresses (which might be difficult to get from your ISP). Also, running non-http services on some random non-default ports (and telling that port number to your users) might be (very sightly) more secure than running them on their respective default ports.
Depending on your use case, one other possible solution would be to have your users connect to your local network using secure VPN, and after that they could have access to your services (which would run on different private IP addresses and any port you like).
I need to run an XMPP server for IM with end-to-end encryption and voice calling. I'm trying to set up Prosody, but is it possible to run an XMPP server without a domain name? Without own DNS server and VPN network between clients?
Short Answer: Yes.
You can still configure a XMPP domain for your server. According to the standard, it doesn't has to be an DNS Name or IP address. Something like myserver is fine. Quoting RFC 7622 ยง 3.2:
The domainpart for every XMPP service MUST be a fully qualified domain
name (FQDN), an IPv4 address, an IPv6 address, or an unqualified
hostname (i.e., a text label that is resolvable on a local network).
But if you don't have a DNS name, then clients won't know automatically how to reach your server. Which means you have to configure the IP address and the port in every client.
You can use an IP address instead of a domain name, but if that address will be changing on a regular basis, you'll probably need modifications to standard XMPP servers and clients, as they'll not be expecting that.
I went through many Prosody tutorials and I think it is not possible to set up server based only on IP address and using SSL. I even have not found how to configure Prosody on local network with SSL and resolvable name like raspberry.local. My client always gave server not found, or incorrect communication.
I'm very confused by the fundamentals of DNS records (in this case MX records). Right now I have registered a domain name (let's call it example.com). This domain is configured to my linode's IP via their nameservers.
The default MX record that is in the Domain Manager is 'mail.example.com'. Fair enough.
I followed this tutorial about setting up a exim server.
Exim Tutorial in Linode Library
and I'm kind of confused. My default hostname on the machine is 'antares' and thus the FQDN is 'antares.example.com'. In this tutorial I don't see how this 'mail.example.com' is coming into play? Where do I specify this? Or should I point the mail MX record to antares.example.com?
I'm very new to DNS records and even more new to mail records. Any hints to clarify my misunderstanding would be invaluable.
the DNS server for your domain will by default serve up the www or .domain.com entry to web browsers etc but it actually hosts a bunch of name pointers for other services, one of which is mail exchange.
Services which need your mx record value know how to look it up from your DNS server, so in this case they will find mail.domain.com when you supply the domain.com part.
If you need to set up a mail server you will need to change the mx record in your domain manager to point to your machine ip, this can be different from your default www host name/ip on the same domain as every service can be served by a different host (any ip).