DNS servers pointing to site saying "owner knows site is down"? - dns

When my site goes down, I want to change my registrar DNS settings to
point to (for example):
ns1.this_site_is_down.com
ns2.this_site_is_down.com
ns3.this_site_is_down.com
ns4.this_site_is_down.com
where these nameservers would return a fixed IP with a low TTL for all
queries (or even a CNAME), and a webpage on that IP address would read
something like:
The owner of this website knows it is down and is working to fix
it. Once the site is fixed, you will no longer see this message.
To use this service, set your DNS servers to ... [as above]
Does such a service exist?
I realize this system wouldn't be perfect, but it would be useful.
DNS and "site is offline" messages
discusses creating your own 2nd nameserver to do this, but I'm looking
to do this with an existing service/server.

It doesn't exist for A records or CNAME records (the closest you can get here is using a round robin, but that doesn't solve your issue).
Your looking for a priority tag, which exists in MX only records.
I'm afraid your best option is just on the servers send out a 503 error with a HTML page as the ErrorDocument.

Related

How can I point my domain from Godaddy to another web server without using # and losing email services?

I have access to a Godaddy account where the company has all their domains. One of those I need to point to another web server running Apache. The person that used to work here before me solved this pointing to the new server IP using the record:
A # the.ip.addr.ess 1 hour
and in the webserver end I get it with Apache and as far as the webserver goes, it runs flawlessly. I even have some subdomains using the same A record structure.
But...now I have two issues. First, I lost email reception. I can send via smtp and webmail but anything sent to my domain gets bounced back after 24 hours, even if sent to an alias or forwarder.
The second issue is that I need to verify the domain with Firebase and even thou I created the TXT record, it cannot be found by Google. I'm sure it's because of the same reason.
What can I do? I understand a little about DNS and records, but not enough for this. I just want all html traffic to reach my webserver as it is now and keep the emails and other domain services working as they were.
As contacting Godaddy support, they said it is not their purview as it is external. I think they just don't know. Go figure.
Are you using GoDaddys NameServers? If not and these are pointing elsewhere no matter what DNS records you set in GoDaddy won't be picked up during DNS lookips. This may explain why the TXT record verification is failing. However if this was true changing the A record wouldn'd disrupt DNS.
# just means the root domain so no subdomain/prefix, mydomain.com.
www is a common subdomain used so you could have an A record which like:
A www the.ip.addr.ess 1 hour
so www.mydomain.com would resolve to the.ip.addr.ess
MX records are used to direct emails to your mail server. Make sure this is pointing to the mail server. If it's pointing at your A record then updating the A record will disrupt this.
Set the MX record to point to the.ip.addr.ess rather then mydomain.com, or an A/CNAME record other then your root domain (which you are updating)
Other considerations may need to be taken, if you have an SPF record (TXT record) this may also need updating, depending on it's current value.
I finally found what I had to do. I needed an A record named 'mail' pointing to the original Godaddy server IP address.
A mail my.ip.add.ress. 1 hour
Thank´s for all the help.

ALIAS record vs A Record for custom domains?

I have a site where users can point their own custom domain through the use of DNS records.
For example, someone might point example.com to theirsite.mysite.com so that they are free to use their own domain rather than a subdomain.
Which record would be best for users to set up?
An ALIAS record pointing to mysite.com
An A record pointing to xxx.xx.xx.xx
A CNAME pointing to mysite.com
What are the advantages of using each one?
Which is best depends on the specifics of what you're establishing. Here are the differences:
If you set up an A record, the DNS will resolve to an IP and the end user's browser will make a call to that IP with the host name. That's the call that you have to listen for and handle. Since it's direct to IP right from the start, at scale that IP should be a redirector or load balancer.
Otherwise if you need to switch it to a different machine as an endpoint, you have to deal with inconsistencies on how that traffic is routed due to DNS cacheing and whatever TTL you set expiring. Beyond that the biggest issue you're going to run into is that the customer registers their domain and if it's an A record you give them, they're putting in that IP and to change it you're going to have to get the customer to do it, which is definitely not best practice.
CNAME and ALIAS records are similar. In the brief outline you give above, either of these would seem to be better than an A record. You can give them a domain to enter and that doesn't ever change on their side - but you can switch the end IP they're going to as your architecture expands. There are a few minor differences, but the only significant one is that a CNAME cannot be used as an apex record, e.g. example.com, so most likely you'd need to use an ALIAS record.
If you want to read more about the differences between CNAME and ALIAS, there is a good article on it here.

