Re: Answers from subzone even when superzone has a delegation elsewhere
Additionally this behaviour is specified in RFC1034 so every nameserver should do this. -- Mark Andrews > On 14 Feb 2024, at 02:24, Friesen, Don CITZ:EX via bind-users > wrote: > > Andy, > The existence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa as an > authoritative zone on the server has higher relevance than the delegation > inside another zone. The answer comes from the authoritative zone, no need > to follow the delegation. > > Don Friesen > > -Original Message- > From: bind-users On Behalf Of Andy Smith > Sent: Tuesday, February 13, 2024 6:46 AM > To: bind-users@lists.isc.org > Subject: Re: Answers from subzone even when superzone has a delegation > elsewhere > > [You don't often get email from a...@strugglers.net. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > > [EXTERNAL] This email came from an external source. Only open attachments or > links that you are expecting from a known sender. > > > Hi Don, > > Yes. > > If you want actual names to look at, these zones are both present on the same > servers: > >1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa > 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa > > However, the presence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa is a > mistake and in the mean time someone has changed the delegation inside > 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa to be: > > 8.f.0.f NS ns-auto.bitfolk.com. > > A query for, say: > > 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa. IN > PTR > > is answered NXDOMAIN because it does not exist inside the > 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa zone file, instead of following that > delegation to ns-auto.bitfolk.com. > > Thanks, > Andy > >> On Tue, Feb 13, 2024 at 02:31:32PM +, Friesen, Don CITZ:EX via >> bind-users wrote: >> Andy, You do also have the A record glue for elsewhere.example.com in the >> example.com zone, right? Just checking. >> >> Don Friesen > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Answers from subzone even when superzone has a delegation elsewhere
Andy, The existence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa as an authoritative zone on the server has higher relevance than the delegation inside another zone. The answer comes from the authoritative zone, no need to follow the delegation. Don Friesen -Original Message- From: bind-users On Behalf Of Andy Smith Sent: Tuesday, February 13, 2024 6:46 AM To: bind-users@lists.isc.org Subject: Re: Answers from subzone even when superzone has a delegation elsewhere [You don't often get email from a...@strugglers.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] [EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender. Hi Don, Yes. If you want actual names to look at, these zones are both present on the same servers: 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa However, the presence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa is a mistake and in the mean time someone has changed the delegation inside 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa to be: 8.f.0.f NS ns-auto.bitfolk.com. A query for, say: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa. IN PTR is answered NXDOMAIN because it does not exist inside the 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa zone file, instead of following that delegation to ns-auto.bitfolk.com. Thanks, Andy On Tue, Feb 13, 2024 at 02:31:32PM +, Friesen, Don CITZ:EX via bind-users wrote: > Andy, You do also have the A record glue for elsewhere.example.com in the > example.com zone, right? Just checking. > > Don Friesen -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Answers from subzone even when superzone has a delegation elsewhere
Hi Don, Yes. If you want actual names to look at, these zones are both present on the same servers: 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa However, the presence of 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa is a mistake and in the mean time someone has changed the delegation inside 1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa to be: 8.f.0.f NS ns-auto.bitfolk.com. A query for, say: 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa. IN PTR is answered NXDOMAIN because it does not exist inside the 8.f.0.f.1.f.1.0.8.a.b.0.1.0.0.2.ip6.arpa zone file, instead of following that delegation to ns-auto.bitfolk.com. Thanks, Andy On Tue, Feb 13, 2024 at 02:31:32PM +, Friesen, Don CITZ:EX via bind-users wrote: > Andy, You do also have the A record glue for elsewhere.example.com in the > example.com zone, right? Just checking. > > Don Friesen -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Answers from subzone even when superzone has a delegation elsewhere
Yes, that's normal and expected. The server would not know if the zone is delegated to it or not, so it responds to queries for zones that are hosted (configured) on that server. Ondřej -- Ondřej Surý (He/Him) ond...@isc.org My working hours and your working hours may be different. Please do not feel obligated to reply outside your normal working hours. > On 13. 2. 2024, at 15:23, Andy Smith wrote: > > Hi, > > I'm running: > > 9.16.44-Debian (Extended Support Version) > > If I have zones example.com and sub.example.com both loaded, but > example.com contains a record: > > sub.example.com. NS elsewhere.example.com. > > (i.e. the subzone is delegated to some other server) > > is it normal and expected that a query for foo.sub.example.com > should be answered NXDOMAIN from the auth servers for example.com > because the zone sub.example.com is also loaded there (and has no > "foo" RR), rather than the delegation to elsewhere.example.com be > followed? > > If that is expected, is there configuration that can alter that > behaviour, or is that RFC required behaviour that should not be > altered? > > Thanks, > Andy > -- > Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from > this list > > ISC funds the development of this software with paid support subscriptions. > Contact us at https://www.isc.org/contact/ for more information. > > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Answers from subzone even when superzone has a delegation elsewhere
Andy, You do also have the A record glue for elsewhere.example.com in the example.com zone, right? Just checking. Don Friesen -Original Message- From: bind-users On Behalf Of Andy Smith Sent: Tuesday, February 13, 2024 6:23 AM To: bind-users@lists.isc.org Subject: Answers from subzone even when superzone has a delegation elsewhere [You don't often get email from a...@strugglers.net. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] [EXTERNAL] This email came from an external source. Only open attachments or links that you are expecting from a known sender. Hi, I'm running: 9.16.44-Debian (Extended Support Version) If I have zones example.com and sub.example.com both loaded, but example.com contains a record: sub.example.com. NS elsewhere.example.com. (i.e. the subzone is delegated to some other server) is it normal and expected that a query for foo.sub.example.com should be answered NXDOMAIN from the auth servers for example.com because the zone sub.example.com is also loaded there (and has no "foo" RR), rather than the delegation to elsewhere.example.com be followed? If that is expected, is there configuration that can alter that behaviour, or is that RFC required behaviour that should not be altered? Thanks, Andy -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
