LSASS.EXE Outbound on Port 53?

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does LSASS.EXE have a legitimate reason to communicate on
port 53 (DNS)? Outside of my network?!

I am auditing port 53 on my domain controller and was
surprised to see outbound traffic from LSASS.EXE. The
destinations include all of the DNS servers specified in
the server's TCP/IP settings. [One of those is the
server's own IP. The other two are fail-over DNS servers
located outside of our network.] What is LSASS.EXE looking
for? And why is it using port 53? [I mean, it isn't
actually performing DNS lookups, is it?]

Any advice is greatly appreciated.
 
Does LSASS.EXE have a legitimate reason to communicate on
port 53 (DNS)? Outside of my network?!

I am auditing port 53 on my domain controller and was
surprised to see outbound traffic from LSASS.EXE. The
destinations include all of the DNS servers specified in
the server's TCP/IP settings.
Click to expand...

If it is a DNS server it might be looking up
forward OR reverse zones on the Internet OR
as a DC it will be both registering and performing
lookups against DNS.
[One of those is the
server's own IP. The other two are fail-over DNS servers
located outside of our network.] What is LSASS.EXE looking
for? And why is it using port 53? [I mean, it isn't
actually performing DNS lookups, is it?]
Probably.

Any advice is greatly appreciated.
Click to expand...

If it is a DNS server arrange for it to FORWARD
to your ISP for DNS resolution (Or better to your
caching only DNS server on your firewall-gateway-
DMZ) and then CHECK the box on the FORWARDERS
tab ONLY that says "Do not use recursion."

Setup the reverse zones for your internal Network
range -- even if you don't care about them this keeps
the machines from trying to find (the usually
non-existent private) reverse zones on the Internet --
which will never be dynamic anyway.

If you use the ISP as a forwarder you will still have
SOME traffic on port 53 but it will be limited to
the ISP DNS server addresses IF you stop those
attempts at dynamic registration on the public network.
 
The Netlogon process regularly touches the DNS records of
the DC if dynamic updates are in use. I thought that this ran
in the context of lsa. If this is the origin, then the traffic will
be directed to the/a DNS server that is the/a primary for the
zone of that DC's DNS domain. There are some checks that
can happen on trigger, such as running netdiag, that cause
all DNS servers listed to be examined to check for consistency.
Netlogon writes a file, netlogon.dns, which contains the current
list of records it believe it needs to make sure exist, and no
others, for that DC.
If it is the update process checking, then you will see this on
a regular schedule, IIRC at on hour for a DC if the records are
as they should be, sooner if it is frantic about being unable to
make them as they should be.
 
So, if I understand correctly, there are two things I
should do:

1.) LSASS.EXE has no legitimate purpose outside of our
network. A separate problem is suggested by this:
External DNS servers should not be specified in the DC's
network config. I will remove these.

2.) LSASS.EXE has legitimate need for port 53 and therefore
should be permitted use. This is corroborated by Netlogon
warnings, "Dynamic registration failed because no DNS
servers are available."

Sound good?

Thank you, all!
-----Original Message-----
The Netlogon process regularly touches the DNS records of
the DC if dynamic updates are in use. I thought that this ran
in the context of lsa. If this is the origin, then the traffic will
be directed to the/a DNS server that is the/a primary for the
zone of that DC's DNS domain. There are some checks that
can happen on trigger, such as running netdiag, that cause
all DNS servers listed to be examined to check for consistency.
Netlogon writes a file, netlogon.dns, which contains the current
list of records it believe it needs to make sure exist, and no
others, for that DC.
If it is the update process checking, then you will see this on
a regular schedule, IIRC at on hour for a DC if the records are
as they should be, sooner if it is frantic about being unable to
make them as they should be.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
Does LSASS.EXE have a legitimate reason to communicate on
port 53 (DNS)? Outside of my network?!

I am auditing port 53 on my domain controller and was
surprised to see outbound traffic from LSASS.EXE. The
destinations include all of the DNS servers specified in
the server's TCP/IP settings. [One of those is the
server's own IP. The other two are fail-over DNS servers
located outside of our network.] What is LSASS.EXE looking
for? And why is it using port 53? [I mean, it isn't
actually performing DNS lookups, is it?]

Any advice is greatly appreciated.
Click to expand...


.
Click to expand...
 
Sounds about right, except strengthing number 1
No domain member should ever be configured to use an
outside DNS server that is unable to locate the zones in
use to support the AD infrastructure, not ever, not client,
not member server, not DC.

