Is it "OK" to use the windows firewall for a DC with a public ip?

As I first read the question, I was really concerned about giving a DC a public IP at all. But thinking about it, I might consider this, IF the DC were not a member of my larger AD forest and the only machines in the domain were the web servers.

This would still allow me to manage my web servers with group policy and common authentication, with just one extra AD account to assign to myself, without exposing my real internal DCs to the big bad web. Effectively, you're setting up an AD just for the DMZ.

However, I still see some challenges to this approach:

1. AD is tightly coupled with DNS. You'll want to think carefully about managing the DNS records for your web servers in conjunction with AD.
2. While the Windows Firewall is adequate (barely) for this from an unauthorized access standpoint, it doesn't cut it from auditing and denial of service resistance standpoints. It would be trivial to disrupt your web sites by directing a DoS attack your central DC — maybe not deface or take down, but at least disrupt.

I don't recommend it as the firewall by itself is really basic.

Having a AD for only your web application is no more insecure as having it under basic authentification, but check there for some tip (even if tagged for 2008): Active Directory Domain Services in the Perimeter Network (Windows Server 2008)

Windows Firewall is a pseudo-statefull for UDP, stateless for ICMP & statefull for Ipv4,Ipv6 (for filtering the traffic, for inspecting I didn't find any document, but if it do, it's really limited).

Hardware appliance are usually stateful.

Stateful :

In computing, a stateful firewall (any firewall that performs stateful packet inspection (SPI) or stateful inspection) is a firewall that keeps track of the state of network connections (such as TCP streams, UDP communication) traveling across it. The firewall is programmed to distinguish legitimate packets for different types of connections. Only packets matching a known active connection will be allowed by the firewall; others will be rejected.

Stateful inspection, also referred to as dynamic packet filtering, is a security feature often included in business networks. Check Point Software introduced stateful inspection in the use of its FireWall-1 in 1994.1[2] https://en.wikipedia.org/wiki/Stateful_firewall

Stateless:

Stateless firewalls watch network traffic, and restrict or block packets based on source and destination addresses or other static values. They are not 'aware' of traffic patterns or data flows. A stateless firewall uses simple rule-sets that do not account for the possibility that a packet might be received by the firewall 'pretending' to be something you asked for. - See more at: http://www.inetdaemon.com/tutorials/information_security/devices/firewalls/stateful_vs_stateless_firewalls.shtml#sthash.iDNnjqWC.dpuf

From TechNet:

Windows Firewall provides the stateful filtering of TCP/IP traffic (IPv4 and IPv6) that uses the TCP transport protocol. It also provides the “pseudo-stateful” filtering of TCP/IP traffic that uses the UDP transport protocol. ICMP traffic is not statefully filtered; rather, ICMP traffic is allowed or blocked based on Windows Firewall settings (for example, you can explicitly allow or deny incoming echo requests or outgoing destination unreachable messages by configuring Windows Firewall settings). Because Windows Firewall is tied directly to the TCP/IP architecture of Windows, it does not provide any filtering of non-TCP/IP protocols, such as IPX/SPX or AppleTalk.

With the exception of some File Transfer Protocol (FTP) traffic, Windows Firewall does not use Application layer information to statefully filter traffic. FTP is a special case because of the way in which an FTP server establishes the data channel for an FTP file transfer. During a typical FTP user session, an FTP client initiates a control channel with an FTP server. When the FTP client transfers a file from the FTP server, the FTP server tries to establish a data channel with the FTP client by initiating communication on a TCP port different from the one used for the control channel. This can cause most firewalls running on the FTP client computer to drop the data channel packets coming from the server because they appear to be unsolicited. To overcome this problem, Windows Firewall uses the Application Layer Gateway Service to provide dynamic port mapping for the FTP data channel, thereby facilitating the stateful filtering of FTP traffic. https://technet.microsoft.com/en-us/library/cc755604(v=ws.10).aspx

It scares the willies out of me to think about putting a Domain Controller out on the public Internet. That having been said, if you really can constrain the communication to the DC down to a group of machines using Windows Firewall in a default-deny posture with "Allow" rules for those authorized machines doesn't seem at all unreasonable to me.

Ideally I'd prefer an isolated management network to which the web servers and DC were attached, with the DC having no direct attachment to the Internet and a VPN to gain access to the management network. Given that you probably can get that in your hosting scenario what you're describing isn't an unreasonable fallback. Someone escalating privilege on one of the web servers, in your firewalled DC scenario, would be in a similar position in my isolated management network scenario. It's not all that much different as long as you're meticulous about treating the DC as an isolated machine and limiting its communication to/from the Internet (ideally completely disabling it once you've got a VPN to a "jump box" established).