[176539] in North American Network Operators' Group
RE: How to track DNS resolution sources
daemon@ATHENA.MIT.EDU (teleric team)
Wed Dec 3 16:26:41 2014
X-Original-To: nanog@nanog.org
From: teleric team <teleric-lists@outlook.com>
To: Stephane Bortzmeyer <bortzmeyer@nic.fr>, Notify Me <notify.sina@gmail.com>
Date: Wed, 3 Dec 2014 12:24:33 -0500
In-Reply-To: <20141203165623.GA13619@laperouse.bortzmeyer.org>
Cc: "nanog@nanog.org list" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
> Date: Wed=2C 3 Dec 2014 17:56:23 +0100
> From: bortzmeyer@nic.fr
> To: notify.sina@gmail.com
> Subject: Re: How to track DNS resolution sources
> CC: nanog@nanog.org
>=20
> On Wed=2C Dec 03=2C 2014 at 05:22:58PM +0100=2C
> Notify Me <notify.sina@gmail.com> wrote=20
> a message of 13 lines which said:
>=20
> > I hope I'm wording this correctly.
>=20
> Not really :-)
>=20
> > I had a incident at a client site where a DNS record was being
> > spoofed.
>=20
> How do you know? What steps did you use to assert this? Answers to
> these questions would help to understand your problem.
>=20
> > How does one track down the IP address that's returning the false
> > records ?
>=20
> If it's real DNS spoofing (which I doubt)=2C the source IP address of
> the poisoner is forged=2C so it would not help.
>=20
> The main tool to use is dig. Let's assume the name that bothers you is
> foobar.example.com. Query your local resolver:
>=20
> dig A foobar.example.com
>=20
> Query an external resolver=2C here Google Public DNS:
>=20
> dig @8.8.4.4 A foobar.example.com
>=20
> Query the authoritative name servers of example.com. First=2C to find the=
m:
>=20
> dig NS example.com
>=20
> Second=2C query them (replace the server name by the real one):
>=20
> dig @a.iana-servers.net. A foobar.example.com
I didn't understand how this will help him identify the poisoner.
What an IDS rule will do is check for responding authoritative query IDs fo=
r DNS queries never made to that responder=2C but made for the authoritativ=
e server identified as per above (direct NS inquiry).
If no IDS is present=2C BIND logging would allow for identification of auth=
oritative responses and query ID identification.=20
In summary whatever is answered authoritatively by a server other than the =
NS ones tracked by "dig +trace foobar.examplecom" is the potential poisoner=
. But if the poisoing is done from an spoofed IP address (spoofing the auth=
oritative IP)=2C well good luck w/ that if the spoofed domain is not DNSSEC=
aware. =
