Path: csiph.com!news.uzoreto.com!news.etla.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!not-for-mail From: pvs Newsgroups: comp.protocols.dns.bind Subject: Algorithm compatibility between BIND 9.6.2 and 9.16 Date: Wed, 5 Aug 2020 14:13:41 +0530 Lines: 61 Approved: bind-users@lists.isc.org Message-ID: References: <2dada4b9-3f0b-9877-d3a1-ef11461b7c9c@cdot.in> NNTP-Posting-Host: lists.isc.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: usenet.stanford.edu 1596617062 30333 149.20.1.60 (5 Aug 2020 08:44:22 GMT) X-Complaints-To: action@cs.stanford.edu To: bind-users@lists.isc.org Return-Path: X-Original-To: bind-users@lists.isc.org Delivered-To: bind-users@lists.isc.org DKIM-Filter: OpenDKIM Filter v2.11.0 sandesh.cdot.in 2D21D30E93112 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cdot.in; s=default; t=1596617026; bh=nwHKZgUBPHRfNRd9qv2XBf2SKYjEjXdGSDtx5X3G7bU=; h=To:From:Subject:Date:From; b=Xopw6I9fzyLbBhzuoqvypSpXrohFLcVW8TLqHCcFOQCs6TDqGZy++7CRgCQrVc+uY v2rOuTixp56FlofrzZrM3N2zSGutonUS7OcKMQv3t2Dpi8Ji8LHEOUgUDPw1EGDcw8 yC7Yo1pwkaYFPeHxn/COHX0sVcTcBQhyueKPz6OI= User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 Content-Language: en-GB X-Spam-Status: No, score=0.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, KAM_NUMSUBJECT,SPF_HELO_NONE,SPF_PASS autolearn=disabled version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on mx.pao1.isc.org X-BeenThere: bind-users@lists.isc.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BIND Users Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Mailman-Original-Message-ID: <2dada4b9-3f0b-9877-d3a1-ef11461b7c9c@cdot.in> Xref: csiph.com comp.protocols.dns.bind:16036 Hello, I am new to BIND installation and configuration. We have been using a set of BIND 9.6.2 servers (one is master & other=20 one is slave) running on Fedora Core 10 with algorithm as 'hmac-md5'=C2=A0= =20 for transferring zones and other DNS related data between Master-Slave.=20 These BIND 9.6.2 server set was installed and configured by my=20 predecessors for the domain 'example.com'(let us say) Our domain got changed recently to 'example.in' and and i setup newly=20 released=C2=A0 BIND 9.16 on CentOS 7.6 for this domain as authoritative N= S=20 and is working perfectly without any issues. For somtime we would like maintain both the domains 'example.com' &=20 'example.in' and=C2=A0 planning to configure 'example.com' zone as slave = in=20 the new 9.16 server. I would like to know the support of algorithm 'hmac-md5' in the new=20 release of BIND 9.16 for making the zone tranfer 'example.com' between=20 the old master and new slave. If this algorithm is not supported, please let me know if any work=20 around is possible to make the new BIND 9.16 as slave to 9.6 Any help is greatly appreciated Thanks in advance --=20 Regards, =E0=A4=AA=E0=A4=82. =E0=A4=B5=E0=A4=BF=E0=A4=B7=E0=A5=8D=E0=A4=A3=E0=A5=81= =E0=A4=B6=E0=A4=82=E0=A4=95=E0=A4=B0 P. Vishnu Sankar =E0=A4=9F=E0=A5=80=E0=A4=AE =E0=A4=B2=E0=A5=80=E0=A4=A1=E0=A4=B0 = Team Leader =E0=A4=B8=E0=A5=80-=E0=A4=A1=E0=A5=89=E0=A4=9F C-DOT =E0=A4=87=E0=A4=B2=E0=A5=88=E0=A4=95=E0=A5=8D=E0=A4=9F=E0=A5=8D=E0=A4=B0=E0= =A5=89=E0=A4=A8=E0=A4=BF=E0=A4=95=E0=A5=8D=E0=A4=B8 =E0=A4=B8=E0=A4=BF=E0= =A4=9F=E0=A5=80 =E0=A4=AB=E0=A5=87=E0=A4=9C=E0=A4=BC I Electronics Ci= ty Phase I =E0=A4=B9=E0=A5=8B=E0=A4=B8=E0=A5=82=E0=A4=B0 =E0=A4=B0=E0=A5=8B=E0=A4=A1= =E0=A4=AC=E0=A5=87=E0=A4=82=E0=A4=97=E0=A4=B2=E0=A5=82=E0=A4=B0=E0=A5=81= Hosur Road Bengaluru =E2=80=93 560100 =E0=A4=AB=E0=A5=8B=E0=A4=A8 Ph 91 80 25119466 ------------------------------------------------------ Disclaimer : This email and any files transmitted with it are confidential and intende= d solely for the use of the individual or entity to whom they are address= ed. If you are not the intended recipient you are notified that disclosing, c= opying, distributing or taking any action in reliance on the contents of = this information is strictly prohibited. The sender does not accept liability for any errors or omissions in the c= ontents of this message, which arise as a result.