Where should DNS be listening?

  • Thread starter Thread starter James W. Long
  • Start date Start date
J

James W. Long

Dear All:

This is an internal active directory integrated DNS server
on w2k server.

The DNS server is set to listen on _all IP addresses.
is that setting right?

My question is, why would it be set
to listen on all addresses,
are there some reasons for this?
(I did not set it up)

Wouldnt I want to set it to listen on its
own address? Our clients point to this address
thru dhcp.

Thank you in advance,
James W. Long
 
DNS server...set to listen on _all IP addresses.
... why would it be set to listen on all addresses,
Wouldnt I want to set it to listen on its own address?

I understand that "listen on all IP addresses" is provided as a
convenience.

A device (in this case, your PC running Windows 2000 Server) may have
several IP addresses. For example, it may be connected to two
separate Ethernet networks and therefore may have at least two IP
addresses.

"All IP addresses" means "all the IP addresses of this device" (rather
than "all the IP addresses everywhere").

I assume (I'm not an expert) that, during initialisation, the DNS
server must enumerate the available IP interfaces and decide on which
of them it should provide service.

You can specify explicitly the addresses on which the server should
listen, to restrict it to those addresses. However, "all IP
addresses" is a convenient and often safe default and, if it weren't
available, you'd have to specify the relevant IP address(es) on every
DNS server.

Mike
 
Dear Mike:

Thank you!

James W. Long

MikeS said:
I understand that "listen on all IP addresses" is provided as a
convenience.

A device (in this case, your PC running Windows 2000 Server) may have
several IP addresses. For example, it may be connected to two
separate Ethernet networks and therefore may have at least two IP
addresses.

"All IP addresses" means "all the IP addresses of this device" (rather
than "all the IP addresses everywhere").

I assume (I'm not an expert) that, during initialisation, the DNS
server must enumerate the available IP interfaces and decide on which
of them it should provide service.

You can specify explicitly the addresses on which the server should
listen, to restrict it to those addresses. However, "all IP
addresses" is a convenient and often safe default and, if it weren't
available, you'd have to specify the relevant IP address(es) on every
DNS server.

Mike
 
I assume (I'm not an expert) that, during initialisation, the DNS
server must enumerate the available IP interfaces and decide on which
of them it should provide service.

Well said. In WinSock you can listen on 0.0.0.0 (or Any) that will listen
on all IPs on all addapters. This can be ~"cheaper" then explicitly
listening on multiple IPs as you can just run one listener socket and thread
to do it. Once you have to listen on multiple sockets, you need multiple
threads or some form of async server. The threads are not that big of deal
but they do have a small cost.
 
In
William Stacey said:
Well said. In WinSock you can listen on 0.0.0.0 (or Any) that will
listen on all IPs on all addapters. This can be ~"cheaper" then
explicitly listening on multiple IPs as you can just run one listener
socket and thread to do it. Once you have to listen on multiple
sockets, you need multiple threads or some form of async server. The
threads are not that big of deal but they do have a small cost.

Now that I didn't know! Always thought it was one thread, but this makes
sense. More overhead.

Question, is this by each physical interface or is it the same for multiple
IPs on one interface?

Thanks William!


--
Regards,
Ace

G O E A G L E S !!!
Please direct all replies ONLY to the Microsoft public newsgroups
so all can benefit.

This posting is provided "AS-IS" with no warranties or guarantees
and confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft Windows MVP - Windows Server - Directory Services

Security Is Like An Onion, It Has Layers
HAM AND EGGS: A day's work for a chicken;
A lifetime commitment for a pig.
 
Question, is this by each physical interface or
is it the same for multiple IPs on one interface ?

Hmm afaict it should be true even for multiple IPs on
the same interface, keep in mind that when you "bind"
a socket you specify an IP address, not an interface
at any rate the "overhead" isn't all that big imho :-)

Regards

--

* ObiWan

Microsoft MVP: Windows Server - Networking
http://www.microsoft.com/communities/MVP/MVP.mspx
http://mvp.support.microsoft.com

DNS "fail-safe" for Windows clients.
http://ntcanuck.com

408+ XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm
 
In
ObiWan said:
Hmm afaict it should be true even for multiple IPs on
the same interface, keep in mind that when you "bind"
a socket you specify an IP address, not an interface
at any rate the "overhead" isn't all that big imho :-)

Regards

That would make sense. A socket is defined as having a port #, the transport
used and the IP. So it makes sense each socket require its own process, and
the number of interfaces is not relevant.

Thanks!

Ace
 
WSM> [Listening on 0.0.0.0] can be ~"cheaper" then explicitly listening on
WSM> multiple IP[ addresse]s as you can just run one listener socket and
WSM> thread to do it.

.... as long as one's inbound IP routing matches one's operating system's
choice of source addresses. If it doesn't, problems ensue.

I recommend that UDP/IP services aren't configured to listen on 0.0.0.0.

WSM> Once you have to listen on multiple sockets,
WSM> you need multiple threads or some form of async server.

.... or, quite simply, select(). Such a server can be single-threaded
and entirely synchronous.

WSM> The threads are not that big of deal but they do have a small cost.

The multi-threading needs to be thought about carefully, especially with
regards to back-end processing, logging, and use of standard C/C++
library features (the details of which will vary from implementation to
implementation).
 
That would make sense. A socket is defined as having a
port #, the transport used and the IP. So it makes sense
each socket require its own process, and the number of
interfaces is not relevant.

Yes, exact... by the way one may as well take the "unix"
approach and use a "select()" on all the sockets, in this
case one thread will be able to handle all the requests
the problem in such a case is just ... performances ;-)
since in this case you'll need to either use a "queue"
to serve all the requests from the various "signalled"
sockets or a bunch of worker thread to which you'll
pass the requests... and in this case we're back to
square one since it's almost the same scenario as
the one you have using a thread for each socket :-)

You're welcome .. as usual :-)


--

* ObiWan

Microsoft MVP: Windows Server - Networking
http://www.microsoft.com/communities/MVP/MVP.mspx
http://mvp.support.microsoft.com

DNS "fail-safe" for Windows clients.
http://ntcanuck.com

408+ XP/2000 tweaks and tips
http://ntcanuck.com/tq/Tip_Quarry.htm
 
In
ObiWan said:
Yes, exact... by the way one may as well take the "unix"
approach and use a "select()" on all the sockets, in this
case one thread will be able to handle all the requests
the problem in such a case is just ... performances ;-)
since in this case you'll need to either use a "queue"
to serve all the requests from the various "signalled"
sockets or a bunch of worker thread to which you'll
pass the requests... and in this case we're back to
square one since it's almost the same scenario as
the one you have using a thread for each socket :-)


You're welcome .. as usual :-)

So either way, it comes down to a performance issue. It seems separate
processes would eliminate the need for queuing and make it more efficient,
even though it's a small performance hit.
:-)

Thanks again!

Ace
 
Back
Top