[162108] in North American Network Operators' Group
Re: Open Resolver Problems
daemon@ATHENA.MIT.EDU (Joe Abley)
Tue Apr 2 18:41:32 2013
From: Joe Abley <jabley@hopcount.ca>
In-Reply-To: <20130402171808.24503d94@localhost>
Date: Tue, 2 Apr 2013 18:41:17 -0400
To: John Kristoff <jtk@cymru.com>
Cc: NANOG <nanog@nanog.org>
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 =3D dst port =3D 53 is =
one of those effective zeros.
[dns1-p1:~]% sudo tcpdump -i em0 -n -c 10000 -w sample.pcap udp port 53 =
=20
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:~]%=20
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=
