From zookeeper doc
ip uses the client host IP as an ACL ID identity. The ACL expression is of the form addr/bits where the most significant bits of addr are matched against the most significant bits of the client host IP.
However setAcl /node1 ip:127.0.0.1/16:cdrwa returns Acl is not valid : /node1 (setAcl /node1 ip:127.0.0.1:cdrwa works fine)
Do I miss anything?
Checked with 3.4.8 and 3.4.10
Solved, caused by the bug which was fixed in 3.5
Related
As far as i know what we get from a dns query is a ip address. So in the end of the day if thats true we are still using ip addresses to connect the server and domains are pretty names for them.
So how does a server know which domain i used to query that ip address?
How does vhosts work an understand that if the domain data is lost during dns query?
The Internet works in layers. Each layer uses different kind of parameters to do its work.
Layer 3 is typically IP aka Internet Protocol. To work it uses IP addresses, each computer has at least one to be able to discuss with another one. And there are two families in fact: version 4 and version 6.
Since multiple services can be on any given computer at some point, you need a layer on top of that, layer 4, that deals with transport. The "predominant" one is TCP aka Transport Control Protocol, but there is also UDP. TCP and UDP uses ports: a 2 bytes integer that encodes for a specific protocol.
For example, HTTP was given port number 80 (completely arbitrary), and HTTPS port 443.
The DNS, which itself uses UDP and TCP (on port 53), allows, among other things, to map a given hostname to a given IP address or multiple IP addresses. This is the typical A and AAAA records. There is also a CNAME record that maps one domain name to another. There also exists a SRV record that maps a service (which is a protocol name + a transport) to a given hostname and port number.
When one computer connects to another, its first step for all the above is to find out which IP address to use to connect to. It can use the DNS for that. Typically it will get only the IP address, but, depending on the protocol (layer above 4), may also get a port (if using SRV records).
The HTTP world does not use SRV records. So a browser just uses the hardcoded 80 or 443 ports, or the port number appearing in the URL.
Then we are at the transport level, let us say TCP.
The connection is done (since now the remote IP address and port are known) and the protocol above TCP, like HTTP, is free to convey any kind of extra data, such as the hostname that the client initially used (as taken from the URL) to find out the IP address.
This is done through the HTTP host header, see RFC 2616
Note that if you do things through TLS (which conceptually sits between TCP and HTTP) there is even something else happening: SNI or Server Name Indication.
When doing the TLS handshake, so before any kind of HTTP headers or content, the client will send the final hostname desired in some specific TLS message. Why? So that the server can find which specific certificate it should answer which as otherwhise it would not be able to know which hostname is requested as this sits in some HTTP header which do not exist until the TLS handshake is finished.
A webserver will be able to see both the SNI content to find out which certificate to send back and then the host header to find out which VirtualHost (in Apache) section is relevant to the query being processed.
If you are not in HTTP world, then it all depends on the protocol used. Older protocols, like FTP, did not plan for "multihoming" at the beginning, a given IP address meant only one hostname and service for example.
I'm a little confused about IP addresses.
I know that every web domain has an ip address.
Does the IP address represent the physical machine / host the website files are stored on?
Therefore when DNS lookup is performed, the domain's IP address is returned to the client. The client then uses this ip to contact the server that the web files reside on.
Is my understanding correct?
Many thanks
You are correct.
It is kind of like how some companies may say Dial PIZZAHUT instead of saying, Dial 74992488. PIZZAHUT is easier to remember, but you actually are dialling the number.
You're talking about HTTP protocol. Yes, FQDN (web domain) is resolved to IP address by DNS server. Client will connect to server IP address. Since you're probably using HTTP 1.1, HTTP request will contain also FQDN. This information is used by web server to perform several checks, like SSL certificate validation or Virtualhost management (several domains on a single IP address).
In man page about SO_REUSEADDR(man 7 socket):
When the listening socket is bound to INADDR_ANY with a specific port then it is not possible to bind to this port for any local address. Argument is an integer boolean flag.
But in Unix Network Programming, I find:
SO_REUSEADDR allows a new server to be started on the same port as an existing server that is bound to the wildcard address, as long as each instance binds a different local IP address. This is common for a site hosting multiple HTTP servers using the IP alias technique (Section A.4). Assume the local host's primary IP address is 198.69.10.2 but it has two aliases: 198.69.10.128 and 198.69.10.129. Three HTTP servers are started. The first HTTP server would call bind with the wildcard as the local IP address and a local port of 80 (the well-known port for HTTP). The second server would call bind with a local IP address of 198.69.10.128 and a local port of 80. But, this second call to bind fails unless SO_REUSEADDR is set before the call. The third server would bind 198.69.10.129 and port 80. Again, SO_REUSEADDR is required for this final call to succeed.
Aren't they contradictory?
They are not in conflict. The second quote provides a way around the default behaviour specified by the first paragraph.
I've a VPS with IPv6 and a IPv4 NAT - so I have access to the server through IPv4 with a port range for my service.
The ideal use for the server would be a mail server and DNS records (specifically MX records) cannot take a port.
Is there anyway to access this server without having to declare the port, for example through a domain like example.com being mapped to 192.168.1.1:200?
IP does know nothing about "ports". It is a network layer protocol that is responsible for addressing and routing. Look closer to OSI model, for example here: OSI
Any service you run is situated above this layer. It hard to understand what do you mean under "access the server"? If you think about SSH or RDP -- you can't reach them without port definition. If you think about exchanging information between client and server without specifing the port -- it is possible. For example by using ICMP for data exchange though it is not meant for that.
Every service need a port.
DNS need to run under a port 53(or not)..
MX record is not a service.
You need to know what is a service and the relation of a service and ports
I'm working with Microchip's TCP/IP stack and the host name of my device is not being broadcasted, although I can access it using its DHCP assigned IP.
So the question is, what is the protocol that a network device uses to broadcast its host name, so that when I see a list of devices in a network I can identify it by name?
Is it the NetBIOS name service or something else? Thanks in advance.
The most network-agnostic way to specify a hostname for a host on the network is through DNS, which your device itself cannot control, but all is not lost.
In most environments, the DHCP and DNS servers are tied (AD in Windows networks, DNSMasq on linux, etc...) so your best option is to rely on this behaviour. When you request an IP using DHCP, the DHCP protocol allows you to specify the hostname you'd like to use and if the network is set up to allow DNS entries to be created and maintained by the DNS server, the hostname you send during your DHCP request will typically be used.
The DHCP parameter is called 'Hostname'. The Network protocol documentation for this parameter is located in RFC 2132, and explained here.
There is WINS (based on NetBIOS) that supports this functionality.
There is ZeroConf/Bonjour that offer a "service advertisement" protocol but I am guessing that's not what you are after here.
In "normal" IP based networks, name resolution would go through a DNS layer: the DNS servers propagate their databases (if instructed too of course) but there is no concept of "broadcasting" at this layer.
I guess you've solved this by now but I modified the dchp.c file in the Microchip stack and added the following to the options part of _DHCPSend().
// host name
i = strlen(AppConfig.NetBIOSName);
UDPPut(12); //host name code
UDPPut(i); //length
UDPPutString(AppConfig.NetBIOSName);
This worked for me.