Re: [dns-operations] cheap traffic measure for a small set of zones

[Tony Finch]

Randy Bush  wrote:

> is there a simple tool to run on a server to measure query and data
> rates for a small set of zones?  i just want to run it for a day.
>
> it is a a bind9 server which serves a few hundred zones.  i would like
> to know the query rate and byte count for six of them.

I usually use BIND's built-in statistics server for this kind of thing,
but it looks like it can count queries per zone but not bytes per zone.
(my servers are configured with `zone-statistics full;`)

e.g.

$ curl -sf http://auth0:8053/json/v1 |
jq -r '.views.main.zones[] |
"\(.name) \((.rcodes.QryUDP) + (.rcodes.QryTCP))"' |
grep ^cam.ac.uk
cam.ac.uk 1294381958

That's queries since the server started.

[ jq is a bit of a puzzle language; I often prefer gron | grep ]

https://stedolan.github.io/jq/
https://github.com/TomNomNom/gron

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Fair Isle: Westerly, backing southerly later, 5 to 7, perhaps gale 8
later in west. Rough or very rough, occasionally moderate in
southeast. Wintry showers. Good, occasionally poor.

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] cheap traffic measure for a small set of zones

[Dobbins, Roland]

> On Mar 26, 2021, at 8:12 PM, Frank Louwers  wrote:
> 
> This message originated outside of NETSCOUT. Do not click links or open 
> attachments unless you recognize the sender and know the content is safe.
> 
> As an alternative, you might look at dnsdist

dnsdist is a great tool, but it might be a bit much just to count stats for a 
few minutes.  ;>


--
Roland Dobbins 


___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] cheap traffic measure for a small set of zones

[Shannon Weyrick via dns-operations]

--- Begin Message ---
Hi, you can also check out pktvisor https://github.com/ns1/pktvisor ... it
has both a command line UI and the ability to collect to a time series
database like Prometheus or Elastic (an imminent release will make the
former very simple). Works via packet capture right now but dnstap support
is coming. In addition it can also summarize pcap files.

Shannon


On Fri, Mar 26, 2021 at 12:22 AM Randy Bush  wrote:

> > is there a simple tool to run on a server to measure query and data
> > rates for a small set of zones?
> >
> > 
>
> bingo!  thanks.
>
> randy
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations
>
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] cheap traffic measure for a small set of zones

[Frank Louwers]

As an alternative, you might look at dnsdist: a simple (but powerful) open 
source dns proxy which could pass all queries to your bind setup, but provide 
you with the metrics you need.

https://dnsdist.org

Frank



> On 26 Mar 2021, at 07:44, Antonio Prado via dns-operations 
>  wrote:
> 
> 
> From: Antonio Prado 
> Subject: Re: [dns-operations] cheap traffic measure for a small set of zones
> Date: 26 March 2021 at 07:44:39 CET
> To: Randy Bush 
> Cc: DNS Operations 
> 
> 
> On 3/26/21 5:20 AM, Randy Bush wrote:
>>> is there a simple tool to run on a server to measure query and data
>>> rates for a small set of zones?
>>> 
>>> 
>> bingo!  thanks.
> 
> hi,
> 
> dnstop does not support TCP at this time
> 
> --
> antonio
> 
> 
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations

___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] cheap traffic measure for a small set of zones

[Antonio Prado via dns-operations]

--- Begin Message ---

On 3/26/21 5:20 AM, Randy Bush wrote:

is there a simple tool to run on a server to measure query and data
rates for a small set of zones?




bingo!  thanks.


hi,

dnstop does not support TCP at this time

--
antonio
--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Re: [dns-operations] UDP fragmentation while not needed/wanted DS www.veilingzaalmelase.be

[Joao Luis Silva Damas]

> On 25 Mar 2021, at 23:36, Paul Vixie  wrote:
> 
> On Wed, Mar 24, 2021 at 11:25:48PM +0100, Florian Weimer wrote:
>>> ...
>> 
>> Proactive fragmentation irrespective of path MTU is required for
>> stateless IPv6 UDP services.  Unlike IPv4, the network does not
>> fragment packets.  So a UDP service has to conservatively fragment
>> around 1200 or so bytes (to account for tunnel overhead).  ...
> 
> 1280 subtracts several hundred bytes from 1500 to allow for tunnel
> overhead.

