Primary and Secondary DNS on two internet connections, one server [closed] - dns

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Currently my network setup is as follows:
1 server, 3 ethernet cards.
eth0 - ISP1
eth1 - ISP2
eth2 - local network.
What would be the proper way of configuring primary and secondary DNS?
Using tinydns.
Current configuration:
2 tinydns services running on the same machine, each configured on a different ip (NS1 = eth0, NS2 = eth1)
each dns configuration contains both records:
NS1:
.domain.lv:10.10.10.10:ns.domain.lv
.domain.lv:20.20.20.20:ns2.domain.lv
#domain.lv:10.10.10.10:mail.didzis.lv:10:256::
#domain.lv:20.20.20.20:mail.domain.lv:20:256::
+www.domain.lv:10.10.10.10
NS2:
.domain.lv:20.20.20.20:ns.domain.lv
.domain.lv:10.10.10.10:ns2.domain.lv
#domain.lv:10.10.10.10:mail.didzis.lv:10:256::
#domain.lv:20.20.20.20:mail.domain.lv:20:256::
+www.domain.lv:20.20.20.20
The second link is more like a backup in case the first one fails and vice versa. Wont this configuration fail if eth1 is down and the www resolves to 20.20.20.20
Thanks!

This kind of configuration can work but there will be issues. What you want to do is make the TTL of the "www.domain.lv." record really low. The TTL tells other DNS servers how long they are allowed to cache the response. The lower you make it, the quicker clients will notice when one of your ISPs is down, but making it lower will also make it so they have to recheck the IP address more often, which will cost time. 300 seconds (5 minutes) might be a reasonable compromise but I would suggest making it longer (like 900 seconds) if you can afford for a failover to take 15 minutes.
By the way, I don't know how you set the TTL for a record in tinydns. I've never used it (and frankly I find its syntax quite cryptic and scary if your transcripts of the zonefiles are anything to go by).
This will all work fine when both ISPs are up.
The major drawback of this solution is that, when one of the ISPs is down, there will be DNS resolution delays no matter what. Lucky clients will try to query the nameserver that's still responding and get back the IP address that works for an answer. Unlucky clients will try to query the nameserver that's down first. This won't work. They will eventually fail over to the one that's still up and get a working IP address, but you must be prepared for a delay of (maybe) several seconds before this happens.

Related

How to force shodan update scanning and port reports according to new values

Hello to this wonderful community. Recently i bought a vps machine to host a website there. i take all the necessary security measures and i am ok. My problem is that shodan finds over than 10 ports open and over than 5 domains assigned and of course, some CVE exploits its probably from previous assigned clients because when i checked it with my nmap and also contact with my service provider we found the only ports open are 80, 443.
I don't want my ip to be black listed like that from previous reports and scans where shodan scanned before me. Any idea how to fix it and force shodan update his stats??
The information in Shodan automatically expires after a port has remained closed. It needs to stay closed for multiple checks by the crawlers in order to confirm that it's permanently closed and not a temporary glitch.

