Re: Question about resolver

[Mark Andrews]

This looks like Google  has forgotten to create the zone 96.34.in-addr.arpa but 
have created
180.96.34.in-addr.arpa resulting in answers that should come from 
96.34.in-addr.arpa getting
REFUSED returned.  DNSSEC validation and QNAME minimisation find these sorts of 
configuration errors.
Intermediate zones can’t be missed.

% dig ns 96.34.in-addr.arpa +trace +all
;; BADCOOKIE, retrying.

; <<>> DiG 9.19.24-dev <<>> ns 96.34.in-addr.arpa +trace +all
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23007
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 14, AUTHORITY: 0, ADDITIONAL: 27

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 7b100d5f1abe6a330100662eea5988229ff2514536e1 (good)
;; QUESTION SECTION:
;. IN NS

;; ANSWER SECTION:
. 274739 IN NS a.root-servers.net.
. 274739 IN NS g.root-servers.net.
. 274739 IN NS h.root-servers.net.
. 274739 IN NS b.root-servers.net.
. 274739 IN NS j.root-servers.net.
. 274739 IN NS i.root-servers.net.
. 274739 IN NS c.root-servers.net.
. 274739 IN NS d.root-servers.net.
. 274739 IN NS l.root-servers.net.
. 274739 IN NS e.root-servers.net.
. 274739 IN NS m.root-servers.net.
. 274739 IN NS k.root-servers.net.
. 274739 IN NS f.root-servers.net.
. 274739 IN RRSIG NS 8 0 518400 2024050821 2024042520 5613 . 
YeVEKbhLW5fUll0QPjIjDWfKbmrnJ/paeh/H86oG17GPeoFRWkecq+iM 
8kjxy28AHg7cElZ3w8Lq0GND+DJUCYItS6cOHdQ07XdEFCPAoXMnVQe2 
sBwd5nRu8tjH/I6NOn43DtfGkNMxzoHZf/64UeWeMFF8tjlD3y9Y+TQ1 
UjBU0kzpsYXkl+QYHsNJ1nABDH3gdlTqpCmtrVA1UUgDjC/12KLSIiQH 
ykSABJZbHnOsDc7OaRH25QLZadE6zrUwP1xiEZuDfe4xuoz2z5WSBQbv 
6JjCGVpm1WDILRra64v4BpO0kVUYE5fvJgAOV2cJwJwhM4gpcBNlMvG7 e3+WFA==

;; ADDITIONAL SECTION:
i.root-servers.net. 169819 IN  2001:7fe::53
d.root-servers.net. 169819 IN  2001:500:2d::d
h.root-servers.net. 169819 IN  2001:500:1::53
j.root-servers.net. 169819 IN  2001:503:c27::2:30
c.root-servers.net. 169819 IN  2001:500:2::c
e.root-servers.net. 169819 IN  2001:500:a8::e
g.root-servers.net. 169819 IN  2001:500:12::d0d
l.root-servers.net. 169819 IN  2001:500:9f::42
m.root-servers.net. 169819 IN  2001:dc3::35
k.root-servers.net. 169819 IN  2001:7fd::1
a.root-servers.net. 169819 IN  2001:503:ba3e::2:30
f.root-servers.net. 169819 IN  2001:500:2f::f
b.root-servers.net. 169819 IN  2801:1b8:10::b
i.root-servers.net. 169819 IN A 192.36.148.17
d.root-servers.net. 169819 IN A 199.7.91.13
h.root-servers.net. 169819 IN A 198.97.190.53
j.root-servers.net. 169819 IN A 192.58.128.30
c.root-servers.net. 169819 IN A 192.33.4.12
e.root-servers.net. 169819 IN A 192.203.230.10
g.root-servers.net. 169819 IN A 192.112.36.4
l.root-servers.net. 169819 IN A 199.7.83.42
m.root-servers.net. 169819 IN A 202.12.27.33
k.root-servers.net. 169819 IN A 193.0.14.129
a.root-servers.net. 169819 IN A 198.41.0.4
f.root-servers.net. 169819 IN A 192.5.5.241
b.root-servers.net. 169819 IN A 170.247.170.2

;; Query time: 0 msec
;; SERVER: ::1#53(::1) (UDP)
;; WHEN: Mon Apr 29 10:31:21 AEST 2024
;; MSG SIZE  rcvd: 1125

;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 39695
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 11, ADDITIONAL: 13

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;96.34.in-addr.arpa. IN NS

;; AUTHORITY SECTION:
in-addr.arpa. 172800 IN NS c.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS f.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS a.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS b.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS e.in-addr-servers.arpa.
in-addr.arpa. 172800 IN NS d.in-addr-servers.arpa.
in-addr.arpa. 86400 IN DS 53696 8 2 
13E5501C56B20394DA921B51412D48B7089C5EB6957A7C58553C4D4D 424F04DF
in-addr.arpa. 86400 IN DS 47054 8 2 
5CAFCCEC201D1933B4C9F6A9C8F51E51F3B39979058AC21B8DF1B1F2 81CBC6F2
in-addr.arpa. 86400 IN DS 63982 8 2 
AAF4FB5D213EF25AE44679032EBE3514C487D7ABD99D7F5FEC3383D0 30733C73
in-addr.arpa. 86400 IN DS 54956 8 2 
E0E2BF5CFBD66572CA05EC18267D91509BA6A9405AF05C3FD4141DFA 45200C08
in-addr.arpa. 86400 IN RRSIG DS 8 2 86400 2024051118 2024042817 43060 
arpa. BBFF1T9b8+woUukDfJj8wBKwDyk2CGVfceNAX5S1LvANDal0g3gf0hFD 
7OhTWZR1yaMoMaLVDgh8b9rDe5gMpOABbCHI/OBByz/rpUgau+XZ5aTJ 
NSJbmBcQRkzelreqm/B+4bjYtn48cK5Lp/iZm7hDHqJ1L/asdF7SRpRc 
BxFQeSf3eOy5BKL/XjlrsGZ510v2bnIlhLZPvjBPinbK10QeXzWOUW3J 
QtsY8MyTl0NE3prBU7bA20bkm+yBn4KMEzWeBz7rYfr6WJoGAw+I2ijM 
J6oC3ims4b1bF7eaPJ4DW6QZJu04a4C/JeluU/RMzWJC11MS2M1RRUf8 /XcxmQ==

;; ADDITIONAL SECTION:
f.in-addr-servers.arpa. 172800 IN A 193.0.9.1
e.in-addr-servers.arpa. 172800 IN A 203.119.86.101
d.in-addr-servers.arpa. 172800 IN A 200.10.60.53
c.in-addr-servers.arpa. 172800 IN A 196.216.169.10
b.in-addr-servers.arpa. 172800 IN A 199.253.183.183
a.in-addr-servers.arpa. 172800 IN A 199.180.182.53
f.in-addr-servers.arpa. 172800 IN  2001:67c:e0::1
e.in-addr-servers.arpa. 172800 IN  2001:dd8:6::101
d.in-addr-servers.arpa. 172800 IN  2001:13c7:7010::53

Re: Question about resolver

[J Doe]

On 2024-04-26 16:45, Josh Kuo wrote:


In this particular case, isn't the resolver attempting to do a reverse
lookup of the IP address that's listed ?


You are right, I missed that this is a reverse-mapping zone. In that
case, run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and
you'll see the problem. Reverse-mapping zones work the same as
forward-mapping zones, they also need to be delegated properly.

If you prefer a more visual output, try DNSViz:
https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/



Hi Josh,

Ok, sounds good!

- J

--
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: Question about resolver

[J Doe]

On 2024-04-26 16:28, Mark Andrews wrote:


DS records live in the parent zone and the RFC 1034 rules for serving zone 
break down when a grandparent zone and child zone are served by the same 
server.  This is corrected be the client by looking for intermediate NS records 
to find the hidden delegations then resuming the DS lookup.

Named was looking up theses NS records I.e. chasing the DS servers.   This can 
result in named finding delegation errors.  QNAME minimisation also exposes 
these errors as it also does NS queries.  Garbage in breakage out.


Hi Mark,

Ah, ok, I believe I've got it now - thanks for you explanation!

- J
--
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: Question about resolver

[Josh Kuo]

>
> In this particular case, isn't the resolver attempting to do a reverse
> lookup of the IP address that's listed ?
>
>
You are right, I missed that this is a reverse-mapping zone. In that case,
run DNSSEC analyzer on the domain "180.96.34.in-addr.arpa" and you'll see
the problem. Reverse-mapping zones work the same as forward-mapping zones,
they also need to be delegated properly.

If you prefer a more visual output, try DNSViz:
https://dnsviz.net/d/180.96.34.in-addr.arpa/dnssec/
-- 
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: Question about resolver

[Mark Andrews]

DS records live in the parent zone and the RFC 1034 rules for serving zone 
break down when a grandparent zone and child zone are served by the same 
server.  This is corrected be the client by looking for intermediate NS records 
to find the hidden delegations then resuming the DS lookup.  

Named was looking up theses NS records I.e. chasing the DS servers.   This can 
result in named finding delegation errors.  QNAME minimisation also exposes 
these errors as it also does NS queries.  Garbage in breakage out. 
-- 
Mark Andrews

> On 27 Apr 2024, at 00:45, J Doe  wrote:
> 
> On 2024-04-25 08:55, Josh Kuo wrote:
> 
>> DS = Delegation Signer, it is the record type that a signed child upload
>> to the parent zone. It's difficult to say for sure without more
>> information such as which domain name you are trying to resolve, but
>> looks like it is probably due to a mis-matching DS record between the
>> child and the parent (security lameness).
>> 
>> You can use tools such as
>> https://dnssec-analyzer.verisignlabs.com/online
>>  to help you analyze
>> further. If you need to refresh your knowledge on how DNSSEC works, see
>> the ISC DNSSEC Guide:
>> https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html
>> 
>> 
>> -Josh
> 
> Hi Josh,
> 
> Thank you for your prompt reply!
> 
> In this particular case, isn't the resolver attempting to do a reverse
> lookup of the IP address that's listed ?
> 
> Secondly, I'm still not entirely sure what the phrasing "chase DS
> servers" means.  I am aware of the DS RR type.
> 
> As a side-note:  I believe the "lame-servers" here is a function of me
> configuring QNAME minimization to "relaxed".
> 
> Thanks,
> 
> - J
> -- 
> 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: Question about resolver

[J Doe]

On 2024-04-25 08:55, Josh Kuo wrote:


DS = Delegation Signer, it is the record type that a signed child upload
to the parent zone. It's difficult to say for sure without more
information such as which domain name you are trying to resolve, but
looks like it is probably due to a mis-matching DS record between the
child and the parent (security lameness).

You can use tools such as
https://dnssec-analyzer.verisignlabs.com/online
 to help you analyze
further. If you need to refresh your knowledge on how DNSSEC works, see
the ISC DNSSEC Guide:
https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html


-Josh


Hi Josh,

Thank you for your prompt reply!

In this particular case, isn't the resolver attempting to do a reverse
lookup of the IP address that's listed ?

Secondly, I'm still not entirely sure what the phrasing "chase DS
servers" means.  I am aware of the DS RR type.

As a side-note:  I believe the "lame-servers" here is a function of me
configuring QNAME minimization to "relaxed".

Thanks,

- J
--
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: Question about resolver

[Josh Kuo]

DS = Delegation Signer, it is the record type that a signed child upload to
the parent zone. It's difficult to say for sure without more information
such as which domain name you are trying to resolve, but looks like it is
probably due to a mis-matching DS record between the child and the parent
(security lameness).

You can use tools such as https://dnssec-analyzer.verisignlabs.com/online
to help you analyze further. If you need to refresh your knowledge on how
DNSSEC works, see the ISC DNSSEC Guide:
https://bind9.readthedocs.io/en/v9.18.14/dnssec-guide.html

-Josh

On Wed, Apr 24, 2024 at 7:31 PM J Doe  wrote:

> Hello,
>
> I run BIND 9.18.26 as a recursive, validating resolver.  In my logs, I
> noticed the following:
>
>  22-Apr-2024 19:25:59.614 lame-servers: info: chase DS servers
>  resolving '180.96.34.in-addr.arpa/DS/IN': 216.239.34.102#53
>
> What does "chase DS servers" mean ?
>
> Thanks,
>
> - J
> --
> 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: Question about authoritative server and AA Authoritative Answer

[Michel Diemer via bind-users]

 


‌
Dear Greg,

Björn Persson gave a reply with seems satisfying.

With dig +norecurse I always get "AUTHORITY: 1".

For the sake of comprehensiveness, please find attached the files you asked for.

  
 

De : "Greg Choules" 
A : pub.dieme...@laposte.net,ma...@isc.org,bind-users@lists.isc.org
Envoyé: mercredi 17 Janvier 2024 16:00
Objet : Re: Question about authoritative server and AA Authoritative Answer
 

Hi again.
Please start a packet capture on the auth server. This should do it:

   sudo tcpdump -nvi any -c 1 -w mydns.pcap port 53
Then from pc1, please do these and copy/paste text output, not screenshots:

 

dig @172.16.0.254 pc1.reseau1.lan NS +norecurse





dig @172.16.0.254 pc1.reseau1.lan SOA +norecurse




 



dig @172.16.0.254 pc1.reseau1.lan A +norecurse




dig @172.16.0.254 pc1.reseau1.lan  +norecurse


 

Now stop the packet capture on the auth server and send all the information.

 

The reason for using @ with dig is to eliminate the stub resolver 
on pc1 itself.

 

Thanks, Greg


 

 

 


 


On Wed, 17 Jan 2024 at 12:59,  wrote:


‌

‌
Dear Greg,
Dear Mark,

Once more thank you for your replies. Please see highlighted words below.

I confirm that 172.16.0.254 is the dns authoritative server.

 'pc1' means 'a generic computer on a local area network'. It could be a web 
server, a file server, a mail server. For a small structure with fixed ip 
addresses only, it could be a user's pc. On pc1 there is a fresh install of 
ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I created 
it only to test various network settings (dynamic dns, fixed ip address, dhcp 
provided ip address, ...). 

For this specific question about authoritative server, pc1 has a fixed ip 
address. Ubuntu's networkd-resolved local dns caching and stub is disabled, 
(Cache=no, DNSStubListener=no). For this specific question, I have only two 
computers, one authoritative non-recursive dns server and a generic computer 
named pc1. 


Please have a look at the highlighted text below to understand my question :

Command dig pc1.reseau1.lan ns


;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002

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


AUTHORITY: 1 : this is ok.


Command dig pc1.reseau1.lan 


;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670

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


Why AUTHORITY: 0 and not AUTHORITY: 1 ???
 
De : "Greg Choules" 
A : pub.dieme...@laposte.net,bind-users@lists.isc.org
Envoyé: lundi 15 Janvier 2024 18:27
Objet : Re: Question about authoritative server and AA Authoritative Answer
 

