Keve Nagy wrote:
Hi Everyone,
I see some oddities frequently showing up in our BIND logfiles.
This is on the official primary NS for our domain.
*Oddity_type#1*
... view external-in: query: server.EXAMPLE.COM IN SOA -E
Please note that the only thing I changed here is the domain name. I
did not capitalize it, the original domain name also got logged this
way. And yes, the original hostname queried was "server", I did not
change that either. These are repeatedly coming from the same source
IP address, once in every 10-70 minutes.
We have never had a host named "server". So why would an external
machine keep asking for a hostname we never had? Especially with such
an obvious name! Also, why is the domain part capitalized for these
queries, and not in any proper/legitimate query? I assume this is what
the query was for. The original request must have been for
server.EXAMPLE.COM, having the domain part this way capitalized in the
query itself.
So why would a remote system look for a never existed host named
"server" in our system, with the domain name capitalized?
Any legitimate reason you could think of?
They're looking up "server" and they have EXAMPLE.COM as their default
domain or in their searchlist.
Why do they have their default domain or searchlist set to that? No
idea. Ask them.
*Oddity_type#2*
... view external-in: query: server.EXAMPLE.COM IN SOA +
... view external-in: updating zone 'example.com/IN': update unsucces
sful: server.EXAMPLE.COM/A: 'RRset exists (value dependent)'
prerequisite not satisfied (NXRRSET)
Again note, that I only changed the name of the domain and I did not
alter the capitalization or the hostname. These are from another
source IP address, but always the same one. For some reason, also
looking for the host named "server". And a few minutes later, it seems
to try to update the domain database.
By the way, no host is allowed to update our DNS records. The zone
files are updated by hand only. And this has always been the case, no
exceptions.
They have their default domain set to EXAMPLE.COM and they're trying to
register their A records in DNS every time they get a new lease from DHCP.
*Oddity_type#3*
... view external-in: query: gc._msdcs.EXAMPLE.COM IN SOA -E
... view external-in: query: _ldap._tcp.gc._msdcs.EXAMPLE.COM IN SOA
-E
... view external-in: query: _ldap._tcp.dc._msdcs.EXAMPLE.COM IN SOA
-E
... view external-in: query: _kpasswd._tcp.EXAMPLE.COM IN SOA -E
... view external-in: query: _kpasswd._udp.EXAMPLE.COM IN SOA -E
... view external-in: query: _ldap._tcp.Alapertelmezett-elso-hely-neve.
_sites.dc._msdcs.EXAMPLE.COM IN SOA -E
... view external-in: query: _ldap._tcp.d819d059-6674-4c56-899c-e6a7aee
fb77f.domains._msdcs.EXAMPLE.COM IN SOA -E
... view external-in: query: d476b9e8-6916-483e-ac68-2329bfac49b1._msdc
s.EXAMPLE.COM IN SOA -E
... view external-in: query: _kerberos._tcp.EXAMPLE.COM IN SOA -E
... view external-in: query: _gc._tcp.EXAMPLE.COM IN SOA -E
Look at these add hostnames which are queried for!
These are all systematically returning queries. And these come from
multiple source IP addresses.
Are these queries legitimate? I mean, do you know of any system that
may be doing this? Are these strange hostname queries part of some
standard way identifying services and I just don't happen to know
about this standard?
It's Active Directory. Those queries would be perfectly normal for an
Active Directory-enabled PC with EXAMPLE.COM set as the Active Directory
domain *if* the the queries were of type SRV instead of SOA.
I, too, see a few SOA queries of AD-looking names, but the vast majority
are SRV.
My only speculation would be that some routine within the Active
Directory subsystem is trying to find the "closest-enclosing zone" (CEZ)
of a particular name by issuing an SOA query. This makes
CEZ-determination relatively easy, since you just look for an SOA in the
response, in either the Answer Section (if the name happened to be the
apex of the zone) *or* the Authority Section (if the apex is higher up
in the hierarchy). If one uses a query type other than SOA for
CEZ-determination, then you have to parse different kinds of responses,
looking for different types of records, and the parsing is a little more
complicated.
- Kevin
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
