I’m troubleshooting an issue where, after switching TLD’s internal and ESP-based emails are getting blocked when going to external customers. Could different A, CNAME, TXT, and NS records cause email deliverability issues? Short of posting actual differences, is there anything obvious before I look for other issues?
I have created two CNAMEs for my (CloudFront) domains, like this:
nslookup works, giving me the correct values for both
d-test — but when I actually get the data, using
curl or a browser, all data is retrieved from the origin pointed to by
www, regardless of which URL I actually use. If I use the origin URLs, it works fine.
How is this even possible?
As far as I understand, there should be no problems with using CNAME or DNAME records in connection with DKIM. That is, while the DKIM record for verifiying a mail from
email@example.com wants to be retrieved as a
some.selector._domainkey.foo.example, it might well be that some redirection occurs, such as
some.selector._domainkey.foo.example. CNAME another-selector._domainkey.elsewhere.com.or
_domainkey.foo.example. DNAME _domainkey.elsewhere.com.or
_domainkey.foo.example. DNAME bar.elsewhere.com.
that is, the DNS resolving might go via a CNAME or DNAME into a completely unrelated domain and even, as the third example clarifies, lead to records that do not involve the well-known DKIM-specific
Tome, this seems to be totally legit as far as DNS is concerned. And as DKIM is theoretically not restricted to retrieving keys by DNS, any Verifier should not care.
Of course, this does somewhat increase the DNS load and may slow down mail delivery by a few milliseconds. But this technique may come in handy when it is easier to change and update records under
elsewhere.com than under the main domain
So my questions are:
- Is this really "legal"?
- Is it fully supported, i.e., do (widespread, non-obscure) implementation behave accordingly or are perhaps some known ti "deduct trust points" for such redirections? Or perhaps do some even then reject signatures altogether because they believe they are for the wrong domain?
- Are there other security considerations that speak against this?
Let’s say I need to change the CNAME for my subdomain
test.mysite.example. I want it to go to a load balancer endpoint
But in creating the CNAME, I type it wrong. e.g.
Since it’s possible that a client can cache DNS for up to 48hrs (despite what the TTL setting is), could this cause
test.mysite.example to be down for 48hours? Even though I immediately fix the CNAME after noticing the typo?
Resolved as in, in the past… Are there any tools for this?
I am doing some research into pentesting and subdomain takeovers with cloud providers like AWS and Azure. I have a list of subdomains (A records) that could be used for this, but they are indecipherable in terms of seeing where they once resolved to. Without this information, the entire thing is redundant.
For example: sjd-3949-af3.trafficmanager.net would have originally resolved to mydomain.takeover.com but doesn’t now.
Anyone know how to find this out please?
Necesito crear un panel, donde las personas colocaran un dominio personal, el cual habran configurado previamente con CNAME y Record A apuntados a mi sitio web. De los cuales luego generare paginas ya predefinidas pero que se veran con el dominio del usuario.
Algo asi como lo que hace adfly, en la seccion donde puedes apuntar tu dominio personal, y al terminar de configurarlo, te queda algo como:
Pero no se por donde empezar, ya que no e manejado este tipo de conexion anteriormente
I’m hosting two subdomains with two (non-wildcard) Let’s Encrypt certificates outside of cloudflare: name.feed.example.com name.example.com
I have a CNAME alias on Cloudflare (free plan) pointing from name.example.com to name.feed.example.com
I’m getting an Error 526: Invalid SSL certificate
Any ideas? Thank you! :*
dig +short command (such as described in “dig show only answer”) is great for batch processing names into IP addresses. It does a simple job and does it well.
Unfortunately when there’s a CNAME even
+short isn’t short enough. For example:
$ dig +short docs.sbonds.org ghs.google.com. 126.96.36.199
+noall but it doesn’t seem like it changes the behavior of
+short. I’ve also tried specifying
-t a just to ensure it didn’t think I meant an A record or CNAME, but that (unsurprisingly) changes nothing.
$ dig +noall +short docs.sbonds.org ghs.google.com. 188.8.131.52
I’m using RedHat 7’s
# dig -v DiG 9.9.4-RedHat-9.9.4-73.el7_6
I can filter out the CNAMEs with trusty
grep, but it seems like dig should have some way to give “Just the IP, ma’am.”
What is that way?
thanks for reading my question.
I’ve tried google for this question and other forums but couldn’t get solution or a hint for the scenario i have.
I’ve a domain say abc.com which is live with ssl on wpengine , Now we need to show a third party login form on our own subdomain , you can read the 3rd party requirement for this setup here https://help.officernd.com/hc/en-us/articles/360002216394-Custom-Domain-for-Members-Portal .
now say i need to show that 3rd party login according to there steps on portal.abc.com , and the main requirement of that third party is the subdomain must have ssl(for which we need to provide them files also) and the subdomain must then cname there domain.
the thing i can’t figure out yet is how the ssl will be applied to the cname only subdomain?
Any hint or suggestions are highly appreciated, TIA.
My company is going to deleting a CNAME record from DNS and replacing it with a new record “\OLDCNAME\Apps” to “\NEWCNAME\Apps”. Currently both are existing values on the network and they both point to the same set of files and folders. We are currently trying to update configuration files (.properties, .ini, .xml) that has any references to OLDCNAME to utilize the new CNAME and test the applications to see if they are working correctly.
Is there a way to simulate the delete of OLDCNAME on a local computer to enable us to test the applications before the company deletes the old CNAME record from DNS?