Hi again and thanks for that.
I'm still not exactly clear on the setup. I think the auth server is 
172.16.0.254 (I don't know what pc1 is).

But anyway, looking at your results I see the AA bit for everything. It appears 
that these queries both went directly to the auth server because recursion is 
disabled and it told you so.

 

==

 

# pc1@pc1:~
dig pc1.reseau1.lan
```

```txt
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

 

# ns1@ns1:~
dig pc1.reseau1.lan
```

```txt
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

 

==

 

So unless I'm missing something I don't see your problem.

Cheers, Greg

 


On Mon, 15 Jan 2024 at 15:24,  wrote:


D‌ear Greg, 

Thank you for your reply.


Please find attached the markdown file  with all the commands and text from the 
terminal.

In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener from 
systemd-resolved. I have netplan and networkd.


Kind Regards,

Michel Diemer.

 
 

De : "Greg Choules"
A : pub.dieme...@laposte.net,bind-users@lists.isc.org
Envoyé: dimanche 14 Janvier 2024 23:28
Objet : Re: Question about authoritative server and AA Authoritative Answer
 

Hi Michel.
Please can you send the following information:

- name and IP address of the authoritative server

- the full contents of the zone file for "reseau1.lan"

- name and IP address of the other server - what does this server do?

- What is the machine "pc1", on which you are running the digs?

- the file "/etc/resolv.conf" on "pc1"

 

Please also re-send the digs with full output.

When you send information, please send it as text, not screenshots.

 

Thanks, Greg

 


On Sun, 14 Jan 2024 at 22:04, Michel Diemer

Re: Question about authoritative server and AA Authoritative Answer

[Björn Persson]

Michel Diemer via bind-users wrote:
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1

This response message has the QR flag, the AA flag and the RD flag
turned on. The message contains 1 copy of the query, 0 answers to the
query, 1 reference to an authoritative nameserver (probably a SOA
record), and 1 additional record (the OPT pseudorecord).

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

This response message has the QR flag, the AA flag and the RD flag
turned on. The message contains 1 copy of the query, 1 answer to the
query, 0 references to authoritative nameservers, and 1 additional
record (the OPT pseudorecord).

> Why AUTHORITY: 0 and not AUTHORITY: 1 ???

Because there are no NS or SOA records attached to the answer. The
server provided the answer to your query, so it didn't need to refer
you to other nameservers that might know the answer.

Björn Persson


pgpjOuTrGvzlY.pgp
Description: OpenPGP digital signatur
-- 
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: Question about authoritative server and AA Authoritative Answer

[Greg Choules via bind-users]

Hi again.
Please start a packet capture on the auth server. This should do it:
   sudo tcpdump -nvi any -c 1 -w mydns.pcap port 53
Then from pc1, please do these and copy/paste text output, not screenshots:

dig @172.16.0.254 pc1.reseau1.lan NS +norecurse
dig @172.16.0.254 pc1.reseau1.lan SOA +norecurse
dig @172.16.0.254 pc1.reseau1.lan A +norecurse
dig @172.16.0.254 pc1.reseau1.lan  +norecurse

Now stop the packet capture on the auth server and send all the information.

The reason for using @ with dig is to eliminate the stub
resolver on pc1 itself.

Thanks, Greg




On Wed, 17 Jan 2024 at 12:59,  wrote:

> ‌
> ‌
> Dear Greg,
> Dear Mark,
>
> Once more thank you for your replies. Please see highlighted words below.
>
> I confirm that 172.16.0.254 is the dns authoritative server.
>
>  'pc1' means 'a generic computer on a local area network'. It could be a
> web server, a file server, a mail server. For a small structure with fixed
> ip addresses only, it could be a user's pc. On pc1 there is a fresh install
> of ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I
> created it only to test various network settings (dynamic dns, fixed ip
> address, dhcp provided ip address, ...).
>
> For this specific question about authoritative server, pc1 has a fixed ip
> address. Ubuntu's networkd-resolved local dns caching and stub is disabled,
> (Cache=no, DNSStubListener=no). For this specific question, I have only
> two computers, one authoritative non-recursive dns server and a generic
> computer named pc1.
>
>
> Please have a look at the highlighted text below to understand my question
> :
>
> Command dig pc1.reseau1.lan *ns*
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
>
> *AUTHORITY: 1 : this is ok.*
>
>
> Command dig pc1.reseau1.lan
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
>
> *Why AUTHORITY: 0 and not AUTHORITY: 1 ???*
>
> De : "Greg Choules" 
> A : pub.dieme...@laposte.net,bind-users@lists.isc.org
> Envoyé: lundi 15 Janvier 2024 18:27
> Objet : Re: Question about authoritative server and AA Authoritative Answer
>
> Hi again and thanks for that.
> I'm still not exactly clear on the setup. I think the auth server is
> 172.16.0.254 (I don't know what pc1 is).
> But anyway, looking at your results I see the AA bit for everything. It
> appears that these queries both went directly to the auth server because
> recursion is disabled and it told you so.
>
> ==
>
> # pc1@pc1:~
> dig pc1.reseau1.lan
> ```
>
> ```txt
> ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> # ns1@ns1:~
> dig pc1.reseau1.lan
> ```
>
> ```txt
> ; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
> ;; WARNING: recursion requested but not available
>
> ==
>
> So unless I'm missing something I don't see your problem.
> Cheers, Greg
>
> On Mon, 15 Jan 2024 at 15:24,  wrote:
>
>> D‌ear Greg,
>>
>> Thank you for your reply.
>>
>>
>> Please find attached the markdown file  with all the commands and text
>> from the terminal.
>>
>> In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener
>> from systemd-resolved. I have netplan and networkd.
>>
>>
>> Kind Regards,
>>
>> Michel Diemer.
>>
>>
>>
>> De : "Greg Choules"
>> A : pub.dieme...@laposte.net,bind-users@lists.isc.org
>> Envoyé: dimanche 14 Janvier 2024 23:28
>> Objet : Re: Question about authoritative server and AA Authoritative
>> Answer
>>
>> Hi Michel.
>> Please can you send the following information:
>> - name and IP address of the authoritative server
>> - the full contents of the zone file for "reseau1.lan"
>> - name and IP address of the other server - what does this server do?
>> - What is the machine "pc1", on which you are running the digs?
>> - the file "/etc/resolv.conf" on "pc1"
>>
>> Please also re-send the digs with

Re: Question about authoritative server and AA Authoritative Answer

[Michel Diemer via bind-users]

‌

‌
Dear Greg,
Dear Mark,

Once more thank you for your replies. Please see highlighted words below.

I confirm that 172.16.0.254 is the dns authoritative server.

 'pc1' means 'a generic computer on a local area network'. It could be a web 
server, a file server, a mail server. For a small structure with fixed ip 
addresses only, it could be a user's pc. On pc1 there is a fresh install of 
ubuntu 22.04 with only a few network settings (dhcp, dns, gateway). I created 
it only to test various network settings (dynamic dns, fixed ip address, dhcp 
provided ip address, ...). 

For this specific question about authoritative server, pc1 has a fixed ip 
address. Ubuntu's networkd-resolved local dns caching and stub is disabled, 
(Cache=no, DNSStubListener=no). For this specific question, I have only two 
computers, one authoritative non-recursive dns server and a generic computer 
named pc1. 


Please have a look at the highlighted text below to understand my question :

Command dig pc1.reseau1.lan ns


;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 56002

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


AUTHORITY: 1 : this is ok.


Command dig pc1.reseau1.lan 


;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670

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


Why AUTHORITY: 0 and not AUTHORITY: 1 ???
 
De : "Greg Choules" 
A : pub.dieme...@laposte.net,bind-users@lists.isc.org
Envoyé: lundi 15 Janvier 2024 18:27
Objet : Re: Question about authoritative server and AA Authoritative Answer
 

Hi again and thanks for that.
I'm still not exactly clear on the setup. I think the auth server is 
172.16.0.254 (I don't know what pc1 is).

But anyway, looking at your results I see the AA bit for everything. It appears 
that these queries both went directly to the auth server because recursion is 
disabled and it told you so.

 

==

 

# pc1@pc1:~
dig pc1.reseau1.lan
```

```txt
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

 

# ns1@ns1:~
dig pc1.reseau1.lan
```

```txt
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

 

==

 

So unless I'm missing something I don't see your problem.

Cheers, Greg

 


On Mon, 15 Jan 2024 at 15:24,  wrote:


D‌ear Greg, 

Thank you for your reply.


Please find attached the markdown file  with all the commands and text from the 
terminal.

In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener from 
systemd-resolved. I have netplan and networkd.


Kind Regards,

Michel Diemer.

 
 

De : "Greg Choules"
A : pub.dieme...@laposte.net,bind-users@lists.isc.org
Envoyé: dimanche 14 Janvier 2024 23:28
Objet : Re: Question about authoritative server and AA Authoritative Answer
 

Hi Michel.
Please can you send the following information:

- name and IP address of the authoritative server

- the full contents of the zone file for "reseau1.lan"

- name and IP address of the other server - what does this server do?

- What is the machine "pc1", on which you are running the digs?

- the file "/etc/resolv.conf" on "pc1"

 

Please also re-send the digs with full output.

When you send information, please send it as text, not screenshots.

 

Thanks, Greg

 


On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users 
 wrote:


‌Ders bind users,

I have already asked a similar question which was more about DNS in general , 
this one is very specific about the AA bit.

Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig 
pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing ? 
If possible, how to get AA answers for QNAME queries ? »

I have set up two virtual machines on a virtual local network using Oracle 
VirtualBox. One machine is a DNS authoritative-only server. The zone is named 
"reseau1.lan" and defined only in bind9 zone files. If I really have to, I will 
name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan inspired by 
RFC 6762 appendix G). The IP address of the DNS server is 172.16.0.254 and the 
IP address of pc1 is 172.16.0.21.


dig soa reseau1.lan : the AA bit is set, which is what I am looking for

͏‌ ͏‌ ͏‌ 

 dig pc1.reseau1.lan ns :  the AA bit is set

͏‌ ͏‌ ͏‌ ͏‌ 

dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge 
am I missing ?

Re: Question about authoritative server and AA Authoritative Answer

[Mark Andrews]

> On 16 Jan 2024, at 02:32, pub.dieme...@laposte.net wrote:
> 
> ‌
> 
> Dear Mark,
> 
> I am sorry but I don'y understand you reply.
> 
> 
> RFC 1034, § 6.2.2 the AA bit is set.
> I have a non-recursive authoritative server and the AA bit is not set. My 
> example is similar to RFC 1034. Why, on the RFC the AA bit is set but not on 
> my example ?

Because you were not querying the authoritative server, you where querying the 
recursive server in the screen shots.  When you queried the authoritative 
server (see dns-authoritative-question.md) you got AA in the response.

The answers from the recursive server:

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

vs the answers from the authoritative server:

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

> On my screenshots, where do you see negative answers ?

The ones where the answer count was zero (look for "ANSWER: 0,”).

> De : "Mark Andrews"
> A : pub.dieme...@laposte.net,"bind users"
> Envoyé: dimanche 14 Janvier 2024 23:54
> Objet : Re: Question about authoritative server and AA Authoritative Answer
>   
> 
> > On 15 Jan 2024, at 09:04, Michel Diemer via bind-users wrote:
> >
> > ‌Ders bind users,
> >
> > I have already asked a similar question which was more about DNS in general 
> > , this one is very specific about the AA bit.
> >
> > Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig 
> > pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I 
> > missing ? If possible, how to get AA answers for QNAME queries ? »
> 
> The difference is because you have positive and negative answers. The 
> authority section has information about how long the negative response can be 
> cached for. See RFC 2308.
> 
> As for AA ask the authoritative server rather than the recursive server. See 
> RFC 1035. Also see the examples where AA is set in RFC 1034 and their 
> descriptions.
> 
> AA Authoritative Answer - this bit is valid in responses,
> and specifies that the responding name server is an
> authority for the domain name in question section.
> 
> Note that the contents of the answer section may have
> multiple owner names because of aliases. The AA bit
> corresponds to the name which matches the query name, or
> the first owner name in the answer section.
> 
> 
> > I have set up two virtual machines on a virtual local network using Oracle 
> > VirtualBox. One machine is a DNS authoritative-only server. The zone is 
> > named "reseau1.lan" and defined only in bind9 zone files. If I really have 
> > to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan 
> > inspired by RFC 6762 appendix G). The IP address of the DNS server is 
> > 172.16.0.254 and the IP address of pc1 is 172.16.0.21.
> 
> 
> > dig soa reseau1.lan : the AA bit is set, which is what I am looking for
> >
> > <540085300119embeddedImage.png>͏‌ ͏‌ ͏‌
> >
> > dig pc1.reseau1.lan ns : the AA bit is set
> >
> > <620630300119embeddedImage.png>͏‌ ͏‌ ͏‌ ͏‌
> >
> > dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or 
> > knowledge am I missing ?
> >
> > <8504625embeddedImage.png>
> >
> > Below my "named.conf.options" file
> >
> > <1311990100238embeddedImage.png>͏‌
> >
> >
> > ͏‌ ͏‌ ͏‌ ͏‌
> > --
> > 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
>  

-- 
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: Question about authoritative server and AA Authoritative Answer

[Greg Choules via bind-users]

Hi again and thanks for that.
I'm still not exactly clear on the setup. I think the auth server is
172.16.0.254 (I don't know what pc1 is).
But anyway, looking at your results I see the AA bit for everything. It
appears that these queries both went directly to the auth server because
recursion is disabled and it told you so.

==

# pc1@pc1:~
dig pc1.reseau1.lan
```

```txt
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57670
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

# ns1@ns1:~
dig pc1.reseau1.lan
```

```txt
; <<>> DiG 9.18.18-0ubuntu0.22.04.1-Ubuntu <<>> pc1.reseau1.lan
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2379
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

==

So unless I'm missing something I don't see your problem.
Cheers, Greg

On Mon, 15 Jan 2024 at 15:24,  wrote:

> D‌ear Greg,
>
> Thank you for your reply.
>
>
> Please find attached the markdown file  with all the commands and text
> from the terminal.
>
> In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener
> from systemd-resolved. I have netplan and networkd.
>
>
> Kind Regards,
>
> Michel Diemer.
>
>
>
> De : "Greg Choules"
> A : pub.dieme...@laposte.net,bind-users@lists.isc.org
> Envoyé: dimanche 14 Janvier 2024 23:28
> Objet : Re: Question about authoritative server and AA Authoritative Answer
>
> Hi Michel.
> Please can you send the following information:
> - name and IP address of the authoritative server
> - the full contents of the zone file for "reseau1.lan"
> - name and IP address of the other server - what does this server do?
> - What is the machine "pc1", on which you are running the digs?
> - the file "/etc/resolv.conf" on "pc1"
>
> Please also re-send the digs with full output.
> When you send information, please send it as text, not screenshots.
>
> Thanks, Greg
>
> On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users <
> bind-users@lists.isc.org> wrote:
>
>> ‌Ders bind users,
>>
>> I have already asked a similar question which was more about DNS in
>> general , this one is very specific about the AA bit.
>>
>> Today's question is : *« "dig pc1.reseau1.lan ns"** show AUTHORITY: 1
>> and "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am
>> I missing ? If possible, how to get AA answers for QNAME queries ? »*
>>
>> I have set up two virtual machines on a virtual local network using
>> Oracle VirtualBox. One machine is a DNS authoritative-only server. The
>> zone is named "reseau1.lan" and defined only in bind9 zone files. If I
>> really have to, I will name it "reseau1.home.arpa" according to RFC 8375.
>> (I chose .lan inspired by RFC 6762 appendix G). The IP address of the DNS
>> server is 172.16.0.254 and the IP address of pc1 is 172.16.0.21.
>>
>>
>> *dig soa reseau1.lan* : the AA bit is set, which is what I am looking for
>>
>> ͏‌ ͏‌ ͏‌
>>
>> * dig pc1.reseau1.lan ns* :  the AA bit is set
>>
>> ͏‌ ͏‌ ͏‌ ͏‌
>>
>> *dig pc1.reseau1.lan* : *the AA bit is not set. Why ? Which setting or
>> knowledge am I missing ?*
>>
>>
>>
>> Below my "named.conf.options" file
>>
>> ͏‌
>>
>>
>> ͏‌ ͏‌ ͏‌ ͏‌
>> --
>> 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: Question about authoritative server and AA Authoritative Answer

[Michel Diemer via bind-users]

D‌ear Greg, 

Thank you for your reply.


Please find attached the markdown file  with all the commands and text from the 
terminal.

In /etc/resolv.conf I had "127.0.0.53" so I disabled the DNSStubListener from 
systemd-resolved. I have netplan and networkd.


Kind Regards,

Michel Diemer.

 
 

De : "Greg Choules"
A : pub.dieme...@laposte.net,bind-users@lists.isc.org
Envoyé: dimanche 14 Janvier 2024 23:28
Objet : Re: Question about authoritative server and AA Authoritative Answer
 

Hi Michel.
Please can you send the following information:

- name and IP address of the authoritative server

- the full contents of the zone file for "reseau1.lan"

- name and IP address of the other server - what does this server do?

- What is the machine "pc1", on which you are running the digs?

- the file "/etc/resolv.conf" on "pc1"

 

Please also re-send the digs with full output.

When you send information, please send it as text, not screenshots.

 

Thanks, Greg

 


On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users 
 wrote:


‌Ders bind users,

I have already asked a similar question which was more about DNS in general , 
this one is very specific about the AA bit.

Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig 
pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing ? 
If possible, how to get AA answers for QNAME queries ? »

I have set up two virtual machines on a virtual local network using Oracle 
VirtualBox. One machine is a DNS authoritative-only server. The zone is named 
"reseau1.lan" and defined only in bind9 zone files. If I really have to, I will 
name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan inspired by 
RFC 6762 appendix G). The IP address of the DNS server is 172.16.0.254 and the 
IP address of pc1 is 172.16.0.21.


dig soa reseau1.lan : the AA bit is set, which is what I am looking for

͏‌ ͏‌ ͏‌ 

 dig pc1.reseau1.lan ns :  the AA bit is set

͏‌ ͏‌ ͏‌ ͏‌ 

dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge 
am I missing ?



Below my "named.conf.options" file

͏‌ 


͏‌ ͏‌ ͏‌ ͏‌ 
--
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





dns-authoritative-question.md
Description: Binary data
-- 
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: Question about authoritative server and AA Authoritative Answer

[Petr Menšík]

Please use home.arpa, as defined by RFC 8375. Or better use existing and 
registered domain of you or your organization.


What kind of resolver is running on DNS server? Which version?

I would guess dnsmasq or similar. That is willing and able to forward 
just queries of selected types, while answering others itself. I think 
any proper DNS server does organize its authoritative zones and will 
answer with AA for any answer from it.


Are you sure you are asking correct server? Have you tried dig 
@172.16.0.254 pc1.reseau1.lan ?


I would guess you have systemd-resolved running on pc1 and it answers 
just A type queries itself, but forwards SOA and NS queries.


Cheers,
Petr

On 14. 01. 24 23:04, Michel Diemer via bind-users wrote:

‌Ders bind users,

I have already asked a similar question which was more about DNS in 
general , this one is very specific about the AA bit.


Today's question is : *« "dig pc1.reseau1.lan ns"*** show AUTHORITY: 1 
and "**dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or 
knowledge am I missing** ? If possible, how to get AA answers for 
QNAME queries ? »**


I have set up two virtual machines on a virtual local network using 
Oracle VirtualBox. One machine is a DNS authoritative-only server. The 
zone is named "reseau1.lan" and defined only in bind9 zone files. If I 
really have to, I will name it "reseau1.home.arpa" according to RFC 
8375. (I chose .lan inspired by RFC 6762 appendix G). The IP address 
of the DNS server is 172.16.0.254 and the IP address of pc1 is 
172.16.0.21.



*dig soa reseau1.lan*: the AA bit is set, which is what I am looking for

͏‌ ͏‌ ͏‌

* dig pc1.reseau1.lan ns*:  the AA bit is set

͏‌ ͏‌ ͏‌ ͏‌

*dig pc1.reseau1.lan*: _*the AA bit is not set. Why ? Which setting or 
knowledge am I missing ?*_




Below my "named.conf.options" file

͏‌


͏‌ ͏‌ ͏‌ ͏‌


--
Petr Menšík
Software Engineer, RHEL
Red Hat,http://www.redhat.com/
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB
-- 
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: Question about authoritative server and AA Authoritative Answer

[Mark Andrews]

> On 15 Jan 2024, at 09:04, Michel Diemer via bind-users 
>  wrote:
> 
> ‌Ders bind users,
> 
> I have already asked a similar question which was more about DNS in general , 
> this one is very specific about the AA bit.
> 
> Today's question is : « "dig pc1.reseau1.lan ns" show AUTHORITY: 1 and "dig 
> pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I missing 
> ? If possible, how to get AA answers for QNAME queries ? »

The difference is because you have positive and negative answers. The authority 
section has information about how long the negative response can be cached for. 
 See RFC 2308.

As for AA ask the authoritative server rather than the recursive server.  See 
RFC 1035.  Also see the examples where AA is set in RFC 1034 and their 
descriptions.

AA Authoritative Answer - this bit is valid in responses,
   and specifies that the responding name server is an
   authority for the domain name in question section.

   Note that the contents of the answer section may have
   multiple owner names because of aliases. The AA bit
   corresponds to the name which matches the query name, or
   the first owner name in the answer section.


> I have set up two virtual machines on a virtual local network using Oracle 
> VirtualBox. One machine is a DNS authoritative-only server. The zone is named 
> "reseau1.lan" and defined only in bind9 zone files. If I really have to, I 
> will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan 
> inspired by RFC 6762 appendix G). The IP address of the DNS server is 
> 172.16.0.254 and the IP address of pc1 is 172.16.0.21.


> dig soa reseau1.lan : the AA bit is set, which is what I am looking for
> 
> <540085300119embeddedImage.png>͏‌ ͏‌ ͏‌ 
> 
>  dig pc1.reseau1.lan ns :  the AA bit is set
> 
> <620630300119embeddedImage.png>͏‌ ͏‌ ͏‌ ͏‌ 
> 
> dig pc1.reseau1.lan : the AA bit is not set. Why ? Which setting or knowledge 
> am I missing ?
> 
> <8504625embeddedImage.png>
> 
> Below my "named.conf.options" file
> 
> <1311990100238embeddedImage.png>͏‌ 
> 
> 
> ͏‌ ͏‌ ͏‌ ͏‌ 
> -- 
> 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: Question about authoritative server and AA Authoritative Answer

[Greg Choules via bind-users]

Hi Michel.
Please can you send the following information:
- name and IP address of the authoritative server
- the full contents of the zone file for "reseau1.lan"
- name and IP address of the other server - what does this server do?
- What is the machine "pc1", on which you are running the digs?
- the file "/etc/resolv.conf" on "pc1"

Please also re-send the digs with full output.
When you send information, please send it as text, not screenshots.

Thanks, Greg

On Sun, 14 Jan 2024 at 22:04, Michel Diemer via bind-users <
bind-users@lists.isc.org> wrote:

> ‌Ders bind users,
>
> I have already asked a similar question which was more about DNS in
> general , this one is very specific about the AA bit.
>
> Today's question is : *« "dig pc1.reseau1.lan ns"** show AUTHORITY: 1 and
> "dig pc1.reseau1.lan" shows AUTHORITY: 0. Which setting or knowledge am I
> missing ? If possible, how to get AA answers for QNAME queries ? »*
>
> I have set up two virtual machines on a virtual local network using Oracle
> VirtualBox. One machine is a DNS authoritative-only server. The zone is
> named "reseau1.lan" and defined only in bind9 zone files. If I really have
> to, I will name it "reseau1.home.arpa" according to RFC 8375. (I chose .lan
> inspired by RFC 6762 appendix G). The IP address of the DNS server is
> 172.16.0.254 and the IP address of pc1 is 172.16.0.21.
>
>
> *dig soa reseau1.lan* : the AA bit is set, which is what I am looking for
>
> ͏‌ ͏‌ ͏‌
>
> * dig pc1.reseau1.lan ns* :  the AA bit is set
>
> ͏‌ ͏‌ ͏‌ ͏‌
>
> *dig pc1.reseau1.lan* : *the AA bit is not set. Why ? Which setting or
> knowledge am I missing ?*
>
>
>
> Below my "named.conf.options" file
>
> ͏‌
>
>
> ͏‌ ͏‌ ͏‌ ͏‌
> --
> 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: Question about DNS / bind9 / authoritative and NXDOMAIN vs NOERROR (NODATA)

[G.W. Haywood]

Hi there,

On Wed, 13 Dec 2023, Greg Choules wrote:


If your server can reach the Internet it can recurse all on its own.


And for extra information, I recommend you give the '+trace' option to dig.


I hope that helps.


Ditto. :)

