I'm currently configuring DNS in my network with Bind9.
This network is splitted in VLANs and it should have 2 DNS zones : an internal zone (internal servers, users VLAN...) and an external zone (DMZ).
Of course the DNS mustn't give internal records to an external request.
I have just configured my DNS master (storing external and internal records) in "internal servers" VLAN and I'm asking myself how to deal with this problem :
-> My DNS master will not reply to an external request since it is in the internal zone (though 802.11Q is enabled), even with external records. Is it right?
-> My DNS mustn't be in the DMZ.
-> If I configure a slave on the DMZ to manage the external zone, who will just store external records, then I have to configure another slave to replicate the master (so 3 servers...).
Initially I just planned to configure 2 servers, a master and a slave which would just be a full replicate.
Am I missing something? Is there any better solution?
The architecture that you will follow depends on what you want to serve and where (internal clients, external both)?
In general, yes you need internal DNS servers these will have at least all the necessary entries for you internal network.
As for the servers in DMZ who will have access to them and from which path? If you need access to them from the internal network directly through firewall, it makes sense to have entries for them also in your internal dns servers.
If you serve also from servers in DMZ to external users you have two solutions either you declare them in public DNS if the external users are from internet or you should have another DNS server on your DMZ.
The key point here is to think who will visit your server and from which path, then it will become kind of obvious how you will configure DNS for them.
Related
I am trying to get the big picture although my primary domain is not networking.
Some question's narrowed down for which I'm not getting enough/proper answers online
Is the IP that is resolved by the DNS server when I hit www.google.com is same as any of the Google router's Gateway IP?
Do bigger companies like Amazon do port forwarding?
If point 2 is true, I suppose they must be port forwarding with only 443 (https) port which means, to use multiple static IP across different data centers, they need to have that many routers. So, if they have N static IP address which resolves to a website, then they must be having N routers right? Is this a fair assumption?
A gateway IP refers to a device on a network which sends local
network traffic to other networks. it sits between you and internet,or other network . its like a watchman.
Question 1 : google.com has multiple ip addresses lets say then , Yes, that is possible, and will need to be two A records. This is called Round-Robin DNS. Clients will semi-randomly use one of the two addresses.
question2: yes port forwarding happens more often than we think. ALL VPC's (virtual private clouds like AWS , GCP , Azure etc) use this as they dont want to expose servers/internal resources to the internet.
depending on the port number , particular service is exposed to requesting client. lets say we want to make a website public , then we explicitly expose port 80(http) 443(https) so that web crawlers and users can see them.
Port forwarding, sometimes called port mapping, allows computers or
services in private networks to connect over the internet with other
public or private computers or services.
google https://www.google.com:444/ wont work because they did not expose port 444 on their cloud router
but https://www.google.com:443/ will work because the server corresponding to google.com has explicitly left it open.
How IP is resolved:
Step 1 - Send a Request to Resolve a Domain Name
When you type www.google.com into a browser, in order to load the webpage, your computer asks for the IP address. Computers do not know in advance where they can find the necessary information, so they try searching through the DNS cache and for available external source. proceed from lower level caches to root/main servers.
Step 2+3 - Try to resolve an IP Locally
Before going externally, your computer loads the local DNS cache database to see if you already requested the IP for that domain name. Every computer has a temporary cache with the most recent DNS requests and attempts to connect to online sources. if required record is present locally its called "CACHE HIT" and query stops.
However A computer’s local DNS cache database does not always contain the necessary data to resolve a domain name this is called a "CACHE MISS" . In that case, the request goes further to your Internet Service Provider (ISP) and its DNS server.
Step 4 - ISPs Ask Outside DNS Servers to Provide an IP Address iff Cache miss
ISP DNS resolvers are configured to ask other DNS servers for correct IP address mapping until they can provide data back to the requester. These are iterative DNS queries.
When a DNS client sends such a request, the first responding server does not provide the needed IP address. Instead, it directs the request to another server that is lower in the DNS hierarchy, and that one to another until the IP address is fully resolved. There are a few stops in this process.
hierarchy looks like this (just for reference):
Root domain nameservers. Root servers themselves do not map IP addresses to domain names. Instead, they hold the information about all top-level domain (TLD) nameservers and point to their location. TLD is the rightmost section of a domain name... Root servers are critical since they are the first stop for all DNS lookup requests.
TLD nameservers. These servers contain the data for second-level domains, such as ‘phoenixnap’ in phoenixnap.com. Previously, the root server pointed to the location of the TLD server. Then, the TLD server needs to direct the request toward the server that contains the necessary data for the website we are trying to reach.
Authoritative nameserver. Authoritative servers are the final destination for DNS lookup requests. They provide the website’s IP address back to the recursive DNS servers. If the site has subdomains, the local DNS server will keep sending requests to the authoritative server until it finally resolves the IP address.
Step 5 - Receive the IP Address
Once the ISP’s recursive DNS server obtains the IP address by sending multiple iterative DNS queries, it finally returns it to your computer. The record for this request now stays cached on the hard drive. The browser can then fetch this IP from the cache and connect it to the website’s server.
ALL this happens in less than 1 second, most of the times. if you just registered a new domain it might take few hours to propagate this DNS cache globally hence newly registered websites do not show up sometimes.
About companies owning multiple IPs
Big companies have pool of IPs reserved for example 123.234.xxx.xxx which means a company has reserved 255*255 ips. they are mapped on a VPC(virtual private cloud)
and accessible vis a subnet masking and CIDR feature, like your EC2 instances on AWS
Is the IP that is resolved by the DNS server when I hit www.google.com is same as any of the Google router's Gateway IP?
For sure it should, but it is mostly a Google management question that only they will be able to answer right. The thing is that we must understand how DNS query's work for this.
Let's take a look of it:
Device A requests the IP address through a DNS query of the device B.
To do this, it uses the network port 53 (Domain) on which it will ask, depending on which DNS server is being used at the time, which is usually the home router. Then the router will ask the ISP's DNS server, which will respond with a cached response, or the query with another server on top of it if it does not have one; All this process is followed until a reliable cache response is reached or until the authoritative response server is reached, that is, the name server that manages the domain in question.
Only the authoritative response server contains the reliable information of which IP of the domain which is going to be reached.
I suppose that within Google's servers and its network they use Google's own DNS servers, which are 8.8.8.8 and 8.8.4.4 where the DNS records are obtained and consulted by caching from many sites.
In general terms Google's IP will change depending on where you are, I made a DIG query to Google's authoritative servers, however, I received a result based on location to improve the route and loading time of the site which was 142.250.73.238.
Do bigger companies like Amazon do port forwarding?
Yes, they do. To handle queries with load balancers or similar and even for caching dns requests.
If point 2 is true, I suppose they must be port forwarding with only 443 (https) port which means, to use multiple static IP across different data centers, they need to have that many routers. So, if they have N static IP address which resolves to a website, then they must be having N routers right? Is this a fair assumption?
This has multiple answers. By the way, they actually can do a secure DNS query.
if they have N static IP address which resolves to a website, then they must be having N routers right?
They don't have to, but if they want to they can.
"Is this a fair assumption?"
No, the IP's doesn't depend on a router, the router only routes to a computer/server which can have multiple IP's. By the other hand, each thing (computer, server, etc... must have an IP which can be also a WAN IP).
Task:
Create a UDP Load Balancer with Failover at Amazon for EC2 Instances.
Problems:
Based on the explanation below, I have the following problems:
AWS EC2 Doesn't have a Public DNS Name that works for both IPv4 and IPv6 traffic.
Unable to reassign the current IPv6 address to a new instance in another availability zone.
Explanation:
By Failover, I mean that if the instance goes down for whatever reason, spin up a new one and replace it. If the availability zone it is in is down spin up a new instance in another availability zone and replace it.
With Elastic IP Addresses I am able to re-assign the existing Elastic IP Address to the new instance, regardless of its availability zone.
With IPv6 Addresses, I am unable to reassign the existing IPv6 Address if the new instance is created in a different availability zone, because it is not in the same subnet. By availability zone, I am referring to Amazon's Availability Zones, such as us-west-2a, us-west-2b, us-west-2c, etc.
The only way I know how to resolve this is to update the Host Record at my registrar (Godaddy in my case.) with the new IPv6 address. Godaddy has an API and I believe I can update my host record programmatically. However, Godaddy has a minimum TTL of 600 seconds, that means my server could be unreachable by IPv6 Traffic for 10 minutes or more based on propagation.
Amazon has an amazing Load Balancer system if I am just doing normal TCP traffic. This problem would be non existent if that were the case. Since I need to load balance UDP traffic, I'm running into this problem. The AWS ELB (Amazon Elastic Load Balancer) provides me with a CNAME that I can point all of my traffic to for TCP traffic. So I don't need to worry about the separate IPv4 vs IPv6 traffic. I can just point the CNAME directly to the DNS Name that Amazon provides with the ELB.
Amazon Also Provides a Public DNS for EC2, but it is only for IPv4 Traffic. So that would work for my IPv4 Traffic but not my IPv6 Traffic.
The only option I can think of is to setup a Software Based Load Balancer, in my case NGINX on an EC2 Instance. Then point the domain to the NGINX Load Balancer's IPv4 and IPv6 Addresses. Then when a zone crashes, I spin up a new AWS EC2 Instance in another zone. Then use Godaddy's API to update the IPv6 Address to the New Instance's IPv6 Address.
Request
Does anyone know how to assign a CNAME to an EC2 Instance without an AWS ELB? The instance would need to be able to receive both IPv4 and IPv6 traffic at the CNAME.
The only way I can think of doing it, will cause down time due to propagation issues with DNS changes at my Domain Registrar.
I've been looking at the Route 53 options in Amazon and it appears to have the same propagation delays.
I've thought about setting up my own DNS server for the domain. Then if the IP Address changes I could potentially change the DNS entry faster than using Godaddy. But DNS Propagation issues are going to be a problem with any dns change.
[EDIT after thinking about my answer]
One item that I did not mention is that Route 53 supports simple load balancing and failover. Since you will need two systems in my answer below, just spin up two EC2 instances for your service, round-robin load balance with Route 53 and add a failover record. Create a CloudWatch alarm so that when one of your instances fail, you know to replace it manually. This will give you a "poor man" load balancer for UDP.
Configuring DNS Failover
[END of EDIT]
First, I would move from GoDaddy DNS to Route 53. I have no experience with programming GoDaddy DNS entries, but Route 53's API is excellent.
GoDaddy does not support zone apex CNAME records (example.com). You would need to use IPv4 A records and IPv6 AAAA records. This should not be a problem. I would use AWS EIP records so that when launching the new instance, at least IPv4 DNS entries would not require DNS delays.
I would not setup my own DNS server. I would switch to Route 53 first. When you mention propagation delays, you mean TTL. You can change the TTL to be short. Route 53 supports a 1 second TTL entry, but most DNS clients will ignore short TTL values so you will have little to no control over this. Short TTLs also mean more DNS requests.
AWS does not offer UDP load balancing but there are third party products and services that do that run on AWS. If your service is critical or revenue producing use a well tested solution.
I would not try to reinvent the wheel. However, sometimes this is fun to do so to better understand how real systems work.
STEP 1: You will need to design a strategy to detect that your instance has failed. You will need to duplicate the health check that a load balancer performs and then trigger an action.
STEP 2: You will need to write code that can update Route 53 (GoDaddy) DNS entries.
STEP 3: You will need to write code that can launch an EC2 instance and to terminate the old instance.
STEP 4: You will need to detect the new addresses for the new instance and update Route 53 (GoDaddy).
The above steps will require a dedicated always on computer with a highly reliable Internet connection. I would use EC2 for the monitoring system. T2-micro is probably fine.
However, look at the amount of time that it will take you to develop and test this new system. Go back and rethink your strategy.
We created a subdomain for a website hosted in our internal server. In GoDaddy we set up the subdomain to point to the public IP address, but when we try to access the link internally it doesn't load (because it needs the internal IP to access it) What can be done in this case?
You obviously need to provide different information to internal DNS clients than those publicly available to the world. For that you need to have internal DNS server or DNS proxy that will respond with internal IP address, and your internal clients need to be configured to use that internal DNS server. Specific steps to achieve all this depend on your environment.
The other option is to create another DNS record (for example subdomain-internal.example.com) that will point to private IP address, and use that from internal network (of course, you might need to configure your webserver to respond to that hostname also)
So basically.
I have one external IP.
I am running few web servers on my internal network.
All web servers are configured in NAT with different ports (80,81,82,...)
My domain's DNS is configured on my external IP. And NAT forwards it to my first web server.
Until now when I open my domain let's say example.com it opens my first web server's page.
When I open example.com:81 it opens second server, etc..
What I am trying to achieve is some way to open my other web servers on different sub-domains without specifying port.
So I would like to have something like:
second.example.com -> example.com:81
third.example.com -> example.com:82
I am using SRV record for my TeamSpeak3 server, so my TS3 is running on port 2222 and SRV record translates my ts3.example.com to example.com:2222 and it works like a charm.
Can those sub-domains be configured by SRV records in DNS?
If it can't. Is there any other way?
Thanks
Since you are behind a NAT all your web-servers share the same endpoint. You will need to set up virtual hosts that resolve all requests based on domain information passed in an HTTP packet. The server that hosts these virtual hosts will then parse the incoming packets and distribute the request to the appropriate virtual host based on domain name resolution.
Apache makes this pretty easy through its implementation of name-based virtual hosts.
IIS has a solution as well as this stack overflow answer points to.
Good luck!
I have got a dedicated server that has nginx web server located in a uk datacenter, the ngnix acts as a front end server which then directs users to other instances that i have on aws located in america. What ip address would the client see, the ngnix front server(which is the desired result), or would the client still know about the instances or servers ip address located in america?
PS. nginx acts as a load balancer here.
Typically, users connect to "www.yoursite.com", and that gets looked up in DNS.
Assuming there is only one DNS entry (corresponding your nginx frontend), then as far as those users are concerned, they are only talking to that one machine.
Sometimes people use round-robin DNS, where multiple machines correspond to a given host name.
Presumably you would know if you were doing this, though (:
You can confirm this by tracing your traffic when connecting. Maybe use WireShark?