Create the CNAME record "portal.domain.com" referring to "obscureServer32324name.domain.com" in the "domain.com" DNS zone. From a command-prompt, do a:
nslookup portal.domain.com
What do you get back?
Bear in mind that if "domain.com" is an Active Directory-integrated zone you could have a slight delay before the DNS server begins to resolve it.
Also on the Active Directory integrated DNS front, bear in mind that your DNS client might not be trying to resolve against a DNS server that's "looking at" the same copy of AD where you added the record (via DNSMGMT) a moment before. Force AD replication or wait 5 minutes for AD replication to complete.
You don't need to stop / restart the Microsoft DNS server for changes like this to "take".
Edit re: your comments:
Bizarre. I'm at a bit of a loss. That's a pretty common configuration, so it ought to work fine. I have several Customers with servers that are configured just that way (w/ CNAME records like "WSUS" or "antivirus", etc).
The computer you're testing from is configured to use the server computer where you added the CNAME as its DNS server-- correct?
Do the following, just be sure that you're querying out of the right zone:
nslookup -querytype=SOA domain.com
You should get back something like this:
domain.com
primary name server = server.domain.com
responsible mail addr = hostmaster
serial = 425
refresh = 900 (15 mins)
retry = 600 (10 mins)
expire = 86400 (1 day)
default TTL = 3600 (1 hour)
server.domain.com internet address = 192.168.1.1
Be sure the SOA record that you get back really is referring to the server computer you expect to be seeing the zone hosted from.
We'll figure it out, it just may take a moment.
There are 2 main ways to go. For the sake of making an example, let's say your company name is example.org
:
a) Per account subdomains under your domain: All your users get a Fully Qualified Domain Name under your domain, i.e. <userid>.example.org
, <nextuser>.example.org
.
I would do this with a catch-all A-Record:
$ORIGIN example.org.
@ IN A 1.2.3.4
www IN CNAME example.org.
* IN A 5.6.7.8 # This one
b) "Vanity domains" going to a dedicated gateway: Say you want to offer your en users the option to set up a FQDN in their own domain, like shop.userdomain.com
. In that case, I would dedicate a gateway server to handle this, and let the users create CNAME's to this gateway. Something like:
$ORIGIN example.org.
@ IN A 1.2.3.4
www IN CNAME example.org.
gateway IN A 5.6.7.8 # This one
.. and your end users must create a CNAME pointing to gateway.example.org
in this example.
Notes: In both cases above I'm using A-Records, but you can also use CNAME's if that's more convenient. And your 5.6.7.8 server must look at the incoming HTTP headers and act appropriately, i.e. your programming of your webapp needs to handle the user accounts right on a per-request basis.
Best Answer
CAA records are supposed to follow CNAMEs, so you need a CAA record for the target of the CNAME record instead.
Citing https://letsencrypt.org/docs/caa/
Trying to "circumvent" this wouldn't be helpful because even if you created an illegal CAA record parallel to the CNAME, clients following the specification would just ignore it.