--

73,
Ged.
--
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: Question about DNS / bind9 / authoritative and NXDOMAIN vs NOERROR (NODATA)

[Greg Choules via bind-users]

Hi Michel.
You will get an authoritative answer (AA bit = 1) if the server is either
primary (master) or secondary (slave) for the QNAME (query name); in this
case "reseau1.lan". From the config snip you provided this is because you
have the config:

zone "reseau1.lan" {
   type master;
...
};

If you make a query for "xxx.reseau1.lan" to this server, the response you
get back will depend on whether you have anything in the zone file
("db.reseau1.lan")
that would match that QNAME. If you do not have "xxx" or "*" (wildcard)
then there will be no match and the response will be (authoritative)
NXDOMAIN - this name does not exist at all.
Personally I would not use a wildcard because it gives the impression that
any name exists when really it doesn't.

NOTE that the existence of "reseau1.lan" means that ALL names beneath this
point will be swallowed by the server, e.g. "a.b.c.d.e.f.reseau1.lan" will
all return NXDOMAIN +AA=1

What behaviour do you think you would like to see?

Looking at another part of your config, you should not need this at all:

options {
   forwarders {8.8.8.8;};
...
};

If your server can reach the Internet it can recurse all on its own.

I hope that helps.
Greg

On Wed, 13 Dec 2023 at 16:29, Michel Diemer via bind-users <
bind-users@lists.isc.org> wrote:

>
> ‌
> Dear Bind user,
>
> I am a teacher and trying to understand how dns works. I am spending hours
> reading various sources without finding satisfying information. For
> teaching purposes I have created a virtual machine with isc dhcp server and
> bind9 and another virtual machine that uses the first one as ics dhcp and
> dns server.
>
> I have disabled IPv6 by setting link-local: [] in netplan's setting.
>
> The name of the network (dns zone) is "reseau1.lan". When I "dig -4
> reseau1.lan" the AUTHORITY bit is set to 1.
>
> Why or when should the AUTHORITY bit set to 1 ? What does it take for
> nslookup to give me an authoritative answer ?
>
> If I "ping xxx.reseau1.lan" I get an NXDOMAIN answer. Why NXDOMAIN and not
> NOERROR (NODATA) ? The domain "reseau1.lan" exists and my dns server is
> authoritative for this zone (SOA record) but the computer "xxx" on this
> domain does not. Should I use a wildcard dns record ?
>
> I have tryed to empty the list of forwarders and disable the dns cache ...
> should I configure a dns-resolver only for the domain reseau1.lan and then
> a dns forwared for external dns queries ? Or maybe configure the resolver
> for the lan network interface and the forwarder on the internet network
> interface on the dns server ?
>
> I managed to get "AUTHORITY: 1" when typing "dig -4 soa reseau1.lan" by
> disabling the forwarders and the cache so I guess I should configure bind
> per network interface. But when typing "dig -4 pc1.reseau1.lan" the
> AUTHORITY bit is always set to 0.
>
>
> ͏‌
>
>
>
> ͏‌
>
>
> Kind Regards,
>
> Michel Diemer
> --
> 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: Question about DNS / bind9 / authoritative and NXDOMAIN vs NOERROR (NODATA)

[Stephane Bortzmeyer]

On Wed, Dec 13, 2023 at 05:29:02PM +0100,
 Michel Diemer via bind-users  wrote 
 a message of 1723 lines which said:

> another virtual machine that uses the first one as ics dhcp and dns
> server.

An important thing about DNS: there are two types of DNS servers, very
different. Resolvers and authoritative. They use the same protocol,
and BIND can do both, but they have very different properties.

> I have disabled IPv6 by setting link-local: [] in netplan's setting.

Too bad. This is 2023, not the 20th century.

> The name of the network (dns zone) is "reseau1.lan". When I "dig -4
> reseau1.lan" the AUTHORITY bit is set to 1. 

You mean AA (authoritative answer)?

> Why or when should the AUTHORITY bit set to 1 ? What does it take
> for nslookup to give me an authoritative answer ? 

nslookup is an old and not very satisfying program. I would suggest
using dig instead.

> If I "ping xxx.reseau1.lan" I get an NXDOMAIN answer. Why NXDOMAIN
> and not NOERROR (NODATA) ? The domain "reseau1.lan" exists and my
> dns server is authoritative for this zone (SOA record) but the
> computer "xxx" on this domain does not. Should I use a wildcard dns
> record ?

Adding an entry for the "xxx" subdomain seems simpler.

> I have tryed to empty the list of forwarders and disable the dns
> cache ... should I configure a dns-resolver only for the domain
> reseau1.lan and then a dns forwared for external dns queries ? Or
> maybe configure the resolver for the lan network interface and the
> forwarder on the internet network interface on the dns server ?

I strongly suggest to separate resolver and authoritative. You
normally have authoritative answers from the authoritative servers
(surprise!) and non-authoritative from the resolvers, at least when
their cache is warm.

-- 
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: Question on ISC BIND DNS Server

[Turritopsis Dohrnii Teo En Ming]

On Thu, 23 Nov 2023 at 00:07, Matus UHLAR - fantomas  wrote:
>
> On 22.11.23 23:44, Turritopsis Dohrnii Teo En Ming wrote:
> >I have Virtualmin / Webmin web hosting server control panel. I have 2
> >Virtual Private Servers in Germany and 1 Virtual Private Server in
> >Japan.
> >
> >Can I upgrade BIND DNS Server manually? Will it cause problems with
> >Virtualmin / Webmin?
>
>
> I think this is question for webmin/virtualmin, but from what I know about
> webmin it tends to edit local configuration, so I guess it will edit primary
> zone file.
>

Noted I will try to ask at the Virtualmin/Webmin mailing list.

Thank you.

Regards,

Mr. Turritopsis Dohrnii Teo En Ming
Targeted Individual in Singapore
-- 
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: Question on ISC BIND DNS Server

[Matus UHLAR - fantomas]

On 22.11.23 23:44, Turritopsis Dohrnii Teo En Ming wrote:

I have Virtualmin / Webmin web hosting server control panel. I have 2
Virtual Private Servers in Germany and 1 Virtual Private Server in
Japan.

Can I upgrade BIND DNS Server manually? Will it cause problems with
Virtualmin / Webmin?



I think this is question for webmin/virtualmin, but from what I know about 
webmin it tends to edit local configuration, so I guess it will edit primary 
zone file.


--
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.
Posli tento mail 100 svojim znamim - nech vidia aky si idiot
Send this email to 100 your friends - let them see what an idiot you are
--
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: Question about URL being logged by resolver

[Ondřej Surý]

It means something in your network sent a query containing the literal URL 
below. The message is just misleading - the resolver tries to do QNAME 
minimization on it, it fails, switches to full name which ends with NXDOMAIN 
from root.

Ondrej
--
Ondřej Surý — ISC (He/Him)

My working hours and your working hours may be different. Please do not feel 
obligated to reply outside your normal working hours.

> On 3. 11. 2023, at 23:30, J Doe  wrote:
> 
> Hello,
> 
> On a Bind 9.18.19 server configured as a recursive resolver, I sometimes see 
> URL's being noted in the log files.
> 
> One such example is:
> 
> 02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
> 'https://app-measurement.com/sdk-exp/A' after disabling qname minimization 
> due to 'ncache nxdomain'
> 
> This seems unusual to me because Bind usually notes the domain name it is 
> attempting to resolve, not an URL.  In this particular case, I would expect 
> to see a notation about "app-measurement.com" and not "http://etc;.
> 
> What is the significance of logging the URL and why does this happen in only 
> some cases ?
> 
> Thanks,
> 
> - J
> --
> 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: Question about URL being logged by resolver

[Mark Andrews]

People accidentally enter urls as domain names into tools.  
https://app-measurement.com/sdk-exp/A is
a legal, but unusual, domain name consisting of 3 labels 
'https://app-measurement’, 'com/sdk-exp/A’ and ‘.’.

Mark

> On 4 Nov 2023, at 13:29, Nick Tait via bind-users  
> wrote:
> 
> Hi J.
> 
> I'm not sure what the cause of the URLs is, but I can confirm I'm seeing the 
> same URLs in my own logs. The queries originate from multiple devices on my 
> internal network - all Apple devices I think.
> 
> My advice: I wouldn't waste too much effort trying to solve this one, as it 
> is almost certainly something that you will have no control over. E.g. It 
> could be something bogus on a web page that these devices have all accessed?
> 
> Nick.
> 
> 
> On 4/11/23 11:30, J Doe wrote:
>> Hello,
>> 
>> On a Bind 9.18.19 server configured as a recursive resolver, I sometimes see 
>> URL's being noted in the log files.
>> 
>> One such example is:
>> 
>> 02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
>> 'https://app-measurement.com/sdk-exp/A' after disabling qname minimization 
>> due to 'ncache nxdomain'
>> 
>> This seems unusual to me because Bind usually notes the domain name it is 
>> attempting to resolve, not an URL.  In this particular case, I would expect 
>> to see a notation about "app-measurement.com" and not "http://etc;.
>> 
>> What is the significance of logging the URL and why does this happen in only 
>> some cases ?
>> 
>> Thanks,
>> 
>> - J
> -- 
> 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: Question about URL being logged by resolver

[Nick Tait via bind-users]

Hi J.

I'm not sure what the cause of the URLs is, but I can confirm I'm seeing 
the same URLs in my own logs. The queries originate from multiple 
devices on my internal network - all Apple devices I think.


My advice: I wouldn't waste too much effort trying to solve this one, as 
it is almost certainly something that you will have no control over. 
E.g. It could be something bogus on a web page that these devices have 
all accessed?


Nick.


On 4/11/23 11:30, J Doe wrote:

Hello,

On a Bind 9.18.19 server configured as a recursive resolver, I 
sometimes see URL's being noted in the log files.


One such example is:

02-Nov-2023 23:32:19.435 lame-servers: info: success resolving 
'https://app-measurement.com/sdk-exp/A' after disabling qname 
minimization due to 'ncache nxdomain'


This seems unusual to me because Bind usually notes the domain name it 
is attempting to resolve, not an URL.  In this particular case, I 
would expect to see a notation about "app-measurement.com" and not 
"http://etc;.


What is the significance of logging the URL and why does this happen 
in only some cases ?


Thanks,

- J

--
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: question about DNSSEC with PKCS11

[Jan-Piet Mens]

1. since I use HSM(now is softhsm) to store the DNSSEC key, does it more
insecure to convert the key(s) from HSM to .private file with
dnssec-keyfromlabel ?


