I am writing to you because I built an infrastructure with a Bind server and a PowerDNS recursor that transmits the requests to the Bind server. What I wanted to do was that the recursor transmits the ip of the client and not its., so I tried to do that using EDNS(0).
Here is a diagram that summarizes what I want to do:
Client : 10.0.0.1/24
|
| “test.com”
|
Server with PDNS-RECURSOR : 192.168.1.1/24
|
| “test.com” with ip_source=10.0.0.1/24
|
Server with BIND : 192.168.1.2/24
And the different configurations files :
• BIND Conf : 3 views
View recursor {} #Return specific IP for the recursor machine
View localhost {} #Return specific IP for the localhost machine.
View external {} #Return specific IP for the external machines.
• Pdns-Recursor Conf (4.1):
edns-outgoing-bufsize=1680
edns-subnet-whitelist=0.0.0.0/0.
forward-zones=192.168.1.2
use-incoming-edns-subnet=yes
Unfortunately, it always returns the view of the recursor, do you have a solution?
Thank you in advance !
You can not transmit the IP but you can transmit a subnet. This needs an EDNS option called Client-Subnet, described in RFC7871
For PowerDNS this is controlled in configuration by various options starting with ecs-, see https://doc.powerdns.com/recursor/settings.html#ecs-add-for
You may try ecs-ipv4-bits: 32 to try sending the whole IP (the option was more about sending a subnet, for privacy issues).
Bind configuration regarding this option is described at https://www.isc.org/wp-content/uploads/2017/04/ecs.pages.pdf
You should sniff out the traffic between the two to make sure PowerDNS sends correctly the information to bind.
You can also try with dig querying directly bind with the appropriate client subnet option (+subnet=) to make sure bind does what you need.
Related
I'm working on a system with three parts that communicate over HTTP. The parts are the Service, the ServiceRegistry, and the Client. The Service and the ServiceRegistry are self-hosted OWIN applications. The nature of the client doesn't matter.
In my design, the Service POSTs to the ServiceRegistry to "register" itself. The ServiceRegistry reads Request.GetOwinContext().Request.RemoteIpAddress to determine where the Service is located and GETs back to the Service to perform some handshaking (the port for this GET is supplied in the original POST). Finally, the Client comes along and performs a GET to the ServiceRegistry asking for the location of the Service and receives back the IP address and port on which it can directly interact with the Service.
This works well when all three parts are running on different machines.
However, when the configuration is that the Service and the ServiceManager are running on MACHINE01 and the Client is running on MACHINE02 the system fails. What appears to be happening is (when both parts are located on one machine) RemoteIpAddress receives a link-local version of the IPV6 address. I strip off the Scope ID from the IPV6 address and return the address and port to the Client. But, to the Client running on a different machine, this is an unreachable address.
Can anybody suggest how I can read the remote IP address from the OWIN request in such a way that it will be reachable from another machine on my network?
When you are connected with any address, I don't think there is a way to get other addresses of the peer.
You could either implement and use some registry of address mappings between link locale addresses and global addresses. (Always in the hope the peer accepts requests on its global address as well.)
Or if you have access to it I'd propose to modify the requesting peer to send the request originating from its global address. This can normally achieved with source address selection. But I have no idea how you do this on the .NET platform as I am working on Unix systems.
I am the proud owner of my very first server(registered with GoDaddy).
This machine, like most, has an IP. Let's pretend my server IP is 255.255.255.255.
I wish to host multiple servers on this tower: Minecraft, TeamSpeak, Feed the Beast, Garry's Mod, and my website. (Don't worry, I don't get much traffic.)
What I would like is a setup as such:
-------------------------------------------------------
|Service |Subdomain |Actual IP |
-------------------------------------------------------
|Website |digiduncan.com |255.255.255.255:80 |
|Minecraft |mc.digiduncan.com |255.255.255.255:25565|
|FTB |ftb.digiduncan.com |255.255.255.255:9001 |
|TeamSpeak |ts3.digiduncan.com |255.255.255.255:9987 |
|Garrys Mod|gmod.digiduncan.com |255.255.255.255:27015|
-------------------------------------------------------
How would I do this with DNS, or other GoDaddy domain manager options?
BLUF: You can't manipulate port traffic like that through DNS
As far as I know, you can not do this with DNS. DNS is for name to ip mapping. To specify a port like you are trying to do, that happens on the application that are trying to connect to your server. For example, someone connecting to your minecraft server would have to know to connect on port 25565 at that IP address (which can be set on the minecraft client connecting in). If you are going to want to do this through DNS, then you are going to have to have multiple IP addresses (which I'm assuming you are not wanting to do this).
I'm not a boundary device guy but maybe, MAYBE some kind of port redirection on your end with your firewall to your server (network firewall, not host) based on the provided URL. Or have a web service on the server to create a connection back to the client based on URL provide. Just spit balling here. I'm not sure how that would (if it would) work.
I have installed CentOS-6 server in our DMZ.
I have a public IP address which I will use for it.
Now, how should I set up its DNS in order to make it accessible from internet?
Is there any particular steps required for BIND in order to propagate the server to internet?
Thanks
to configure you can use
http://www.howtoforge.com/bind-installation-on-centos
You should refer this previous thread
https://serverfault.com/questions/153690/why-arent-our-dns-records-propagating-out-into-the-internet
There is no "propagation" so to speak; propagation is usually a term used to describe the delay in any updates made to the DNS when the old records have already been cached by some servers.
In this case, when you say that you want DNS on your server to be accessible to the Internet, you likely are planning to use BIND as an authoritative server, serving one or more zones. In that case, you will just have to ensure that TCP and UDP port 53 are open for incoming traffic from anywhere. You will set up BIND in a fairly standard manner. Just install BIND, add some zones to it.
On the zone that you're hosting, you will then refer to the hostname of the machine that you are running this BIND instance (and that hostname must be resolvable to an IP address), say ns1.myzns.com.
I have a gateway server that is also acting as a web proxy for clients and I need to get some information about the network connections. The gateway server has an internal and an external interface/IP-address.
If I use the 'netstat' or 'ss' command I get a display showing of all the clients' internal IP addresses/ports connecting to the gateway's internal IP address/squid-port. But if I run 'iftop' I get a display of the clients' internal IP addresses and the external IP address/port they are ultimately connecting to, it seems to ignore the proxy middleman.
The information from iftop is what I need, that is, internal ip:port to final ip:port ignoring the proxy, but I need to parse the output and can't seem to do that with iftop as it is interactive. Does anyone know a way to get iftop like information from a standard Linux command?
Thanks
If you are using a typical HTTP proxy setup, ss -at will show two entries: one for client--proxy, and one for proxy--webpage, just as it should, because two connections are live in such a case.
I have took a look to STUN Server settings in openfire, and this statement from there:
"In order to act as a STUN server, two different public IP addresses on the same machine are required, as well as two different port numbers for each IP."
I have researched on google, and generally stun servers need two public IPs, what is reason for that?
For attempting to establish P2P connectivity, the STUN binding request and response to/from the STUN service's primary address (IP and port) is all that really matters. The mapped address returned in the response body of this request is passed (via XMPP or other service) to the remote node that the local client is attempting to establish directly communication with.
The second IP and port that the STUN service listens on are useful for determining NAT port mapping behavior and NAT filtering behavior.
By making binding requests to the alternate IP:port on the service, a client can discover if his NAT has consistent mapping semantics for local ports. In the event he gets different port mapping values for each test, the client can conclude it is behind a "symmetric NAT" - which are the most difficult to traverse for P2P.
By sending up a bind request with a "change request" attribute that asks the service to respond from the other IP or port, a client can detect if his NAT just filters datagrams from remote hosts based on IP and port, or allows for datagrams from alternate ports on hosts it has sent outbound datagrams to.
The mapping behavior and filtering tests only provide limited information for subsequent P2P connections. In the case of determining a symmetric NAT is between the host and the Internet, some implementations may observe the NAT to have a consistent incremental value of the port value in each binding response. (e.g. the external port observed by the STUN service increases by one). As such, the client can offer an IP and guessed port number for the remote client to try to send to instead of the one mapped back from the first binding request. Or the client may use this behavior/filtering test for logging. Or to automatically allocate a relay in the event of symmetric NAT.
Because in some rare cases, the behavior of NAT translation is a function of the target IP address. Meaning, you must 'ping' two different IP addresses to find the precise behavior of the NAT (does it depend of the target IP address or not?)
If you 'pinged' twice the same server with two distinct ports, that would not cover this case properly (i.e., you would not be covering all your bases).
P.S.: The two IP addresses don't need be on the same server, it could be different servers.
I'm guessing that it is required to identify the type of NAT being performed - some NAT will use the same source IP address and encode the session id via the port number (I think it's called cone NAT but not sure), some NAT will use a combination of source IP and port to encode the session ID. The answer the STUN server needs to give the client is different based on NAT type.