I have a website hosted at Azure, registered {0}.com and www.{0}.com as custom domain, both are working fine!
But if I use the plain IP which I put into the A record, it gives me an 404.
My understanding is that the plain IP address should also return the website, am I wrong? If it should do so, whats my mistake?
Did you create an “awverify” record in your domain register? You need to create a special CNAME record that is used to verify you own your domain. This is required if you are going to use A record, and is not necessary for CNAME. You can check http://azure.microsoft.com/en-us/documentation/articles/web-sites-custom-domain-name/.
Related
there is an obligatory CNAME entry for one of my Google domains.
It reads:
_domainconnect.[mydomain].de CNAME 6 hours connect.domains.google.com.
What is this CNAME entry used for? As far as I have understood DNS this should not be necessary to find the actual server IP.
It is indeed not necessary for IP lookup. I suppose maybe Google itself uses it for something. I've found this https://community.cloudflare.com/t/domainconnect-in-dns-record-is-it-needed/185059 but no actual explanation of what it is.
I noticed this entry in one of my domains I have in CloudFlare that is registered via Google Domains, I also have another domain purchased there with a DNS zone on CF that does not have it. I'd say it's safe to get rid of the record — Google's dashboard never complained about it and DNS itself certainly does not need it.
It is more protocol than anything, and is not used to find your server's IP.
There is an open Web standard called Domain Connect that Google adheres to. Within Domain Connect's specifications (at this link at the time of writing) there is a section called DNS Provider Discovery that gives a full explanation of the spec Google is trying to fulfill by having that CNAME record.
To summarize what the Domain Connect docs say on this spec:
Every domain name, to meet this spec, needs to provide information on what DNS provider is being used (in your case, Google). It says that that information must be available via a TXT type DNS record with the host name of _domainconnect.<your domain name here>.
However, the docs alternatively allow for a CNAME type DNS record (CNAME is used as an alias record) with host name _domainconnect.<your domain name here> to point to another domain/subdomain that contains this TXT record with the record value the spec asks for. (Google does it the CNAME way with connect.domains.google.com. as the value.)
Whichever way this spec is done, the record value of this final TXT record should be a domain that you can do an HTTP GET request to, with the full URL being in the form of https://<the TXT record value>/v2/<your domain>/settings to get a JSON response that contains information about the DNS provider.
To see this in action:
If I go to a DNS lookup tool site like https://mxtoolbox.com/txtlookup.aspx, I can put the value of the CNAME record, connect.domains.google.com, in the search bar and see the corresponding TXT record, which has a record value of "domainconnect.googleapis.com". (Note: of course, when I use this value in an HTTP GET request in the next step, I'm going to strip off the double quotes.)
I should then be able to do an HTTP GET request to https://domainconnect.googleapis.com/v2/mydomain.de/settings and get a JSON response with information on Google as a DNS provider. I can see the JSON by just entering that URL in a browser URL bar. At the time of writing, assuming mydomain.de was a valid domain with Google Domains as its DNS provider, you should get:
{
"providerId": "domains.google.com",
"providerName": "Google Domains",
"providerDisplayName": "Google Domains",
"urlSyncUX": "https://domains.google.com/domainconnect",
"urlAPI": "https://domainconnect.googleapis.com"
}
And that entire journey was so that people/software can see who your DNS provider is, and some basic info about them, all via DNS. Phew...
Be advised that Google isn't the only big DNS provider that adheres to Domain Connect specs.
I have a Next.js (deployed with Vercel) app and I am trying to implement SendGrid to create a contact form on my site.
I have followed this tutorial
when trying to submit the form I get the following error:
POST http://localhost:3000/api/send 400 (Bad Request)
I believe the issue is around sender authentication. (https://app.sendgrid.com/settings/sender_auth)
My domain provider is '123-reg'.
I have added the dns records from Sendergrid to the 123 dns section. However when I click on verify I get the following errors:
I can't seem to verify these records.
UPDATE
I have actually updated my Vercel dashboard domains section with the values provided from SendGrid but I still get the same errors:
It seems you are using Vercel (Zeit Now) for your DNS and you haven't configured the SendGrid DNS records that the service requires.
When adding CNAME to the Vercel DNS interface, try adding only the subdomain part. This means em8573 instead of em8573.alex-web.co.uk and so on.
You can find instructions on how to create CNAME here.
You can easily test your records using Dig web interface, an amazing web service.
if your domain doesn't match 'alex-web.co.uk' then it will not work. Ensure the CNAME has the correct domain. If it matches your domain name Vercel will auto remove the domain name from your CNAME.
I just recently started my shopify store, as with all shopify sites my site has a X.myshopify.com url. However, I have a domain, X.com, that points at the same ip as the myshopify.com. The problem is that in search results (Google), the myshopify.com link is showing up instead of my main domain. Is there a way to fix this?
If you cant get shopify to redirect the shopify domain to the proper domain then ensure the shopify domain has canonical tags pointing to the proper domain and the proper domain should replace indexing in time.
I have registered a domain (though there is no hosting yet, just name registration) and I am trying to set up google apps so that I can have email, but I cannot figure it out. Is there something I am missing? I feel like it should be easier than it is right now.
You need to correctly set the MX records at your registrar.
Have you proved domain ownership including a CNAME record in your DNS server? Just follow the instructions.
If you don't have access to your DNS server for adding records, and don't have a webserver where you can put a verification file I think you wont be able do setup e-mail.
If you already have the domain, you just need to follow the registration process, you will be taken through all the steps. If you got to the Admin Console you should have a message bar Top of the page with Verify Domain.
the best way to do it is to try the new Learning Center, http://learn.googleapps.com/.
A domain name that we have is using google mail as its backend, but its not hosted anywhere (no website). How can I, through the registrar interface (I'm using 1&1), redirect ppl who type in http://mail.example.com to http://mail.google.com/a/example.com ?
I can create a subdomain and set its DNS/CNAME, but what do I put where? Also, if I make this change will it affect the existing mail delivery (for which everything is running fine presently).
It turns out it wasn't that tough... and the instructions are part of Google itself:
Dashboard -> Service settings: Email -> General:Web address -> Change URL
https://www.google.com/a/cpanel/example.com/CustomUrl?s=mail
Changing CNAME record
To use the custom URL mail.example.com, you must change the CNAME record with your domain host.
Sign in to oneandone.
Navigate to your DNS Management page. The location and name
of this page will vary by host, but
can generally be found in Domain
Management or Advanced Settings.
Find the CNAME settings and enter the following as the CNAME value
or alias:
mail
Set the CNAME destination to the following address:
ghs.googlehosted.com
Save changes with your domain host and click "I've completed
these steps" below.
You cannot redirect to a path (such as /a/example.com) using only DNS. DNS CNAME records can make mail.example.com/foo effectively point to mail.google.com/foo, but something more sophisticated will require HTTP redirects. This means you need someone hosting your web page for this to work.
Sorry.
If your registrar offers an "HTTP Redirect" option, you can use that. Some registrars do. If you use this, they're effectively running a minimal web server for you. Note that this may break SSL when users access your page via https://example.com.
Mail delivery is via MX records, which won't be affected by changes to other types of record (so long as you don't interfere with the DNS records for the domain's mail servers).