keys are not actually 'converted' with this utility; instead the .private file
links to the corresponding private (and typically unexportable) key on the HSM.
(If you look inside the .private key you'll see a "Label:" which contains the
base64-encoded "pointer" to the key on the HSM.

In other words, use of dnssec-keyfromlabel(1) is not a security issue per se.

-JP
--
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: question about DNSSEC with PKCS11

[Matthijs Mekking]

Hi,

The KB article was written before dnssec-policy. Unfortunately, OpenSSL 
with engine_pkcs11 does not support creating keys. So if you want to use 
an HSM with dnssec-policy, you will need to create the keys yourself and 
you can then import them in the key-directory with dnssec-keyfromlabel. 
Then, when it is time to create a new key according to BIND, it will 
select a pregenerated key instead.


Sorry for this inconvenience. We are working on making dnssec-policy 
work with HSMs including key generation through the OpenSSL 3.0 provider 
API.


Best regards,

Matthijs


On 8/5/23 04:50, sun guonian wrote:

hi,

I have tried the DNSSEC sign testing according the document,
https://kb.isc.org/docs/bind-9-pkcs11 


(and section 5.5 of the Bv9ARM of version 9.18.16)

I have two questions about it,

1. since I use HSM(now is softhsm) to store the DNSSEC key, does it more
insecure to convert the key(s) from HSM to .private file with 
dnssec-keyfromlabel ?


2. when I configure KASP policy, I notice that bind will generate new key(s)
each time it need, but there is no new object in softhsm generated. 
Could bind

of this version roll the objects in HSM/softhsm ?

Thanks in advanced.

Best Regards,
SUN Guonian

And my environment is,
bind-9.18.16
opensc-0.42
softhsm-2.6.1
openssl-1.1.1k from system
RockyLinux 8


--
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: Question regarding delv and custom local trust anchor

[Evan Hunt]

On Thu, Jun 08, 2023 at 07:57:12PM +, Evan Hunt wrote:
> So, I'm guessing systemd-resolved is choking on the EDNS COOKIE option.
> This needs to be reported as a bug to the systemd maintainers. And, maybe
> delv should have a +nocookie option.

Hmm, on further inspection, I was wrong about this - the COOKIE isn't the
problem.  It seems to be sending back NOTIMP if you specify the CD and DO
bits (i.e., +cd and +dnssec) in the same query.

I had added the +cd flag to the query because I was seeing SERVFAIL on a
query for the .org DS record. I guessed that this was caused by an upstream
validation problem, and I may have been right about that, but we can't
bypass it with +cd because of this NOTIMP bug.

So... I'm not sure what the specific problem is now, but the general
problem does appear to be systemd-resolved.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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: Question regarding delv and custom local trust anchor

[Evan Hunt]

On Thu, Jun 08, 2023 at 09:54:15AM -0400, Josh Kuo wrote:
> *$ delv -a right.key www.example.com . A*;; broken
> trust chain resolving 'www.example.com/A/IN': 127.0.0.53#53
> ;; resolution failed: broken trust chain

The address 127.0.0.53 was the clue I needed to figure this out: I suspect
you're on linux, and it's using systemd-resolved as the local resolver.

When I tried delv on a system configured that way, it got a NOTIMP response
to its first query:

$ delv +cd +mtrace @127.0.0.53 www.isc.org
;; fetch: www.isc.org/A
;; sending packet to 127.0.0.53#53
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id:   7870
;; flags: rd cd; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: 8e31ae172137a02f
;; QUESTION SECTION:
;www.isc.org.   IN  A


;; received packet from 127.0.0.53#53
;; ->>HEADER<<- opcode: QUERY, status: NOTIMP, id:   7870
;; flags: qr rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 65494
; OPT=5: 05 07 08 0a 0d 0e 0f ("...")
; OPT=6: 01 02 04 ("...")
; OPT=7: 01 (".")
;; QUESTION SECTION:
;www.isc.org.   IN  A


;; NOTIMP unexpected RCODE resolving 'www.isc.org/A/IN': 127.0.0.53#53
;; resolution failed: SERVFAIL

So, I'm guessing systemd-resolved is choking on the EDNS COOKIE option.
This needs to be reported as a bug to the systemd maintainers. And, maybe
delv should have a +nocookie option.

In the meantime, the workaround is the one you found: point delv to a
resolver that implements EDNS correctly. It will validate the data it
receives, but it has to receive some.

The newest version of delv, in the BIND 9.19 development release, has
a 'delv +ns' option to do its own resolution internally, without needing
an external server to look up the data; that would also work.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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: Question About Internal Recursive Resolvers

[Matus UHLAR - fantomas]

On 18.10.22 09:23, Bob McDonald wrote:

There are no outside clients. In this example, I'm only discussing inside
clients on inside DNS. The recursive resolvers that ALL inside clients
connect to will seek responses from the DNS root servers AFTER determining
that the response can not be determined from the internal DNS zones. There
is no access provided to outside (internet centric) clients to inside DNS.
The determination of known/unknown clients is via a NAC layer and further,
the classification of unknown gets automatically assigned to those clients
combining in through GUEST WiFi (e.g. cell phones, ipads, etc.). Most
organizations with a NAC layer in place have procedures to allow unknown
clients temporary access at some level (e.g. vendors, etc.).


this way the situation is even easier.

you can use two distinct serves for internal and wi-fi clients, where only 
internal server will contain internal zones.


you can achieve the same effect with views, no other DNS servers are 
necessary


--
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.
There's a long-standing bug relating to the x86 architecture that
allows you to install Windows.   -- Matthew D. Fuller
--
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: Question About Internal Recursive Resolvers

[Bob McDonald]

Let's not overthink this. I fear that I've activated a lot of creative
circuitry in individuals and provided flimsy details around my example.

There are no outside clients. In this example, I'm only discussing inside
clients on inside DNS. The recursive resolvers that ALL inside clients
connect to will seek responses from the DNS root servers AFTER determining
that the response can not be determined from the internal DNS zones. There
is no access provided to outside (internet centric) clients to inside DNS.
The determination of known/unknown clients is via a NAC layer and further,
the classification of unknown gets automatically assigned to those clients
combining in through GUEST WiFi (e.g. cell phones, ipads, etc.). Most
organizations with a NAC layer in place have procedures to allow unknown
clients temporary access at some level (e.g. vendors, etc.).

HTH,

Bob
-- 
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: Question About Internal Recursive Resolvers

[Petr Špaček]

On 14. 10. 22 18:08, Bob McDonald wrote:

I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only. That said, all clients would connect to recursive resolvers.

The question is this; do I use an internal root with pointers to the
internal zones (as well as the outside DNS world) or do I include stub
zones to point at the non-recursive internal servers?

Access to the internal DNS zones would be controlled by location.
(e.g. guest WiFi devices would NOT have access to internal DNS
zones...)

Recursive resolvers would allow implementation of features such as RPZ, etc.


I have a better proposition for you:
Use a properly delegated name like internal.example.com, where 
example.com is a domain you own.


This way you don't need to mess with manual configuration for stub zones 
or hints and keep them updated.


ACLs can be applied on auths as needed to limit access to the "internal" 
zone from outside, but there is no technical reason why it cannot be 
delegated from public tree - and it will save you lots of headache.


HTH.

--
Petr Špaček

--
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: Question About Internal Recursive Resolvers

[Matus UHLAR - fantomas]

On 15.10.22 16:03, Bob McDonald wrote:

OK, if a known client accesses DNS on the internal network, that
client is pointed at a recursive resolver (e.g by DHCP). That resolver
either provides access to the internal DNS zones (e.g. via stub zones)
or sends the client query to the root servers on the internet. An
unknown client (e.g. guest WiFi) will be given the same resolver
address for its DNS server. At this point it would require ACLs to
prevent that unknown client from accessing the internal DNS zones. All
DNS traffic from that client would be sent to the internet.

Another way to achieve that would be to have a separate set of DNS
resolvers for unknown clients (resolver addresses handed out via
DHCP). That's my current view of how to get things done in this case.



What I'm discerning from the discussion so far is that this isn't
strictly necessary. The internal DNS zones can/should reside on the
recursive resolvers. The question of unknown client access to internal
DNS zones is resolved (no pun intended...).


bind supports views, which work like virtual DNS servers, you can define 
some zones only in internal views.


you can even support multiple views for internal, wi-fi and external 
clients, where the internal clients will get recursion and see internal 
zones, wi-fi clients get recursion w/o seeing internal zones, and external 
zones only see public zones.


You can separate these clients by their source IPs, without any need to 
configure separate servers with separate iP addresses.


you may want to share dns cache between internal and wi-fi zones using 
attach-cache directive, and share public zones to the internal and wi-fi 
directives by configuring thoze zones using "in-view".



RPZ COULD be implemented on ANY of the recursive DNS resolvers.


note that RPZ is designed to prevent/redirect access to destinations, not to 
clients - it's not designed to separate clients and access to zones this 
way.



The tsig key discussion is around its use as a method of allowing
updates to internal DNS zones. Strictly hypothetical. Don't get hung
up on it.


Tsig is good security measure to only allow specific clients to submit 
updates. You can configure tsig key to belong to particular view even 
without having proper client IP address.




Thank you all for the information. You've provided answers to my
questions and have renewed my faith in geekdom.

If anyone is still confused, I'd be glad to discuss this offline until
we have a final solution. Then we can publish if necessary.


--
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.
Microsoft dick is soft to do no harm
--
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: Question About Internal Recursive Resolvers

[Grant Taylor via bind-users]

On 10/15/22 1:51 PM, Greg Choules via bind-users wrote:

Hi Grant.


Hi Gred,

I'm quickly replying to your message.  I'll reply to Matus & Fred later 
when I have more time for a proper reply.


My understanding is this, which is almost identical to what I did in a 
former life:


client ---recursive_query---> recursive_DNS_server 
---non_recursive_query---> internal_auth/Internet


where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is asking about, a recursive-only DNS 
server

internal_auth == the other component, an authoritative-only DNS server


ACK

I that's the topology I had in my mental map.

Separation of internal and external clients - preventing external ones 
from accessing internal names - is easily achieved with a couple of 
views, such as this:


I /absolutely/ agree with you.  However "views" is /non-default/.  -- 
To reflect Bob's original message.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Question About Internal Recursive Resolvers

[Bob McDonald]

OK, if a known client accesses DNS on the internal network, that
client is pointed at a recursive resolver (e.g by DHCP). That resolver
either provides access to the internal DNS zones (e.g. via stub zones)
or sends the client query to the root servers on the internet. An
unknown client (e.g. guest WiFi) will be given the same resolver
address for its DNS server. At this point it would require ACLs to
prevent that unknown client from accessing the internal DNS zones. All
DNS traffic from that client would be sent to the internet.

Another way to achieve that would be to have a separate set of DNS
resolvers for unknown clients (resolver addresses handed out via
DHCP). That's my current view of how to get things done in this case.

What I'm discerning from the discussion so far is that this isn't
strictly necessary. The internal DNS zones can/should reside on the
recursive resolvers. The question of unknown client access to internal
DNS zones is resolved (no pun intended...).

RPZ COULD be implemented on ANY of the recursive DNS resolvers.

The tsig key discussion is around its use as a method of allowing
updates to internal DNS zones. Strictly hypothetical. Don't get hung
up on it.

Thank you all for the information. You've provided answers to my
questions and have renewed my faith in geekdom.

If anyone is still confused, I'd be glad to discuss this offline until
we have a final solution. Then we can publish if necessary.

Bob
-- 
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: Question About Internal Recursive Resolvers

[Greg Choules via bind-users]

Hi Grant.
My understanding is this, which is almost identical to what I did in a
former life:

client ---recursive_query---> recursive_DNS_server
---non_recursive_query---> internal_auth/Internet

where:
client == laptop/phone/server running stub resolver code
recursive_DNS_server == what Bob is asking about, a recursive-only DNS
server
internal_auth == the other component, an authoritative-only DNS server

Separation of internal and external clients - preventing external ones from
accessing internal names - is easily achieved with a couple of views, such
as this:

view "external" {
match-clients { address_match_list }; # the set of all possible
addresses that external clients may be given.
match-destinations { address_match_list }; # the address(es) given to
external clients for their DNS service.
  ...
};
view "internal" {
   # there is no `match clients`. Any client not already match by the
"external" view potentially has access to this view, if they target the
correct service address(es).
  match-destinations { address_match_list }; # the address(es) given to
internal clients for their DNS service. Different from the one(s) given to
external clients.
  attach-cache "external"; # internal clients have access to records that
have already been cached due to queries made by external clients.
   ...
};

Greg

On Sat, 15 Oct 2022 at 18:52, Grant Taylor via bind-users <
bind-users@lists.isc.org> wrote:

> On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
> > If you are an ISP/registry/DNS provider, it makes sense to separate
> > authoritative zones for your clients' domains, for all those cases your
> > client move their domains somewhere else without notifying you (hell,
> > they do that too often), or to be able to prepare moving domains to your
> > servers.
>
> #truth
>
> > forward zones - named sends recursive query to the primary servers
> > stub zones- named fetches NS records from primary servers and
> > uses them for resolution
> > static-stub zones - named forwards iterative (non-recursive) requests to
> > primary servers
> >
> > clients accessing any of these zones must have recursion allowed and
> > recursion must be enabled in BIND.
>
> Please clarify where recursion needs to be allowed; the BIND server
> clients are talking to and / or the back end server that BIND is talking
> to on the client's behalf.
>
> I'm not completely clear and I think it's better to ask than to assume
> incorrectly.
>
> > On 10/15/22 10:03 AM, Bob McDonald wrote:
> >> If a non-secure client (read the next sentence...) accesses the same
> >> recursive server as a regular client, it will have access to the
> >> internal zones by default.. Therefore we need to have some sort of
> >> access controls in place.
> > and THIS is exactly the reason you SHOULD put your internal zones on
> > your internal server.
>
> Sorry if I'm being particularly dense this morning, but I'm not
> following ~> understanding Bob's and Matus's statements like I want to.
>
> How does hosting the zone on an internal server provide any additional
> security?  Or are you simply relying on other security mechanisms to
> prevent non-secure clients -- as Bob described them -- from accessing
> the server ~> zone?
>
> I feel like, by default -- as Bob described, any hosted zone is going to
> be accessible by any client that can query the server.
>
> With this in mind, I feel like the type of zone; primary / secondary /
> mirror / stub / static-stub / forward, makes little difference in and of
> itself.  Rather, it would be dependent on global and / or per-zone
> allow-* statements to protect the server / zone(s) at the BIND
> application level.
>
> Does that make sense?
>
> What am I missing / misunderstanding?
>
> > that's why we are here.
>
> :-)
>
>
>
> --
> Grant. . . .
> unix || die
>
> --
> 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: Question About Internal Recursive Resolvers

[Fred Morris]

People do the funniest things with DNS. It's a pretty good key-value 
store, especially for read-heavy workloads.


Maybe you update counters for "what clients in this OT environment are 
posting telemetry to this web server"? DNS wouldn't be a good choice for 
that, but Redis is. But maybe you want to query for the info with the DNS; 
as a bonus, DNS can offload / cache reads.


On Sat, 15 Oct 2022, Grant Taylor via bind-users wrote:

[...]
How does hosting the zone on an internal server provide any additional 
security?  Or are you simply relying on other security mechanisms to prevent 
non-secure clients -- as Bob described them -- from accessing the server ~> 
zone?


I feel like, by default -- as Bob described, any hosted zone is going to be 
accessible by any client that can query the server.


DNS is federated, meaning that a server can be both a service and a 
client, which means in the use case given above that the Redis instances 
can be distributed close to where the counters are updated; the DNS will 
go out and collect those counters when you query them, no need to send a 
constant stream of telemetry to a central location.


You probably don't want those counters accessible to every dog on the 
internet. Some thought is necessary in deploying DNS servers so that 
intended clients get access. (We don't usually expect DNS clients to issue 
hundreds of requests per second either, but it works; you just need to 
give it some thought.)


I assume that people have been doing variations on this sort of thing 
since PDPs were as common as LSD in Berkely.


The usual suspects arrive: TSIG, allowed addresses, firewall rules; 
site-to-site VPNs; that sort of thing. Turns out RPZ is useful as a WAF 
equivalent, limiting the Redis keys which can be queried as well as the 
types of allowed queries.



Here is my contribution to ensuring employment for DNS subject matter 
experts:


* https://github.com/m3047/rkvdns -- DNS proxy for Redis

* https://github.com/m3047/rkvdns_examples -- examples

--

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: Question About Internal Recursive Resolvers

[Matus UHLAR - fantomas]

If you are an ISP/registry/DNS provider, it makes sense to separate 
authoritative zones for your clients' domains, for all those cases 
your client move their domains somewhere else without notifying you 
(hell, they do that too often), or to be able to prepare moving 
domains to your servers.


#truth



On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:

forward zones - named sends recursive query to the primary servers
stub zones- named fetches NS records from primary servers 
and uses them for resolution
static-stub zones - named forwards iterative (non-recursive) 
requests to primary servers


clients accessing any of these zones must have recursion allowed and 
recursion must be enabled in BIND.


On 15.10.22 11:50, Grant Taylor via bind-users wrote:
Please clarify where recursion needs to be allowed; the BIND server 
clients are talking to and / or the back end server that BIND is 
talking to on the client's behalf.


I'm not completely clear and I think it's better to ask than to assume 
incorrectly.


recursion must be allowed on the BIND server that is supposed to forward 
queries from clients, and those clients need to have recursion enabled on 
that BIND server.


the Bob mentions copnfiguring recursive server so I assume everything is 
already allowed, I just noted that recursion is needed for zone types above.



On 10/15/22 10:03 AM, Bob McDonald wrote:
If a non-secure client (read the next sentence...) accesses the 
same recursive server as a regular client, it will have access to 
the internal zones by default.. Therefore we need to have some 
sort of access controls in place.


and THIS is exactly the reason you SHOULD put your internal zones on 
your internal server.


Sorry if I'm being particularly dense this morning, but I'm not 
following ~> understanding Bob's and Matus's statements like I want 
to.


How does hosting the zone on an internal server provide any additional 
security?  Or are you simply relying on other security mechanisms to 
prevent non-secure clients -- as Bob described them -- from accessing 
the server ~> zone?


Company has internal/recursive servers only accessible by internal clients.

If you configure internal zones on these servers, all internal clients will 
immediately have access to these zones, no measures needed (though possible)


If you configure internal zones on separate servers, you must:
- configure recursive servers to direct lookups to authoritative servers
- control access to those zones on authoritative servers.

so, you must take two more measures.


I feel like, by default -- as Bob described, any hosted zone is going 
to be accessible by any client that can query the server.


Bob describes moving internal zones to non-recursive servers.
https://lists.isc.org/pipermail/bind-users/2022-October/106756.html

Which requires those measures above, without obvious need, except the 
misunderstood principle "separate recursive and authoritative servers".



With this in mind, I feel like the type of zone; primary / secondary / 
mirror / stub / static-stub / forward, makes little difference in and 
of itself.  Rather, it would be dependent on global and / or per-zone 
allow-* statements to protect the server / zone(s) at the BIND 
application level.


Does that make sense?

What am I missing / misunderstanding?


the point is to make the system simple and robust.

separating DNS servers may make DNS more robust and it may make DNS less 
robust.



Bob describes access to different zones from different clients (internal, 
wi-fi, ...) configured on recursive server.


There's no visible gain if Bob moves internal zones to another server.

However there are still some questions to this
https://lists.isc.org/pipermail/bind-users/2022-October/106764.html

- where/how/why is TSIG used
- how is the DNS configured now, don't internal recursive servers have 
  access to the internet now?




--
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.
Fighting for peace is like fucking for virginity...
--
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: Question About Internal Recursive Resolvers

[Grant Taylor via bind-users]

On 10/15/22 10:34 AM, Matus UHLAR - fantomas wrote:
If you are an ISP/registry/DNS provider, it makes sense to separate 
authoritative zones for your clients' domains, for all those cases your 
client move their domains somewhere else without notifying you (hell, 
they do that too often), or to be able to prepare moving domains to your 
servers.


#truth


forward zones - named sends recursive query to the primary servers
stub zones- named fetches NS records from primary servers and 
uses them for resolution
static-stub zones - named forwards iterative (non-recursive) requests to 
primary servers


clients accessing any of these zones must have recursion allowed and 
recursion must be enabled in BIND.


Please clarify where recursion needs to be allowed; the BIND server 
clients are talking to and / or the back end server that BIND is talking 
to on the client's behalf.


I'm not completely clear and I think it's better to ask than to assume 
incorrectly.



On 10/15/22 10:03 AM, Bob McDonald wrote:
If a non-secure client (read the next sentence...) accesses the same 
recursive server as a regular client, it will have access to the 
internal zones by default.. Therefore we need to have some sort of 
access controls in place.
and THIS is exactly the reason you SHOULD put your internal zones on 
your internal server.


Sorry if I'm being particularly dense this morning, but I'm not 
following ~> understanding Bob's and Matus's statements like I want to.


How does hosting the zone on an internal server provide any additional 
security?  Or are you simply relying on other security mechanisms to 
prevent non-secure clients -- as Bob described them -- from accessing 
the server ~> zone?


I feel like, by default -- as Bob described, any hosted zone is going to 
be accessible by any client that can query the server.


With this in mind, I feel like the type of zone; primary / secondary / 
mirror / stub / static-stub / forward, makes little difference in and of 
itself.  Rather, it would be dependent on global and / or per-zone 
allow-* statements to protect the server / zone(s) at the BIND 
application level.


Does that make sense?

What am I missing / misunderstanding?


that's why we are here.


:-)



--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Question About Internal Recursive Resolvers

[Grant Taylor via bind-users]

On 10/15/22 10:03 AM, Bob McDonald wrote:
My understanding has always been that the recommendation is/was to 
separate recursive and non-recursive servers.


I too (had) long shared -- what I'm going to retroactively call -- that 
over simplification.


Now I understand I'm talking about an INTERNAL environment and the 
rules have over the years become somewhat lax... In this case I also 
believe this would provide a more granular approach to using security 
features such as tsig keys to control updates.


I don't know if the rules have become more lax so much as been clarified 
to indicate internal / private vs external / (semi)public servers. 
Semi-public in things like an ISP allows it's IP space to perform 
recursive queries.


If a non-secure client (read the next sentence...) accesses the same 
recursive server as a regular client, it will have access to the 
internal zones by default.. Therefore we need to have some sort of 
access controls in place.


I think the emphasis is on "by default".  I also believe there are many 
ways to alter this default behavior.


Please forgive me if my post was confusing, arrogant, or naive. I'm 
simply trying to seek the wisdom of those on the list that have more 
experience or different experience than myself. Hopefully, I can gain 
from that wisdom and we can provide a kind environment where those 
less educated feel mentored.


I've found that almost everyone, myself included, tends to get invested 
and energetic in discussions.  Sometimes even animated.  But as long as 
we don't make anything personal and keep things at arms length, we can 
almost always see through the fog and help / learn from each other.


By all means, feel free to dislike / disagree with things I say / do. 
Please ask why I do things.  Please share why you think / do what you do 
as I'd like to learn from you.  But please, for the love of $DEITY 
please do not perpetuate ad hominem attacks.  --  Not that anyone has in 
this thread.




--
Grant. . . .
unix || die



smime.p7s
Description: S/MIME Cryptographic Signature
-- 
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: Question About Internal Recursive Resolvers

[Matus UHLAR - fantomas]

I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only.



why?


On 15.10.22 12:03, Bob McDonald wrote:

My understanding has always been that the recommendation is/was to
separate recursive and non-recursive servers. Now I understand I'm
talking about an INTERNAL environment and the rules have over the
years become somewhat lax... In this case I also believe this would
provide a more granular approach to using security features such as
tsig keys to control updates.


This is a common misconception.

Yes, it's a good idea to separate recursive servers accessed/used by your 
clients from authoritative servers accessed/used by whole internet.


But this does NOT mean that internal/recursive servers must not, nor should 
not containt your internal zones, nor it means you should put your internal 
zones to your publicly accessible authoritative servers.


If you have own zones for your own usage, exactly the same way you have 
recursive servers, it makes rarely sense to put them to other servers than 
your internal/recursive servers, just put internal zones to internal servers.


If you are an ISP/registry/DNS provider, it makes sense to separate 
authoritative zones for your clients' domains, for all those cases your 
client move their domains somewhere else without notifying you (hell, they 
do that too often), or to be able to prepare moving domains to your servers.




The question is this; do I use an internal root with pointers to the
internal zones (as well as the outside DNS world) or do I include stub
zones to point at the non-recursive internal servers?



stub zones, forward zones (forward with recursion bit set) or static-stub

zones (send iterative queries to configured servers)>

Again, my understanding is that forwarding would require recursion.
Thanks for the info about stub zones etc.


forward zones - named sends recursive query to the primary servers
stub zones - named fetches NS records from primary servers and uses them for 
resolution
static-stub zones - named forwards iterative (non-recursive) requests to 
primary servers


clients accessing any of these zones must have recursion allowed and 
recursion must be enabled in BIND. 


Access to the internal DNS zones would be controlled by location.



if you have recursive servers in internal network, you don't need control
access on auth-only servers


If a non-secure client (read the next sentence...) accesses the same
recursive server as a regular client, it will have access to the
internal zones by default.. Therefore we need to have some sort of
access controls in place.


and THIS is exactly the reason you SHOULD put your internal zones on your 
internal server.



Please forgive me if my post was confusing, arrogant, or naive.


neither one.

I'm simply trying to seek the wisdom of those on the list that have more 
experience or different experience than myself.  Hopefully, I can gain from 
that wisdom and we can provide a kind environment where those less educated 
feel mentored.


that's why we are here.

--
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.
The 3 biggets disasters: Hiroshima 45, Tschernobyl 86, Windows 95
--
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: Question About Internal Recursive Resolvers

[Bob McDonald]

>>I'm thinking about redesigning an internal DNS environment. To begin
>>with, all internal DNS zones would reside on non-recursive servers
>>only.

>why?

My understanding has always been that the recommendation is/was to
separate recursive and non-recursive servers. Now I understand I'm
talking about an INTERNAL environment and the rules have over the
years become somewhat lax... In this case I also believe this would
provide a more granular approach to using security features such as
tsig keys to control updates.

>> That said, all clients would connect to recursive resolvers.

>don't they now?

They do. I'm talking about a situation where an edge layer can be
eliminated. Each recursive server would have access out to the
internet. No forwarding would be required.

