[124300] in North American Network Operators' Group
Re: IPv4 ANYCAST setup
daemon@ATHENA.MIT.EDU (bmanning@vacation.karoshi.com)
Tue Mar 30 06:06:23 2010
Date: Tue, 30 Mar 2010 10:05:27 +0000
From: bmanning@vacation.karoshi.com
To: Randy Bush <randy@psg.com>
In-Reply-To: <m2fx3i8aj6.wl%randy@psg.com>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Tue, Mar 30, 2010 at 05:43:25PM +0900, Randy Bush wrote:
> >>> I have talked to multiple security officers (who are generally not
> >>> really knowledgeable on networks) who had 53/tcp blocked and none
> >>> have yet agreed to change it.
> >> patience. when things really start to break, and the finger of fate
> >> points at them, clue may arise.
> > 36 days until all root servers have DNSSEC data, at which point large
> > replies become normal.
>
> are end user tools, i.e. a web click a button, available so they can
> test if they are behind a clueless security id10t?
no - in part because using a browser to debug DNS involves
a third app (and likly a third/forth) platform.
the nifty OARC testpoint is nearly worthless for real operations,
since its not located at/near a DNS authoritative source. the
K testpoint is good, I should prolly put back the one off B.
> is there good simple end user docco they are somewhat likely to find
> when things break for them?
not yet. in part because out of the few simple parts, many, many
combinations of failure can occur.
) MTU strictures:
v6/v4 tunneling
v6/v4 MTU
clamping
) Fragmenation
UDP
) Port blocking
) Resolver Behaviour
EDNS awareness
> i.e. what can we do to maximize the odds that the victim will quickly
> find the perp, as opposed to calling our our tech support lines?
thats a tough call. as tech support staff, we are almost always
an outside observer on the path btwn the victim and the perp.
troubleshooting is going to be problematic.
>
> randy
