Organization: Missouri S&T Return-Path: Date: Fri, 2 Feb 2018 11:56:11 -0600 Content-Language: en-US To: bind-bugs@isc.org MIME-Version: 1.0 X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW autolearn=disabled version=3.4.1 From: "Nathan Neulinger" Message-ID: X-RT-Incoming-Encryption: Not encrypted Subject: Changes in 9.12 (related to additional-from changes?) break functionality of a recursive resolver that has cnames crossing zones Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 753E7D78B0E for ; Fri, 2 Feb 2018 17:56:16 +0000 (UTC) Received: from mail-it0-x231.google.com (mail-it0-x231.google.com [IPv6:2607:f8b0:4001:c0b::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id 6194C3AB06A for ; Fri, 2 Feb 2018 17:56:14 +0000 (UTC) Received: by mail-it0-x231.google.com with SMTP id i144so2582201ita.3 for ; Fri, 02 Feb 2018 09:56:14 -0800 (PST) Received: from [192.168.125.10] (67-43-241-123.fidnet.com. [67.43.241.123]) by smtp.gmail.com with ESMTPSA id s70sm3087161itb.0.2018.02.02.09.56.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 09:56:12 -0800 (PST) X-Original-To: bind9-bugs@bugs.isc.org content-type: text/plain; charset="utf-8"; format="flowed" X-Google-SMTP-Source: AH8x224ow6yPKoaIITz+E3QYHxJ+yo27uQtX2BlmzG4PjyXHWp7XDQGB1NRyGttm6eGPE02nLBx+Hg== Delivered-To: bind9-bugs@bugs.isc.org X-Google-Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:organization:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=gf//H3H1bsa8bomb/9upJRvOb5Qd+eQ9/Uf2n56tE7w=; b=rIOdWwA8NVw/lC2DtOni3tflRyEe0o68P5fU0zTclL9HB5t6wT7sQNuoFpSqNJxY/U HOtaYhqiTVNYQKEpqGXYg5GQu6Pa1Q3DqRUT7b9WYeoslVekNvk2L4J80Q7XY/z7P6op uTFlEQtoGxxth2Nuzkqa9AndWt4EIteXujX64BG5xoPyA3JyU3QFEbEaFRXsVw5RlNAd XDLgOrU4V+M12IDpqk73eXbQE0BXxDozHctf3xKgV7OWjEjM3c+QUGOm9WBWfBdrqoYg fzKvo4Pn49I6ixlLYaS7ihla/s7euYEVSGVIf0hfEP7rDBNvskjFU5X75FrfU73m0e2L Z/XQ== Content-Transfer-Encoding: 7bit X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mx.pao1.isc.org X-Received: by 10.36.61.205 with SMTP id n196mr49121282itn.95.1517594173220; Fri, 02 Feb 2018 09:56:13 -0800 (PST) From nneul@mst.edu Fri Feb 2 17:56:16 2018 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Dkim-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mst.edu; s=google; h=to:from:subject:organization:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=gf//H3H1bsa8bomb/9upJRvOb5Qd+eQ9/Uf2n56tE7w=; b=fV87gCApdupbHdQDoqBsmYf2NZ+CHbLOxUMVArkubjjLTEibsg1SLrSrkyS+JZhE+l 1gqati+hJS7+loOUDkD6uAVGOtZbNLYSr4xl8fla5jUqH+VhD0FmxTLPm0PRI3ub8ChD FtRNuiUtH+DbKZ7B5OQRWCXwq2LqIN/3aLbwk= X-GM-Message-State: AKwxytceZJUN5MzDi7pITk0sSy7zpLDQqYw8G4Ccj4U43uH8ly4rxAK0 hOYgdnAuTyyaFoZkwgmgpVbgNeU1 X-RT-Original-Encoding: utf-8 X-RT-Interface: Email Content-Length: 1448 Scenario: Recursive resolver host that is either A) Authoritative master for zones srv.example.com and example.com B) Authoritative ixfr slave for zones srv.example.com and example.com With 9.11, a lookup of 'service.example.com' that is a cname to 'server.srv.example.com' will return the cname and the A record. With 9.12, it returns only the cname, expecting the client system to do the recursion to the second zone. I can understand this new behavior on a normal master server for multiple zones - since that should not be getting queried by clients that don't do their own recursive lookups. However, for a server that has recursion enabled - it shouldn't be sending back a partial response like this and expecting the client system to do the recursion since that will break any normal desktop client system. Another way of looking at it would be if I had a recursive-only (no slave zones) server - it would work fine. The moment I enhance that recursive server by giving it a full authoritative copy of the zones - it breaks. If the expectation/statement going forward is that a bind 9.12 recursive server cannot also be authoritative slave, then that should be called out much more blatantly in release notes. -- Nathan ------------------------------------------------------------ Nathan Neulinger nneul@mst.edu Missouri S&T Information Technology (573) 612-1412 System Administrator - Architect