Re: forwarder cache

2022-12-01 Thread Ondřej Surý 

> On 30. 11. 2022, at 22:17, Hamid Maadani  wrote:
> 
> Ondrej, I have not been "withholding" or "censoring" information.

Yes, you were and still are - yet again, you don't give us full picture and
you are guessing what might be wrong.

> Instead of dumping all data on you guys, I have tried to provide targeted 
> information in order to help.

And yet this quickly turned from "why does cache doesn't work" into "I'm 
developing DLZ module and it doesn't work as expected".

> If you and your team find this a "waste of time", feel free to ignore this 
> thread and do not respond.

No, it's a waste of time if you don't tell the whole picture and selectively 
pick information that you think is relevant.

If you want help, don't do that. You don't have to "dump all data", but telling 
the whole story would likely lead to a positive result much quicker. You are 
asking people to help you for free, so you need to do your homework properly.


Now the important part we haven't heard yet...

How do the DNS responses (full messages) from NS2 that are not being cached 
look like?

The DNS messages should roughly look like this:

; <<>> DiG 9.19.5-1+0~20220921.84+debian10~1.gbp190ab0-Debian <<>> +norec -p 
5300 IN A example.nil @10.53.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38535
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: f50707710c959ced01006388d08116eb56fc18db4c07 (good)
;; QUESTION SECTION:
;example.nil.   IN  A

;; ANSWER SECTION:
example.nil.1800IN  A   10.53.0.1

;; AUTHORITY SECTION:
example.nil.3600IN  NS  example.nil.

;; Query time: 0 msec
;; SERVER: 10.53.0.1#5300(10.53.0.1) (UDP)
;; WHEN: Thu Dec 01 17:04:17 CET 2022
;; MSG SIZE  rcvd: 98

This is from the example driver located in the system tests 
(bin/tests/system/dlzexternal/driver).

Ondrej
--
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.

-- 
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: forwarder cache

2022-12-01 Thread Hamid Maadani 
> Yes, you were and still are - yet again, you don't give us full picture and
> you are guessing what might be wrong.> And yet this quickly turned from "why 
> does cache doesn't work" into "I'm developing DLZ module and it doesn't work 
> as expected".
> No, it's a waste of time if you don't tell the whole picture and selectively 
> pick information that you think is relevant.
> If you want help, don't do that. You don't have to "dump all data", but 
> telling the whole story would likely lead to a positive result much quicker. 
> You are asking people to help you for free, so you need to do your homework 
> properly.
You keep accusing me of censorship, like developing a DLZ is military work!
Feels childish at this point. Would be counter productive to keep it up.
> Now the important part we haven't heard yet...
> How do the DNS responses (full messages) from NS2 that are not being cached 
> look like?
Oh yes, let's spill the state secrets.
Here is the answer I get from NS2, which provides data from the DLZ:

/ # dig A test.com -p 153 @127.0.0.1

; <<>> DiG 9.18.9 <<>> A test.com -p 153 @127.0.0.1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 47058
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 615bd381af73601201006388d58f953e68e0a4def2c0 (good)
;; QUESTION SECTION:
;test.com. IN A

;; ANSWER SECTION:
test.com. 0 IN A 10.10.10.10

;; Query time: 114 msec
;; SERVER: 127.0.0.1#153(127.0.0.1) (UDP)
;; WHEN: Thu Dec 01 16:25:51 UTC 2022
;; MSG SIZE rcvd: 82

I can see "AUTHORITY: 0" in the answer, and now I understand NS1 does not cache 
this because of that (did not know only authority 1 answers are cached when I 
sent the initial email. How did you expect me to ask the question in the first 
place? Is that documented somewhere btw?)
My question still stands: shouldn't NS2 answer with AUTHORITY: 1, regardless of 
DLZ or local-file backend, since the definition for the zone is as below?

dlz XDB {
 database "dlopen /usr/lib/bind/dlz_mongodb_mod.so  0";
 search no;
};

zone "test.com" {
 type master;
 dlz XDB;
 allow-query { any; };
};

Regards
Hamid Maadani
-- 
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: forwarder cache

2022-12-01 Thread Ondřej Surý 
> test.com . 0 IN A 10.10.10.10

I think this line just have it all - you are generating record with TTL 0.

> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1


FTR it's an authoritative answer.

Ondrej
--
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.

-- 
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: forwarder cache

2022-12-01 Thread Hamid Maadani 
Hmm.. odd. Understood, let me go fix that.
Appreciate the help.

Regards
Hamid Maadani