>>The question is this; do I use an internal root with pointers to the
>>internal zones (as well as the outside DNS world) or do I include stub
>>zones to point at the non-recursive internal servers?

>stub zones, forward zones (forward with recursion bit set) or static-stub
zones (send iterative queries to configured servers)>

Again, my understanding is that forwarding would require recursion.
Thanks for the info about stub zones etc.

>>Access to the internal DNS zones would be controlled by location.

>if you have recursive servers in internal network, you don't need control
>access on auth-only servers

If a non-secure client (read the next sentence...) accesses the same
recursive server as a regular client, it will have access to the
internal zones by default.. Therefore we need to have some sort of
access controls in place.

>>(e.g. guest WiFi devices would NOT have access to internal DNS
>>zones...)
>>
>>Recursive resolvers would allow implementation of features such as RPZ, etc.

>do you need RPZ for internal zones?

Since ALL recursive servers have access out to the internet, yes.

Please forgive me if my post was confusing, arrogant, or naive. I'm
simply trying to seek the wisdom of those on the list that have more
experience or different experience than myself. Hopefully, I can gain
from that wisdom and we can provide a kind environment where those
less educated feel mentored.

Bob
-- 
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: Question About Internal Recursive Resolvers

[Matus UHLAR - fantomas]

On 14.10.22 12:08, Bob McDonald wrote:

I'm thinking about redesigning an internal DNS environment. To begin
with, all internal DNS zones would reside on non-recursive servers
only.


why?


That said, all clients would connect to recursive resolvers.


don't they now?


The question is this; do I use an internal root with pointers to the
internal zones (as well as the outside DNS world) or do I include stub
zones to point at the non-recursive internal servers?


stub zones, forward zones (forward with recursion bit set) or static-stub 
zones (send iterative queries to configured servers)



Access to the internal DNS zones would be controlled by location.


if you have recursive servers in internal network, you don't need control 
access on auth-only servers.



(e.g. guest WiFi devices would NOT have access to internal DNS
zones...)

Recursive resolvers would allow implementation of features such as RPZ, etc.


do you need RPZ for internal zones?

--
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.
LSD will make your ECS screen display 16.7 million colors
--
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: Question About Internal Recursive Resolvers

[JW λ John Woodworth]

Hi Greg,Great points!  I must have forgotten how messy this got :) ./John
 Original message From: Greg Choules 
Hi John.Yes, you *could* forward and that 
was a setup I inherited a good few years ago. The appeal is obvious: it's easy 
to do; just chuck queries over there and get answers.But forwarding keeps the 
RD bit set, meaning that the server being forwarded to should a) have recursion 
enabled (though it will still answer if it is authoritative anyway) and b) is 
now obliged to try and find an answer, so if the people who run that server 
happen to configure forwarding somewhere else you can potentially end up with 
long, ugly chains of forwarding, even loops. None of stub, static-stub or 
mirror do this.Just my 2p.GregOn Fri, 14 Oct 2022 at 17:38, JW λ John Woodworth 
 wrote:Hi Bob,I've been able to do this with 'forward' zones. 
 The config would go in the resolver but the files would not./John 
Original message From: Bob McDonald I'm thinking 
about redesigning an internal DNS environment. To beginwith, all internal DNS 
zones would reside on non-recursive serversonly. That said, all clients would 
connect to recursive resolvers.The question is this; do I use an internal root 
with pointers to theinternal zones (as well as the outside DNS world) or do I 
include stubzones to point at the non-recursive internal servers?Access to the 
internal DNS zones would be controlled by location.(e.g. guest WiFi devices 
would NOT have access to internal DNSzones...)Recursive resolvers would allow 
implementation of features such as RPZ, etc.Regards,Bob-- Visit 
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this 
listISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.bind-users 
mailing 
listbind-us...@lists.isc.orghttps://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: Question About Internal Recursive Resolvers

[Greg Choules via bind-users]

Hi John.
Yes, you *could* forward and that was a setup I inherited a good few years
ago. The appeal is obvious: it's easy to do; just chuck queries over there
and get answers.
But forwarding keeps the RD bit set, meaning that the server being
forwarded to should a) have recursion enabled (though it will still answer
if it is authoritative anyway) and b) is now obliged to try and find an
answer, so if the people who run that server happen to configure forwarding
somewhere else you can potentially end up with long, ugly chains of
forwarding, even loops. None of stub, static-stub or mirror do this.

Just my 2p.
Greg

On Fri, 14 Oct 2022 at 17:38, JW λ John Woodworth  wrote:

> Hi Bob,
>
> I've been able to do this with 'forward' zones.  The config would go in
> the resolver but the files would not.
>
>
> /John
>
>  Original message 
> From: Bob McDonald 
>
> I'm thinking about redesigning an internal DNS environment. To begin
> with, all internal DNS zones would reside on non-recursive servers
> only. That said, all clients would connect to recursive resolvers.
>
> The question is this; do I use an internal root with pointers to the
> internal zones (as well as the outside DNS world) or do I include stub
> zones to point at the non-recursive internal servers?
>
> Access to the internal DNS zones would be controlled by location.
> (e.g. guest WiFi devices would NOT have access to internal DNS
> zones...)
>
> Recursive resolvers would allow implementation of features such as RPZ,
> etc.
>
> Regards,
>
> Bob
> --
> 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: Question About Internal Recursive Resolvers

[JW λ John Woodworth]

Hi Bob,I've been able to do this with 'forward' zones.  The config would go in 
the resolver but the files would not./John
 Original message From: Bob McDonald I'm 
thinking about redesigning an internal DNS environment. To beginwith, all 
internal DNS zones would reside on non-recursive serversonly. That said, all 
clients would connect to recursive resolvers.The question is this; do I use an 
internal root with pointers to theinternal zones (as well as the outside DNS 
world) or do I include stubzones to point at the non-recursive internal 
servers?Access to the internal DNS zones would be controlled by location.(e.g. 
guest WiFi devices would NOT have access to internal DNSzones...)Recursive 
resolvers would allow implementation of features such as RPZ, etc.Regards,Bob-- 
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this listISC funds the development of this software with paid support 
subscriptions. Contact us at https://www.isc.org/contact/ for more 
information.bind-users mailing 
listbind-us...@lists.isc.orghttps://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: Question About Internal Recursive Resolvers

[Greg Choules via bind-users]

Hi Bob.
In a previous life I did just this. Large resolvers for customers and
internal users, defaulting to the Internet but with specific configuration
to internal auth-only servers for private zones (I used stub but
static-stub and mirror are alternatives - they each behave slightly
differently). In my case these resolvers forwarded (only) to Internet-edge
resolvers, which then did recursion. There were no internal roots anywhere.
Essentially the idea was, treat internal resolution as specific exceptions
to the general rule of "everything lives in the Internet".

One note of caution is, beware DNSSEC validation. These days it is on by
default, which is not necessarily a problem, even if your internal zones
aren't signed. But what it does mean is that internal zones *must* be
properly delegated from parent zones in the Internet, otherwise the chain
of trust will be broken and validation will fail. e.g. if your registered
domain in the outside world is "example.com" then a valid internal zone
could be "internal.example.com".
You can configure BIND to *not* validate certain zones, which is a way
around it. But I'd recommend doing it right from the start, if you have the
option.

I hope that helps.
Greg

On Fri, 14 Oct 2022 at 17:08, Bob McDonald  wrote:

> I'm thinking about redesigning an internal DNS environment. To begin
> with, all internal DNS zones would reside on non-recursive servers
> only. That said, all clients would connect to recursive resolvers.
>
> The question is this; do I use an internal root with pointers to the
> internal zones (as well as the outside DNS world) or do I include stub
> zones to point at the non-recursive internal servers?
>
> Access to the internal DNS zones would be controlled by location.
> (e.g. guest WiFi devices would NOT have access to internal DNS
> zones...)
>
> Recursive resolvers would allow implementation of features such as RPZ,
> etc.
>
> Regards,
>
> Bob
> --
> 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: Question about dnstap

[Borja Marcos]

> On 13 Sep 2022, at 14:34, Peter  wrote:
> 
> Apparently, the first connect() happens (after chroot but) before
> droppings priviledges.
> (The FreeBSD integration script does set -u to UID "bind", by default.)
> 
> So, apparently, fstrm_capture should also run as UID "bind" (and would
> then need a proper filespace where it is allowed to create that
> socket). Or something else along that line.
> 
> The OP should check if their problem suddenly resolves when doing a
> "chmod 777" on that socket (and then devise a suitable design
> according to their security policy).

My fault indeed, sorry! *blush*.

Actually my confusion was slightly more stupid but still a permissions issue.

My apologies!




Borja.

-- 
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: Question about dnstap

[Peter]

On Tue, Sep 13, 2022 at 12:24:15PM +0200, Petr Špaček wrote:
! On 12. 09. 22 15:49, Peter wrote:
! > On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! > ! My testing did not uncover anything problematic.
! > !
! > ! Versions:
! > ! fstrm 0.6.1-1
! > ! protobuf 21.5-1
! > ! protobuf-c 1.4.1-1
! > !
! > !
! > ! A procedure which works:
! > ! - start BIND configured with
! > ! options {
! > !   dnstap { all; };
! > !   dnstap-output unix "/tmp/unix";
! > ! };
! > !
! > ! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u 
/tmp/unix
! > ! -w /tmp/capture
! > !
! > ! - fire couple queries: sleep 6 && dig bla example
! > !
! > ! - check content of /tmp/capture with dnstap-read: dnstap-read -y 
/tmp/cature
! > 
! > Negative. Does not work here:
! > 
! > /tmp # ls -la capture
! > -rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
! > /tmp # dnstap-read -y /tmp/capture
! > /tmp # named -V
! > BIND 9.16.30 (Extended Support Version) 
! > running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
! 
! Unfortunately neither me on Linux or my colleague who testing on FreeBSD are
! able to reproduce the problem you describe.

Okay, thank You for checking. I didn't look into the matter since I
got my things working nevertheless.
It looks a bit different now as not only me is experiencing the
behaviour.

! There is a caveat, though: Without the --split interval option one has to
! terminate fstrm_capture to get data for dnstap-read to consume. That's
! probably by design and outside of our control (in libfstrm).

This would then happen no matter if fstrm_capture is started before or
after named.


Let's have a short look.
truss tells me that named is trying to open the socket, and receives
ECONNREFUSED.
Then, after every 5 seconds (just as the docs say) it tries again, but
now it receives EPERM !

Apparently, the first connect() happens (after chroot but) before
droppings priviledges.
(The FreeBSD integration script does set -u to UID "bind", by default.)

So, apparently, fstrm_capture should also run as UID "bind" (and would
then need a proper filespace where it is allowed to create that
socket). Or something else along that line.

The OP should check if their problem suddenly resolves when doing a
"chmod 777" on that socket (and then devise a suitable design
according to their security policy).

It's a joy to work with you folks, as always. :)

-- 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: Question about dnstap

[Petr Špaček]

On 12. 09. 22 15:49, Peter wrote:

On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! My testing did not uncover anything problematic.
!
! Versions:
! fstrm 0.6.1-1
! protobuf 21.5-1
! protobuf-c 1.4.1-1
!
!
! A procedure which works:
! - start BIND configured with
! options {
!   dnstap { all; };
!   dnstap-output unix "/tmp/unix";
! };
!
! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! -w /tmp/capture
!
! - fire couple queries: sleep 6 && dig bla example
!
! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature

Negative. Does not work here:

/tmp # ls -la capture
-rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
/tmp # dnstap-read -y /tmp/capture
/tmp # named -V
BIND 9.16.30 (Extended Support Version) 
running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1


Unfortunately neither me on Linux or my colleague who testing on FreeBSD 
are able to reproduce the problem you describe.


There is a caveat, though: Without the --split interval option one has 
to terminate fstrm_capture to get data for dnstap-read to consume. 
That's probably by design and outside of our control (in libfstrm).


Have you terminated fstrm_capture before reading the file?

--
Petr Špaček

--
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: Question about dnstap

[Peter]

On Mon, Sep 12, 2022 at 03:01:38PM +0200, Petr Špaček wrote:
! My testing did not uncover anything problematic.
! 
! Versions:
! fstrm 0.6.1-1
! protobuf 21.5-1
! protobuf-c 1.4.1-1
! 
! 
! A procedure which works:
! - start BIND configured with
! options {
!   dnstap { all; };
!   dnstap-output unix "/tmp/unix";
! };
! 
! - after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u /tmp/unix
! -w /tmp/capture
! 
! - fire couple queries: sleep 6 && dig bla example
! 
! - check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature

Negative. Does not work here:

/tmp # ls -la capture
-rw-r--r--  1 root  wheel  42 Sep 12 15:42 capture
/tmp # dnstap-read -y /tmp/capture
/tmp # named -V
BIND 9.16.30 (Extended Support Version) 
running on FreeBSD amd64 13.1-RELEASE-p2 FreeBSD 13.1-RELEASE-p2 
n250182-0c5ca3f87266[0c5ca3f87266=752f813d6ccc+24] C6R13V1
built by make with '--disable-linux-caps' '--localstatedir=/var' 
'--sysconfdir=/usr/local/etc/namedb' '--with-dlopen=yes' '--without-python' 
'--with-libxml2' '--with-openssl=/usr' '--with-readline=-L/usr/local/lib 
-ledit' '--with-dlz-filesystem=yes' '--enable-dnstap' '--disable-fixed-rrset' 
'--disable-geoip' '--without-maxminddb' '--with-gssapi=/usr' 
'CFLAGS=-I/usr/include -O2 -pipe -march=haswell -DLIBICONV_PLUG 
-fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing ' 
'LDFLAGS= -fstack-protector-strong ' 'LIBS=-lkrb5 -lgssapi -lgssapi_krb5 
-L/usr/local/lib' 'KRB5CONFIG=/usr/bin/krb5-config' '--with-libidn2=/usr/local' 
'--without-json-c' '--disable-largefile' '--without-lmdb' 
'--disable-native-pkcs11' '--enable-querytrace' '--enable-tcp-fastopen' 
'--disable-symtable' '--prefix=/usr/local' '--mandir=/usr/local/man' 
'--infodir=/usr/local/share/info/' '--build=amd64-portbld-freebsd13.1' 
'build_alias=amd64-portbld-freebsd13.1' 'CC=cc' 'CPPFLAGS=-DLIBICONV_PLUG 
-isystem /usr/local/include' 'CPP=cpp' 'PKG_CONFIG=pkgconf' 
'PKG_CONFIG_LIBDIR=/var/local/ports/usr/ports/dns/bind916/work/.pkgconfig:/usr/local/libdata/pkgconfig:/usr/libdata/pkgconfig'
 'PYTHON=/usr/local/bin/python3.8'
compiled by CLANG FreeBSD Clang 13.0.0 (g...@github.com:llvm/llvm-project.git 
llvmorg-13.0.0-0-gd7b669b3a303)
compiled with OpenSSL version: OpenSSL 1.1.1o-freebsd  3 May 2022
linked to OpenSSL version: OpenSSL 1.1.1o-freebsd  3 May 2022
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libxml2 version: 2.9.13
linked to libxml2 version: 20913
compiled with zlib version: 1.2.12
linked to zlib version: 1.2.12
compiled with protobuf-c version: 1.4.0
linked to protobuf-c version: 1.4.0
threads 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: Question about dnstap

[Peter]

On Mon, Sep 12, 2022 at 12:27:25PM +0200, Borja Marcos wrote:

! I am not sure this is intended behavior, or maybe I should file a bug.
! 
! I am doing some tests with dnstap and bind (9.18.6 now but I see the same 
behavior with older 9.18 versions). I am using
! dnstap-go.
! 
! I have configured bind to use dnstap with no other options and using a Unix 
domain socket. (On named.conf, dnstap {all;};).
! 
! If I start named but the dnstap collector is not running it will never try to 
connect. I need to start the dnstap program 
! _before_ starting named. 
! 
! From the named.conf documentation I assumed that bind would retry the dnstap 
connection periodically. (fstrm-reopen-interval).

I don't know if intended or not, but when configuring dnstap I
noticed the same behaviour.

I tried at first to write to a file, but not by any means could I get
the file rotation to work. Then I considered writing to a file that is
a named pipe - but that would require the reading program to reopen
whenever named might be restarted. Finally I resorted to the socket,
and noticed that the reader program now must not be restarted while
named is running.
I can live with that.

bind916-9.16.30
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3
(Probably slightly lower versions at the time of testing.)

FreeBSD 13.1-RELEASE-p2, w/ some patches, all ports locally built,
build logs available on request.
(Maybe FreeBSD 12.3 at the time of testing.)
-- 
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: Question about dnstap

[Petr Špaček]

On 12. 09. 22 12:27, Borja Marcos wrote:

Hi,


I am not sure this is intended behavior, or maybe I should file a bug.

I am doing some tests with dnstap and bind (9.18.6 now but I see the same 
behavior with older 9.18 versions). I am using
dnstap-go.

I have configured bind to use dnstap with no other options and using a Unix 
domain socket. (On named.conf, dnstap {all;};).

If I start named but the dnstap collector is not running it will never try to 
connect. I need to start the dnstap program
_before_ starting named.

 From the named.conf documentation I assumed that bind would retry the dnstap 
connection periodically. (fstrm-reopen-interval).

Is that correct or I am making a wrong assumption? I think at least it would be 
desirable to have bind reconnect in case the dnstap
collector was restarted for whatever reason.

Versions:

bind 9.18.6
fstrm-0.6.1
protobuf-3.20.1,1
protobuf-c-1.4.0_3


My testing did not uncover anything problematic.

Versions:
fstrm 0.6.1-1
protobuf 21.5-1
protobuf-c 1.4.1-1


A procedure which works:
- start BIND configured with
options {
dnstap { all; };
dnstap-output unix "/tmp/unix";
};

- after BIND starts run fstrm_capture -t protobuf:dnstap.Dnstap -u 
/tmp/unix -w /tmp/capture


- fire couple queries: sleep 6 && dig bla example

- check content of /tmp/capture with dnstap-read: dnstap-read -y /tmp/cature

Seems all good to me. I suggest checking it using the fstrm tools to the 
dnstap-go can be eliminated from the equation.


--
Petr Špaček

--
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: Question about additional section in BIND-responses

[Matus UHLAR - fantomas]

On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote:

Using BIND-9.18.5 as a recursive server:
What's the reason, that BIND answers with the additional section for the
the following query where for example Knot resolver and also PowerDNS
resolver doesn't add the additional section for the same query?

[...]

Any hints why BIND adds the additional section while other resolvers
doesn't? Is there an option in BIND to behave like Knot/PDNS?



On 8/17/22 02:27, Evan Hunt wrote:

The option is "minimal-responses".  If you set it to "yes", it will omit
authority and additional section data except when necessary.

The default is "no-auth-recursive", which omits authority section data
when it isn't strictly necessary, but will still add additional data for
records in the answer section.



On 8/17/22 06:45, Tom wrote:
I've already set "minimal-responses yes;", but the additional 
section/data is still shown. So based on your explanation, BIND 
assumes, this data is necessary, why? And why behaves BIND different 
here than Knot/PDNS where no additional section is shown for the 
same query?


On 22.08.22 15:06, Tom wrote:
Does an BIND expert has an idea or an explanation, why the additional 
section is still shown, although "minimal-responses yes;" is set? And 
why the additional section seems necessary for BIND and not for 
example for Knot/PDNS for the same query?


ftp://ftp.isc.org/isc/bind9/9.18.5/doc/arm/html/reference.html#namedconf-statement-minimal-responses

yes: the server only adds records to the authority and additional sections 
when such records are required by the DNS protocol (for example, when 
returning delegations or negative responses).  This provides the best server 
performance but may result in more client queries.



--
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.
Support bacteria - they're the only culture some people have.
--
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 18:04, Greg Choules wrote:

Hi again J.
If I understand correctly, you want to enable querylog on a busy 
recursive server permanently, rotate the files once a day and don't care 
if you lose some logs because the number of queries on a busy day 
generates more data than the specified log file is allowed to contain.


My question has to be, why?

Firstly, querylog is not an efficient way to record information about 
what your clients are doing, dnstap is far more efficient if you want a 
record of some or all information about queries and/or their responses. 
If using files to retain this information, the rotation choices are the 
same as for channels. If your server is only handling a few 10s or 100s 
QPS, querylog will do. But if it's handling 1000s times more than that 
you will cause it unnecessary extra stress and dnstap is your friend.


Secondly, if you insist on using querylog (actually, this also applies 
to dnstap), why not just leave named to rotate the files based on size 
and number, allowing for the set of files to be easily large enough to 
contain (say) a week's worth of data. Then you could run a cron job to 
grep today's logs and do what you want with them. You don't have to 
worry about other processes sending commands to named to cause something 
to happen, it just gets on with it.


/soapbox.


Hi Greg,

Yes, that's correct.  The size limit for the busy day is actually much 
larger than I think it would ever get.  I want a size limit to ensure 
that the query logs are not eating up too much disk space.  The size 
limit of a days' log will never get that high, but if it does, the disk 
is not filled up.  In that case, I understand logging for that day may 
be incomplete because Bind would stop logging if I it did get to 1 G, 
but for this server and the purpose it serves, it's never going to reach 
1 G.


I like to have an upper bound on logs to prevent disk from being filled up.

I am familiar with dnstap but am looking for a more simple solution at 
this time.  I agree it is probably the most correct tool for most jobs, 
but in this case text logs for queries are fine.


I could also do as you suggest with cron and grep, but I'm not concerned 
with sending commands via a separate process (rndc) as that is the 
current method of sending commands to Bind.  The big goal is to have 
compressed logs for 24 hours of queries, holding onto that data for a 
week.  I think that's achievable by newsyslog.


It would be great to know if:

/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true

...is the correct trigger for named to open a new log.  Can anyone 
provide feedback on that ?


Thanks,

- J
--
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: Question regarding newsyslog.conf and Bind logs

[Greg Choules via bind-users]

Hi again J.
If I understand correctly, you want to enable querylog on a busy recursive
server permanently, rotate the files once a day and don't care if you lose
some logs because the number of queries on a busy day generates more data
than the specified log file is allowed to contain.

My question has to be, why?

Firstly, querylog is not an efficient way to record information about what
your clients are doing, dnstap is far more efficient if you want a record
of some or all information about queries and/or their responses. If using
files to retain this information, the rotation choices are the same as for
channels. If your server is only handling a few 10s or 100s QPS, querylog
will do. But if it's handling 1000s times more than that you will cause it
unnecessary extra stress and dnstap is your friend.

Secondly, if you insist on using querylog (actually, this also applies to
dnstap), why not just leave named to rotate the files based on size and
number, allowing for the set of files to be easily large enough to contain
(say) a week's worth of data. Then you could run a cron job to grep today's
logs and do what you want with them. You don't have to worry about other
processes sending commands to named to cause something to happen, it just
gets on with it.

/soapbox.

On Thu, 25 Aug 2022 at 22:08, J Doe  wrote:

