Win32Exception @ ServiceHost.Open() for WCF servic

I am working on writing BDD specifications for a broad set of WCF service infrastructure I am writing. I have noticed that each specification I write that involves a call to ServiceHost.Open(), that line takes a good 2 - 6 seconds to execute (the time keeps growing as I add more and more specs). I noticed that when this method is called, a Win32Exception is thrown:

Win32Exception occurred
Message: The specified domain either does not exist or could not be contacted.
Stack Trace: at System.ServiceModel.UpnEndpointIdentity.GetUpnFromDownlevelName(String downlevelName)
NativeErrorCode: 1355
ErrorCode: -2147467259

The ServiceModel configuration is as follows:

<system.serviceModel>
  <services>
    <service name="TestServices.Calculator" behaviorConfiguration="default">
      <endpoint
        name="calculator"
        address=""
        binding="wsHttpBinding"
        contract="TestServiceContracts.ICalculator" />
      <endpoint
        address="mex"
        binding="mexHttpBinding"
        contract="IMetadataExchange" />
      <host>
        <baseAddresses>
          <add baseAddress="http://localhost/calculator" />
        </baseAddresses>
      </host>
    </service>
  </services>

  <behaviors>
    <serviceBehaviors>
      <behavior name="default" >
        <serviceMetadata httpGetEnabled="true" />
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel>

Note: I have configured Http.sys and added http://+:80/calculator/ as an http namespace exclusion, so that is not part of the problem.

This error is most severe on a Windows 7 Ultimate system. On a Vista Ultimate system, it does not seem to cause as much of a performance hit, however ServiceHost.Open() is the vast bulk of the time spent in execution. I don't understand why it is an issue at all when the URL's are localhost...I would expect the loopback interface to be the fastest of all.

The problem isn't with localhost vs dns name... it's related to WCF calling the TranslateName() api to convert the UPN identity of the service from a SAM-compatible name (i.e DOMAIN\user) to a canonical name, and complaining that it cannot connect to the domain specified in the SAM-Compatible name presented as input.

Not sure what might be causing this, but it could be that you're somehow specifying a wrong domain in your UPN identity, or there's something wrong with your machine's domain registration, or the firewall is getting in the way.