whois lookup shows correct ip but why my browser can not find IP address of domain?

My website suddenly stopped working.
When I search for the domain name in WHOIS websites it is showing the correct server ip address and correct DNS IP address.
I can reach the website by its IP address but somehow when I am trying the domain name in browser its not working and its showing "This site can’t be reached"!
There is no error in my server log.
I tried different browsers and different systems and it is same issue.
I am really confused. Even when I am sending GET requests with Postman to my domain, it not reachable but sending request to IP is working!
whois and DNS resolution are two separate things and one does not imply anything for the other, so in short, except in very specific cases, if you have a DNS resolution problem you should use DNS troubleshooting tools, not the whois and especially not web-based whois (the only relevant whois is the registry one).
Now you are giving so few details that noone can really help.
Among the possible ideas to check and probable problems:
you forgot to renew the domain, your registrar put it on hold or worse deleted it (that you can see in whois)
you did a change in the DNS resolution and now it does not work anymore, use online troubleshooting tools like Zonemaster or DNSViz; alternatively your registrar and/or webhosting company should be able to help (since you are neither giving here the domain name nor details about the troubleshooting you do: for DNS problems, the browser is not the first tool to use, look instead at dig).
in appear that the problem was DNS on our local system. we changed it to 8.8.8.8 and then we could access to our domain!
it's usually because you use an addon domain, not the main domain for hosting orders that are set up on cpanel whm

Defining two sub domains of my domain as nameservers of another domain

Suppose that I own example.com that is served by my own DNS server and I can create every records that I want.
Now imagine that one of my friends get a new domain called new-domain.com and I want to help him manage his domain with his own DNS server.
So in my dns system for example.com, I create two A records as:
my.ns1.example.com -> some.ip.addr
and
my.ns2.example.com -> some.ip.addr
(some.ip.addr is the ip address of his DNS server)
and ask him to set my.ns1.example.com and my.ns2.example.com as name servers for his domain.
But he cannot set them because it gets invalid nameserver error!
Its my understanding that because example.com is working properly in DNS system and thus my.ns1.example.com and my.ns2.example.com are resolved to the IP address properly, so nothing can prevent them to be used as nameservers.
I searched around and found that some people say the nameservers should be registered. I understand registering when we have to ask for setting glue records, but for this case I have no idea why would we need to register those name.
To be more specific with real life example, why would jobs.ns.cloudflare.com is a valid nameserver but www.cloudflare.com is not?
I asked the same question on serverfault.com with this link
There, I quote important part of the answer here,
From a pure DNS perspective, an authoritative nameserver (such as those for com) should not perform any kind of recursion to learn the IP address of the nameservers that are defined in your example.com zone. Instead, the registry permits registrars to add glue records to the com domain, and those registrars can provide a user interface so that the owners of the domains that these custom nameservers live in can do so. (example: Namecheap - How do I register personal nameservers for my domain?)
(To address the elephant in the room...no, these glue records are not strictly required. But policies are policies, and if the registrar interface requires the registry level glue to be present, you have little choice in the matter.)
While the answer does not answer my updated part of the question, I picked it as the answer and decided to ask another question.
The problem does not lie in the names: my.ns1.example.com and my.ns2.example.com are fine.
The registry, and sometimes even the registrar, normally perform a few checks before approving a nameserver change. If your nameservers are rejected as invalid they are most likely not yet correctly configured for your friend's domain. I mean, the servers at my.ns1.example.com and my.ns2.example.com do not contain the minimum required records for new-domain.com.
That said, the registrar support team should be able to provide more details: if it's them who reject the change they should let you know what part of the automatic tests fails and even provide the test output so you can see by yourself. On the other hand, if they just pass the change to the registry (your friend should see a "operation pending at registry level" notice in his control panel for some time) they could do the extra effort of helping you out by providing hints based on their experience with that particular TLD. That is, if your friend didn't grab a promo offer in the 0.99$-5.99$ a year range for the domain: if he pays them something in the 20$-50$ a year range then he should expect and demand a proper, helpful support. I use one of the cheapest registrars and if my nameserver change gets rejected I still get a full report:
Dear customer,
The registry did not accept the nameservers you tried assigning to
new-domain.com because they did not pass the registry tests. Please
check the report we got from the registry below, fix the errors
and try assigning the nameservers again.
Nameservers Resolvable Test: ERROR
my.ns1.example.com. ERROR Unresolvable host my.ns1.example.com.
my.ns2.example.com. ERROR Unresolvable host my.ns2.example.com.
my.ns3.example.com. OK
my.ns4.example.com. OK
SOAQueryAnswerTest: ERROR
my.ns1.example.com. ERROR java.net.SocketTimeoutException
my.ns2.example.com. ERROR java.net.SocketTimeoutException
my.ns3.example.com. OK
my.ns4.example.com. OK
... ... ...
Update: The OP posted an update saying that as soon as the nameservers were registered with the registry, they were accepted in his friend's control panel. It appears that particular registrar checks for glue records and rejects the nameservers if they have none. This is an unnecessary check because glue records are only needed if the nameservers are within the same domain they serve, as explained in these questions. Registrars usually explain this very clearly or at least mention this above the nameserver change form:
Please note that in most cases the ip address is not required and will actually be ignored. It is only necessary if the nameservers you are entering are sub-domains of the selected domain (also called custom nameservers or vanity nameservers).
We can conclude that the friend's registrar performs an unnecessary blocking test and does not respond to user inquiries in a helpful matter. Since the OP has the following need (citation from his updated post on serverfault):
I need to be able to create dynamic nameservers programmatically and ask my users to enter their specific nameservers for their domains in their registrars.
I warmly recommend he does some research looking for a decent and reasonably priced registrar he can point his customers/friends to in case they have any issues with their current ones.

