CC: Tony Finch MIME-Version: 1.0 In-Reply-To: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,RP_MATCHES_RCVD autolearn=ham autolearn_force=no version=3.4.0 X-Cam-Antivirus: no malware found References: Message-ID: Content-Type: TEXT/PLAIN; charset="utf-8" X-X-Sender: fanf2@hermes-1.csi.cam.ac.uk X-RT-Original-Encoding: utf-8 Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) by bugs.isc.org (Postfix) with ESMTP id A475A2D20571 for ; Fri, 25 Jul 2014 14:59:27 +0000 (UTC) Received: from ppsw-52.csi.cam.ac.uk (ppsw-52.csi.cam.ac.uk [IPv6:2001:630:212:8::e:f52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 5A288349314 for ; Fri, 25 Jul 2014 14:59:25 +0000 (UTC) Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:43813) by ppsw-52.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.159]:25) with esmtpa (EXTERNAL:fanf2) id 1XAgxv-0007t8-Ev (Exim 4.82_3-c0e5623) (return-path ); Fri, 25 Jul 2014 15:59:23 +0100 Received: from fanf2 by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1XAgxv-0003Xg-Hy (Exim 4.72) (return-path ); Fri, 25 Jul 2014 15:59:23 +0100 Delivered-To: bind9-bugs@bugs.isc.org User-Agent: Alpine 2.00 (LSU 1167 2008-08-23) Subject: Re: [ISC-Bugs #36330] EDNS fail - problems resolving dns2v6.cdns.net Return-Path: X-Original-To: bind9-bugs@bugs.isc.org Date: Fri, 25 Jul 2014 15:59:23 +0100 Sender: Tony Finch X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on mx.pao1.isc.org To: Mark Andrews via RT X-Cam-Scannerinfo: http://www.cam.ac.uk/cs/email/scanner/ From: Tony Finch RT-Message-ID: Content-Length: 3081 I have just sent some patches which seem to improve things for me. > I think it would make sense to use different EDNS logic when resolving a > signed zone. In this situation named should never send a query without > EDNS DO. Interestingly there's a NEEDEDNS0 flag which was not actually used. One of my patches deletes it for tidiness, since I was hacking around in that area. My trivial test is: $ dig axfr . | sed -E '/^([0-9a-z-]+)[.][ ].*/!d;s//\1/' | sort -u | while read d; do dig dnskey $d. | grep 'status: SERVFAIL' && echo $d; done When running rev. e58154a6ec0a8a0bde32bb1e39ad2f1fbc3d2ef2 I get: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 9205 ac ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 60366 am ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 17601 college ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46668 cologne ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44970 eus ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 44278 feedback ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 65460 foo ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49232 gal ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 48754 host ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 61070 ink ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26656 koeln ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15330 lacaixa ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 26155 lu ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 30175 mango ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 3460 museum ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 54959 nrw ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 6631 quebec ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 43315 ruhr ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 51870 scot ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 46699 soy ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 56911 ua ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 5356 xn--80asehdb ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 62827 xn--80aswg ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 36947 xn--l1acc ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49480 xn--mgbab2bd ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 39194 xn--q9jyb4c With my patch that deletes the EDNS512 logic I get: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57772 foo ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49115 soy ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49205 xn--l1acc ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 33837 xn--q9jyb4c With the change of initial buffer size from 512 to 1232 I get just: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 2320 xn--l1acc which is an operational fuckup not a protocol bug. Tony. -- f.anthony.n.finch http://dotat.at/ South-east Iceland: Variable 3 or 4, occasionally southwesterly 5 in north. Slight, occasionally moderate in north. Showers, fog patches. Moderate or good, occasionally very poor.