Re: SERVFAIL error during the evening

[Michael Batchelder]

> Hello Michael
> Thank you for your response. Here is a pcap file and some logs.

Hello Sami,

Your pcap shows your resolver making thousands of queries that get no responses 
(or at least the pcap does not contain them). There's not much I can say, 
beyond that this does not appear to be a problem related to BIND. You will need 
to look at your infrastructure and beyond to determine why you are not getting 
responses to your queries.

One possibility may be in your infrastructure/network, where a firewall or 
other stateful inspection device is running out of resources to make additional 
state table entries. You will need to speak with the technical support of that 
device's vendor if you need help in assessing this.

Michael
-- 
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: qname minimization: me too :(

[Peter]

On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
! On Fri, Jun 21, 2024 at 07:03:14AM +,
! 65;6800;1c Michael Batchelder  wrote 
!  a message of 59 lines which said:
! 
! > You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.
! 
! Yes and, if you want the whole context, you can read RFC 8020
!  and section 4 of RFC 7816
! .


Sure, I did that already. And I also talked to the maintainer of
ns*.he.net, i.e. this one:

! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
! >
! > You'll need to fix these zones so that the response is NOERROR rather than 
NXDOMAIN.

And they seem to think, there is nothing wrong with that, because
nobody ever has complained about that.


Now I am really wondering: why do I, an unemployed old guy just
running his own computer, suddenly find myself in between a root
operator and the biggest v6 network on the planet?

In other words: why do You guys no longer talk to each other?


cheerio,
PMc
-- 
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: qname minimization: me too :(

[Mark Andrews]

It’s just a false positive when the result is NXDOMAIN. Because people forget 
to put delegating NS records in parent zones when both are served by the same 
server the lookups continue on NXDOMAIN. There is an issue to address this. 

-- 
Mark Andrews

> On 25 Jun 2024, at 06:36, Peter  wrote:
> 
> On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
> ! On Fri, Jun 21, 2024 at 07:03:14AM +,
> ! 65;6800;1c Michael Batchelder  wrote 
> !  a message of 59 lines which said:
> ! 
> ! > You'll need to fix these zones so that the response is NOERROR rather 
> than NXDOMAIN.
> ! 
> ! Yes and, if you want the whole context, you can read RFC 8020
> !  and section 4 of RFC 7816
> ! .
> 
> 
> Sure, I did that already. And I also talked to the maintainer of
> ns*.he.net, i.e. this one:
> 
> ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
> NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
> ! >
> ! > You'll need to fix these zones so that the response is NOERROR rather 
> than NXDOMAIN.
> 
> And they seem to think, there is nothing wrong with that, because
> nobody ever has complained about that.
> 
> 
> Now I am really wondering: why do I, an unemployed old guy just
> running his own computer, suddenly find myself in between a root
> operator and the biggest v6 network on the planet?
> 
> In other words: why do You guys no longer talk to each other?
> 
> 
> cheerio,
> PMc
> -- 
> 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: qname minimization: me too :(

[Mark Andrews]

I should add that a resolver should be able to stop on the first NXDOMAIN.  
It’s only because we know there are mis-implementations of the protocol 
(returning NXDOMAIN rather that NOERROR for empty non-terminals) and 
mis-configurations (missing delegating NS records) that the default is to 
continue.  If people where willing to put up with NXDOMAIN being returned 
rather than the data that is later found by continuing or not using QNAME 
minimisation the default could be changed.  'But it “works" when I ask Google' 
is a hard thing to fight against.

Mark

> On 25 Jun 2024, at 07:00, Mark Andrews  wrote:
> 
> It’s just a false positive when the result is NXDOMAIN. Because people forget 
> to put delegating NS records in parent zones when both are served by the same 
> server the lookups continue on NXDOMAIN. There is an issue to address this. 
> 
> -- 
> Mark Andrews
> 
>> On 25 Jun 2024, at 06:36, Peter  wrote:
>> 
>> On Fri, Jun 21, 2024 at 04:58:55PM +0200, Stephane Bortzmeyer wrote:
>> ! On Fri, Jun 21, 2024 at 07:03:14AM +,
>> ! 65;6800;1c Michael Batchelder  wrote 
>> !  a message of 59 lines which said:
>> ! 
>> ! > You'll need to fix these zones so that the response is NOERROR rather 
>> than NXDOMAIN.
>> ! 
>> ! Yes and, if you want the whole context, you can read RFC 8020
>> !  and section 4 of RFC 7816
>> ! .
>> 
>> 
>> Sure, I did that already. And I also talked to the maintainer of
>> ns*.he.net, i.e. this one:
>> 
>> ! > The f.1.0.7.4.0.1.0.0.2.ip6.arpa zone (@216.66.80.18) responds with 
>> NXDOMAIN to queries for any QTYPE for QNAME f.1.0.7.4.0.1.0.0.2.ip6.arpa
>> ! >
>> ! > You'll need to fix these zones so that the response is NOERROR rather 
>> than NXDOMAIN.
>> 
>> And they seem to think, there is nothing wrong with that, because
>> nobody ever has complained about that.
>> 
>> 
>> Now I am really wondering: why do I, an unemployed old guy just
>> running his own computer, suddenly find myself in between a root
>> operator and the biggest v6 network on the planet?
>> 
>> In other words: why do You guys no longer talk to each other?
>> 
>> 
>> cheerio,
>> PMc
>> -- 
>> 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

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

-- 
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: SERVFAIL error during the evening

[Michael Batchelder]

>> Hello Michael
>> Thank you for your response. Here is a pcap file and some logs.
> 
> Hello Sami,
>
> Your pcap shows your resolver making thousands of queries that get
> no responses (or at least the pcap does not contain them). There's
> not much I can say, beyond that this does not appear to be a > problem
> related to BIND.

Sami,

My co-worker helpfully pointed out something I missed when reviewing your 
packet capture. A large number of your resolution failures are because your 
BIND is configured to use QNAME minimization (a.k.a. "qmin") and the queries 
are to zones whose configuration is done incorrectly and breaks qmin.

The pcap indicates you have the 'qname-minimization strict' setting in your 
BIND configuration file. See the "qname-minimization" statement in the Options 
section of the BIND ARM 
(https://bind9.readthedocs.io/en/v9.16.25/reference.html#options-statement-definition-and-usage).
 For the general background on qmin, read RFCs 7816 and 9156.

I don't know of a reason why you would experience more qmin failures in the 
evening, other than the requests that fail are only made at that time. 
Regardless, if you want to stop the failures completely, you can change the 
'qname-minimization strict' setting to 'qname-minimization disabled'. The 
drawback is that your queries will no longer be minimized, so all authoritative 
servers will see the full query name during recursion.

As a compromise between doing nothing and fully disabling qmin, you can use the 
'qname-minimization relaxed' setting which will try qmin and if BIND encounters 
a zone which breaks qmin, then BIND will switch to not doing qmin and do normal 
recursion (equivalent to 'qname-minimization disabled') for that query.

Also, you should upgrade your version of BIND, as we can see that the qmin 
queries are those used in older versions of BIND. 

Michael
-- 
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