DNS Nameserver points to itself. Why?

I have inherited a web server that is hosting 5 websites for my client. Call them domian1, domain2, etc I just discovered that all the domain nameservers for all 5 domains are set to ns1.domain1.com and ns2.domain1.com. The single server is running the DNS for all the domains including domain1.com. ns1 and ns2 are both pointing to the same web server.
Aside from the fact that there is no redundancy, and the domain1 name servers are using the DNS to resolve their own IP's, why would anyone do this? Am I missing something?
There are two options when creating NS records for zones:
1) Set the NS record of each zone to point only to itself. Hence, domain1.com would get ns1.domain1.com, etc. The advantage of this is that the remote site doesn't need to do a cross reference to somewhere else and go look it up too. EG, if you have domain1.com's NS records pointing to ns1.domain2.com, then a lookup of the NS records for domain2.com have to be checked too to ensure it has the right location to go lookup where ns1.domain2.com really is. You could imagine the case where domain2.com's NS records point to domain3.com's name servers... This is obviously inefficient and results in a lot of unneeded chasing. So... pointing entirely internal seems like a no-duh, right! Less chasing! But... it also means you need to keep com's notion of your name servers in sync with your notion of your name servers, and when you add or remove them and/or change the IP addresses, you need to notify your com (through your registrar) that things have changed. (tech speak: update com's notion of your glue records).
2) Add an NS record pointing to an external server. This is common for server farms that sell you DNS services as part of their transaction as your registrar (ie, where you went to go buy domain1.com). They set your NS record to something like "ns1.godaddy.com". In your case, the previous zone owner set the NS records to all point to the domain1.com zone. This is actually helpful when you expect to change your address in the future. Rather than have to go change the IP address in all 5 of your zones, you only change it in domain1.com's ns1.domain1.com record and you're good to go. The other zones don't need to be touched. Yay! It's even more yay-full when you are managing 100 zones.
So, there isn't a right or a wrong here... It's a trade-off and different administrators do different things. Feel free to change it to the other model if you don't mind the zone-editing maintenance if you ever change anything. Personally, it's what I do when possible too: I like them internally self-contained. But then, that's also when most people fail to update the parent's glue records to match and there are tons and tons of zones in the world that are out of sync for exactly this reason: "oh, I'll do that tomorrow".

Resources