--
Roger
So, if I understand correctly, there are two things I
should do:

1.) LSASS.EXE has no legitimate purpose outside of our
network. A separate problem is suggested by this:
External DNS servers should not be specified in the DC's
network config. I will remove these.

2.) LSASS.EXE has legitimate need for port 53 and therefore
should be permitted use. This is corroborated by Netlogon
warnings, "Dynamic registration failed because no DNS
servers are available."

Sound good?

Thank you, all!
-----Original Message-----
The Netlogon process regularly touches the DNS records of
the DC if dynamic updates are in use. I thought that this ran
in the context of lsa. If this is the origin, then the traffic will
be directed to the/a DNS server that is the/a primary for the
zone of that DC's DNS domain. There are some checks that
can happen on trigger, such as running netdiag, that cause
all DNS servers listed to be examined to check for consistency.
Netlogon writes a file, netlogon.dns, which contains the current
list of records it believe it needs to make sure exist, and no
others, for that DC.
If it is the update process checking, then you will see this on
a regular schedule, IIRC at on hour for a DC if the records are
as they should be, sooner if it is frantic about being unable to
make them as they should be.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
Does LSASS.EXE have a legitimate reason to communicate on
port 53 (DNS)? Outside of my network?!

I am auditing port 53 on my domain controller and was
surprised to see outbound traffic from LSASS.EXE. The
destinations include all of the DNS servers specified in
the server's TCP/IP settings. [One of those is the
server's own IP. The other two are fail-over DNS servers
located outside of our network.] What is LSASS.EXE looking
for? And why is it using port 53? [I mean, it isn't
actually performing DNS lookups, is it?]

Any advice is greatly appreciated.
Click to expand...


.
Click to expand...
Click to expand...
 
So, if I understand correctly, there are two things I
should do:

1.) LSASS.EXE has no legitimate purpose outside of our
network.
Click to expand...

Generally ture.
A separate problem is suggested by this:
External DNS servers should not be specified in the DC's
network config. I will remove these.
Click to expand...

Even more true that #1 -- internal DNS clients must
use STRICTLY internal DNS servers -- DCs and other
servers are DNS clients too.
2.) LSASS.EXE has legitimate need for port 53 and therefore
should be permitted use. This is corroborated by Netlogon
warnings, "Dynamic registration failed because no DNS
servers are available."
Click to expand...

It has a need to register by contacting the DNS server
on port 53 as a DESTINATION (if the same machine
is a DNS server, which is commn for DCs, then it will
also -- AS THE DNS SERVER -- need to allowing this
incoming as the destination.)

Even with the above, it is POSSIBLE that the client will
attempt to register it's REVERSE record with the (likely
non-existent) external zones for the locally administered
addresses you use -- this can mean that the internal DNS
servers will attempt to find the reverse of 192.168.x, 10.x,
or 172.16-32.x EVEN if the client is set to correctly
let them do the searching.

You stop the latter by creating the reverse zones, even if
you choose to leave them empty -- although there is little
reason not to just make them dynamic too and let the
machines register.

--
Herb Martin

Sound good?

Thank you, all!
-----Original Message-----
The Netlogon process regularly touches the DNS records of
the DC if dynamic updates are in use. I thought that this ran
in the context of lsa. If this is the origin, then the traffic will
be directed to the/a DNS server that is the/a primary for the
zone of that DC's DNS domain. There are some checks that
can happen on trigger, such as running netdiag, that cause
all DNS servers listed to be examined to check for consistency.
Netlogon writes a file, netlogon.dns, which contains the current
list of records it believe it needs to make sure exist, and no
others, for that DC.
If it is the update process checking, then you will see this on
a regular schedule, IIRC at on hour for a DC if the records are
as they should be, sooner if it is frantic about being unable to
make them as they should be.

--
Roger Abell
Microsoft MVP (Windows Security)
MCSE (W2k3,W2k,Nt4) MCDBA
Does LSASS.EXE have a legitimate reason to communicate on
port 53 (DNS)? Outside of my network?!

I am auditing port 53 on my domain controller and was
surprised to see outbound traffic from LSASS.EXE. The
destinations include all of the DNS servers specified in
the server's TCP/IP settings. [One of those is the
server's own IP. The other two are fail-over DNS servers
located outside of our network.] What is LSASS.EXE looking
for? And why is it using port 53? [I mean, it isn't
actually performing DNS lookups, is it?]

Any advice is greatly appreciated.
Click to expand...


.
Click to expand...
Click to expand...
 
Back
Top