Skip to content

Est. 2011ยทMicrosoft Partner 7033487ยทDelivery under 3 minยทSupport 7 days a week

Your vault is empty.

Free Fix Event ID 408

Event ID 408: the DNS server could not open a socket on its listen address

11 min read Updated October 5, 2026 Windows Server: AD, DNS & Group Policy

Fix it now

Microsoft publishes 408 as the DNS server being unable to open a socket for a named address, and gives two things to check: that the address is genuinely valid on this machine, and that no other application is running that would attempt to use the DNS port. The address in the event is the whole diagnosis.

Run these on the DNS server, in an elevated Command Prompt

ipconfig /all
netstat -ano | findstr :53
  1. Read the address the event names, and compare it against the addresses actually on the machine. If it is not there, the listen list is stale and Microsoft’s documented fix is to remove it in DNS Manager.
  2. If the address is valid, find out what holds the port. Microsoft’s documented cause is Network Address Translation and the DNS Server service on the same host: NAT’s DNS proxy and DNS Server cannot both use the same interface and address with default settings.
  3. Correct the listen addresses: in DNS Manager, right-click the server, choose Properties, go to the Interfaces tab, select “Only the following IP addresses”, select the address you do not want the server to listen on and remove it.
  4. Stop and restart the DNS server, which is the step Microsoft’s own guidance ends with, then confirm the service holds the port.

Event 407 is the companion and is more specific: Microsoft publishes it as the server being unable to bind a datagram, that is UDP, socket to the address shown.

If the server answers on every address it should, you are done. If not, the next section covers what it is doing when it fails.

Why it happens

At startup the DNS server binds sockets on the addresses in its listen list. UDP carries ordinary queries; TCP carries responses too large for a datagram and zone transfers. If a bind is refused, that address cannot serve queries, and the failure is logged with the address attached. A server with several addresses can therefore be half working – answering on one interface and silent on another – which makes the fault look intermittent from the client side even though it is completely deterministic.

Microsoft’s published text for 408 gives both branches. Verify that the address named is a valid one on this machine; if it is not, remove it from the list of IP interfaces using the Interfaces dialog under Server Properties in DNS Manager, then stop and restart the DNS server. If it is valid, make sure no other application – Microsoft’s own example is another DNS server – is running that would attempt to use the DNS port.

The documented cause for that second branch is more specific than most people expect. Microsoft attributes these errors to computers running both Network Address Translation and the DNS Server service. NAT has a DNS proxy setting that lets clients direct queries at the NAT server, which then forwards them to the configured DNS server. The proxy and the DNS Server service cannot coexist on the same host using the same interface and address with default settings, and one of them takes the port first.

Event 407 is the companion Microsoft publishes: the server could not bind a datagram socket, meaning UDP, to the named address, with the error in the event data. The others in this family – 409, 414 and 404 – are not published, so read them for the address and transport they carry rather than for their numbers.

Another service already holds port 53

You have this one if Something is listening on 53 with a process that does not belong to the DNS server.

  1. Identify the owner from the process identifier before stopping anything.
  2. Microsoft’s documented case is NAT with DNS proxy on the same host. Its three documented resolutions are: use a different server for DNS; do not use the DHCP allocator and DNS proxy functionality in NAT; or configure DNS Server not to listen on the address of the adapter acting as the private interface for NAT.
  3. Look also at hypervisor and container networking components, and at security products that intercept DNS.
  4. Restart the DNS server and confirm it now holds 53 on both transports.

On a domain controller this is not a matter of preference. If anything other than the DNS server holds 53, domain clients on that server cannot locate the domain.

The listen address no longer exists on the machine

You have this one if The address in the event does not appear in the machine’s own address list, and the change lines up with a network card replacement, a team rebuild or a change of addressing.

  1. Open DNS Manager, right-click the server, choose Properties and go to the Interfaces tab.
  2. Either select all IP addresses, or select only the addresses that genuinely exist now, removing the one that does not.
  3. Apply, then stop and restart the DNS server.
  4. Confirm the server answers on each remaining address.

The port is unavailable even though nothing appears to be listening

You have this one if Nothing shows as listening on 53 and the bind still fails, on a host running a hypervisor or container networking stack.

  1. Establish whether a block of ports covering 53 has been reserved by another component before it started.
  2. Where it has, either reserve the port for the DNS server before that component claims it, or move the role to a server that is not also a virtualisation host.
  3. Reboot and confirm the DNS service starts cleanly and holds the port.

On a domain controller, a virtualisation stack that reserves ephemeral ports before the DNS service starts is a configuration argument you will keep having. Separating the roles ends it.

DNS starts before the network is ready

You have this one if 408 appears at every boot, and simply restarting the DNS service afterwards fixes it until the next reboot.

  1. Update the network adapter driver and any teaming or virtual switch software. Slow adapter initialisation is the usual reason.
  2. Where the addresses are static, confirm nothing is waiting on a DHCP response that will never come.
  3. As a mitigation rather than a fix, start the DNS service after the network rather than alongside it.
  4. Reboot twice and confirm the event has gone rather than moved.

