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.
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 own the domain abc.com purchased through NameCheap. I have set up a custom DNS redirecting it to my digital ocean droplet as below.
NAMESERVERS:
ns1.digitalocean.com
ns2.digitalocean.com
ns3.digitalocean.com
This is working fine.
My email for #abc.com is provided by Google and this has been setup through corresponding A and MX records on Digital Ocean, and the email is working fine.
Now, I am attempting to authenticate this domain for both Mailchimp and firebase to send emails using my #abc.com email.
For Mailchimp, they need me to authenticate the domain using c-name records as below -
Mailchimp Instructions:
CNAME 1 : Name: k2._domainkey.abc.com, Value: dkim2.mcsv.net
CNAME 2: Name: k3._domainkey.abc.com, Value: dkim3.mcsv.net
On my digital ocean I set up the following CNAME records:
Type- Hostname - Value - TTL (seconds)
CNAME- k2._domainkey.abc.com - dkim3.mcsv.net - 43200
CNAME- k3._domainkey.abc.com - dkim2.mcsv.net - 43200
This is Not Working. I am getting the following message:
Uh oh, something went wrong.It looks like something didn't get copied and pasted correctly when you added the CNAME records to your domain. Delete or edit those records to try copying and pasting again.
I am having a similar problem with authenticating the domain for firebase to send emails from my #abc.com email, which leads me to believe that my setting up of CNAME record is incorrect.
Given my setup of the domain (Namecheap), custom DNS (digital ocean) and email (google) am I supposed to set up the c-name record differently? Please help me solve this problem.
The problem seemed to be occurring because of the custom DNS set-up on NameCheap redirecting it to digital ocean servers. I am given to understand from Mailchimp service provider that this means that some of the DNS records were not publicly visible. Hence the domain authentication failed.
I changed the set-up to a standard DNS set up on NameCheap, and created the CName records. The authentication then worked.
I have a website deployed to Azure. I've used Cloudflare in order to CNAME the azurewebsites domain, and therefore set the redirect URL to the Cloudflare hosted domain name as:
https://www.example.com/signin-microsoft
When I try and login, I get a failure, and the link provided by Microsoft is:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+'https://login.live.com/oauth20_desktop.srf'+or+a+URL+which+matches+the+redirect+URI+registered+for+this+client+application.&state=xxx
When I run Fiddler, I can see that the redirect URL passed through by my app, is not the https://www.example.com, but the following:
/common/oauth2/v2.0/authorize?client_id=f0caa31c-3117-4479-a284-65f5a38ff5b6&scope=https%3A%2F%2Fgraph.microsoft.com%2Fuser.read&response_type=code&redirect_uri=https%3A%2F%2Fexample.azurewebsites.net%2Fsignin-microsoft
When I setup the Microsoft OAuth in my app, I have these settings, but I can't find one to override the redirect-url:
services.AddAuthentication().AddMicrosoftAccount(microsoftOptions =>
{
microsoftOptions.ClientId = Configuration["Authentication:Microsoft:ApplicationId"];
microsoftOptions.ClientSecret = Configuration["Authentication:Microsoft:Password"];
});
Does anyone have any suggestions? To complicate the matters, I've got this structure:
Cloudflare
Azure CDN
Azure Web app
You can double check the redirect URL is expecting by checking the application AAD reply URLs with the instructions here. This must be an exact match to what you are sending in your request. If can take a few minutes for updates to propagate, so give it some time after you update this setting for errors to resolve.
I was able to override the redirect uri using a similar strategy to the answer in this question.
.AddMicrosoftAccount(microsoftOptions =>
{
microsoftOptions.ClientId = Configuration["AzureAd:AppId"];
microsoftOptions.ClientSecret = Configuration["AzureAd:Password"];
microsoftOptions.AuthorizationEndpoint = Configuration["AzureAd:AuthEndpoint"];
microsoftOptions.CallbackPath = "/signin-oidc";
microsoftOptions.Events.OnRedirectToAuthorizationEndpoint = context =>
{
context.Response.Redirect(Regex.Replace(context.RedirectUri, "redirect_uri=(.)+%2Fsignin-oidc", "redirect_uri=https%3A%2F%2Fwww.yourcustomdomain.com%2Fsignin-oidc"));
return Task.FromResult(0);
};
});
The problem is due to a conflict between CloudFlare's CNAME flattening and Azure's CNAME verification. The CNAME flattening essentially returns A records, which speeds up DNS resolution and is a good idea in general. However, Azure's CNAME verification only verifies CNAME records.
The best workaround I've found is to:
1.Disable CloudFlare's HTTP proxying (click the orange cloud on that CNAME record so that it turns grey); this also disables CNAME flattening for that record.
2.Check your host on dig until you see the CNAME records show up.
3.Verify your CNAME host on the Azure portal.
4.Re-enable CloudFlare's HTTP proxying (click the grey cloud on that CNAME record so it turns orange).
This allows you to verify on Azure and still take advantage of CloudFlare's CDN.
For more details, you could refer to this article.
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/.
I'm trying to access my content on my Azure CDN via a a custom domain (cdn.mydomain.com/pictures/logo.jpg)
But I get an error 400:
<Error>
<Code>InvalidUri</Code>
<Message>
The requested URI does not represent any resource on the server. RequestId:8fa9ea29-e46f-4053-a902-5707d19e1520 Time:2011-05-13T09:40:08.3459953Z
</Message>
<UriPath>http://cdn.mydomain.com/pictures/logo.jpg</UriPath>
</Error>
However, when accessing through the URL given på Azure (accountname.blob.core.windows.net) things work perfectly.
The storage is created a few weeks ago, and so is the custom domain. I've created a CNAME and pointed it to accountname.blob.core.windows.net.
How to show content from my custom domain?
EDIT: I tried pointing my custom domain to xxxxxxx.vo.msecnd.net. Now, all I get is a blank page. I can't seem to figure out where to point my custom domain. No matter what, I end up with a http error 400.
I have not used the Azure CDN, but I suggest you verify that your CNAME is set up properly. Try dig your DNS name and check that it includes something like
;; ANSWER SECTION:
cdn.mydomain.com. 7200 IN CNAME accountname.blob.core.windows.net.
Have you followed the CName mapping instructions in http://blog.smarx.com/posts/using-the-new-windows-azure-cdn-with-a-custom-domain ?