December 1, 2022 9:05 AM, "Ondřej Surý" mailto:ond...@isc.org?to=%22Ond%C5%99ej%20Sur%C3%BD%22%20)> 
wrote:
test.com (http://test.com/). 0 IN A 10.10.10.10

I think this line just have it all - you are generating record with TTL 0.

;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

FTR it's an authoritative answer.

Ondrej
--Ondřej Surý (He/Him)ond...@isc.org (mailto: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.
-- 
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: forwarder cache

2022-12-01 Thread Fred Morris 

On Thu, 1 Dec 2022, Hamid Maadani wrote:
[...] I can see "AUTHORITY: 0" in the answer, and now I understand NS1 
does not cache this because of that (did not know only authority 1 
answers are cached when I sent the initial email.


Confusion of causes and effects: "AUTHORITY:0" is reportage regarding of 
an artifact of the message over the wire. There are no records in the 
AUTHORITY section, hence this reporting.


[...] My question still stands: shouldn't NS2 answer with AUTHORITY: 1, 
regardless of DLZ or local-file backend, since the definition for the 
zone is as below?


Have we gotten to 20 questions yet? Here's mine:

  Is what's in the "regardless of DLZ or local-file backend" properly
  constituted so that the desired information can be conveyed?

Regarding the preamble to your standing question: you need to figure that 
out. If nothing else, RFCs should help. Comparing the meta contents of a 
working zone to this one: are they the same? By which I mean SOA, NS, 
dnssec...


What does a query against that nameserver for NS records for the zone 
return?


How does a nameserver know if it is authoritative if the copy of the zone 
it relies on (to differentiate from caching) does not list it as 
authoritative? (What is the definition of "authoritative"?) What is a 
server which is caching the result of querying it supposed to do when it 
sees that it is authoritative for that zone? Now, these are good 
questions, can't say I definitively know the answer; I have seen enough to 
know that people come up with notions.


I strongly suggest starting with a configuration for which an analogous 
configuration works, and breaking it from there. What do the contents of 
an "authoritative" zone served by an authoritative server configured 
to return complete 1024/1025 responses look like? Is the server configured 
to return complete responses, and does it have properly constituted zone 
data to do so?


I would expect a server so constituted to be able to answer the following 
questions when queried on port 53:


* What is the SOA?

* An NS response containing:

  * The FQDN of the server;

  * resolving to the address at which it was queried.

You don't even have it queryable on port 53 from what I can tell. (You've
got 2^24 IPv4 loopback addresses to work with, right?)

Have fun arguing about whether or not a server which is "authoritative" 
should have an NS record in the zone, once you have something which 
demonstrably works.


I don't have a lot of patience for "experts" who can't demonstrate a 
working system, so I probably won't be back.


--

Fred Morris, internet plumber

--
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: forwarder cache

2022-12-01 Thread Fred Morris 

Errata..

On Thu, 1 Dec 2022, Fred Morris wrote:
"authoritative" zone served by an authoritative server configured to return 
complete 1024/1025 responses look like?


1034/1035

--

FWM
--
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: forwarder cache

2022-12-01 Thread Hamid Maadani 
> Have fun arguing about whether or not a server which is "authoritative" 
> should have an NS record in the zone, once you have something which 
> demonstrably works.
> I don't have a lot of patience for "experts" who can't demonstrate a working 
> system, so I probably won't be back.

Not sure where I claimed to be an "expert". The whole point is, I am NOT an 
expert, but I am trying to contribute (for free). So I am asking my questions 
from the experts (yes, also for free).
Now, if I am not providing enough information, or have the wrong approach in 
asking my question, it is perfectly fine to ask me to correct my approach, or 
provide more information. Even better, have a guideline somewhere on what basic 
information to provide when asking questions (or point me to it if one exists). 
There is absolutely no need for telling me to stop "withholding" information, 
or "censor" data (!!), or "waste people's time".

We all know Ondrej is a fantastic engineer, and knows this system inside out. 
He has already spotted the error after asking for the right data (which is much 
appreciated). It is fixed and all is working fine now. I see no point in 
continuing this thread, so I probably won't be back either :)

Regards
Hamid Maadani
-- 
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

Ask for help with SERVFAIL

2022-12-01 Thread 张星 
'servfail' exception occurs after BIND runs for a period of time, restart bind 
：servfail does not appear

but，After running for some time, it still had the same 'servfail' problem






#./sbin/named -VBIND 9.11.5 (Extended Support Version) running on 
Linux x86_64 3.10.0-514.26.2.el7.x86_64 #1 SMP Tue Jul 4 15:04:05 UTC 2017built 
by make with '--prefix=/home/bind/' '--enable-filter-' 
'--with-tuning=large' '--enable-largefile' '--enable-threads'compiled by GCC 
4.8.5 20150623 (Red Hat 4.8.5-28)compiled with OpenSSL version: OpenSSL 1.0.2k  
26 Jan 2017linked to OpenSSL version: OpenSSL 1.0.2k-fips  26 Jan 2017compiled 
with zlib version: 1.2.7linked to zlib version: 1.2.7threads support is enabled











-- 
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: Ask for help with SERVFAIL

2022-12-01 Thread Mark Andrews 
The DNS server at 119.29.29.29 is broken.  It does not implement EDNS (RFC 6891)
correctly.  Some of the errors may be due to a misconfigured firewall in front 
of
the server.  This is the section of RFC 6891 the server is not following and it
is designed to allow clients to use options the server does not know about which
allows new options to be deployed without causing problems.  The same with 
ignoring
unknown options in responses.

   Any OPTION-CODE values not understood by a responder or requestor
   MUST be ignored.  Specifications of such options might wish to
   include some kind of signaled acknowledgement.  For example, an
   option specification might say that if a responder sees and supports
   option XYZ, it MUST include option XYZ in its response.

The server is echoing back the unknown option "; COOKIE: 45aac8f8acbe209c 
(echoed)”.
If DNS COOKIE is not supported this should not be present in the response and if
DNS COOKIE is implemented then a server cookie should also be present in the 
response.

It is not ignoring an unknown option 100 when they are added to the request.  
The
request is being dropped.

It is not responding to requests that happen to have both a client and server
cookie present. The expected response if DNS COOKIE is supported is BADCOOKIE,
as this example has a server cookie that did not come from the server being
queried, if DNS COOKIE is supported or no COOKIE option if it is not supported.

Complain to qq.com that they are running non-compliant DNS servers and are 
breaking
DNS interoperability.  You can workaround the issue by telling named to not 
send DNS
COOKIES in its requests.

e.g.
server 119.29.29.29 { send-cookie false; };

Mark

% dig www.qq.com @119.29.29.29 +norec

; <<>> DiG 9.19.6-dev <<>> www.qq.com @119.29.29.29 +norec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53841
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 45aac8f8acbe209c (echoed)
;; QUESTION SECTION:
;www.qq.com.IN  A

;; ANSWER SECTION:
www.qq.com. 60  IN  CNAME   
ins-r23tsuuf.ias.tencent-cloud.net.
ins-r23tsuuf.ias.tencent-cloud.net. 88 IN A 121.14.77.221
ins-r23tsuuf.ias.tencent-cloud.net. 88 IN A 121.14.77.201

;; Query time: 209 msec
;; SERVER: 119.29.29.29#53(119.29.29.29) (UDP)
;; WHEN: Fri Dec 02 15:15:39 AEDT 2022
;; MSG SIZE  rcvd: 131

% dig www.qq.com @119.29.29.29 +norec +qr +ednsopt=100

; <<>> DiG 9.19.6-dev <<>> www.qq.com @119.29.29.29 +norec +qr +ednsopt=100
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32627
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0322cb71fefb91f7
; OPT=100:
;; QUESTION SECTION:
;www.qq.com.IN  A

;; QUERY SIZE: 55

;; communications error to 119.29.29.29#53: timed out
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32627
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0322cb71fefb91f7
; OPT=100:
;; QUESTION SECTION:
;www.qq.com.IN  A

;; QUERY SIZE: 55

;; communications error to 119.29.29.29#53: timed out
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 32627
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 0322cb71fefb91f7
; OPT=100:
;; QUESTION SECTION:
;www.qq.com.IN  A

;; QUERY SIZE: 55

;; communications error to 119.29.29.29#53: timed out
;; no servers could be reached

% dig www.qq.com @119.29.29.29 +norec +qr 
+cookie=57dc9aec153f3647010063897e4ed466568c4ab8742a

; <<>> DiG 9.19.6-dev <<>> www.qq.com @119.29.29.29 +norec +qr 
+cookie=57dc9aec153f3647010063897e4ed466568c4ab8742a
;; global options: +cmd
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54256
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 57dc9aec153f3647010063897e4ed466568c4ab8742a
;; QUESTION SECTION:
;www.qq.com.IN  A

;; QUERY SIZE: 67

;; communications error to 119.29.29.29#53: timed out
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54256
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 57dc9aec153f3647010063897e4ed466568c4ab8742a
;; QUESTION SECTION:
;www.qq.com.IN  A

;; QUERY SIZE: 67

;; communications error to 119.29.29.29#53: timed out
;; Sending:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54256
;; flags: ad; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0