Breaking change between 9.16.20 and 9.16.21 (check-names) ?

[Thib D]

Hello,

I am currently rolling the 9.16.21 on a few bind servers. Most of the
servers rolled the update correctly except for one in particular (this is a
primary server of 2 other secondaries).

Here is the issue logged

Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from
master file [...] failed: bad owner name (check-names)
Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from
master file [...] failed: bad owner name (check-names)


I am aware of the issues with these zone configuration, this is why my
named.conf has this parameter, which I believe is useful to tell named to
keep loading the affected zone and log an issue, am I correct ?

check-names master warn;

Correct me if I'm wrong the 9.16.21 CHANGES do not mention any change on
this behaviour ? More surprisingly, it's only affecting one particular
server, one with a pretty similar config than the others on the zone load
policies.

Did I miss something in the changelog here ?

Thanks !
___
Please 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: Breaking change between 9.16.20 and 9.16.21 (check-names) ?

[Ondřej Surý]

Hi,

we cannot really help you if anonymize everything and don’t provide any details 
at all.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 23. 9. 2021, at 10:54, Thib D  wrote:
> 
> Hello,
> 
> I am currently rolling the 9.16.21 on a few bind servers. Most of the servers 
> rolled the update correctly except for one in particular (this is a primary 
> server of 2 other secondaries).
> 
> Here is the issue logged
> 
> Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from 
> master file [...] failed: bad owner name (check-names)
> Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from 
> master file [...] failed: bad owner name (check-names)
> 
> I am aware of the issues with these zone configuration, this is why my 
> named.conf has this parameter, which I believe is useful to tell named to 
> keep loading the affected zone and log an issue, am I correct ?
> 
> check-names master warn;
> 
> Correct me if I'm wrong the 9.16.21 CHANGES do not mention any change on this 
> behaviour ? More surprisingly, it's only affecting one particular server, one 
> with a pretty similar config than the others on the zone load policies.
> 
> Did I miss something in the changelog here ? 
> 
> Thanks !
> 
> 
> ___
> Please 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

___
Please 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: CNAME query

[Sonal Pahuja]

Can some one please help me on this

From: Sonal Pahuja
Sent: Thursday, September 23, 2021 10:26:48 AM
To: bind-users@lists.isc.org 
Subject: CNAME query


Hi All,



We are sending a CNAME query but currently we don’t have any CNAME record, just 
have NS info.

What should be the Bind9 response for this CNAME query? Will it return NS 
Record in Authority/Answer section?



Regards,

Sonal
___
Please 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: CNAME query

[Anand Buddhdev]

Sonal,

How do you expect anyone to help you when you ask such a vague question? 
If you want help, the least you can do is ask a question properly. It 
only takes 2 more minutes to describe a situation more accurately, so 
please stop taking shortcuts, and try again, with a more detailed 
question, because we cannot read your mind.


Anand

On 23/09/2021 13:36, Sonal Pahuja wrote:


Can some one please help me on this

From: Sonal Pahuja
Sent: Thursday, September 23, 2021 10:26:48 AM
To: bind-users@lists.isc.org 
Subject: CNAME query

Hi All,

We are sending a CNAME query but currently we don’t have any CNAME record, just 
have NS info.

What should be the Bind9 response for this CNAME query? Will it return NS 
Record in Authority/Answer section?

___
Please 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: CNAME query

[Phill Twiss]

+1


you set two forwarders ( possibly the same machine )


On 23/09/2021 7:47 pm, Anand Buddhdev wrote:

Sonal,

How do you expect anyone to help you when you ask such a vague 
question? If you want help, the least you can do is ask a question 
properly. It only takes 2 more minutes to describe a situation more 
accurately, so please stop taking shortcuts, and try again, with a 
more detailed question, because we cannot read your mind.


Anand

On 23/09/2021 13:36, Sonal Pahuja wrote:


Can some one please help me on this

From: Sonal Pahuja
Sent: Thursday, September 23, 2021 10:26:48 AM
To: bind-users@lists.isc.org 
Subject: CNAME query

Hi All,

We are sending a CNAME query but currently we don’t have any CNAME 
record, just have NS info.


What should be the Bind9 response for this CNAME query? Will it 
return NS Record in Authority/Answer section?

___
Please 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

___
Please 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: Breaking change between 9.16.20 and 9.16.21 (check-names) ?

[Thib D]

Hi Ondrej,

Thanks for your reply,

I'm afraid I am unable to share any more detail regarding the zone content
because it's customer data. I will use example.com and try to make the most
sense out of the issue.