> On 2022-08-25 16:46, Richard T.A. Neal wrote:
>
> > Hi J,
> >
> > I'm coming a little late to the party on this one and I think you might
> struggle to do rotation based on both date/time *and* file size, but I use
> logrotate to rotate all of my BIND logs daily, keeping 31 days of logs. And
> you'll see that one of the last things that logrotate does is to call [rndc
> reconfig] which causes BIND to generate fresh log files in place of the
> rotated ones.
> >
> > My BIND logging itself is setup based largely on the configuration
> described here:
> > https://kb.isc.org/docs/aa-01526
> >
> > My logrotate.conf file then looks like this the following, which itself
> is based on this:
> > https://ixnfo.com/en/logrotate-bind9.html
> >
> > #-
> > # RTAN BIND 9 daily log rotation
> > #
> > # Note that the log file won't rotate until at least one day AFTER you
> set this for the first time.
> > # Eg if you create this file on a Wednesday then they won't rotate for
> the first time until THURSDAY night:
> > #
> https://serverfault.com/questions/375004/logrotate-not-rotating-the-logs
> > #-
> >
> > /var/log/named/*.log
> > {
> >olddir /var/log/named/archived
> >compress
> >create 0644 bind bind
> >daily
> >dateext
> >missingok
> >notifempty
> >rotate 31
> >sharedscripts
> >postrotate
> >  /usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true
> >endscript
> > }
> > #-
> >
> > Best,
> > Richard.
>
> Hi Richard,
>
> Thank you for your reply.  I am not attempting to configure the server
> so that rotation is based on size *and* time.  The size configuration in
> the logging stanza was more to put an upper limit on a log *before* it
> is rotated.  I could drop the parts that mention 2 versions and
> incrementing the filename and just keep: size 1G.
>
> Let's say it's an extremely busy day and my Bind recursive resolver logs
> are getting really big.  I want the maximum size a day's logs can be
> *before* they are compressed to be 1G.  I am aware that if the server is
> still under heavy load that queries past that point will not be logged.
>
> Then, at the end of the day, newsyslog compresses the logs and rotates
> them so that I keep 7 days worth of compressed logs.
>
> The logrotate your example uses looks good, but I'm on a very minimal
> OpenBSD 7.1 host.  I could add the logrotate package, but newsyslog is
> in the base system and I already use it for doing the same kind of log
> rotation for my firewall logs, so I was hoping to stick to newsyslog.
>
> The postrotate directive in the logrotate example you sent me was what I
> was basing my newsyslog config on, as it uses rndc and not pkill SIGHUP.
>
> I am assuming it would work with newsyslog, or am I incorrect about that ?
>
> Thanks again,
>
> - J
> --
> 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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 16:46, Richard T.A. Neal wrote:


Hi J,

I'm coming a little late to the party on this one and I think you might 
struggle to do rotation based on both date/time *and* file size, but I use 
logrotate to rotate all of my BIND logs daily, keeping 31 days of logs. And 
you'll see that one of the last things that logrotate does is to call [rndc 
reconfig] which causes BIND to generate fresh log files in place of the rotated 
ones.

My BIND logging itself is setup based largely on the configuration described 
here:
https://kb.isc.org/docs/aa-01526

My logrotate.conf file then looks like this the following, which itself is 
based on this:
https://ixnfo.com/en/logrotate-bind9.html

#-
# RTAN BIND 9 daily log rotation
#
# Note that the log file won't rotate until at least one day AFTER you set this 
for the first time.
# Eg if you create this file on a Wednesday then they won't rotate for the 
first time until THURSDAY night:
# https://serverfault.com/questions/375004/logrotate-not-rotating-the-logs
#-

/var/log/named/*.log
{
   olddir /var/log/named/archived
   compress
   create 0644 bind bind
   daily
   dateext
   missingok
   notifempty
   rotate 31
   sharedscripts
   postrotate
 /usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true
   endscript
}
#-

Best,
Richard.


Hi Richard,

Thank you for your reply.  I am not attempting to configure the server 
so that rotation is based on size *and* time.  The size configuration in 
the logging stanza was more to put an upper limit on a log *before* it 
is rotated.  I could drop the parts that mention 2 versions and 
incrementing the filename and just keep: size 1G.


Let's say it's an extremely busy day and my Bind recursive resolver logs 
are getting really big.  I want the maximum size a day's logs can be 
*before* they are compressed to be 1G.  I am aware that if the server is 
still under heavy load that queries past that point will not be logged.


Then, at the end of the day, newsyslog compresses the logs and rotates 
them so that I keep 7 days worth of compressed logs.


The logrotate your example uses looks good, but I'm on a very minimal 
OpenBSD 7.1 host.  I could add the logrotate package, but newsyslog is 
in the base system and I already use it for doing the same kind of log 
rotation for my firewall logs, so I was hoping to stick to newsyslog.


The postrotate directive in the logrotate example you sent me was what I 
was basing my newsyslog config on, as it uses rndc and not pkill SIGHUP.


I am assuming it would work with newsyslog, or am I incorrect about that ?

Thanks again,

- J
--
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: Question regarding newsyslog.conf and Bind logs

[Richard T.A. Neal]

J wrote:

> I'm looking to have my: queries.log (which logs all the queries my Bind
> 9.16.30 recursive resolver resolves), rotated at the end of the day and I'd 
> like to keep 7 days worth of those logs.
   {snip}
> I still want any daily log *before* it's being rotated to be a maximum size 
> of 1 GB.

Hi J,

I'm coming a little late to the party on this one and I think you might 
struggle to do rotation based on both date/time *and* file size, but I use 
logrotate to rotate all of my BIND logs daily, keeping 31 days of logs. And 
you'll see that one of the last things that logrotate does is to call [rndc 
reconfig] which causes BIND to generate fresh log files in place of the rotated 
ones.

My BIND logging itself is setup based largely on the configuration described 
here:
https://kb.isc.org/docs/aa-01526

My logrotate.conf file then looks like this the following, which itself is 
based on this:
https://ixnfo.com/en/logrotate-bind9.html

#-
# RTAN BIND 9 daily log rotation
#
# Note that the log file won't rotate until at least one day AFTER you set this 
for the first time.
# Eg if you create this file on a Wednesday then they won't rotate for the 
first time until THURSDAY night:
# https://serverfault.com/questions/375004/logrotate-not-rotating-the-logs
#-

/var/log/named/*.log
{
  olddir /var/log/named/archived
  compress
  create 0644 bind bind
  daily
  dateext
  missingok
  notifempty
  rotate 31
  sharedscripts
  postrotate
/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true
  endscript
}
#-

Best,
Richard.
-- 
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 04:52, Anand Buddhdev wrote:


On 25/08/2022 05:23, J Doe wrote:

Hello J Doe,

I was wondering if anyone could provide feedback on whether the 
following: newsyslog.conf file is correct to allow for daily log 
rotation for my Bind 9.16.30 logs ?


My currently logging settings in: named.conf are:

 ...
 logging {
 channel chn_file_queries {
 buffered no;
 file "/var/queries.log"
 versions 2 size 1g suffix increment;


This configuration makes BIND rotate the file by itself, when it grows 
bigger than 1 GB. You do NOT need any external tool like newsyslog to do 
log file rotation.


Regards,
Anand


Hi Anand,

Yes, I am aware that the logging stanza I listed for the query log will 
do the rotation when the log reaches 1 GB and then it will rotate it and 
store two logs in total.


What I would like to introduce is rotation based on time.  So after 24 
hours, newsyslog would compress and rotate the logs and keep them for 7 
days before removing the oldest.  That way I always have a week's worth 
of query data in separate logs by day.


Was my newsyslog.conf file correct for that ?

Thanks,

- J

--
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: Question regarding newsyslog.conf and Bind logs

[J Doe]

On 2022-08-25 03:05, Greg Choules wrote:


Hello J
What is it you're actually trying to achieve here?

Cheers, Greg


Hi Greg,

I'm looking to have my: queries.log (which logs all the queries my Bind 
9.16.30 recursive resolver resolves), rotated at the end of the day and 
I'd like to keep 7 days worth of those logs.


I didn't see anywhere in the log rotation options for: named.conf that 
mentioned rotation based on *time*.  I saw I can configure rotations 
based on the size of the file, but I'd like rotation to happen once 
every 24 hours.


With that in mind, I believe I could change the logging stanza from:

file "/var/queries.log"
versions 2 size 1G suffix increment;

to (syntax might be incorrect):

file "/var/queries.log"
size 1G;

I still want any daily log *before* it's being rotated to be a maximum 
size of 1 GB.


I believe my: newsyslog.conf line to rotate the logs daily is correct, 
except I wasn't entirely sure what the: rndc equivalent of sending 
SIGHUP to Bind was, as the ARM and man note that sending signals to 
control Bind is deprecated.


Thanks,

- J
--
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: Question regarding newsyslog.conf and Bind logs

[Anand Buddhdev]

On 25/08/2022 05:23, J Doe wrote:

Hello J Doe,

I was wondering if anyone could provide feedback on whether the 
following: newsyslog.conf file is correct to allow for daily log 
rotation for my Bind 9.16.30 logs ?


My currently logging settings in: named.conf are:

     ...
     logging {
     channel chn_file_queries {
     buffered no;
     file "/var/queries.log"
     versions 2 size 1g suffix increment;


This configuration makes BIND rotate the file by itself, when it grows 
bigger than 1 GB. You do NOT need any external tool like newsyslog to do 
log file rotation.


Regards,
Anand
--
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: Question regarding newsyslog.conf and Bind logs

[Greg Choules via bind-users]

Hello J
What is it you're actually trying to achieve here?

Cheers, Greg

On Thu, 25 Aug 2022 at 04:24, J Doe  wrote:

> Hello,
>
> I was wondering if anyone could provide feedback on whether the
> following: newsyslog.conf file is correct to allow for daily log
> rotation for my Bind 9.16.30 logs ?
>
> My currently logging settings in: named.conf are:
>
>  ...
>  logging {
>  channel chn_file_queries {
>  buffered no;
>  file "/var/queries.log"
>  versions 2 size 1g suffix increment;
>  print-category yes;
>  print-severity yes;
>  print-time yes;
>  severity info;
>  };
>  ...
>  };
>  ...
>
> newsyslog.conf examples tend to make use of: pkill but I note in the
> Bind ARM and man page that signals are deprecated in favor of: rndc.
>
> I am *thinking* the following should work for newsyslog.conf
>
> /var/named/var/queries.log6407 *$D0  Z
> "/usr/sbin/rndc reconfig > /dev/null 2>/dev/null || true"
>
> So settings:
>
>  Log path: My Bind is running in chroot
>  File mode:0640
>  Log count:7 (1 per day)
>  Size limit:   none
>  Frequency:$D0 (daily)
>  Flags:z to compress
>  Binary:   rndc (instead of pkill)
>
> Is this correct ?
>
> Thank you,
>
> - J
> --
> 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: Question about additional section in BIND-responses

[Tom]

On 8/17/22 06:45, Tom wrote:



On 8/17/22 02:27, Evan Hunt wrote:

On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote:

Using BIND-9.18.5 as a recursive server:
What's the reason, that BIND answers with the additional section for the
the following query where for example Knot resolver and also PowerDNS
resolver doesn't add the additional section for the same query?

[...]

Any hints why BIND adds the additional section while other resolvers
doesn't? Is there an option in BIND to behave like Knot/PDNS?


The option is "minimal-responses".  If you set it to "yes", it will omit
authority and additional section data except when necessary.

The default is "no-auth-recursive", which omits authority section data
when it isn't strictly necessary, but will still add additional data for
records in the answer section.



I've already set "minimal-responses yes;", but the additional 
section/data is still shown. So based on your explanation, BIND assumes, 
this data is necessary, why? And why behaves BIND different here than 
Knot/PDNS where no additional section is shown for the same query?


Does an BIND expert has an idea or an explanation, why the additional 
section is still shown, although "minimal-responses yes;" is set? And 
why the additional section seems necessary for BIND and not for example 
for Knot/PDNS for the same query?


Many thanks for any hints.
Tom
--
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: Question about additional section in BIND-responses

[Tom]

On 8/17/22 02:27, Evan Hunt wrote:

On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote:

Using BIND-9.18.5 as a recursive server:
What's the reason, that BIND answers with the additional section for the
the following query where for example Knot resolver and also PowerDNS
resolver doesn't add the additional section for the same query?

[...]

Any hints why BIND adds the additional section while other resolvers
doesn't? Is there an option in BIND to behave like Knot/PDNS?


The option is "minimal-responses".  If you set it to "yes", it will omit
authority and additional section data except when necessary.

The default is "no-auth-recursive", which omits authority section data
when it isn't strictly necessary, but will still add additional data for
records in the answer section.



I've already set "minimal-responses yes;", but the additional 
section/data is still shown. So based on your explanation, BIND assumes, 
this data is necessary, why? And why behaves BIND different here than 
Knot/PDNS where no additional section is shown for the same query?

--
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: Question about additional section in BIND-responses

[Evan Hunt]

On Tue, Aug 16, 2022 at 05:28:19PM +0200, Tom wrote:
> Using BIND-9.18.5 as a recursive server:
> What's the reason, that BIND answers with the additional section for the 
> the following query where for example Knot resolver and also PowerDNS 
> resolver doesn't add the additional section for the same query?
> 
> [...]
> 
> Any hints why BIND adds the additional section while other resolvers 
> doesn't? Is there an option in BIND to behave like Knot/PDNS?

The option is "minimal-responses".  If you set it to "yes", it will omit
authority and additional section data except when necessary.

The default is "no-auth-recursive", which omits authority section data
when it isn't strictly necessary, but will still add additional data for
records in the answer section.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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: Question about linking jemalloc with Bind 9.18.x when doing the compile.

[Michal Nowak]

On 02/08/2022 18:46, Bhangui, Sandeep - BLS CTR via bind-users wrote:

Hello all

We are getting ready to test Bind 9.18.x. Currently we are running the 
latest version of 9.16.x branch.


We have downloaded and successfully installed the jemalloc module on the 
Server ( RHEL 7.9 OS) and getting ready to compile the latest version of 
Bind 9.18.x.


Can someone please point me to some documentation which tells as to what 
exact flags/parameters to use to properly link jemalloc when we compile 
latest version of Bind 9.18.x using “configure” so that we get the 
compile correctly done in the first run.


Thanks in advance.

Sandeep




Sandeep,

not much is needed as BIND 9's ./configure script handles it for you 
when jemalloc and jemalloc-devel packages are installed.


Just check that after ./configure is run, there are the following two lines:

Optional features enabled:
Memory allocator: jemalloc

Once BIND 9 is compiled, run "ldd /path/to/named" and look for the 
jemalloc line, it should look similar to this:


libjemalloc.so.2 => /lib64/libjemalloc.so.2 (0x7f895f20)

Michal
--
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: Question about missing bind.keys

[Evan Hunt]

On Tue, Apr 12, 2022 at 09:37:22PM -0400, J Doe wrote:
> Apologies for my late reply.  Thank you so much for the detailed 
> explanation of: dnssec-validation auto and what happens when: bind.keys 
> doesn't exist.
> 
> With this setting in place in my: named.conf I then restarted BIND, gave 
> it a second to pull the trust information and then used: delv to test 
> verification.
> 
> The first test for unverified/unsigned was:
> 
>   $ delv google.com
>   ; unsigned answer
>   . . .
> 
> ... and the second test for verified/signed was:
> 
>   $ delv ietf.org
>   ; fully validated
>   . . .
> 
> ... which wouldn't have worked if: dnssec-validation auto failed in 
> getting the same information as: bind.keys

"delv" isn't actually the right tool for this job - it does its own
internal validation, regardless of whether the name server it's querying
is doing validation correctly or not.

Instead, use "dig" to query your name server and look for the "ad" bit
(Authenticated Data) in the reponse:

$ dig @localhost unsigned.com | grep flags
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 3

$ dig @localhost ietf.org | grep flags
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
   ^^

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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: Question about missing bind.keys

[J Doe]

On 2022-03-30 02:23, Evan Hunt wrote:


On Wed, Mar 30, 2022 at 12:16:05AM -0400, J Doe wrote:

I have a question about the bind.keys file and what happens when it is
not available.

[...]

** If I don't have bind.keys in my BIND directory but have:
dnssec-validation auto in my named.conf, is BIND automatically getting
the trust anchor and storing it in managed-keys.bind so that when my
recursive resolver does a lookup and performs DNSSEC validation,
validation works ?  Or do I still need to download bind.keys from [1] ?


There's a copy of bind.keys that's compiled directly in named. If
the file isn't there, named will just use its own internal copy.

The first time named starts up with 'dnssec-validation' set to 'auto',
it fetches the current root key, validates it against its local
copy (either from bind.keys or from its own built-in copy), and then
keeps the key up to date according to the RFC 5011 protocol from
then on.

The recommendation to use bind.keys and not rely on the built-in
version was based on some assumptions that are no longer true. First,
`dnssec-validation auto` is now the default, so unless you disabled it on
purpose, you've been validating and keeping the root key up to date since
the first time you ran your server.  Second, back in those days it was
harder to get hold of regularly-updated packages for BIND, and scads
of people were running outdated code.

We were concerned that someone would be running an old version of named,
the root key would change, and *then* they'd decide to turn validation on
for the first time, and it wouldn't work. To smooth that out a bit, we
added the bind.keys file to the release tarball, and when giving tutorials
about turning on DNSSEC validation, we included a note that you should
always check whether bind.keys needed to be updated.

In today's world, I don't think it's inmportant anymore.



Hi Evan,

Apologies for my late reply.  Thank you so much for the detailed 
explanation of: dnssec-validation auto and what happens when: bind.keys 
doesn't exist.


With this setting in place in my: named.conf I then restarted BIND, gave 
it a second to pull the trust information and then used: delv to test 
verification.


The first test for unverified/unsigned was:

$ delv google.com
; unsigned answer
. . .

... and the second test for verified/signed was:

$ delv ietf.org
; fully validated
. . .

... which wouldn't have worked if: dnssec-validation auto failed in 
getting the same information as: bind.keys


- J
--
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: Question about missing bind.keys

[Evan Hunt]

On Wed, Mar 30, 2022 at 12:16:05AM -0400, J Doe wrote:
> I have a question about the bind.keys file and what happens when it is 
> not available.
[...]
> ** If I don't have bind.keys in my BIND directory but have: 
> dnssec-validation auto in my named.conf, is BIND automatically getting 
> the trust anchor and storing it in managed-keys.bind so that when my 
> recursive resolver does a lookup and performs DNSSEC validation, 
> validation works ?  Or do I still need to download bind.keys from [1] ?

There's a copy of bind.keys that's compiled directly in named. If
the file isn't there, named will just use its own internal copy.

The first time named starts up with 'dnssec-validation' set to 'auto',
it fetches the current root key, validates it against its local
copy (either from bind.keys or from its own built-in copy), and then
keeps the key up to date according to the RFC 5011 protocol from
then on.

The recommendation to use bind.keys and not rely on the built-in
version was based on some assumptions that are no longer true. First,
`dnssec-validation auto` is now the default, so unless you disabled it on
purpose, you've been validating and keeping the root key up to date since
the first time you ran your server.  Second, back in those days it was
harder to get hold of regularly-updated packages for BIND, and scads
of people were running outdated code.

We were concerned that someone would be running an old version of named,
the root key would change, and *then* they'd decide to turn validation on
for the first time, and it wouldn't work. To smooth that out a bit, we
added the bind.keys file to the release tarball, and when giving tutorials
about turning on DNSSEC validation, we included a note that you should
always check whether bind.keys needed to be updated.

In today's world, I don't think it's inmportant anymore.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
-- 
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: Question about "max-zone-ttl" in dnssec-policy

[Evan Hunt]

On Tue, Sep 21, 2021 at 03:11:30PM +0200, Tom wrote:
> The documentation says, that "any record encountered with a TTL higher 
> than max-zone-ttl is capped at the maximum permissible TTL value".
> 
> Is the documentation wrong here?

It does appear to be wrong, yes.

It also differs from the behavior of the 'max-zone-ttl' zone option, which
works by preventing a zone from loading if any TTLs exceed the maximum,
rather than loading the zone but capping the TTL values.

We should probably regularize this, it's confusing to have the same option
mean two different things (not to mention being documented to mean a third).
Thanks for bringing this to our attention. I've created issue #2918 to track
it in gitlab.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
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: Question about "max-zone-ttl" in dnssec-policy

[Tom]

Hi Matthijs

Thank you for your explanation.

The documentation says, that "any record encountered with a TTL higher 
than max-zone-ttl is capped at the maximum permissible TTL value".


Is the documentation wrong here?

Thank you.
Kind regards,
Tom



On 21.09.21 09:47, Matthijs Mekking wrote:

Hi Tom,

The max-zone-ttl is there to calculate the right timings for key 
rollovers. It won't alter the zone TTL values.


You should set the max-zone-ttl to whatever the highest TTL is in your 
zone to make sure key rollovers timings are correct.


This value exists until we have added code to the key manager that will 
read the zone's contents and detect the maximum TTL automatically.


I hope this clarifies things.

Best regards,

Matthijs


On 20-09-2021 17:47, Tom wrote:

Hi list

Testing dnssec-policy with BIND-9.16.21:

I'd like to better understand the "max-zone-ttl"-directive.
So I defined "max-zone-ttl 3600s;" within the dnssec-policy-options, 
but when I configure the default zone TTL or even a ressource record 
TTL higher than the "max-zone-ttl" (for example to 7200s), then it's 
not capped, as described in the documentation.


Look here:
- Within the dnssec-policy, I've defined "max-zone-ttl 3600;"
- The RR "www.example.com." has a TTL of 7200
- The server returns a TTL of 7200

$ dig @192.168.1.10 www.example.com +dnssec +multi
...
...
;; ANSWER SECTION:
www.example.com.    7200 IN A 127.0.0.1
www.example.com.    7200 IN RRSIG A 13 3 7200 (
 20211002202425 20210920143830 42786 example.com.
 3cprtWPAOwEuUvaiV5DKYWxhJHrdU6FL7Jk2+aNavOao
 lTzQMKev2OF6TqPhXXfaHANIz+tiVhZaeaDCDagkSA== )
...
...


What do I misunderstand here?

Many thanks for a hint.

Kind regards,
Tom
___
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

___
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: Question about "max-zone-ttl" in dnssec-policy

[Matthijs Mekking]

Hi Tom,

The max-zone-ttl is there to calculate the right timings for key 
rollovers. It won't alter the zone TTL values.


You should set the max-zone-ttl to whatever the highest TTL is in your 
zone to make sure key rollovers timings are correct.


This value exists until we have added code to the key manager that will 
read the zone's contents and detect the maximum TTL automatically.


I hope this clarifies things.

Best regards,

Matthijs


On 20-09-2021 17:47, Tom wrote:

Hi list

Testing dnssec-policy with BIND-9.16.21:

I'd like to better understand the "max-zone-ttl"-directive.
So I defined "max-zone-ttl 3600s;" within the dnssec-policy-options, but 
when I configure the default zone TTL or even a ressource record TTL 
higher than the "max-zone-ttl" (for example to 7200s), then it's not 
capped, as described in the documentation.


Look here:
- Within the dnssec-policy, I've defined "max-zone-ttl 3600;"
- The RR "www.example.com." has a TTL of 7200
- The server returns a TTL of 7200

$ dig @192.168.1.10 www.example.com +dnssec +multi
...
...
;; ANSWER SECTION:
www.example.com.    7200 IN A 127.0.0.1
www.example.com.    7200 IN RRSIG A 13 3 7200 (
     20211002202425 20210920143830 42786 example.com.
     3cprtWPAOwEuUvaiV5DKYWxhJHrdU6FL7Jk2+aNavOao
     lTzQMKev2OF6TqPhXXfaHANIz+tiVhZaeaDCDagkSA== )
...
...


What do I misunderstand here?

Many thanks for a hint.

Kind regards,
Tom
___
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: [Question] About migration for 9.11.X to 9.16.X.

[Petr Menšík]

Hi,

I would recommend reading Release notes for BIND 9.16.0 and 9.14.0 as
primary source of key differences. They include most of important
differences. I don't know about good summary at single place.

Regards,

Petr

On 8/19/21 7:35 AM, Techs-yama wrote:
> Hi BIND users all.
>
> I'm thinking about BIND Version migration for 9.11.X to 9.16.X.
> Also,  I'm about to check the different default config value and
> config parameters for the purpose of that now.
>
> I would like to ask you all.
> Are there any other points of observe carefully when migrating versions?
>   e.g.)Behaves differently, Added 9.16.X only new features, etc.
> also, Is there any documentation that might be helpful?
>
> Best regards. 
>
> ___
> 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

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB

___
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: [Question] About migration for 9.11.X to 9.16.X.

[Techs-yama]

Hi, Thank you for replying.

> called README.  In it you will find the answers to your questions.
Thanks. Yes, I know that.
also, I wanted to hear from anyone who had
actual experience and knowledge about migration as opinions.

>You could also spend some quality time in the mailing list archives.
I'll also check the mailing list archives.

Thank you so much.

2021年8月19日(木) 17:26 G.W. Haywood via bind-users :

> Hi there,
>
> On Thu, 19 Aug 2021, Techs-yama wrote:
>
> > I'm thinking about BIND Version migration for 9.11.X to 9.16.X.
> > Also,  I'm about to check the different default config value and config
> > parameters for the purpose of that now.
> >
> > I would like to ask you all.
> > Are there any other points of observe carefully when migrating versions?
> >  e.g.)Behaves differently, Added 9.16.X only new features, etc.
> > also, Is there any documentation that might be helpful?
>
> The source tarball available from the ISC Website contains a file
> called README.  In it you will find the answers to your questions.
>
> You could also spend some quality time in the mailing list archives.
>
> --
>
> 73,
> Ged.
>
___
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: [Question] About migration for 9.11.X to 9.16.X.

[G.W. Haywood via bind-users]

Hi there,

On Thu, 19 Aug 2021, Techs-yama wrote:


I'm thinking about BIND Version migration for 9.11.X to 9.16.X.
Also,  I'm about to check the different default config value and config
parameters for the purpose of that now.

I would like to ask you all.
Are there any other points of observe carefully when migrating versions?
 e.g.)Behaves differently, Added 9.16.X only new features, etc.
also, Is there any documentation that might be helpful?


The source tarball available from the ISC Website contains a file
called README.  In it you will find the answers to your questions.

You could also spend some quality time in the mailing list archives.

--

73,
Ged.
___
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: Question about Recommended stress test tools for bind.

[Techs-yama]

Hi, UHLAR.

Thank you for your advice.

I'll check these templates.

Best regards.

2020年6月26日(金) 19:28 Matus UHLAR - fantomas :
>
> >On 2020-06-25 04:10, Techs-yama wrote:
> >>and How do you have any recommended statistics items to check by
> >>rndc stats.
>
> On 25.06.20 12:43, Chuck Aurora wrote:
> >I don't know what you are looking for, but I would recommend NOT
> >using rndc stats:
> >
> >https://kb.isc.org/docs/aa-00769
>
> if you want to say that xml statistics are better than rndc stads, I admin
> that they are kind fo better solution, however, I haven't found anything
> better for cacti, that could process those than what we currently have:
>
> https://docs.cacti.net/usertemplate:host:bind9.7
>
> snmp support would be great.
>
> --
> 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.
> Microsoft dick is soft to do no harm
> ___
> 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: Question about Recommended stress test tools for bind.

[Matus UHLAR - fantomas]

On 2020-06-25 04:10, Techs-yama wrote:

and How do you have any recommended statistics items to check by
rndc stats.


On 25.06.20 12:43, Chuck Aurora wrote:

I don't know what you are looking for, but I would recommend NOT
using rndc stats:

https://kb.isc.org/docs/aa-00769


if you want to say that xml statistics are better than rndc stads, I admin
that they are kind fo better solution, however, I haven't found anything
better for cacti, that could process those than what we currently have:

https://docs.cacti.net/usertemplate:host:bind9.7

snmp support would be great.

--
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.
Microsoft dick is soft to do no harm
___
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: Question about Recommended stress test tools for bind.

[Brett Delmage]

On Thu, 25 Jun 2020, Chuck Aurora wrote:


On 2020-06-25 04:10, Techs-yama wrote:

Hi, bind forks !


I'm a spoon, not a fork! :)


418 I'm a teapot!

___
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: Question about Recommended stress test tools for bind.

[Techs-yama]

Thank you for your reply!

>I'm a spoon, not a fork! :)
Oops I'm Sorry typo.

>I don't know what you are looking for, but I would recommend NOT
Are there any stats result items, I should check when I perform tuning on bind?
 e.g.) socket error,  cache memory in use, and more...

Thank you and best regards.



2020年6月26日(金) 2:43 Chuck Aurora :
>
> On 2020-06-25 04:10, Techs-yama wrote:
> > Hi, bind forks !
>
> I'm a spoon, not a fork! :)
>
> [snip]
>
> > and How do you have any recommended statistics items to check by
> > rndc stats.
>
> I don't know what you are looking for, but I would recommend NOT
> using rndc stats:
>
> https://kb.isc.org/docs/aa-00769
> ___
> 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: Question about Recommended stress test tools for bind.

[Chuck Aurora]

On 2020-06-25 04:10, Techs-yama wrote:

Hi, bind forks !


I'm a spoon, not a fork! :)

[snip]


and How do you have any recommended statistics items to check by
rndc stats.


I don't know what you are looking for, but I would recommend NOT
using rndc stats:

https://kb.isc.org/docs/aa-00769
___
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: Question about expected recursive resolver behavior

[Tony Finch]

Sarah Newman  wrote:

> What should happen when for a given domain:
>
> - The domain resolves via TCP but not UDP - UDP for this domain had no
> response at all.

I would expect the domain to be completely unresolvable: the resolver will
only try TCP if it gets a truncated reaponse over UDP.

> - That authoritative nameserver hosts other domains, and those domains
> resolve via UDP.

The lack of response for some domains might cause problems for the other
domains if the resolver decides that the authoritative server is too
broken to bother asking.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
Bailey: Variable 3 or less, increasing 4 at times. Moderate. Fair. Good,
occasionally poor.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about expected recursive resolver behavior

[Sarah Newman]

On 4/23/20 12:41 PM, Chuck Aurora wrote:

On 2020-04-23 14:16, Sarah Newman wrote:

What should happen when for a given domain:

- The domain resolves via TCP but not UDP - UDP for this domain had no
response at all.
- That authoritative nameserver hosts other domains, and those domains
resolve via UDP.


Do you have an example for this?  I don't get the "no response on UDP"
part.  If the same nameserver is answering other queries on UDP, why
wouldn't at least send a REFUSED reply?

Perhaps REFUSED has been disabled somehow; that could be tested by
querying it for other non-hosted zones,

dig @ ns isc.org.


Here is my example, but it's been fixed now:

https://prgmr.com/blog/2020/04/23/debugging-freebsd-resolution-failure.html

REFUSED hasn't been disabled.

I bring this up because we had customers complaining about our resolvers not 
working and I don't know if we could/should have done better.

--Sarah
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about expected recursive resolver behavior

[Chuck Aurora]

On 2020-04-23 14:16, Sarah Newman wrote:

What should happen when for a given domain:

- The domain resolves via TCP but not UDP - UDP for this domain had no
response at all.
- That authoritative nameserver hosts other domains, and those domains
resolve via UDP.


Do you have an example for this?  I don't get the "no response on UDP"
part.  If the same nameserver is answering other queries on UDP, why
wouldn't at least send a REFUSED reply?

Perhaps REFUSED has been disabled somehow; that could be tested by
querying it for other non-hosted zones,

dig @ ns isc.org.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

ipv6, was: Re: Question About Recursion ...

[Chuck Aurora]

On 2020-04-17 11:40, Tim Daneliuk wrote:

On 4/17/20 10:17 AM, julien soula wrote:

On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:

On 4/17/20 9:50 AM, Bob Harold wrote:



'dig' should tell you what address it used, at the bottom of the
output - what does it say?


;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE  rcvd: 83

Does the SERVER line indicate it's trying to get to the local
instance via IPV6 or is this just standard notation?  (This is
an IPV4 only environment).


"::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
you should add this IP to trustedhosts to check if it works.


Aha!  That was it.  What is curious to me is that bind uses this even
in the absence of any IPV6 in the environment.

Problem solved.  Thanks all!


What "absence" is this?  You showed us that dig connected to ::1#53, 
yes,
via ipv6.  Not having external ipv6 routing is not the same as absence 
of

ipv6.  Your system DOES have ipv6 enabled.

As others have pointed out, you either need to put ::1 in your ACL, or
make a resolv.conf with "nameserver 127.0.0.1".  Personally, I always
disable the ipv6 module in the OS kernel if there is no connectivity.
And Bob (I think it was) mentioned "named -4".

Since ipv6 is the future, it's generally the default protocol in many
OSs when it is enabled.  That's why I suggest disabling it in your
kernel, to avoid this and many other problems; not just with dig &
named, but with other software as well.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Fri, Apr 17, 2020 at 12:45 PM Tim Daneliuk  wrote:

> On 4/17/20 10:17 AM, julien soula wrote:
> > On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
> >> On 4/17/20 9:50 AM, Bob Harold wrote:
> >>>
> >>> Agree, that's odd, and not what the man page says.  Any chance that
> there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
> >>
> >> Nope.  This is vanilla FreeBSD with vanilla bind running.
> >>
> >>> 'dig' should tell you what address it used, at the bottom of the
> output - what does it say?
> >>
> >>
> >>
> >> ;; Query time: 0 msec
> >> ;; SERVER: ::1#53(::1)
> >> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020
> >> ;; MSG SIZE  rcvd: 83
> >>
> >>
> >> Does the SERVER line indicate it's trying to get to the local instance
> via
> >> IPV6 or is this just standard notation?  (This is an IPV4 only
> environment).
> >
> > "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
> > you should add this IP to trustedhosts to check if it works.
> >
> > best regard,
> >
>
>
> Aha!  That was it.  What is curious to me is that bind uses this even in
> the absence
> of any IPV6 in the environment.
>
> Problem solved.  Thanks all!
>
>
>
> --
>
> 
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>
>
As a separate issue:  Check the logs to see if BIND is trying to use IPv6
to resolve queries.  Look for messages like:
address not available resolving  with some IPv6 address
I have to start named with the "-4" option on my servers that do not yet
have IPv6 connectivity.

-- 
Bob Harold
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Timothe Litt]

On 17-Apr-20 10:56, Tim Daneliuk wrote:
> On 4/17/20 9:50 AM, Bob Harold wrote:
>> Agree, that's odd, and not what the man page says.  Any chance that there is 
>> some other DNS helper running, like resolved, nscd, dnsmasq, etc?
> Nope.  This is vanilla FreeBSD with vanilla bind running.
>
>> 'dig' should tell you what address it used, at the bottom of the output - 
>> what does it say?
>
>
> ;; Query time: 0 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020
> ;; MSG SIZE  rcvd: 83
>
>
> Does the SERVER line indicate it's trying to get to the local instance via
> IPV6 or is this just standard notation?  (This is an IPV4 only environment).
>
>
You seem to be selecting views based on IP address.

If the host on which you are running dig is multi-homed, the OS may pick
a source
address other than what you intend.  Use -b to explicitly bind to a
particular interface.

(Or, if you use TSIG to match views, -k)


Timothe Litt
ACM Distinguished Engineer
--
This communication may not represent the ACM or my employer's views,
if any, on the matters discussed. 



signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 10:17 AM, julien soula wrote:
> On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
>> On 4/17/20 9:50 AM, Bob Harold wrote:
>>>
>>> Agree, that's odd, and not what the man page says.  Any chance that there 
>>> is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
>>
>> Nope.  This is vanilla FreeBSD with vanilla bind running.
>>
>>> 'dig' should tell you what address it used, at the bottom of the output - 
>>> what does it say?
>>
>>
>>
>> ;; Query time: 0 msec
>> ;; SERVER: ::1#53(::1)
>> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020
>> ;; MSG SIZE  rcvd: 83
>>
>>
>> Does the SERVER line indicate it's trying to get to the local instance via
>> IPV6 or is this just standard notation?  (This is an IPV4 only environment).
> 
> "::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
> you should add this IP to trustedhosts to check if it works.
> 
> best regard,
> 


Aha!  That was it.  What is curious to me is that bind uses this even in the 
absence
of any IPV6 in the environment.

Problem solved.  Thanks all!



-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[julien soula]

On Fri, Apr 17, 2020 at 09:56:21AM -0500, Tim Daneliuk wrote:
> On 4/17/20 9:50 AM, Bob Harold wrote:
> > 
> > Agree, that's odd, and not what the man page says.  Any chance that there 
> > is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
> 
> Nope.  This is vanilla FreeBSD with vanilla bind running.
> 
> > 'dig' should tell you what address it used, at the bottom of the output - 
> > what does it say?
> 
> 
> 
> ;; Query time: 0 msec
> ;; SERVER: ::1#53(::1)
> ;; WHEN: Fri Apr 17 09:53:51 CDT 2020
> ;; MSG SIZE  rcvd: 83
> 
> 
> Does the SERVER line indicate it's trying to get to the local instance via
> IPV6 or is this just standard notation?  (This is an IPV4 only environment).

"::1" is locahost in IPv6. It is not the same as 127.0.0.1 . A least,
you should add this IP to trustedhosts to check if it works.

best regard,
-- 
Julien
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Fri, Apr 17, 2020 at 11:03 AM Konstantin Stefanov 
wrote:

> On 17.04.2020 17:56, Tim Daneliuk wrote:
> > On 4/17/20 9:50 AM, Bob Harold wrote:
> >>
> >> Agree, that's odd, and not what the man page says.  Any chance that
> there is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
> >
> > Nope.  This is vanilla FreeBSD with vanilla bind running.
> Lately vanilla FreeBSD has unbound as caching and recursive DNS server.
> Did you turn it off?
>
> >
> >> 'dig' should tell you what address it used, at the bottom of the output
> - what does it say?
> >
> >
> >
> > ;; Query time: 0 msec
> > ;; SERVER: ::1#53(::1)
> > ;; WHEN: Fri Apr 17 09:53:51 CDT 2020
> > ;; MSG SIZE  rcvd: 83
> >
> >
> > Does the SERVER line indicate it's trying to get to the local instance
> via
> > IPV6 or is this just standard notation?  (This is an IPV4 only
> environment).
>

The server is using IPv6 locally, so you need to include "::1" in the
"trustedhosts"
and view match statements.
Or just create /etc/resolv.conf with: nameserver 127.0.0.1
So the man page was right, just not specific.

-- 
Bob Harold


>
> --
> Konstantin Stefanov
>
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Konstantin Stefanov]

On 17.04.2020 17:56, Tim Daneliuk wrote:

On 4/17/20 9:50 AM, Bob Harold wrote:


Agree, that's odd, and not what the man page says.  Any chance that there is 
some other DNS helper running, like resolved, nscd, dnsmasq, etc?


Nope.  This is vanilla FreeBSD with vanilla bind running.
Lately vanilla FreeBSD has unbound as caching and recursive DNS server. 
Did you turn it off?





'dig' should tell you what address it used, at the bottom of the output - what 
does it say?




;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE  rcvd: 83


Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation?  (This is an IPV4 only environment).





--
Konstantin Stefanov
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 9:50 AM, Bob Harold wrote:
> 
> Agree, that's odd, and not what the man page says.  Any chance that there is 
> some other DNS helper running, like resolved, nscd, dnsmasq, etc?

Nope.  This is vanilla FreeBSD with vanilla bind running.

> 'dig' should tell you what address it used, at the bottom of the output - 
> what does it say?



;; Query time: 0 msec
;; SERVER: ::1#53(::1)
;; WHEN: Fri Apr 17 09:53:51 CDT 2020
;; MSG SIZE  rcvd: 83


Does the SERVER line indicate it's trying to get to the local instance via
IPV6 or is this just standard notation?  (This is an IPV4 only environment).



-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Fri, Apr 17, 2020 at 10:34 AM Tim Daneliuk  wrote:

> On 4/17/20 7:26 AM, Bob Harold wrote:
> >
> > On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  > wrote:
> >
> > We have split horizon setup and enable our internal and trusted hosts
> > to do things as follows:
> >
> > allow-recursion { trustedhosts; };
> > allow-transfer  { trustedhosts; };
> >
> > 'trustedhosts' includes a number of public facing IPs as well as the
> > 192.168.0/24 CIDR block.  It also includes the IPs of the Master and
> > Slave bind servers.
> >
> > So here's the part that has me wondering.  If I do a reverse lookup
> of
> > an IP, it works as expected _except_ if I do it on either the Master
> > or Slave machines. They will not only look up reverses on our
> > own IPs, they won't do it for ANY IP and returns the warning:
> >
> > WARNING: recursion requested but not available
> >
> > This is replicable with 9.14 or 9.16 (or was until today's assert
> borkage)
> > running on FreeBSD 11.3-STABLE.  Master is on a cloud server, Slave
> is
> > on a physical machine.  Neither instance is jailed.
> >
> > Ideas?
> >
> > --
> >
>  
> > Tim Daneliuk tun...@tundraware.com  >
> > PGP Key: http://www.tundraware.com/PGP/
> >
> >
> > Is 127.0.0.1 in the 'trustedhosts' list?
>
> Yes
>
> > Are you telling 'dig' what server to use  - dig @*MailScanner warning:
> numerical links are often malicious:* 127.0.0.1 
>
> No.  But when I do, it works properly.  Doesn't dig default to localhost
> (in this case the host running bind)?
>
> > What servers are listed in /etc/resolv.conf?  Do they resolve the
> reverse zones?
>
> There is no resolv.conf on these machines.  They are the ones running the
> nameservers.
>
> > Are local queries hitting the right 'view' (if you have multiple views) ?
>
> Yes, IF I explicitly point dig to the right nameserver.
>
>
> So ... what's going on is that dig appears to not be using localhost first
> to resolve reverses.
>
>
Agree, that's odd, and not what the man page says.  Any chance that there
is some other DNS helper running, like resolved, nscd, dnsmasq, etc?
'dig' should tell you what address it used, at the bottom of the output -
what does it say?

-- 
Bob Harold


> >
> > --
> > Bob Harold
> >
>
>
> --
>
> 
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/
>
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Tim Daneliuk]

On 4/17/20 7:26 AM, Bob Harold wrote:
> 
> On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  > wrote:
> 
> We have split horizon setup and enable our internal and trusted hosts
> to do things as follows:
> 
>     allow-recursion { trustedhosts; };
>     allow-transfer  { trustedhosts; };
> 
> 'trustedhosts' includes a number of public facing IPs as well as the
> 192.168.0/24 CIDR block.  It also includes the IPs of the Master and
> Slave bind servers.
> 
> So here's the part that has me wondering.  If I do a reverse lookup of
> an IP, it works as expected _except_ if I do it on either the Master
> or Slave machines. They will not only look up reverses on our
> own IPs, they won't do it for ANY IP and returns the warning:
> 
>     WARNING: recursion requested but not available
> 
> This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
> running on FreeBSD 11.3-STABLE.  Master is on a cloud server, Slave is
> on a physical machine.  Neither instance is jailed.
> 
> Ideas?
> 
> -- 
> 
> 
> Tim Daneliuk     tun...@tundraware.com 
> PGP Key:         http://www.tundraware.com/PGP/
> 
> 
> Is 127.0.0.1 in the 'trustedhosts' list?

Yes

> Are you telling 'dig' what server to use  - dig @*MailScanner warning: 
> numerical links are often malicious:* 127.0.0.1 

No.  But when I do, it works properly.  Doesn't dig default to localhost (in 
this case the host running bind)?

> What servers are listed in /etc/resolv.conf?  Do they resolve the reverse 
> zones?

There is no resolv.conf on these machines.  They are the ones running the 
nameservers.

> Are local queries hitting the right 'view' (if you have multiple views) ?

Yes, IF I explicitly point dig to the right nameserver.


So ... what's going on is that dig appears to not be using localhost first to 
resolve reverses.



> 
> -- 
> Bob Harold
> 


-- 

Tim Daneliuk tun...@tundraware.com
PGP Key: http://www.tundraware.com/PGP/

___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question About Recursion In A Split Horizon Setup

[Bob Harold]

On Thu, Apr 16, 2020 at 7:17 PM Tim Daneliuk  wrote:

> We have split horizon setup and enable our internal and trusted hosts
> to do things as follows:
>
> allow-recursion { trustedhosts; };
> allow-transfer  { trustedhosts; };
>
> 'trustedhosts' includes a number of public facing IPs as well as the
> 192.168.0/24 CIDR block.  It also includes the IPs of the Master and
> Slave bind servers.
>
> So here's the part that has me wondering.  If I do a reverse lookup of
> an IP, it works as expected _except_ if I do it on either the Master
> or Slave machines. They will not only look up reverses on our
> own IPs, they won't do it for ANY IP and returns the warning:
>
> WARNING: recursion requested but not available
>
> This is replicable with 9.14 or 9.16 (or was until today's assert borkage)
> running on FreeBSD 11.3-STABLE.  Master is on a cloud server, Slave is
> on a physical machine.  Neither instance is jailed.
>
> Ideas?
>
> --
>
> 
> Tim Daneliuk tun...@tundraware.com
> PGP Key: http://www.tundraware.com/PGP/


Is 127.0.0.1 in the 'trustedhosts' list?
Are you telling 'dig' what server to use  - dig @127.0.0.1
What servers are listed in /etc/resolv.conf?  Do they resolve the reverse
zones?
Are local queries hitting the right 'view' (if you have multiple views) ?

-- 
Bob Harold
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about CVE-2019-6477: TCP-pipelined queries can bypass tcp-clients limit

[Cathy Almond]

Hi Veronique,

What is being logged is individual queries (or rather, query responses
in actual fact, as those queries are responded to).

It doesn't make any difference to the logging how they arrived - each
query is logged independently, whether it was pipelined over TCP,
arrived non-pipelined, or came in over UDP.

You can't determine whether a client is using TCP pipelining from
looking at the querylog channel - that's because what is being logged is
individual queries being handled, not client connections and how the
queries are transported.

Hoping this helps.

Cathy

On 20/12/2019 15:44, Veronique Lefebure wrote:
> Many thanks for your reply. It answers the second part of my question.
> But what about the first part of the question: " If a client is using 
> TCP-pipelining, and if querylog channel is enabled, what will appear in the 
> query log file for that client ? Shall we see one line per DNS query, i.e. N 
> lines if the client has sent N queries in the pipeline, or shall we see only 
> one line ?" 
> 
> You say "Just seeing multiple queries from the same client TCP connection 
> doesn't mean that it is pipelining them."
> But are we sure that one would see multiple queries in the querylogs in case 
> of pipelining ?
> 
> Thanks,
> Veronique
> 
> -Original Message-
> From: Cathy Almond  
> Sent: 09 December 2019 10:05
> To: Veronique Lefebure 
> Subject: Re: FW: Question about CVE-2019-6477: TCP-pipelined queries can 
> bypass tcp-clients limit
> 
> Hi Veronique,
> 
> I replied the same day:
> 
> https://lists.isc.org/pipermail/bind-users/2019-November/102372.html
> 
> But oddly, I don't see your posting on the list at all, just my reply.
> 
> It looks like it never made it to the list - the reason being that you can't 
> post to the list unless you're a subscriber (which, after
> checking, it turns out that you're not).   You should have received an
> auto-reply saying that your posting was held for moderation because you 
> weren't signed-up to the list.
> 
> I'm guessing that you BCCd me when you posted, and I just replied to the 
> list, thinking that your posting had come from the list and not directly.
> 
> So.. if you didn't subscribe, you wouldn't have seen the reply...
> 
> Cathy
> 
> 
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
> from this list
> 
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: Question about CVE-2019-6477: TCP-pipelined queries can bypass tcp-clients limit

[Veronique Lefebure]

Many thanks for your reply. It answers the second part of my question.
But what about the first part of the question: " If a client is using 
TCP-pipelining, and if querylog channel is enabled, what will appear in the 
query log file for that client ? Shall we see one line per DNS query, i.e. N 
lines if the client has sent N queries in the pipeline, or shall we see only 
one line ?" 

You say "Just seeing multiple queries from the same client TCP connection 
doesn't mean that it is pipelining them."
But are we sure that one would see multiple queries in the querylogs in case of 
pipelining ?

Thanks,
Veronique

-Original Message-
From: Cathy Almond  
Sent: 09 December 2019 10:05
To: Veronique Lefebure 
Subject: Re: FW: Question about CVE-2019-6477: TCP-pipelined queries can bypass 
tcp-clients limit

Hi Veronique,

I replied the same day:

https://lists.isc.org/pipermail/bind-users/2019-November/102372.html

But oddly, I don't see your posting on the list at all, just my reply.

It looks like it never made it to the list - the reason being that you can't 
post to the list unless you're a subscriber (which, after
checking, it turns out that you're not).   You should have received an
auto-reply saying that your posting was held for moderation because you weren't 
signed-up to the list.

I'm guessing that you BCCd me when you posted, and I just replied to the list, 
thinking that your posting had come from the list and not directly.

So.. if you didn't subscribe, you wouldn't have seen the reply...

Cathy


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about CVE-2019-6477: TCP-pipelined queries can bypass tcp-clients limit

[Cathy Almond]

On 21/11/2019 14:40, Veronique Lefebure wrote:
> Hi,
> 
> I have a question regarding the vulnerability described in the mail below.
> 
> If a client is using TCP-pipelining, and if querylog channel is enabled, what 
> will appear in the query log file for that client ?
> Shall we see one line per DNS query, i.e. N lines if the client has sent N 
> queries in the pipeline, or shall we see only one line ?
> Also, is there a way to know is a client is using pipelining (a part from 
> analysing the traffic) ?
> 
> Thanks,
> Veronique

Hi Veronique,

This is an interesting question.

The querylog channel is logging query responses, one per client query.
So you're not going to be able to determine from query logging whether a
client is using TCP-pipelining or not.

Realistically, you're going to have to analyze the traffic in some way
or another.  The difference with a pipelining client as opposed to
another TCP client that just holds open a TCP socket while it sends
several queries, is that the pipelining client won't wait for a query
response to the last query it sent before sending the next one.  It will
have code in place locally to keep track of pending queries and to
handle out of order query responses.

Just seeing multiple queries from the same client TCP connection doesn't
mean that it is pipelining them.

Someone else on the list might have some other ideas, but that's all
that I can think of at the moment - sorry.

Cathy


___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about at zone transfer behaviour on slave

[Matus UHLAR - fantomas]

On Wed, Jun 5, 2019, 10:09 PM Techs-yama  wrote:

Have a question about at zone transfer behaviour on slave server.

In case of slave zone configure and restarting named on slave server,
After the named restart, It looks like starting polling to the master
server for zone transfer by slave server.
How many seconds polling interval on this timer ?
and can i change interval value to configure it ?



2019年6月6日(木) 11:37 Ben Croswell :

You are looking for the refresh timer in the SOA if you mean the timer for a 
slave to check the serial with the master.


On 06.06.19 12:46, Techs-yama wrote:

Sorry I'm write wrong,
It is about when configure the slave at the first time.
What  do trigger on polling at the timing?
Because I think slave server do not have soa date at first time.
Also, assuming that have not received notify from the master.


in such case, BIND tends to start zone transfer immediately.
Unless, there's too many zone transfers in which case BIND delays the
transfer. Also, there may be too many transfers on the master and it may
refuse the zone transfer temporarily. See the transfers-in and transfers-out
BIND options.

--
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.
REALITY.SYS corrupted. Press any key to reboot Universe.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe 
from this list

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about at zone transfer behaviour on slave

[Techs-yama]

Thanks for reply.

Sorry I'm write wrong,
It is about when configure the slave at the first time.
What  do trigger on polling at the timing?
Because I think slave server do not have soa date at first time.
Also, assuming that have not received notify from the master.

Thanks and regards.

2019年6月6日(木) 11:37 Ben Croswell :
>
> You are looking for the refresh timer in the SOA if you mean the timer for a 
> slave to check the serial with the master.
>
> On Wed, Jun 5, 2019, 10:09 PM Techs-yama  wrote:
>>
>> Hi all,
>>
>> Have a question about at zone transfer behaviour on slave server.
>>
>> In case of slave zone configure and restarting named on slave server,
>> After the named restart, It looks like starting polling to the master
>> server for zone transfer by slave server.
>> How many seconds polling interval on this timer ?
>> and can i change interval value to configure it ?
>>
>> Thanks and regards.
>> ___
>> Please visit https://lists.isc.org/mailman/listinfo/bind-users to 
>> unsubscribe from this list
>>
>> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question about at zone transfer behaviour on slave

[Ben Croswell]

You are looking for the refresh timer in the SOA if you mean the timer for
a slave to check the serial with the master.

On Wed, Jun 5, 2019, 10:09 PM Techs-yama  wrote:

> Hi all,
>
> Have a question about at zone transfer behaviour on slave server.
>
> In case of slave zone configure and restarting named on slave server,
> After the named restart, It looks like starting polling to the master
> server for zone transfer by slave server.
> How many seconds polling interval on this timer ?
> and can i change interval value to configure it ?
>
> Thanks and regards.
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
>
> 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

bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users