Home page logo
/

nanog logo nanog mailing list archives

Re: Open Resolver Problems
From: Jerry Dent <effinjdent () gmail com>
Date: Wed, 3 Apr 2013 10:25:26 -0500

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



  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault