What are all the possible causes of the "An Active Directory Domain Controller (AD DC) for the domain ..." error message?

Earlier I was having issues connecting one of my workstations (client) to my domain, and I thought it was because the domain was not in my possession yet (reference: this question). But, due to the answer I'm led to believe that there is something else going on? I've searched the internet and can't really find out why I'm still having issues, so I figured I'd ask to see what the possible causes of this error message could be. Here is my setup:

Server (DC)
==============================
IP:              192.168.0.2
Subnet Mask:     255.255.255.0
Default Gateway: 192.168.0.1
Preferred DNS:   192.168.0.2

Workstation
==============================
IP:              DHCP
Subnet Mask:     
Default Gateway: 
Preferred DNS:   192.168.0.2

Additionally, I have a Forward Lookup Zone for my local domain (internal.domain.com). Here is a dump of both the client and server's nslookups:

> nslookup internal.domain.com
Server:  cdns02.comcast.net
Address: 2001:558:feed::2

Non-authoritative answer:
Name:    internal.domain.com
Address: 50.19.***.*** (definitely not my IP address)

> nslookup -type=SRV _Kerberos._tcp.dc._msds.internal.domain.com
Server:  cdns02.comcast.net
Address: 2001:558:feed::2

         primary name server = ns.buydomains.com
         responsible mail addr = hostmaster.buydomains.com
         serial  = ...
         refresh = ...
         retry   = ...
         expire  = ...
         default TTL = ...

This shows up equal on both the server and the client, which makes me think that both of them are not using my server as the DNS lookup, which is why I'm having issues? I'm really not sure what's going on here. Just looking for what could possibly be an issue, and I tried to answer most of the followup questions on the answer to my previous question.

Update:

I used this question's answers to generate a pseudo-unique IPv6 address, which was in the format of xxxx:xxxx:xxxx:xxxx::/64. Here are the settings I used on my server:

Server (DC) IPv6
=============================================================
IPv6 Address:         xxxx:xxxx:xxxx:xxxx::1
Subnet Prefix Length: 64 
Default Gateway:      xxxx:xxxx:xxxx:xxxx:ffff:ffff:ffff:ffff

I went into my router and changed the IPv6 settings as well. It had stated "Obtain a DNS server address automatically or enter a specific DNS server address.", in which case I selected to specify the DNS Server Address to the static address of my server. I also setup Google's public DNS server as the secondary.

Finally, my client machine was able to join the network instantly. Also, just for good measure I set the client machines IPv6 DNS to point to my server (again, just for good measure).

If anyone else runs into an IPv6 issue, this seems to be the solution. What's nice is that I can use the RSAT now to manage my server from my primary client (I can remove my monitor, keyboard, and mouse from the server).

You're not finding a lot of articles describing what you're seeing, I'm guessing, because the vast majority of the Active Directory deployments aren't using IPv6. The addresses displayed in your nslookup output show me that you are definitely using IPv6 (which also makes sense given Comcast as your ISP).

Your clients are getting IPv6 DNS from your ISP (a DNS server outside your control) and, as such, the authoritative forward lookup zone on your DNS server isn't being consulted. Generally and broadly speaking, it's recommended that your clients have only DNS servers specified that are Active Directory domain controllers (DCs).

Configure the DNS server option on your DHCPv6 scope (option "0023 DNS Recursive Name Server IPv6 Addresses") to specify your DC as the DNS server and your clients will stop looking outside your LAN for DHCP.

Edit:

Assuming you don't recall setting up an IPv6 scope on your Windows Server computer you likely have a router that's acting as a DHCPv6 server. Without knowing what the router is (if it is the DHCP server for IPv6) I can't give you step-by-step guidelines on how to change it.

Have a look at the router's administration interface to see if you can configure the DHCP server's IPv6 options. Assuming you can, you can set your Windows Server machine to a static IPv6 address and specify it is the DNS server for the PCs.

If the router won't allow you modify the DHCP options for IPv6 options then you'll need to disable IPv6 DHCP on the router and configure a DHCP scope for IPv6 on the Windows Server machine. You'll need to create a Unique Local Address for your IPv6 network, assign a static IPv6 address to the Windows Server machine, and configure it as a DNS server in the IPv6 scope's options. There's an article here that describes configuring IPv6 DHCP on Windows Server 2008 and ought to be at least reasonably accurate for Windows Server 2012.

As an alternative to all of this you could opt to configure Windows to prefer IPv4 over IPv6 or out-right disable IPv6 on your server and client computers. It's not something that Microsoft recommends, but it's something you could do. There's a nice Technet wiki article that includes Administrative Templates for Group Policy to disable IPv6, but you're in a bit of a chicken-and-egg scenario where your clients aren't going to be able to process Group Policy until you've taken care of this issue.

Finally, I am concerned about your choice of Active Directory domain name. There have been religious wars in the past about this, but recommended best practices for Active Directory domain naming say that you could choose a name that isn't (and will never become) a valid Internet name. You're using something that Comcast's DNS servers can resolve and this could present problems with mobile clients, down the road, because the ability to resolve the domain's name is part of the protocol a client uses during boot to determine if it should attempt to contact DCs and process Group Policy. You can have exceedingly long bootup times on clients when they are connected to the Internet, can't actually reach your DCs, but get bogus DNS responses back for the Active Directory domain's name. (I've cursed several consultants over the years who have set up networks that I've later "inherited" this way... Thanks, guys! That'll be one domain rename coming up...)

This error is usually DNS related. Your workstation need to use your internal DNS Server and it has to have the AD related (created) records.

If your nslookup is resolving addresses from outside your network, it means that your queries are being forwarded to an outside server and you are using an existing valid name to your internal domain.