Path: csiph.com!aioe.org!nntp.terraraq.uk!nntp-feed.chiark.greenend.org.uk!ewrotcd!usenet-its.stanford.edu!usenet.stanford.edu!not-for-mail From: Matus UHLAR - fantomas Newsgroups: comp.protocols.dns.bind Subject: Re: Error "Query section mismatch : got" Date: Fri, 21 Aug 2020 11:40:41 +0200 Lines: 43 Approved: bind-users@lists.isc.org Message-ID: References: <20200819114133.GA6272@fantomas.sk> <20200819144110.GA15085@fantomas.sk> <807AE33D-182E-459A-BEEB-9CE46854548E@isc.org> <20200821094041.GA15298@fantomas.sk> NNTP-Posting-Host: lists.isc.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: usenet.stanford.edu 1598002853 16786 149.20.1.60 (21 Aug 2020 09:40:53 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 X-Authentication-Warning: fantomas.fantomas.sk: uhlar set sender to uhlar@fantomas.sk using -f Mail-Followup-To: bind-users@lists.isc.org Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.10.1 (2018-07-13) X-Spam-Status: No, score=-0.0 required=5.0 tests=SPF_HELO_PASS,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: <20200821094041.GA15298@fantomas.sk> X-Mailman-Original-References: <20200819114133.GA6272@fantomas.sk> <20200819144110.GA15085@fantomas.sk> <807AE33D-182E-459A-BEEB-9CE46854548E@isc.org> Xref: csiph.com comp.protocols.dns.bind:16061 On 21.08.20 09:28, Smile TV wrote: > > my question is why would anyone do this, as this apparently does not make >> sense. >Because when I was from a server that was querying the reverse record >250.199.212.125.in-addr.arpa it gave an error with the "SERVFAIL" error >code so I tried to query directly to the hosting that managed it to >determine the cause. your query of course makes sense under there curcumstances. But delegating /24 subnet using RFC2317 delegation is useless, because in fact you can delegate whole /24 directly >> >> On Wed, Aug 19, 2020 at 7:42 AM Matus UHLAR - fantomas >> >> wrote: >> >>> again, why you query for 250.0-24.199.212.125.in-addr.arpa >> >>> under normal circumstances there's no point of querying that name. >> > On 19.08.20 10:05, tale via bind-users wrote: >> >> Well yes and no. While an individual user would typically not, >> >> resolvers sure will. While trying to resolve >> >> 250.199.212.125.in-addr.arpa, it will eventually get to >> >> 250.199.212.125.in-addr.arpa CNAME 250.0-24.199.212.125.in-addr.arpa. >> > On 20 Aug 2020, at 00:41, Matus UHLAR - fantomas >> > wrote: >> > my question is why would anyone do this, as this apparently does not make >> > sense. >Vào Th 4, 19 thg 8, 2020 vào lúc 22:00 Mark Andrews đã >viết: >> Presumably because they don’t know that APNIC can delegate the /24s that >> make >> up the /17 independently of each other. -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. How does cat play with mouse? cat /dev/mouse