I have an existing COM domain with TTL 24 hours. I will be re-pointing the COM domain (A and CNAME records only) to a new website within a few hours.
The new website is already functioning with a NET domain, so it's live online. I'm leaving the COM domain DNS with the old hosting as we have email there.
To handle the 24 hour lag, can I use DNS URL redirects to send visitors to pages on the new, until propagation is complete?
Or can I use a simple HTML redirect to do similar job?
I think the DNS URL redirect is easier for me to set up but will it work, considering the COM will already have been changed?
First off, it's important to plan ahead. If you have a 24 hour TTL, lower it at least 24 hours in advance of the changeover. This would avoid your dilemma (or rather, shorten it to your new, lowered TTL)
From the description, it sounds like the .com and .net sites are identical. Since you didn't mention any database, I assume these are static sites that don't save data to a database. If so, you really could just leave the sites alone and not worry about a redirect. If you want to get people onto the new server asap, use a temporary HTTP redirect or an HTML-based one.
If you do persist data to a database, are you also migrating that at the same time or are the two sites using the same database server? Migrating database servers is a complicated affair, beyond what we can answer here.
(n.b. There is no "DNS URL" redirect. That's just a service that some DNS providers offer, built on top of HTTP and DNS. Setting it up would suffer from the same TTL lag time you're trying to avoid)
Related
As part of the upcoming changes to Facebook Ads, you now must verify ownership of your domain name.
We operate a SaaS platform where user content is hosted on subdomains (myaccount.example.com etc). We need these users to be able to verify ownership of their domain so they can track their own events. We have enabled them to add the meta tag on their domain, and this verifies okay.
<meta name="facebook-domain-verification" content="codefromfbhere" />
However, the problem is, when you go into 'Events manager' -> 'Aggregated event measurement' -> 'Configure web events', it shows me the root domain instead of the subdomain I just verified (e.g. example.com instead of myaccount.example.com).
This is possible, as Leadpages has achieved the same goal. When you add in a Leadpages subdomain, you're able to verify it via meta tag, and it shows the subdomain in the 'Web event configurations' area.
I don't see any extra headers that they have provided or anything else that would enable this.
How do you mark subdomains as independent from the eTLD+1?
I wanted to chime in with the perspective of someone who works for Facebook. For most businesses, even ones that host pages for other businesses, Aggregated Event Measurement without anything extra is the correct solution.
Advertisers who do not own their own domains will not be able to verify the domain for the purpose of event configuration in Ads Manager. Advertisers may consider purchasing their own domain to continue running their campaigns uninterrupted, or moving toward link clicks/landing page views for campaign optimization and reporting. We are currently investigating other solutions for this use case but do not have any additional information to share at this time.
For a very small number of businesses already on the Public Suffix List (PSL) subdomains will be able to get data as if they were a root domain. This is because being on the PSL basically makes the root domain name act as if it was a TLD (such as “co.uk“ or ”gov.au“). In almost every case it does not make sense for sites to request to be added to the PSL as this dramatically changes how the Public Suffix listed domain name will function.
The PSL process is intended only for platform providers that provide subdomains for large numbers of small businesses which really ought to be treated as though they were in fact separate domains.
The Public Suffix List is not useful, nor intended to be used as a means to gain additional subdomain events reporting. Adding a domain name to the PSL means that there will be total cookie separation between subdomains and that cookies will become disabled on the root domain. If you a domain gets added to the PSL you'll not have much control for that site itself. For example, if you have a /login page on that domain. This may not work as it does today if you proceeded with a PSL addition, as cookies may get disabled on the root domain.
It’s also important to note that browsers will enforce the behavior described based on their own update cadence of the PSL. Some browsers don't update their lists more regularly than bi-annually. This means that if you're on the list and a browser updates their copy of the list, and you later decide to not be on the list, there may not be an easy way to back out the effects; it's not as simple as submitting another request to get taken off of the list.
More information can be found at Facebook’s help center article here.
[Update Mar 19 2021]
Facebook just announced they will be supporting the Public Suffix List for domain verification and event configuration. This means that merchants using a registered domain on the Public Suffix List will be able to use that domain for verifying and configuring their top 8 events on the domain. For example, if myplatform.com is a registered domain on the Public Suffix List, then Jasper, a merchant with the subdomain jasper.myplatform.com, would now qualify as an effective eTLD+1 and would be able to verify "jasper.myplatform.com" and use it to configure their top 8 events in the web events configuration tool.
Read more here:
https://developers.facebook.com/docs/sharing/domain-verification
[Original Answer]
For the upcoming changes for Apple iOS 14.5, you can only verify root domain, which is example.com in your example in order to setup the web event configurations.
The only way you can do this is provide your client's a way to buy/setup their own domain on your service.
You may watch the webinar recording here
https://www.facebook.com/business/m/sessionsforsuccess
Firebase hosting requires that a TXT setting be set up to as they call it
Prove the domain is yours
I purchased a domain. It is mine. In order to set this TXT setting I have to have the domain hosted. The place I purchased the domain from sells hosting for minimum one year at a time. What is the point of firebase hosting when I have to buy hosting somewhere in order to prove that the domain is mine? Is there any way to get around this catch 22?
Proving ownership is done by putting a TXT record in the DNS. This doesn't require that you have a website hosted yet, it merely requires access to the DNS settings for your domain.
It's hard to help beyond that without knowing where you registered your domain.
Update. I took Frank's advice and set up a few Namecheap accounts. Wowie! The discount names are as cheap as 50 cents/year if you buy 1 or 5 years. Thanx for the advice. There is a caveat to using Namecheap/firebase, however.
Do not take this as if I were looking a gift horse in the mouth. I am super grateful to Google for free hosting. I merely want to warn users that firebase is not a free country. Google forces the s religion. I put in many hours of work to create my website using my girlfriend's hosting MySQL. Her hosting platform does not have an s in the URL: https. So the Angular 5 HTTP calls barf. I also included a contact page and a share via email popup. I used my girlfriend's hosting and set up a poor man's PHP web service for that. That does not work because girlfriend's hosting uses HTTP not https. So now I have to go back and recode these backend connections to use Google firebase and Google functions/SendGrid. I could have done that from the get-go and saved myself the time and aggravation.
Okay, so a Wordpress gallery plugin lead to a massive headache - with about 17 galleries having their own pagination, the links within created what might as well be infinite number of variant URLs combining the various query variables from each gallery.
As such, Google has been not so smart and has been HAMMERING the server to the tune of 4 gigs an hour prior to my actions, and about 800 requests a minute on the same page sending the server load up to 30 at one point.
It's been about 12 hours, and regardless of the changes I've made, Google is not listening (yet) and is still hammering away.
My question is: Is there a way to contact Google support and tell them to shut their misbehaving bot down on a particular website?
I want a more immediate solution as I do not enjoy the server being bombarded.
Before you say it, even though this isn't what I'm asking about, I've done the following:
Redirected all traffic using the misused query variable back to the Googlebot IP in hopes that the bot being forwarded back to itself will be a wake up call that something is not right with the URL. (I don't care if this is a bad idea)
Blocking the most active IP address from accessing that site.
Disabled the URLs from being created by the troubled plugin.
In Google Webmaster Tools/Search Console, I've set the URL parameters to "No: Doesn't affect page content" for the query variables.
Regardless of all of this, Google is still hammering away at 800 requests per minute/13 requests a second.
Yes, I could just wait it out, but I'm looking for a "HEY GOOGLE! STOP WHAT YOU ARE DOING!" solution besides being patient and allowing resources to be wasted.
I work for a company which has its own web server they are due to have a complete power blackout over the weekend, meaning their servers will be down.
Does anyone know a way we could present a down status on a maintenance page or some kind of redirect so we can at least inform our users that the site is down for maintenance and not just missing/broken?
The best way is probably setting up a redirection to dummy server on your load balancer or border routers. If you have no such thing, then you can either try asking your provider about the options, or temporarily change the DNS record, provided that you reduce DNS cache timeouts before and after the change, so it takes effect immediately.
Set up a server on another location and point their domains DNS record to that server during the blackout.
The redirect has to be carried out by the web server. No web server, no redirect. What you can do is to get another web site by a web hosting company (which will not be subject to your blackout), and configure it to route requests from your main dns to the temp site with just a plain notice html page, then remove it once power is restored. This can be done if you have the dns info from the primary site. You could also mirror the site this way, and then shut down the mirror and no one will be the wiser. Try http://siteground.com I have used them for years.
If you are using a load balancer, see if it supports a "Sorry Server" page. Most of them have this feature built in.
I'm having trouble with another website stealing all my blog content. I know that happens all the time, but this new attack is taking down my server.
Looking at my access logs I see he is hitting me from multiple IP address. I can't block them all. Wondering how to block by domain name.
I have full access to my server so I would like to block with iptables, but not sure that is possible.
Also, how do I shut them down, it's a private registration with godaddy. I called them but no help at all.
probably belongs on superuser.com, BUT in code, you could do a quick IP hash map that keeps a running count of visits by IP in the last 10 minutes, then 404's if there are over X number of them. You could then log out the IP's that you are 404ing to, and dump them into iptables to block.