1. Forum
  2. USENET
  3. comp.protocols.dns.bind

  • Re: Request for review of performance advice

    From Chuck Aurora@ca@nodns4.us to bind-users on Wed Jul 8 13:06:05 2020
    From Newsgroup: comp.protocols.dns.bind

    On 2020-07-07 20:57, Victoria Risk wrote:
    A while ago we created a KB article with tips on how to improve your performance with our Kea dhcp server. The tips were fairly obvious to
    our developers and this was pretty successful. We would like to do
    something similar for BIND, provide a dozen or so tips for how to
    maximize your throughput with BIND. However, as usual, everything is
    more complicated with BIND.
    [big snip]
    Any further suggestions, corrections or warnings are very welcome.

    Vicky, I'd suggest separating these performance tips into two separate articles: authoritative and recursive. Lumping both together is going
    to create more confusion.

    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Havard Eidnes@he@uninett.no to vicky on Thu Jul 9 22:25:05 2020
    From Newsgroup: comp.protocols.dns.bind

    OS settings and the system environment
    ...
    2e) Make sure your socket send buffers are big enough. (not
    sure if this is obsolete advice, do we need to tell people how
    to tell if their buffers are causing delays?)
    2e#1) Make sure your UDP socket *receive* buffers are big enough.
    If on BSD, monitor for "dropped due to full socket buffers"
    count in "netstat -s" output, and tune accordingly. Note that
    this may be a symptom of mis-tuning of other parts of BIND,
    causing excessive CPU usage, which may contribute to this
    problem.
    BTW, unbound has configuration options ("so-rcvbuf" / "so-sndbuf")
    to tune these for only the name server; when I earlier looked for
    something similar in BIND I could not find a corresponding option,
    so had to do a system-wide tuning via sysctl, which isn't ideal, but
    solved the problem in my case.
    named Features
    3a) Minimize logging. Query logging is expensive (can cost you
    20% or more of your throughput) so don't do it unless you
    are using the logs for something. Logging with dnstap is
    lower impact, but still fairly expensive. Don't run in
    debug mode unless necessary.
    3a#1) Do not configure BIND with --enable-querytrace. It most
    probably doesn't do what you might think it does, and is a
    major drag on performance.
    See above under the new "2e#1" for a possible symptom...
    4b) Set an appropriate MTU for your network. Ensure that your
    network infrastructure supports EDNS and large UDP responses up
    to 4096. Ensure that your network infrastructure allows transit
    for and reassembly of fragmented UDP packets (these will be
    large query responses if you are DNSSEC signing)
    Well, isn't the major goal of DNS Flag Day 2020 to eliminate
    fragmentation for various reasons (some of them security-related),
    and recommends to set EDNS buffer size to 1232 instead of letting it
    be the present default of BIND of 4096?
    Best regards,
    - Hovard
    --- Synchronet 3.21d-Linux NewsLink 1.2
  • From Niall O'Reilly@niall.oreilly@ucd.ie to Havard Eidnes on Wed Jul 29 10:55:48 2020
    From Newsgroup: comp.protocols.dns.bind


    --=_MailMate_5EAF6C78-4BE0-4040-9B12-D0E5203B8C45_=
    Content-Type: text/plain

    On 9 Jul 2020, at 21:25, Havard Eidnes via bind-users wrote:

    2e#1) Make sure your UDP socket *receive* buffers are big enough.
    If on BSD, monitor for "dropped due to full socket buffers"
    count in "netstat -s" output, and tune accordingly. Note that
    this may be a symptom of mis-tuning of other parts of BIND,
    causing excessive CPU usage, which may contribute to this
    problem.

    I'm seeing some instances of "dropped due to no socket" on my FreeBSD
    systems where my resolvers run.

    I'm wondering

    - whether and how I can address this with tuning, and also
    - whether I'm wandering out of scope for this list.

    Thanks in anticipation and/or apologies.
    Niall

    --=_MailMate_5EAF6C78-4BE0-4040-9B12-D0E5203B8C45_=
    Content-Type: text/html
    Content-Transfer-Encoding: quoted-printable

    <!DOCTYPE html>
    <html>
    <head>
    <meta http-equiv=3D"Content-Type" content=3D"text/xhtml; charset=3Dutf-8"=

    </head>
    <body>
    <div style=3D"font-family:sans-serif"><div style=3D"white-space:normal">
    <p dir=3D"auto">On 9 Jul 2020, at 21:25, Havard Eidnes via bind-users wro= te:</p>

    </div>
    <div style=3D"white-space:normal"><blockquote style=3D"border-left:2px so=
    lid #777; color:#777; margin:0 0 5px; padding-left:5px"><p dir=3D"auto">2=
    e#1) Make sure your UDP socket *receive* buffers are big enough.<br>
    If on BSD, monitor for "dropped due to full socket buffers"<br>
    count in "netstat -s" output, and tune accordingly. Note that<br>
    this may be a symptom of mis-tuning of other parts of BIND,<br>
    causing excessive CPU usage, which may contribute to this<br>
    problem.</p>
    </blockquote></div>
    <div style=3D"white-space:normal">

    <p dir=3D"auto">I'm seeing some instances of "dropped due to no socket" o=
    n my FreeBSD<br>
    systems where my resolvers run.</p>

    <p dir=3D"auto">I'm wondering</p>


    <li>whether and how I can address this with tuning, and also</li>
    <li>whether I'm wandering out of scope for this list.</li>
    </ul>

    <p dir=3D"auto">Thanks in anticipation and/or apologies.<br>
    Niall</p>
    </div>
    </div>
    </body>
    </html>

    --=_MailMate_5EAF6C78-4BE0-4040-9B12-D0E5203B8C45_=--
    --- Synchronet 3.21d-Linux NewsLink 1.2