[162123] in North American Network Operators' Group
Re: Open Resolver Problems
daemon@ATHENA.MIT.EDU (Jerry Dent)
Wed Apr 3 11:25:39 2013
In-Reply-To: <C9102BF8-AAC2-4807-BD4D-28E2BC330E0C@hopcount.ca>
Date: Wed, 3 Apr 2013 10:25:26 -0500
From: Jerry Dent <effinjdent@gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
I think that is .2% - .3%, no?
On Tue, Apr 2, 2013 at 5:41 PM, Joe Abley <jabley@hopcount.ca> wrote:
>
> On 2013-04-02, at 18:18, John Kristoff <jtk@cymru.com> wrote:
>
> > I would expect from stubs this will be close enough to zero to be
> > effectively zero. At least I would hope so.
>
> This (below) is one of four resolvers, together providing service for two
> recursive DNS servers used by residential DSL and cable internet users at a
> medium-sized ISP in Canada. These resolvers are running unbound, which will
> never choose a source port of 53 on an outbound query; hence anything we
> see here with src port = dst port = 53 is one of those effective zeros.
>
> [dns1-p1:~]% sudo tcpdump -i em0 -n -c 10000 -w sample.pcap udp port 53
> tcpdump: listening on em0, link-type EN10MB (Ethernet), capture size 96
> bytes
> 10000 packets captured
> 10267 packets received by filter
> 0 packets dropped by kernel
> [dns1-p1:~]% tcpdump -r sample.pcap -q udp src port 53 and udp dst port 53
> | wc -l
> reading from file sample.pcap, link-type EN10MB (Ethernet)
> 26
> [dns1-p1:~]%
>
> 26/1000 is more than zero but still quite small. Subsequent samples with
> bigger sizes give 332/100000, 3017/1000000.
>
> No science here, but 2% - 3% is what it looks like, which is big enough to
> be a noticeable support cost for a medium-scale provider if the customer
> damage is not robo-mediated in some way (e.g. whitelist known offenders to
> avoid the support phone glowing red when you first turn it on).
>
>
> Joe
>