Full reference

The events

Event Status What it says
408 Published The DNS server could not open a socket for the named address. Verify the address is valid on this machine; if not, remove it on the Interfaces tab and restart. If it is valid, make sure nothing else is using the DNS port
407 Published The DNS server could not bind a datagram (UDP) socket to the named address. The data is the error
409 Not published Read the entry for the address and transport it names
414 Not published Read the entry for the address or name it carries. It is not necessarily a socket failure
404 Not published Read the entry for the address and transport it names

Only 407 and 408 are published. The remaining three are read from their own contents, and the useful information in all of them is the address, not the number.

Microsoft’s documented resolutions for the NAT case

  1. Use a different server for the DNS Server role rather than installing NAT and DNS Server on the same host.
  2. Do not use the DHCP allocator and DNS proxy functionality in NAT; use the DHCP Server service instead.
  3. Configure the DNS server so that it does not listen on the address of the network adapter acting as the private interface for NAT: DNS Manager, right-click the server, Properties, Interfaces tab, select Only the following IP addresses, select the address, and remove it.

Half-working is the normal presentation

What you observe What it means
Clients on one subnet resolve and clients on another time out The bind failed on one address and succeeded on another
The server answers when queried by name and not by one of its addresses The same, seen from the other direction
Only an IPv6 address is named in the event That address changed, or IPv6 configuration on the adapter did
Every address fails at boot and a manual service restart fixes it The service is starting before the network is usable
Nothing appears to hold 53 and the bind still fails Something reserved the port before the DNS service started

Do not disable IPv6 to make an IPv6 socket failure go away

Turning IPv6 off to stop one of these events is a larger change than it looks, and Microsoft’s position elsewhere is that IPv6 is a mandatory part of current Windows and should not be disabled. Correct the address, or remove it from the listen list, and leave the protocol alone.

Why moving DNS to another port is not an option

It is technically possible and practically useless. Clients, domain controllers, resolvers and every piece of network equipment that inspects DNS expect port 53. Changing it breaks name resolution for everything that does not know about the change, which is everything. If the port is genuinely unavailable on that host, the answer is to move the role to a host where it is available, not to move the port.

Confirming it before you close the ticket

  • Check that the DNS server process holds both UDP and TCP on every address it is supposed to serve, not just on the first one.
  • Query the server on each of its addresses individually rather than by name, so a working interface cannot mask a broken one.
  • Reboot and re-check, because a restart of the service alone hides a start-order problem.
  • Test from a client on each subnet, so that you find out about a half-bound server before your users do.

Every code this article covers

Code What it points at Source
Event ID 408 The DNS server could not open a socket for the address named. Microsoft’s guidance is to verify the address is valid on the machine, remove it on the Interfaces tab if not, and otherwise confirm nothing else is using the DNS port Microsoft Learn
Event ID 409 An entry from the same bind and listen phase. Not published by the vendor; read it for the address and transport it names not published by the vendor
Event ID 414 A startup entry carrying an address or name. Not published by the vendor, and not necessarily a socket failure despite appearing beside them not published by the vendor
Event ID 407 The DNS server could not bind a datagram, that is UDP, socket to the address named. The event data is the error Microsoft Learn
Event ID 404 A further entry from the same phase. Not published by the vendor; read it for the address and transport it names not published by the vendor

Confirm the fix worked

  1. The DNS server process holds both UDP and TCP on every address it should serve.
  2. A query directed at each address individually is answered.
  3. No new 407 or 408 appears in the DNS Server log after a reboot.
  4. A client on each subnet resolves without falling back to a secondary server.
  5. Nothing other than the DNS server is listening on port 53 on that host.

Questions people ask about this

Do I need to buy anything to resolve this?

No. This is a port conflict or a stale address on a server you already run. Nothing about the licence changes whether a socket can be bound.

What is Microsoft’s documented cause?

Running both Network Address Translation and the DNS Server service on the same host. NAT’s DNS proxy lets clients send queries to the NAT server, and the proxy and the DNS Server service cannot coexist on the same host using the same interface and address with default settings.

Can I move DNS to a different port?

Technically yes, practically no. Everything that resolves names expects 53, so changing it breaks resolution for everything that has not been told.

Should I disable IPv6 to stop the IPv6 socket failing?

No. Fix the address or remove it from the listen list. Disabling IPv6 is a larger change than the problem warrants and causes issues of its own.

Why does the server answer some clients and not others?

Because the bind failed on one address and succeeded on another. Clients that reach the working interface get answers and clients pointed at the failed one time out, so the pattern follows subnets rather than users.

Related error codes

Was this article helpful?

Your feedback helps us improve our documentation.

Related articles

License Error Error 1788 trusted domain failure: forest and external trusts that stop working Free Fix Error 1789 trust relationship failed: rebuilding a broken secure channel License Error Error 8340: metadata cleanup after a domain controller that never came back License Error Error 8557 machine account quota exceeded: no more computers may join
โ† Back to Knowledge Base