[168523] in North American Network Operators' Group
Re: BCP38.info
daemon@ATHENA.MIT.EDU (Jared Mauch)
Tue Jan 28 21:18:47 2014
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <3D726033-682D-4743-8BC7-6E2A41FB3AF3@puck.nether.net>
Date: Tue, 28 Jan 2014 21:18:27 -0500
To: Valdis.Kletnieks@vt.edu
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 28, 2014, at 2:16 PM, Jared Mauch <jared@puck.nether.net> wrote:
>=20
> On Jan 28, 2014, at 1:50 PM, Valdis.Kletnieks@vt.edu wrote:
>=20
>> On Tue, 28 Jan 2014 08:06:31 -0500, Jared Mauch said:
>>=20
>>> 52731 ASN7922
>>=20
>>> It includes IP address where you send a DNS packet to it and another =
IP address responds to the query, e.g.:
>>=20
>>> The data only includes those where the =93source-ASN=94 and =
=93dest-asn=94 of these packets don=92t match.
>>=20
>> Hang on Jared, I'm trying to wrap my head around this. You're saying =
that
>> AS7922 has over 50K IP addresses which, if you send a DNS query to =
that IP,
>> you get an answer back from *an entirely different ASN*? How the heck =
does
>> *that* happen?
>=20
> Yup.
>=20
>> Hmm.. Comcast. Anybody over there have an explanation what's going =
on there?
So I owe an apology to Comcast for a few things here.. Thanks to a few =
people (Tony Tauber, Aaron Hopkins)
I found an error in one of the scripts that decodes the =93encoded=94 =
dns query name. It was misprocessing some
data and it resulted in the 73.73.73.73 IP address occurring when it =
should not have. This IP maps to Comcast
and resulted in wrong data here.
This also means I need to go back and reprocess all the old data to =
correct for this constraint problem. (that should
take awhile =85)
Once again, sorry to Comcast for this. Their numbers should be much =
lower.
- Jared=
