Oddities in my named.log. Can you explain?

[Kevin Darcy]

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