I want to host only a subdomain to cloudflare. I do not want to change the nameserver of my main domain to theirs. Is it really possible?
Yes, this is possible, however it needs to be set-up via a CloudFlare Partner or you need to be on the Business or Enterprise plan. They can set-up domains via a CNAME record instead of moving nameservers.
There is a complete list of partners at: https://www.cloudflare.com/hosting-partners
We use this at Creare, it allows us to set-up a clients site on CloudFlare yielding the performance and security benefits without altering their nameservers (where it is impractical or the client doesn't want us to), we provide this option without them needing a Business or Enterprise plan leading to it being at a lower price for the client.
Related
I see that in CloudFlare’s DNS FAQs they say this about wildcard DNS entries:
Non-enterprise customers can create but not proxy wildcard records.
If you create wildcard records, these wildcard subdomains are served directly without any Cloudflare performance, security, or apps. As a result, Wildcard domains get no cloud (orange or grey) in the Cloudflare DNS app. If you are adding a * CNAME or A Record, make sure the record is grey clouded in order for the record to be created.
What I’m wondering is if one would still get the benefits of CloudFlares infrastructure of the target of the wildcard CNAME record IS a Cloudflare Worker, like my-app.my-zone.workers.dev? I imagine that since this is a Cloudflare controlled resource, it would still be protected for DDoS for example. Or is it that much of the Cloudflare security and performance happening at this initial DNS stage that will be lost even if the target is a Cloudflare worker?
Also posted to CloudFlare support: https://community.cloudflare.com/t/wildcard-dns-entry-protection-if-target-is-cloudflare-worker/359763
I believe you are correct that there will be some basic level of Cloudflare services in front of workers, but I don't think you'll be able to configure them at all if accessing the worker directly (e.g. a grey-cloud CNAME record pointed at it). Documentation here is a little fuzzy on the Cloudflare side of things however.
They did add functionality a little while back to show the order of operations of their services, and Workers seem to be towards the end (meaning everything sits in front). However, I would think this only applies if you bind it to a route that is covered under a Cloudflare-enabled DNS entry.
https://blog.cloudflare.com/traffic-sequence-which-product-runs-first/
The good news is you should be able to test this fairly easily. For example, you can:
Setup a worker with a test route
Point a DNS-only (grey cloud)
record at it
Confirm you can make a request to worker
Add a firewall rule to block the rest route
See if you can still make the request to worker
This will at least give you an answer on whether your zone settings apply when accessing a worker (even through a grey cloud / wildcard DNS entry). Although it will not answer what kind of built-in / non-configurable services there are in front of workers.
We have around 50 applications currently configured with LDAP and we have around 20 Domain Controllers. As per the security best practice we have to migrate all these applications from LDAP to LDPAS.
Currently, all applications are connected using Domain's "NETBIOS" name so there no need to worry about high availability.
What is the best design approach to achieve high availability for LDAPS?
Prefer not to configure individual DC servers as LDAPS servers in the application.
Note: all the servers (DC and application servers) are enrolled in on-prem PKI.
In my enterprise environment, there is a load balancer with a virtual IP which distributes traffic accross multiple DCs. Clients access ad.example.com, and each DC behind ad.example.com has a cert valid both for hostname.example.com and ad.example.com (SAN, subject alternative name). This has the advantage of allowing the load balancer to manage which hosts are up -- if a target does not respond on port 636, it is automatically removed from the virtual IP. When the target begins responding, it is automatically added back. LDAP clients don't need to do anything unusual to use this high availability AD LDAPS solution. The down side is that the server admin has ongoing maintenance as DCs are replaced -- we build a new server and then remove the old one. In doing so, the old IP is retired. The new IP needs to be added to the load balancer virtual IP config.
Another approach would be to use DNS to find the domain controllers -- there are SRV records registered both for the Site domain controllers and all domain controllers. Something like _ldap.tcp.SiteName._sites.example.com will give you the DCs in example.com's SiteName site. For all DCs in the example.com domain, look up _ldap._tcp.example.com ... this approach, however, requires the LDAP client to be modified to perform the DNS lookups. The advantage of this approach is that the DCs manage their DNS entries. No one needs to remember to add a new DC to the DNS service records.
I have recently acquired a domain name from GoDaddy. At home i am trying to setup a nextcloud server. Since my ISP serves me a dynamic IP addresse i had to create another domain name on no-ip website. Furthermore, i want to forward http requests to https. The following questions rises:
Do i create the ssl certificate (with let’s encrypt) for the godaddy domain or the no-ip domain?
What is the correct forwarding sequence here? Assume godaddy is foo.com and no-ip bar.dyndns.me and the user types foo.com, my server apache settings would forward foo.com:80 to :443 but this i guess should be corrected to my dyndns. I am confused.
I would appreciate any help - thank you.
you are making it too complicated. Instead of using a redirect you should request a static ip from you isp. this costs money varying by your provider but then you only need one domain. you then apply the ssl certificate to that domain and enforce ssl only with your hosting server (i.e apache, iis).
You can write a simple app/script to manage the Dynamic DNS from your server using the GoDaddy Api, thats what i have been doing for ~3 years now as my ISP want a stupid amount for a static IP. I have mine pinging out every 10 mins to check if my IP changed (ISP sucked for a while and mine would change several times a day)
Here are some links to various implementations of the GoDaddy API
BASH
Python
Powershell
So I think I have a fix for this, before I give you my answer I will outline problems with other solutions.
Static IP from your ISP. The problem with this is it may cost too much. (However if it’s cheap I’d probably do this solution)
Script and update godaddy DNS. This is okay however only if you can allow for some outage time between changes. (The DNS will take time to Propagate up to 24 hours)
Upgrade your noip account to a plus managed DNS it costs $29.95 a year. However it will allow you to bring your own domain name from another provider like go daddy. Depending how often your noip client is running there could be a very small outage between changes.
https://www.noip.com/support/knowledgebase/can-i-use-my-own-domain-name-with-no-ip/
I recently signed up for CloudFlare to take advantage of the security feautres the service provides. Specifically, I'm interested in its use against DDOS attacks (which are a problem I'm facing).
My web application employs nginx as a reverse proxy (with gunicorn as the application server). The Ubuntu-based virtual machine - procured via Azure - has a static/reserved IP (used as a VIP). I've read that after connecting to CloudFlare, it's best practice to change server IP so that malicious actors can't directly DDOS the said server.
Being a newbie, I'm unsure whether this guideline was applicable to the public VIP (virtual IP) or to the internal IP (which is entirely different). Can someone please conceptually and functionally clarify this for me? Can really use some help in setting this up!
What services like CloudFlare do is acting like a CDN for your website. They become front-end of your content delivery to clients while they have vast network for doing so (resources i.e. bandwidth which are consumed by DDoS). Then your IP is just known by the anti-DDoS service provider to fetch the content and deliver on your behalf.
You see if the IP is leaked by any mean the whole defense mechanism become useless since attackers can directly point to your machine while dynamic DNS of CloudFlare would distribute requests to its network and serve clients via them.
Since your website was up for a while before you migrate to CloudFlare your current public IP is known to attackers and hiding behind CloudFlare is useless since they don't ask CloudFlare DNS service and directly attack your server. This is the reason you need a new IP and the new one should not be revealed by any mean. Just set it in your CloudFlare panel and don't use it for other purposes.
I faced attacks too and used CloudFlare to prevent them, however, I have learned how to perform those attacks by myself and also how to bypass CloudFlare and take down the protected website. The best practice is to secure your server by yourself. Using nginx as a reverse proxy is a good option.
I have a web domain registered and a hosting space.
When I access my website with www (for ex. www.example.com) it shows expected content. However when I try to access it without www (for ex. example.com) it shows site under construction page. This site under construction page is provided by web hosting provider and is html file.
What changes are required for accessing site both ways?
setup an A-record for the domain name without the 'www' prefix pointing to the IP address of
the web-server, and setup a CNAME-record for the domain name with the 'www' prefix pointing
to the web-server IP.
use a CNAME record for "www" to point it to the base name. Use an A record for the base name.
But I find it easier (and it's ever so slightly faster for users) to simply use an A record for both the base name and www.
Creating A record and CNAME record usually is the solution - but on your authoritative DNS.
You will want to put A and/or CNAME records into master DNS, not secondary DNS. There are two approaches to DNS which are:
authoritative DNS (master DNS)
local DNS (usually resides on your host machine/router) (secondary DNS)
Indeed - it is not simple as it may seemed. To have your own working authoriative DNS, you need 2 host machines physcially connected to two different separated ip addresses (eth0 physical connect - not virtually bridged). Since this is so complicated and time-consuming implemention, it is typical to outsource master DNS to a DNS provider (and is a common practice among many of us).
I have 4 servers on my one ip, and my local DNS are being managed in between my router and 4 host machines and it works great on local network ONLY. Since I wanted the local network to be hooked to my domain, I outsourced my master DNS to http://dnsimple.com (there are other DNS provider competitors), so it'd manage my domain directly. This therefore functions as an authoritative DNS, known as master DNS.
The issue you are trying to fix should be focused toward master DNS, not secondary DNS (local network) as it'd not work. If you got your domain via a registrar company or a web-hosting company, you should be able to find the setting/management on your account with the company (for example, C-Panel)...not DNS on your local network.
EDITED: This is a tool that I always use and is a great benefit in tackling down DNS / Domain issues. I dont know what I'd have done without it. http://www.dnsstuff.com/tools