Where should DNS be listening?

G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns (More info?)

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
 

MikeS

Distinguished
Apr 7, 2004
20
0
18,510
Archived from groups: microsoft.public.win2000.dns (More info?)

>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
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns (More info?)

> 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.

--
William Stacey, MVP
http://mvp.support.microsoft.com
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns (More info?)

Dear Mike:

Thank you!

James W. Long

"MikeS" <mikeshepherd564@btinternet.com> wrote in message
news:f7suq05ls3pp87prmnke22qorpd9tilu7f@4ax.com...
> >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
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns (More info?)

In news:ObVu3sN2EHA.824@TK2MSFTNGP11.phx.gbl,
William Stacey [MVP] <staceywREMOVE@mvps.org> made a post then I commented
below
>> 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.

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.
--
=================================
 

obiwan

Distinguished
Feb 16, 2001
90
0
18,630
Archived from groups: microsoft.public.win2000.dns (More info?)

> 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
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns (More info?)

In news:eqYSwCV2EHA.4028@TK2MSFTNGP15.phx.gbl,
ObiWan <obiwan@mvps.org> made a post then I commented below
>> 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

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
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns,comp.protocols.tcp-ip.domains (More info?)

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).
 

obiwan

Distinguished
Feb 16, 2001
90
0
18,630
Archived from groups: microsoft.public.win2000.dns (More info?)

>>> 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

> 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 :)

> Thanks!

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
 
G

Guest

Guest
Archived from groups: microsoft.public.win2000.dns (More info?)

In news:%23ryKDo72EHA.4004@tk2msftngp13.phx.gbl,
ObiWan <obiwan@mvps.org> made a post then I commented below
>> 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 :)
>
>> Thanks!
>
> 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