It depends on whether you want to delegate hosting the subdomain off to a different DNS server (or to the same server, but in a different zone file). You delegate a zone when you want some other entity to control it, such as a different IT department or organization.
If you do, then you need NS records. If not, A or CNAME records will suffice.
Let's say you have the domain example.com. You have an A record for www.example.com and you want to create the subdomain info.example.com with www.info.example.com as a host in it.
Delegation
In the this situation, let's further say you have two DNS servers that will be hosting that subdomain. (They could be the same servers that are currently hosting example.com.) In this case, you will create two NS entries in the example.com zone file:
info IN NS 192.168.2.2
info IN NS 192.168.2.3
On those two servers, you will create the info.example.com zone and populate it as you would any other domain.
www IN A 192.168.2.6
No delegation
Here, just add an A record in the example.com zone file, using a dot to indicate that you want to create the www.info
host in the example.com
domain:
www.info IN A 192.168.2.6
Using CNAME
The decision of whether to use a CNAME is independent of the delegation choice. I generally like to use a CNAME for the "generic" names which point to specific machine names. For example, I might name my machines using an organizational naming convention such as cartoon characters (daffy, elmer, mickey, etc.) or something bureaucratic (sc01p6-serv) and point the generic names to them. If the IP address of the machine ever changes, I need look in only one place to modify it.
www IN CNAME sc01p6-serv
mail IN CNAME sc01p6-serv
sc01p6-serv IN A 192.168.2.6
Best Answer
In this case you would need separate ports if they were on the same IP, or separate IPs if you wanted them on the same standard SSL port (443). IIS doesn't support reading host headers and redirecting using SSL. You can use the same wildcard certificate without any issue, but you would need something inbetween IIS and the client (like Microsoft Forefront Threat Management Gateway) in order to do routing by hostname over SSL. (I hope that makes sense)
The reason this happens is because the connection is encrypted and the certificate is validated before the HTTP header is actually sent, so at that time IIS has to know what site it's using beforehand. Now, Firefox does send the hostname in with the initial encryption request but I'm not sure if IIS supports that (or if any other browsers do).
The First Few Milliseconds of a HTTPS Connection has an incredibly in depth description on how HTTPS generally works (through a special debug build of Firefox). As you can see a few paragraphs in TLS supports a server name extension, but as far as I know IIS does not support that extension.