Hi,
Jakob and I spent the past few weeks hacking up a DNS implementation
fingerprint tool (where implementation == anything responding to a query).
This mail introduces the methodology of fingerprinting DNS
implementations.
A nameserver basically responds to a query. Inter-operability is an
obvious requirement here, the standard protocol behaviour of different DNS
implementations is expected to be the same.
Protocol behaviour of a DNS implementation is widely documented in the
case of a 'common' query. The DNS protocol is over 20 years old and since
its inception, there have been over 40 independant DNS implementations,
while some implementations have over 20 versions.
The methodology used to identify individual nameserver implementations is
based on "borderline" protocol behaviour. The DNS protocol offers a
multitude of message bits, response types, opcodes, classes, query types
and label types in a fashion that makes some mutually exclusive while some
are not used in a query messages at all. Not every implementation offers
the full set of features the DNS protocol set currently has. Some
implementations offer features outside the protocol set, and there are
implementations that do not comform to standards.
Also, new features added to - or bugs removed allow for differentiations
between versions of an implementation.
Methodology
We use a serie of "borderline" query-response messages to identify
implementations. A serie of query-response messages form a sequence.
We call the interpretation of these series to form a conclusion "DNS
sequencing".
As mentioned, responses to a "borderline" query is used in this method.
To be somewhat efficient, a tree can be constructed which consists of
queries (nodes) and responses (branches), where the leave nodes identify
the implementation.
Every path, from the root node (initial query) to a leave node (final
query) is essentially a "strain". The strains are used to distinguish
between, and as said, ultimatly identify implementations.
Parallel to this technique it is possible to identify some brands and
their versions by doing a specific query asking for the servers' version.
This technique does not satisfy our requirement since this has not been
implemented in all brands of nameservers (it is not part of any standard),
operators may have obscured the information and there are implementations
that try to resolve the query, essentially asking root-servers from a
different class for their version.
Implementation.
Our current software is written as a proof-of-concept. In field tests,
false positives were encountered when trying to identify a set of servers
residing behind a load-balancing apparatus where the servers itself are of
different implementations, or when a specific implementation behaves like
a forwarder.
We are actively looking for implementations not yet identified by this
tool to complement the set of strains.
The current set of strains identify the following implementations
and their versions:
ATLAS
BIND 4
BIND 4.8 -- 4.8.3
BIND 4.9.3 -- 4.9.11
BIND 8
BIND 8.1 -- 8.2.1T4B
BIND 8.2.1
BIND 8.2.2P3 -- 8.4.1
BIND 8.4.1P1
BIND 9
BIND 9.0.0b5 -- 9.0.1
BIND 9.1.0 -- 9.1.3
BIND 9.2.0a1 -- 9.2.0rc3
BIND 9.2.0rc4 -- 9.2.2P3
BIND 9.2.3rc1 -- 9.4.0a0
eNom DNS
Incognito DNS Commander
MARADNS
Microsoft Windows
Server 2003
Server 2000
Server NT4
MyDNS
Nominum ANS
Nominum CNS
NonSequitur DNS
NSD
Oak DNS
Pliant DNS Server
Posadis
PowerDNS
2.8 -- 2.9.3
2.9.4 -- 2.9.11
QuickDNS
Simple DNS plus
TinyDNS
UltraDNS
We are actively looking for volunteers who allow us to identify their
running code in some form or configuration of some version of:
chives
custom-dns
dents
dnrd
dnsmasq
gnudip-www
ibmdns
jeeves
lbdns
lbnamed
ldapdns
MacDNS
Microsoft Windows Server NT3.51
pdnsd
Stanford::DNSserver
yaku-ns
and/or
All other unidentified, unmentioned original code.
Thanks,
Roy Arends
Jakob Schlyter