Our upgrading procedure is to recompile the binaries provided in
https://ftp.isc.org/isc/bind9/9.16.21/bind-9.16.21.tar.xz , named is
compiled on a Debian Buster OS here.
After the successful compilation, named is restarted (systemd service).

After zones are loaded, a few errors can be seen on zones with these
check-names error

> Sep 23 10:42:07 primary-host named[22788]: general: dbase/m/com/s/
> named.example.com:36: *._sip._tls.example.com: bad owner name
> (check-names)
> Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN:
> loading from master file dbase/m/com/e/named.example.com failed: bad
> owner name (check-names)
> Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN:
> not loaded due to errors.
>

This causes our server to answer SERVFAIL for a few of the affected zones.

At line 36 of the zonefile of example.com, there is this record (under
*example.com
 *origin) :

*._sip._tls A 12.34.56.78


On the secondary server hosting that same zone, I am not seeing any unusual
behaviour after 9.16.21 upgrade:

Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:20: _tcp.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:22: *._tcp.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:25: *._sipfederationtls._tcp.example.com: bad owner
> name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:27: _tls.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:29: *._tls.example.com: bad owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:32: *._sip._tls.example.com: bad owner name
> (check-names)
>

Note that the content of the zone is a bit different, since AXFR does alter
the zone format a little bit (both version "read" the same though (?))

> $ORIGIN _sip._tls.example.com
> * A 12.34.56.78
>

I guess this is a wrong kind of record here,but fine, since I'm not able to
fix these, I'm using the option I mentioned earlier :

check-names master warn;


After seeing this the first time, I decided to rollback to 9.16.20
following the same procedure, which is first compile then restart with
systemd.
After loading all the zones we can see that the "loading from master file
dbase/m/com/e/named.example.com failed" is gone and the zone loaded, just
like on secondary-host:


> Sep 23 10:42:35 primary-host named[22788]: general: dbase/m/com/s/
> named.example.com:36: *._sip._tls.example.com: bad owner name
> (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:38: *._tcp.example.com: bad owner name (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:39: *._tls.example.com: bad owner name (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:51: _tcp.example.com: bad owner name (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:52: _tls.example.com: bad owner name (check-names)


First thing I had in mind was to double check the changelog to see if I
misunderstood anything.

Then, I tried switching from

> check-names master warn;

to

> check-names primary warn;

or

> check-names master ignore;


but nothing changed.

Hope that helps, even with the anonymized data. I understand running zones
configured like this is not quite recommended, but that's a different topic.
I will update this mail thread if I find anything else worth mentioning.

Regards,
Thibaud



Le jeu. 23 sept. 2021 à 11:47, Ondřej Surý  a écrit :

> Hi,
>
> we cannot really help you if anonymize everything and don’t provide any
> details at all.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> > On 23. 9. 2021, at 10:54, Thib D  wrote:
> >
> > Hello,
> >
> > I am currently rolling the 9.16.21 on a few bind servers. Most of the
> servers rolled the update correctly except for one in particular (this is a
> primary server of 2 other secondaries).
> >
> > Here is the issue logged
> >
> > Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from
> master file [...] failed: bad owner name (check-names)
> > Sep 23 10:42:07 host named[22788]: zoneload: zone [...]/IN: loading from
> master file [...] failed: bad owner name (check-names)
> >
> > I am aware of the issues with these zone configuration, this is why my
> named.conf has this parameter, which I believe is useful to te

Re: CNAME query

[Danilo Godec via bind-users]

Don't know if that helps, but if I query my local Bind DNS for a CNAME,
that doesn't exists, dig gives me the SOA record:


> dig cname nonexisting.example.com @mydns

; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22683
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nonexisting.example.com. IN  CNAME

;; AUTHORITY SECTION:
example.com.  600 IN  SOA mydns.example.com. 
hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800

;; Query time: 0 msec
;; SERVER: mydns#53(mydns)
;; WHEN: thu sep 23 13:50:00 CEST 2021
;; MSG SIZE  rcvd: 100




Obviously I replaced my real domain with 'example.com'...



  Regards,

   Danilo






On 23. 09. 21 13:36, Sonal Pahuja wrote:
> Can some one please help me on this
> 
> *From:* Sonal Pahuja
> *Sent:* Thursday, September 23, 2021 10:26:48 AM
> *To:* bind-users@lists.isc.org 
> *Subject:* CNAME query
>  
>
> Hi All,
>
>  
>
> We are sending a CNAME query but currently we don’t have any CNAME
> record, just have NS info.
>
> What should be the Bind9 response for this CNAME query? Will it return
> NS Record in Authority/Answer section?
>
>  
>
> Regards,
>
> Sonal
>
>
> ___
> Please 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


-- 
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@example.com  | T: +386
(0)2 421 61 31 | F: +386 (0)2 420 06 90
Agenda OpenSystems  | Največji slovenski
odprtokodni integrator
Red Hat v Sloveniji  | Red Hat Premier Business
Partner
ElasticBox  | Poslovne rešitve v oblaku
Agenda d.o.o. 
Izjava o omejitvi odgovornosti / Legal disclaimer statement


___
Please 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: [External] : Re: CNAME query

[Sonal Pahuja]

Thanks a lot Danilo for understanding my query! This is what i was looking for!

From: bind-users  on behalf of Danilo Godec 
via bind-users 
Sent: Thursday, September 23, 2021 17:27
To: bind-users@lists.isc.org
Subject: [External] : Re: CNAME query


Don't know if that helps, but if I query my local Bind DNS for a CNAME, that 
doesn't exists, dig gives me the SOA record:



> dig cname nonexisting.example.com @mydns

; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22683
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;nonexisting.example.com. IN  CNAME

;; AUTHORITY SECTION:
example.com.  600 IN  SOA mydns.example.com. 
hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800

;; Query time: 0 msec
;; SERVER: mydns#53(mydns)
;; WHEN: thu sep 23 13:50:00 CEST 2021
;; MSG SIZE  rcvd: 100



Obviously I replaced my real domain with 'example.com'...



  Regards,

   Danilo






On 23. 09. 21 13:36, Sonal Pahuja wrote:
Can some one please help me on this

From: Sonal Pahuja
Sent: Thursday, September 23, 2021 10:26:48 AM
To: bind-users@lists.isc.org 

Subject: CNAME query


Hi All,



We are sending a CNAME query but currently we don’t have any CNAME record, just 
have NS info.

What should be the Bind9 response for this CNAME query? Will it return NS 
Record in Authority/Answer section?



Regards,

Sonal



___
Please 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



--
Danilo Godec | Sistemska podpora / System Administration
AGENDA d.o.o. | Ul. Pohorskega bataljona 49, Sl-2000 Maribor
E: danilo.go...@example.com  | T: +386 (0)2 421 
61 31 | F: +386 (0)2 420 06 90
Agenda OpenSystems 

 | Največji slovenski odprtokodni integrator
Red Hat v Sloveniji 

 | Red Hat Premier Business Partner
ElasticBox 

 | Poslovne rešitve v oblaku
[Agenda d.o.o.] 

Izjava o omejitvi odgovornosti / Legal disclaimer statement 

___
Please 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: Breaking change between 9.16.20 and 9.16.21 (check-names) ?

[Ondřej Surý]

Hi Thib,

thanks, this is much better and I can now safely say, this has been already 
reported and tracked as https://gitlab.isc.org/isc-projects/bind9/-/issues/2911

The only thing weird is:

> Then, I tried switching from
> check-names master warn;
> to
> check-names primary warn;


This should be the right workaround at this moment, so I wonder why it didn’t 
work.

Ondrej
--
Ondřej Surý (He/Him)
ond...@isc.org

> On 23. 9. 2021, at 13:51, Thib D  wrote:
> 
> Hi Ondrej, 
> 
> Thanks for your reply,
> 
> I'm afraid I am unable to share any more detail regarding the zone content 
> because it's customer data. I will use example.com and try to make the most 
> sense out of the issue.
> 
> Our upgrading procedure is to recompile the binaries provided in 
> https://ftp.isc.org/isc/bind9/9.16.21/bind-9.16.21.tar.xz , named is compiled 
> on a Debian Buster OS here. 
> After the successful compilation, named is restarted (systemd service).
> 
> After zones are loaded, a few errors can be seen on zones with these 
> check-names error
> Sep 23 10:42:07 primary-host named[22788]: general: 
> dbase/m/com/s/named.example.com:36: *._sip._tls.example.com: bad owner name 
> (check-names)
> Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN: 
> loading from master file dbase/m/com/e/named.example.com failed: bad owner 
> name (check-names)
> Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN: not 
> loaded due to errors.
> 
> This causes our server to answer SERVFAIL for a few of the affected zones.
> 
> At line 36 of the zonefile of example.com, there is this record (under 
> example.com origin) :
> 
> *._sip._tls A 12.34.56.78
> 
> On the secondary server hosting that same zone, I am not seeing any unusual 
> behaviour after 9.16.21 upgrade:
> 
> Sep 22 10:53:13 secondary-host named[14330]: general: 
> dbase/s/com/e/named.example.com:20: _tcp.example.com: bad owner name 
> (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: 
> dbase/s/com/e/named.example.com:22: *._tcp.example.com: bad owner name 
> (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: 
> dbase/s/com/e/named.example.com:25: *._sipfederationtls._tcp.example.com: bad 
> owner name (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: 
> dbase/s/com/e/named.example.com:27: _tls.example.com: bad owner name 
> (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: 
> dbase/s/com/e/named.example.com:29: *._tls.example.com: bad owner name 
> (check-names)
> Sep 22 10:53:13 secondary-host named[14330]: general: 
> dbase/s/com/e/named.example.com:32: *._sip._tls.example.com: bad owner name 
> (check-names)
> 
> Note that the content of the zone is a bit different, since AXFR does alter 
> the zone format a little bit (both version "read" the same though (?))
> $ORIGIN _sip._tls.example.com
> * A 12.34.56.78
> 
> I guess this is a wrong kind of record here,but fine, since I'm not able to 
> fix these, I'm using the option I mentioned earlier :
> 
> check-names master warn;
> 
> After seeing this the first time, I decided to rollback to 9.16.20 following 
> the same procedure, which is first compile then restart with systemd.  
> After loading all the zones we can see that the "loading from master file 
> dbase/m/com/e/named.example.com failed" is gone and the zone loaded, just 
> like on secondary-host:
>  
> Sep 23 10:42:35 primary-host named[22788]: general: 
> dbase/m/com/s/named.example.com:36: *._sip._tls.example.com: bad owner name 
> (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: 
> dbase/m/com/s/named.example.com:38: *._tcp.example.com: bad owner name 
> (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: 
> dbase/m/com/s/named.example.com:39: *._tls.example.com: bad owner name 
> (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: 
> dbase/m/com/s/named.example.com:51: _tcp.example.com: bad owner name 
> (check-names)
> Sep 23 10:42:35 primary-host named[24110]: general: 
> dbase/m/com/s/named.example.com:52: _tls.example.com: bad owner name 
> (check-names)
> 
> First thing I had in mind was to double check the changelog to see if I 
> misunderstood anything. 
> 
> Then, I tried switching from
> check-names master warn;
> to
> check-names primary warn;
> or
> check-names master ignore; 
> 
> but nothing changed.
> 
> Hope that helps, even with the anonymized data. I understand running zones 
> configured like this is not quite recommended, but that's a different topic.
> I will update this mail thread if I find anything else worth mentioning.
> 
> Regards,
> Thibaud
> 
> 
> 
> Le jeu. 23 sept. 2021 à 11:47, Ondřej Surý  a écrit :
> Hi,
> 
> we cannot really help you if anonymize everything and don’t provide any 
> details at all.
> 
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
> 
> > On 23. 9. 2021, at 10:54, Thib D  wrote:
> > 
> > Hello,
> > 
> > I am currently rolling the 9.16.2

Re: CNAME query

[Havard Eidnes via bind-users]

> Don't know if that helps, but if I query my local Bind DNS for a CNAME,
> that doesn't exists, dig gives me the SOA record:
>
>> dig cname nonexisting.example.com @mydns
>
> ; <<>> DiG 9.16.6 <<>> cname nonexisting.example.com @mydns
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 22683
> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 4096
> ;; QUESTION SECTION:
> ;nonexisting.example.com. IN  CNAME
>
> ;; AUTHORITY SECTION:
> example.com.  600 IN  SOA mydns.example.com. 
> hostmaster.mydns.example.com. 2020042504 86400 3600 604800 604800
>
> ;; Query time: 0 msec
> ;; SERVER: mydns#53(mydns)
> ;; WHEN: thu sep 23 13:50:00 CEST 2021
> ;; MSG SIZE  rcvd: 100

More importantly, perhaps, is that it returns NXDOMAIN status,
which indicates that "the name that you queried for does not
exist" -- in other words, there doesn't exists any other resource
records (of a different type) at the queried-for name, and there
doesn't exist any data "below" the queried-for name either.

Furthermore, the response has the 'aa' flag set, indicating an
"authoritative answer".  This means that the answer came from a
name server which is set up to serve queries for the enclosing
zone (i.e. it didn't come from a cache on a recursive resolver).

The SOA record in the authority section basically says from which
zone the negative response originates, and the "minimum" value in
the SOA record indicates to a caching recursive resolver how long
it ought to cache the information that the queried-for name
doesn't exist (so that negative answers can be provided from the
cache instead of having to bother one of the publishing name
servers for the zone each time).

Lastly, there is no DNSSEC validation being performed (no "ad"
for "authentic data" asserted as a flag), and since the query
wasn't done with "+do" flag ("DNSSEC OK"), no DNSSEC records are
returned (even if they existed).


If, on the other hand, you had queried

dig cname example.com @mydns

you would in all probability get

1) an answer with "status: NOERROR", because the queried-for name
*does* exist in the name tree, as there exists other record types
at the queried-for name, just no CNAME records (which is natural,
since CNAME cannot legally coexist with other record types at the
same name, and at the top of the zone you must have SOA and NS
records).

2) an SOA record in the authority section, as above.

3) the 'aa' flag set again, as above.

4) no DNSSEC processing etc., as above.


Best regards,

- Håvard
___
Please 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: bind9 forwarder query

[Matus UHLAR - fantomas]

On 23.09.21 06:18, Sonal Pahuja wrote:

We have configured a forward zone in bind9  for e164.arpa and in forwarders we 
are giving 2 IPs.
Just wanted to know the mechanism/routing/ Load balancing policy by which bind9 
forwarding to different IPs.




I can see sometimes it routes to same IP always, sometime it forward it in 
round robin way.


bind keeps track of servers that responds fastest and periodically rechecks
the rest.
it's called SRTT algorithm, web search should give some explanations.
--
Matus UHLAR - fantomas, uh...@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.
Nothing is fool-proof to a talented fool.
___
Please 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: How to measure use of forwarders?

[Tony Finch]

Parkin, Richard (R.)  wrote:
>
> I’d like to understand how much traffic is flowing to each forwarder
> (QPS, etc) and monitor that for any issues.  Is there a way to do that
> effectively in Bind without putting some kind of network device on the
> outbound path to measure it?  If not, does anyone have any suggestions?

One option is dnstap, though you will need to do your own scripting to get
the numbers you are interested in. You can configure dnstap to log only
forwarded queries so it doesn't have to drink the whole firehose.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Irish Sea, Shannon: West or southwest 4 to 6. Moderate or rough in
Shannon, slight or moderate in Irish Sea. Occasional drizzle. Good
occasionally poor.
___
Please 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: Breaking change between 9.16.20 and 9.16.21 (check-names) ?

[Thib D]

> This should be the right workaround at this moment, so I wonder why it
didn’t work.

It seems like it does after all, I messed up my checks. Thanks.

However our procedure runs named-checkconf before restarting named, and no
error is brought up when running it, I'm guessing this should be mentioned
that the use of master/slave [in this specific option] is obsolete?

Should I also anticipate moving all of the master/slave options from the
zone configuration asap?

Thanks,

Thibaud


Le jeu. 23 sept. 2021 à 14:41, Ondřej Surý  a écrit :

> Hi Thib,
>
> thanks, this is much better and I can now safely say, this has been
> already reported and tracked as
> https://gitlab.isc.org/isc-projects/bind9/-/issues/2911
>
> The only thing weird is:
>
> > Then, I tried switching from
> > check-names master warn;
> > to
> > check-names primary warn;
>
>
> This should be the right workaround at this moment, so I wonder why it
> didn’t work.
>
> Ondrej
> --
> Ondřej Surý (He/Him)
> ond...@isc.org
>
> > On 23. 9. 2021, at 13:51, Thib D  wrote:
> >
> > Hi Ondrej,
> >
> > Thanks for your reply,
> >
> > I'm afraid I am unable to share any more detail regarding the zone
> content because it's customer data. I will use example.com and try to
> make the most sense out of the issue.
> >
> > Our upgrading procedure is to recompile the binaries provided in
> https://ftp.isc.org/isc/bind9/9.16.21/bind-9.16.21.tar.xz , named is
> compiled on a Debian Buster OS here.
> > After the successful compilation, named is restarted (systemd service).
> >
> > After zones are loaded, a few errors can be seen on zones with these
> check-names error
> > Sep 23 10:42:07 primary-host named[22788]: general: dbase/m/com/s/
> named.example.com:36: *._sip._tls.example.com: bad owner name
> (check-names)
> > Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN:
> loading from master file dbase/m/com/e/named.example.com failed: bad
> owner name (check-names)
> > Sep 23 10:42:07 primary-host named[22788]: zoneload: zone example.com/IN:
> not loaded due to errors.
> >
> > This causes our server to answer SERVFAIL for a few of the affected
> zones.
> >
> > At line 36 of the zonefile of example.com, there is this record (under
> example.com origin) :
> >
> > *._sip._tls A 12.34.56.78
> >
> > On the secondary server hosting that same zone, I am not seeing any
> unusual behaviour after 9.16.21 upgrade:
> >
> > Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:20: _tcp.example.com: bad owner name (check-names)
> > Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:22: *._tcp.example.com: bad owner name (check-names)
> > Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:25: *._sipfederationtls._tcp.example.com: bad owner
> name (check-names)
> > Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:27: _tls.example.com: bad owner name (check-names)
> > Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:29: *._tls.example.com: bad owner name (check-names)
> > Sep 22 10:53:13 secondary-host named[14330]: general: dbase/s/com/e/
> named.example.com:32: *._sip._tls.example.com: bad owner name
> (check-names)
> >
> > Note that the content of the zone is a bit different, since AXFR does
> alter the zone format a little bit (both version "read" the same though (?))
> > $ORIGIN _sip._tls.example.com
> > * A 12.34.56.78
> >
> > I guess this is a wrong kind of record here,but fine, since I'm not able
> to fix these, I'm using the option I mentioned earlier :
> >
> > check-names master warn;
> >
> > After seeing this the first time, I decided to rollback to 9.16.20
> following the same procedure, which is first compile then restart with
> systemd.
> > After loading all the zones we can see that the "loading from master
> file dbase/m/com/e/named.example.com failed" is gone and the zone loaded,
> just like on secondary-host:
> >
> > Sep 23 10:42:35 primary-host named[22788]: general: dbase/m/com/s/
> named.example.com:36: *._sip._tls.example.com: bad owner name
> (check-names)
> > Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:38: *._tcp.example.com: bad owner name (check-names)
> > Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:39: *._tls.example.com: bad owner name (check-names)
> > Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:51: _tcp.example.com: bad owner name (check-names)
> > Sep 23 10:42:35 primary-host named[24110]: general: dbase/m/com/s/
> named.example.com:52: _tls.example.com: bad owner name (check-names)
> >
> > First thing I had in mind was to double check the changelog to see if I
> misunderstood anything.
> >
> > Then, I tried switching from
> > check-names master warn;
> > to
> > check-names primary warn;
> > or
> > check-names mas

Re: CNAME query

[Tony Finch]

Sonal Pahuja  wrote:
>
> We are sending a CNAME query but currently we don't have any CNAME
> record, just have NS info. What should be the Bind9 response for this
> CNAME query? Will it return NS Record in Authority/Answer section?

In general, applications should not make CNAME queries because then they
have to implement their own CNAME-chasing logic which is fraught with
peril. Instead they should query for the final type the application needs,
and let the DNS server handle CNAMEs. (In fact, DNS resolvers also should
not make CNAME queries if they are looking for another type.)

If you query for CNAME at a delegation point, the result you get depends:

  * If the server is authoritative for the parent zone, but not the child
zone, and does not offer recursive service, you will get a referral in
response.

  * If it is a recursive server, and your query has RD=1 (recursion
desired) you should get a NODATA/NOERROR response from the child zone.
The exact contents of the response can depend on the server's
implementation and/or configuration; see RFC 2308 for details.

  * If it is a recursive server, and your query has RD=0, then the
response will depend on the contents of the server's cache.

Tony.
-- 
f.anthony.n.finchhttps://dotat.at/
Humber, Thames: West 4 to 6, occasionally 7 at first in Humber. Slight
or moderate, occasionally rough. Showers. Good.

___
Please 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

how/why the kernel is "routing" incoming packets to a specific core

[rams]

Hi,
I am using bind 9.16.21 on ubuntu. When I am running dnsperf against that,
always load is going one CPU core, because of this issue, I am seeing less
QPS. Has anyone faced the same issue? Could you please someone look into
this and help me with this?

Regards,
Ramesh
___
Please 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

CPU core load not distributing with bind 9.16.21

[rams]

Hi,
I am using bind 9.16.21 on ubuntu. When I am running dnsperf against that,
always load is going one CPU core, because of this issue, I am seeing less
QPS. Has anyone faced the same issue? Could you please someone look into
this and help me with this?

Regards,
Ramesh
___
Please 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