Actually it doesn’t. The IETF arrived at this number from the other side (small 
values for MTU). See mail at bottom to see just what assumptions went into the 
parameters (1280=1025+256 because IPv4 was 512+64 and IPv6 needed to reduce the 
header overhead below that of IPv4. please…, 9600bps...)

> 1232 subtracts dozens more to allow for IP and UDP headers
> and options.

That is does, unnecessarily. There is, and has been for a while, data out there 
showing bigger numbers are OK (for instance, Google published how they got to 
the size they use on QUIC packets based on traffic they observed arriving at 
their network, a fairly decent piece of data).

> 
> please, nobody, subtract even more. if everyone subtracts a fudge
> factor, forever, we'll eventually run out of payload space, or worse,
> go negative.

:)

> 
> -- 
> Paul Vixie
> ___
> dns-operations mailing list
> dns-operations@lists.dns-oarc.net
> https://lists.dns-oarc.net/mailman/listinfo/dns-operations


From owner-i...@sunroof.eng.sun.com   
Thu Nov 13 16:41:01 1997
Received: (from majordomo@localhost)
by sunroof.eng.sun.com  
(8.8.8+Sun.Beta.0/8.8.8) id QAA14339
for ipng-dist; Thu, 13 Nov 1997 16:38:00 -0800 (PST)
Received: from Eng.Sun.COM  (engmail1 [129.146.1.13])
by sunroof.eng.sun.com  
(8.8.8+Sun.Beta.0/8.8.8) with SMTP id QAA14332
for ; Thu, 13 Nov 1997 16:37:51 -0800 (PST)
Received: from saturn.sun.com  (saturn.EBay.Sun.COM 
 [129.150.69.2])
by Eng.Sun.COM  (SMI-8.6/SMI-5.3) with SMTP id 
QAA28654
for mailto:i...@sunroof.eng.sun.com>>; Thu, 
13 Nov 1997 16:37:48 -0800
Received: from postoffice.cisco.com  
(postoffice.cisco.com  [171.69.200.88])
by saturn.sun.com  (8.8.8/8.8.8) with ESMTP id 
QAA28706
for mailto:i...@sunroof.eng.sun.com>>; Thu, 
13 Nov 1997 16:37:49 -0800 (PST)
Received: from [171.69.199.124] (deering-mac.cisco.com 
 [171.69.199.124]) by postoffice.cisco.com 
 (8.8.5-Cisco.1/8.6.5) with ESMTP id QAA20862; 
Thu, 13 Nov 1997 16:37:48 -0800 (PST)
X-Sender: deer...@postoffice.cisco.com 
Message-Id: 
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 13 Nov 1997 16:37:00 -0800
To: IPng Working Group mailto:i...@sunroof.eng.sun.com>>
From: Steve Deering mailto:deer...@cisco.com>>
Subject: (IPng 4802) increasing the IPv6 minimum MTU
Cc: hin...@ipsilon.com 
Sender: owner-i...@eng.sun.com 
Precedence: bulk

In the ipngwg meeting in Munich, I proposed increasing the IPv6 minimum MTU
from 576 bytes to something closer to the Ethernet MTU of 1500 bytes, (i.e.,
1500 minus room for a couple layers of encapsulating headers, so that min-
MTU-size packets that are tunneled across 1500-byte-MTU paths won't be
subject to fragmentation/reassembly on ingress/egress from the tunnels,
in most cases).

After the short discussion in the Munich meeting, I called for a show of
hands, and of those who raised their hands (about half the attendees, if
I recall correctly), the vast majority were in favor of this change --
there were only two or three people opposed.  However, we recognized that
a fundamental change of this nature requires thoughtful discussion and
analysis on the mailing list, to allow those who were not at the meeting
and those who were there but who have since had second thoughts, to express
their opinions.  A couple of people have already, in private conversation,
raised some concerns that were not identified in the discussion at the
meeting, which I report below.  We would like to get this issue settled as
soon as possible, since this is the only thing holding up the publication
of the updated Proposed Standard IPv6 spec (the version we expect to advance
to Draft Standard), so let's see if we can come to a decision before the ID
deadline at the end of next week (hoping there isn't any conflict between
"thoughtful analysis" and "let's decide quickly" :-).

The reason I would like to increase the minimum MTU is that there are some
applications for which Path MTU Discovery just won't work very well,