X-RT-Interface: Email Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org From: "Mark Andrews" To: bind9-confidential@isc.org content-type: text/plain; charset="utf-8" In-Reply-To: Your message of "Sat, 19 Aug 2017 23:05:19 +0000." X-RT-Incoming-Encryption: Not encrypted References: <183c01d3193f$9c8803f0$d5980bd0$@chrysalisnet.org> X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00, RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Original-To: bind9-confidential@bugs.isc.org From marka@isc.org Sun Aug 20 00:20:20 2017 Delivered-To: bind9-confidential@bugs.isc.org Message-ID: <20170820002012.5304382C3A29@rock.dv.isc.org> Subject: Re: [ISC-Bugs #45814] possible EDNS bug X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx.pao1.isc.org", Issuer "COMODO RSA Organization Validation Secure Server CA" (not verified)) by bugs.isc.org (Postfix) with ESMTPS id 8414CD78AED for ; Sun, 20 Aug 2017 00:20:20 +0000 (UTC) Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id E958234C1A6 for ; Sun, 20 Aug 2017 00:20:17 +0000 (UTC) Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id D4EC7160074 for ; Sun, 20 Aug 2017 00:20:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id BBB12160072 for ; Sun, 20 Aug 2017 00:20:17 +0000 (UTC) Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id nbHtjQDJTwIc for ; Sun, 20 Aug 2017 00:20:17 +0000 (UTC) Received: from rock.dv.isc.org (c27-253-115-14.carlnfd2.nsw.optusnet.com.au [27.253.115.14]) by zmx1.isc.org (Postfix) with ESMTPSA id 6337216004A for ; Sun, 20 Aug 2017 00:20:16 +0000 (UTC) Received: from rock.dv.isc.org (localhost [IPv6:::1]) by rock.dv.isc.org (Postfix) with ESMTP id 5304382C3A29 for ; Sun, 20 Aug 2017 10:20:12 +1000 (AEST) Date: Sun, 20 Aug 2017 10:20:12 +1000 RT-Message-ID: Content-Length: 3031 Named starts out with EDNS queries with a UDP buffer size of 512 because that allows named to determine if the remote server supports EDNS without also having to determine if the path supports larger responses. There are still servers that do not respond to EDNS queries. There are still firewalls that think DNS over UDP is limited to 512 bytes. There are still firewalls that think dropping fragments is a good thing. If you start talking to a new nameserver with EDNS using a buffer size of 4096 named cannot determine which of the above or packet loss is causing lack of answers. By advertising a 512 byte buffer you eliminate two sources of error and increase the probability that you can accurately determine if a server supports EDNS or not. If you start with 4096 byte packets you and the server gets no response you have to try multiple recovery strategies simultaneously. Unfortunately you can't just treat non response as packet loss. Mark In message , "Chris via RT" wri tes: > I dont know if this is intentional or a bug, but to me seems buggy behaviour. > > I am diagnosing EDNS by using the following command. Which makes a test > server send responses to show the EDNS size used. > > ‘dig +short rs.dns-oarc.net txt’ > > on unbound and bind 9.9 This will result in large packets of over 4000 bytes. > It also reports a EDNS buffer size of 4096. > > On bind 9.10 the first request has packets below 512 bytes and reports and > EDNS buffer size of 512. However if U run another query shortly after it > then reports larger sizes of over 4000 bytes. So it seems it needs multiple > requests to use large EDNS packets. I have confirmed this behaviour on 3 > different servers all of which run FreeBSD. The EDNS size seems to be > stored in some kind of cache that expires because eventually a request > will then drop back t o a 512 byte limit again. > > Result of first query using bind 9.10 > > rst.x487.rs.dns-oarc.net. > rst.x499.x487.rs.dns-oarc.net. > rst.x457.x499.x487.rs.dns-oarc.net. > "2001:41d0:1:a16c::10:1 DNS reply size limit is at least 499" > "2001:41d0:1:a16c::10:1 sent EDNS buffer size 512" > > Result of second query using bind 9.10 > > rst.x4090.rs.dns-oarc.net. > rst.x4060.x4090.rs.dns-oarc.net. > rst.x4066.x4060.x4090.rs.dns-oarc.net. > "2001:41d0:1:a16c::10:1 sent EDNS buffer size 4096" > "Tested at 2017-08-19 22:56:40 UTC" > "2001:41d0:1:a16c::10:1 DNS reply size limit is at least 4090" > > Result of any query made on unbound or bind 9.9 > > rst.x4090.rs.dns-oarc.net. > rst.x4060.x4090.rs.dns-oarc.net. > rst.x4066.x4060.x4090.rs.dns-oarc.net. > "2a01:4f8:201:5465::2 DNS reply size limit is at least 4090" > "2a01:4f8:201:5465::2 sent EDNS buffer size 4096" > "Tested at 2017-08-19 23:03:20 UTC" > > Please let me know if you need more information. > > regards > > Chris -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org