Best Practice DNS Configuration for Single Server Hosting Multiple Domains [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 2 years ago.
Improve this question
Note: IP addresses and domain names have been changed to equivalents so as not to attract attacks!
Background
I'm setting up a standalone VPS on which I'll host half a dozen or so domains catering both email and web hosting. I may add additional VPSs later but don't want to register a new FQDN for each new server. I plan to have single domain name with a subdomain created for each server. For example s1.myserverdomain.com and s2.myserverdomain.com. These FQDNs will be used to provide resolvable names for common services like mail.s1.myserverdomain.com.
The first VPS will have two IP addresses, so that I can use it for providing nameserver services as ns1.s1.myserverdomain.com and ns2.s1.myserverdomain.com. Later, when I add another server, I'll split them up.
(You might tell me that this is bad practice to run both nameservers on the same machine, because in the event that one goes down, so will the other, but considering that in that instance, so too will the mail and web hosting, there doesn't seem much point paying for another server just yet.)
What I want to finish up with is with godaddy handling the DNS for myserverdomain.com and creation of nameservers for ns1.s1..., ns2.s1... on my VPS and later will transfer ns2.s1 to ns2.s2. I will set the nameservers for each of the half dozen hosted domains to use those nameservers.
My Configuration
So far I have created the following DNS records at Godaddy for myserverdomain.com in addition to the default records created automatically by Godaddy:
TYPE NAME VALUE
A s1 100.1.1.1
A ns1.s1 100.1.1.1
A ns2.s1 100.1.1.2
A mail.s1 100.1.1.1
A smtp.s1 100.1.1.1
There is a section on Godaddy for setting up hosts. I don't fully understand why this is, as I thought we just needed to create 'A' records to do that? Anyway, these are the hosts I've setup in that section:
HOST IP ADDRESS
s1 100.1.1.1
ns1.s1 100.1.1.1
ns2.s1 100.1.1.1
These records were all created more than 48 hours ago, so have completed propagation.
The VPS Setup
The VPS is running Ubuntu 18.04 with ISPConfig 3.1 installed for the panel. It was setup following "The Perfect Server" tutorial for ISPConfig which included the installation of Bind. The hostname was set to s1.myserverdomain.com from the outset.
The panel currently shows the status of BIND as being "UP".
Current Status
When I head over to mxtoolbox.com and perform a DNS check on s1.myserverdomain.com it reports "No DNS server can be found".
My Question
I need to know what I've done wrong. Are there any records I should have created? Of those I did create, are any unnecessary or wrong? Thanks!
Could be several things, maybe you have port 53 closed, maybe your NS records aren't set up correctly, etc...
You already noted how having the nameservers on the same machine is bad practice. Using a second IP is useless, I wouldn't bother. People can point a subdomains to a different IP address, and some DNS providers will wait a long time if they can't reach you, so even if your server is down for a minute, for some users it will be down for a long time.
If you share your domain name, we can look it up and see what's wrong. You can also do this yourself with tools like zonemaster.net and intodns.com
Lastly, ISPConfig has a good forum on howtoforge.com/community, I recommend it!

What's the danger in DNS nameserver downtime?

I am thinking about hosting my own nameservers.
Two different IPs are required for this, and generally it is expected that these will be two different machines because downtime of one's DNS nameservers is evidently "bad".
But I can't find anywhere that will actually tell me the consequences.
If I am running a number of domains on a single server that has close to 100% uptime, is it really a big deal if I run my nameserver on that machine (I have two+ IP addresses that point to that server).
Can someone tell me what the worst case failure is, apart from possibly the DNS being down for a few hours after a downtime for the machine?
If all your name servers are unavailable for a longer period than your zone TTL, your zone will disappear from the Internet. Until at least one name server is brought back online, the zone will not exist. Mail sent to your domain will bounce, attempts to reach your web servers will make the browser go "Nope, no such site" and so on.
Since most people have a domain because they want to use it for something, it ceasing to exist is generally regarded as a problem.

Slow website even though VPS is up and running

Sorry if this is a bit of a newbie question, but I am quite new to VPS and the relatively more complicated set up. I have a VPS set up, and every day or twice a day the site loads for a bout 10 minutes with no luck. Then when it comes back on line its fine after that. Upon logging on to Plesk, the server is up and running, very low CPU usage (0.10 and drops to 0.00 after a few minutes) and around 18% RAM usage.
The MySQLAdmin loads up fine.
So it seems the VPS is running fine.
Is there maybe another reason? The domain is with Daily.co.uk and the VPS is with LCN.com. Could there be another problem somewhere? On daily.co.uk, there are two nameservers set. ns0.etc*** and ns1.etc***. I did a tracert on windows cmd, this traced down to the server, with two timeouts.
I also tried a check on http://dnscheck.pingdom.com/ while the site was slow and this came back fine, except this: Too few IPv4 name servers (1). Only one IPv4 name server was found for the zone. You should always have at least two IPv4 name servers for a zone to be able to handle transient connectivity problems.
Any help would be appreciated. I have tried searching but with no luck.
The recommended diagnostic check for the issue you are experiencing is called a DIG.
On your Windows system, this check is not intrinsically available, but it can be downloaded from http://members.shaw.ca/nicholas.fong/dig/
Once you have installed it, you'll want to run it from the command prompt with the following syntax:
C:> dig -insert your domain here- +trace
This will show you how DNS resolution is happening from your location to the requested end point. Chances are, the error you received is correct. Most DNS setups have several name servers to assign to your domain registration to allow the round-robining of delegated name servers in the event that one becomes unresponsive.
My personal recommendation would be to outsource the DNS to a managed provider. Doing so will increase the availability of the zone, and reduce latency.

Can reverse DNS be turned off for NFS? [closed]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
We have setup 3 Virtual Machine server machines that mount the VMs from 2 other storage machines. We mount the VMs from the storage servers to have less data to move when moving the VMs(pause on one server, mount on new server, unpause) and to facilitate snapshots and backup.
We were in the middle of an extended power outage due to storms (the ops team forgot to check that we had fuel in the generator and the don't test it weekly tsk, tsk), so we shut everything down.
After fueling the generator, we started to bring everything up. Big problem.
To NFS mount the storage, NFS wants to do a reverse DNS lookup, but the DNS server is a VM that can't start until the storage is NFS mounted!
We copied the DNS server VM to one of the VM servers locally and started it so we could then bring everything up.
We would like to run NFS without the reverse lookup (everything is on our internal network) but can't find out how to turn off.
Any help is appreciated
Put the IP address of the NFS clients in the /etc/hosts file of the NFS server with a comment like:
# 2009-04-17 Workaround a chicken and egg DNS resolution problem at boot
192.0.2.1 mynfsclient
192.0.2.2 anothernfsclient
Then, add to your runbook "When changing the IP addresses of a machine, do not forget to update the hosts file of the NFS server".
Now, to shut off this stupid DNS test in the NFS server, it depends on the server. You apparently did not indicate the OS or the server type.
I had a similar problem with an old Yellow Machine NAS box - I was having DNS/DHCP fights where the reverse lookups were not matching the forward lookups.
In our case, just putting dummy entries in the NAS box /etc/hosts for all the IPs solved the problem. I don't even need to have correct names for the IPs - just any name for an IP solved stopped mountd from complaining.
(Interesting side note - at least in the older version of Linux on the NAS box, there's a typo in the NFS error message: "DNS forward lookup does't match with reverse " )
Can't you just put the ip address of the server in question in the fstab file and no dns lookup will be required.
It's NFS v4, the problem is that all the requests for access use a reverse DNS lookup to determine the NFS domain for access/security purposes.
I think you can stop this behavior by putting a line in /etc/default/nfs containing:
NFSMAPID_DOMAIN=jrandom.dns.domain.com
This needs to match across all the systems that are sharing/using NFS from each other. See the section about Setting NFSMAPID_DOMAIN, which is to the end of the page which explains what happens when it's not set.
NFSv4 - more fun than a bag of weasels.

Resources