Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Re: bind9 and dns forward
22 views
Skip to first unread message
Michel Verdier
Apr 29, 2023, 3:30:05 AM4/29/23
to
Le 28 avril 2023 Bonno Bloksma a écrit :
> We use a different dns server(s) and zonefile for the external dns environment from what we use internally. Company dns is Windows server 2016 incase that is relevant.
It's better to use dig (package bind9-dnsutils) to first eliminate
problems on other DNS. Give us:
dig @13.107.206.240 trafficmanager.net SOA
dig @13.107.206.240 outlook.ha.office365.com IN
dig @172.16.128.40 vijl.staf.tio.nl AAAA
dig @172.16.128.10 vijl.staf.tio.nl AAAA
> Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53
> resolving staf.tio.nl/AAAA for client 172.16.17.11#65033: Name tio.nl (SOA)
> not subdomain of zone staf.tio.nl -- invalid response
I suppose you reboot after your upgrade ?
Do you have defined somewhere on linbobo a zone staf.tio.nl ?
I guess not but do a grep just to be sure.
> We use a different dns server(s) and zonefile for the external dns environment from what we use internally. Company dns is Windows server 2016 incase that is relevant.
It's better to use dig (package bind9-dnsutils) to first eliminate
problems on other DNS. Give us:
dig @13.107.206.240 trafficmanager.net SOA
dig @13.107.206.240 outlook.ha.office365.com IN
dig @172.16.128.40 vijl.staf.tio.nl AAAA
dig @172.16.128.10 vijl.staf.tio.nl AAAA
> Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53
> resolving staf.tio.nl/AAAA for client 172.16.17.11#65033: Name tio.nl (SOA)
> not subdomain of zone staf.tio.nl -- invalid response
I suppose you reboot after your upgrade ?
Do you have defined somewhere on linbobo a zone staf.tio.nl ?
I guess not but do a grep just to be sure.
Michel Verdier
May 2, 2023, 9:00:06 AM5/2/23
to
Le 2 mai 2023 Bonno Bloksma a écrit :
> linbobo:/etc/bind# cat named.conf.local
> -----<Quote>----------------------
> [....]
> zone "tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "staf.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "student.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
> The problem is not that the company dns servers are not working, it is that it somehow thinks the answers are not valid, not even for the top level domain.
In fact you don't resolv at all. Can you provide:
dig einsccmdp-01.tio.nl +trace +cd
dig @172.16.208.10 einsccmdp-01.tio.nl
(this one to eliminate 172.16.208.10 beeing broken)
I don't understand why you define staf.tio.nl and student.tio.nl as
tio.nl is already on the same forwarders. I don't know if it's valid but
it seems useless. And your logs suggest a problem between staf.tio.nl and
tio.nl. Could you comment staf.tio.nl and student.tio.nl, restart bind
(or reload + flush) and try again above dig ?
> linbobo:/etc/bind# cat named.conf.local
> -----<Quote>----------------------
> [....]
> zone "tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "staf.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
>
> zone "student.tio.nl" IN {
> type forward;
> forward only;
> forwarders {172.16.128.40; 172.16.208.10;};
> };
> The problem is not that the company dns servers are not working, it is that it somehow thinks the answers are not valid, not even for the top level domain.
In fact you don't resolv at all. Can you provide:
dig einsccmdp-01.tio.nl +trace +cd
dig @172.16.208.10 einsccmdp-01.tio.nl
(this one to eliminate 172.16.208.10 beeing broken)
I don't understand why you define staf.tio.nl and student.tio.nl as
tio.nl is already on the same forwarders. I don't know if it's valid but
it seems useless. And your logs suggest a problem between staf.tio.nl and
tio.nl. Could you comment staf.tio.nl and student.tio.nl, restart bind
(or reload + flush) and try again above dig ?
Michel Verdier
May 6, 2023, 3:00:06 AM5/6/23
to
Le 5 mai 2023 Bonno Bloksma a écrit :
> linbobo:/etc/bind# cat named.conf.local
You have only zone blocks in this file, right ?
> linbobo:/etc/bind# cat named.conf.local
And you don't use views ?
> Why does it first go to the public dns and then run into the dnssec problem? There is a direct definition for the tio.nl zone in my config file.
The public dns don't answer at all, so dnssec problem is only a
consequence. The main problem seems to be the broken forwarding.
Do you restart or flush your bind before the queries ? I suppose you do
but... :)
Your tio.nl zone seems correct. Could you provide full
/etc/bind/named.conf.options and /etc/bind/named.conf ?
Michel Verdier
May 8, 2023, 7:20:05 AM5/8/23
to
Le 8 mai 2023 Bonno Bloksma a écrit :
> I also do not understand this difference when querying the internal dns server directly.
> Why does the +trace +cd not show an answer but when I leave them out I get a
> correct answer. Is that because +trace forces it to start at the root which is
> irrelevant when trying to get an answer from an internal dns server?
yes
> What does +cd do? I was unable to find it in the man page.
it disable dnssec checks, was just in case of real dnssec problem
can you give full /etc/resolv.conf
from your result you should have 127.0.0.1 in it but just to be sure
and also :
dig tio.nl NS
dig @172.16.208.10 tio.nl NS
> I also do not understand this difference when querying the internal dns server directly.
> Why does the +trace +cd not show an answer but when I leave them out I get a
> correct answer. Is that because +trace forces it to start at the root which is
> irrelevant when trying to get an answer from an internal dns server?
yes
> What does +cd do? I was unable to find it in the man page.
it disable dnssec checks, was just in case of real dnssec problem
can you give full /etc/resolv.conf
from your result you should have 127.0.0.1 in it but just to be sure
and also :
dig tio.nl NS
dig @172.16.208.10 tio.nl NS
Michel Verdier
May 23, 2023, 10:20:06 AM5/23/23
to
Le 19 mai 2023 Bonno Bloksma a écrit :
> Been a few busy week, that is why I only respond now, sory.
Same for me :/
> beheerdertio@linbobo:~$ cat /etc/resolv.conf
> domain bobo.xs4all.nl
> search bobo.xs4all.nl
> search tio.nl
> search staf.tio.nl
> search student.tio.nl
> nameserver 127.0.0.1
> nameserver 8.8.8.8
resolv.conf must have only one search entry. And you don't want to
resolv with google directly. So you should have :
domain bobo.xs4all.nl
search bobo.xs4all.nl tio.nl staf.tio.nl student.tio.nl
nameserver 127.0.0.1
> When booting if the internal bind is not up and running yet some services might need a resolver so I have 8.8.8.8 in there as well as a second dns entry.
Ensure this in services ordering (systemd or initd). It's better and
safer. And I think it's better to get an error than a false result from
bind.
> linbobo:~# dig tio.nl NS
>
> ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34517
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
This is the point : your local dns don't find tio.nl NS and then ask
somewhere else. 8.8.8.8 is in resolv.conf so you search tio.nl directly
on it and it gives you your provider name server.
Retry
dig tio.nl NS
with a clean resolv.conf and also
ss -nap | grep named
> Been a few busy week, that is why I only respond now, sory.
Same for me :/
> beheerdertio@linbobo:~$ cat /etc/resolv.conf
> domain bobo.xs4all.nl
> search bobo.xs4all.nl
> search tio.nl
> search staf.tio.nl
> search student.tio.nl
> nameserver 127.0.0.1
> nameserver 8.8.8.8
resolv.conf must have only one search entry. And you don't want to
resolv with google directly. So you should have :
domain bobo.xs4all.nl
search bobo.xs4all.nl tio.nl staf.tio.nl student.tio.nl
nameserver 127.0.0.1
> When booting if the internal bind is not up and running yet some services might need a resolver so I have 8.8.8.8 in there as well as a second dns entry.
Ensure this in services ordering (systemd or initd). It's better and
safer. And I think it's better to get an error than a false result from
bind.
> linbobo:~# dig tio.nl NS
>
> ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 34517
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
This is the point : your local dns don't find tio.nl NS and then ask
somewhere else. 8.8.8.8 is in resolv.conf so you search tio.nl directly
on it and it gives you your provider name server.
Retry
dig tio.nl NS
with a clean resolv.conf and also
ss -nap | grep named
Michel Verdier
Jun 1, 2023, 9:50:06 AM6/1/23
to
Le 1 juin 2023 Bonno Bloksma a écrit :
> linbobo:~# ss -nap | grep named
> tcp LISTEN 0 10 [2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3]:53 [::]:*
> users:(("named",pid=554,fd=78))
> tcp LISTEN 0 10 [fe80::1e69:7aff:fe0c:65e3]%eno1:53 [::]:*
> users:(("named",pid=554,fd=71))
> tcp LISTEN 0 10 [fe80::33bc:2b:d928:991d]%tun0:53 [::]:*
> users:(("named",pid=554,fd=94))
You should not use fe80:: adresses on eno1 as you have an ipv6 2a02 on
this interface. But you don't have real ipv6 on tun0. fe80:: is only
assigned when there is no adress assigned for an interface. Usually fe80::
are local only and not routed. And bind use ipv6 first. So I suspect that
your vpn block ipv6 from your tun0 fe80::. Check your vpn configuration
to setup a real ipv6 adress.
Meanwhile change /etc/bind/named.conf.options to select only your good ip
listen-on port 53 {
127.0.0.1;
172.16.17.1;
172.16.1.138;
};
listen-on-v6 port 53 {
::1;
2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3;
# add here real ipv6 from vpn when setup
};
> linbobo:~# ss -nap | grep named
> tcp LISTEN 0 10 [2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3]:53 [::]:*
> users:(("named",pid=554,fd=78))
> tcp LISTEN 0 10 [fe80::1e69:7aff:fe0c:65e3]%eno1:53 [::]:*
> users:(("named",pid=554,fd=71))
> tcp LISTEN 0 10 [fe80::33bc:2b:d928:991d]%tun0:53 [::]:*
> users:(("named",pid=554,fd=94))
You should not use fe80:: adresses on eno1 as you have an ipv6 2a02 on
this interface. But you don't have real ipv6 on tun0. fe80:: is only
assigned when there is no adress assigned for an interface. Usually fe80::
are local only and not routed. And bind use ipv6 first. So I suspect that
your vpn block ipv6 from your tun0 fe80::. Check your vpn configuration
to setup a real ipv6 adress.
Meanwhile change /etc/bind/named.conf.options to select only your good ip
listen-on port 53 {
127.0.0.1;
172.16.17.1;
172.16.1.138;
};
listen-on-v6 port 53 {
::1;
2a02:a45f:96c2:1:1e69:7aff:fe0c:65e3;
# add here real ipv6 from vpn when setup
};
Tim Woodall
Jun 1, 2023, 2:10:07 PM6/1/23
to
On Thu, 1 Jun 2023, Bonno Bloksma wrote:
>
> My bind instance can reach the company dns server buy claims the response is false/insecure
>
> Does that maybe mean that my bind gets a "normal" response from the company dns whereas the external dns at toplevel .nl. (being the parent zone) tells that any response from a tio.nl dns server should be a secure response. And therefore bind does not accept it?
> Where does bind store this info and can I overrule it?
>
/etc/bind/named.conf.options:
dnssec-validation auto;
You'll have to check the docs but I think setting this to no or none (I
don't remember which) should mean that it doesn't complain.
But this is rather brute force. There may be a cleaner way to do it for
a single domain via trust anchors but it's not something I've tried to
do.
Tim.
>
> My bind instance can reach the company dns server buy claims the response is false/insecure
>
> Does that maybe mean that my bind gets a "normal" response from the company dns whereas the external dns at toplevel .nl. (being the parent zone) tells that any response from a tio.nl dns server should be a secure response. And therefore bind does not accept it?
> Where does bind store this info and can I overrule it?
>
/etc/bind/named.conf.options:
dnssec-validation auto;
You'll have to check the docs but I think setting this to no or none (I
don't remember which) should mean that it doesn't complain.
But this is rather brute force. There may be a cleaner way to do it for
a single domain via trust anchors but it's not something I've tried to
do.
Tim.
Michel Verdier
Jun 1, 2023, 2:10:07 PM6/1/23
to
Le 1 juin 2023 Bonno Bloksma a écrit :
> I can do that, but ... that is only for inbound traffic TO my dns server on this network.
> That part is working without any problem. Changing that will not change anything for the clients on this network.
You are right. I simply used to fix explicitely interfaces for
security and it's not the point here.
> My bind instance can reach the company dns server buy claims the response is false/insecure
> Does that maybe mean that my bind gets a "normal" response from the company
> dns whereas the external dns at toplevel .nl. (being the parent zone) tells
> that any response from a tio.nl dns server should be a secure response. And
> therefore bind does not accept it?
external dns masked the real problem) :
dig tio.nl NS +cd
If you get an answer it's a dnssec problem with the error message in your
logs. If there is no answer it's another problem.
> Where does bind store this info and can I overrule it?
And it's definitely not the good solution but you could transfert the
full zone (or get a copy of the file) and serve it as master.
Michel Verdier
Jun 1, 2023, 6:30:06 PM6/1/23
to
Le 1 juin 2023 Bonno Bloksma a écrit :
>> If you get an answer it's a dnssec problem with the error message in your logs. If there is no answer it's another problem.
> Well, it seems I get an answer with the +cd option, and none without.
>> If you get an answer it's a dnssec problem with the error message in your logs. If there is no answer it's another problem.
Yes. If I do :
# dig tio.nl A +dnssec +multiline
; <<>> DiG 9.18.12-1~bpo11+1-Debian <<>> tio.nl A +dnssec +multiline
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 15946
;; Got answer:
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; COOKIE: b5616e99dab9dfa2010000006479183bc71c1f369d50dcb2 (good)
;; QUESTION SECTION:
;tio.nl. IN A
;; ANSWER SECTION:
tio.nl. 3600 IN A 188.166.202.179
tio.nl. 3600 IN RRSIG A 8 2 3600 (
20230615000000 20230525000000 11454 tio.nl.
M3ZcaxHNXwnmZ5SQnvMcPsUDPLQLpyl0RO7azsSWoUTx
6CgENJbWQuMqHyiQlzxeSnzVbfFIlKdbsBACFylJUhsT
Mby5rp8ouOr8XOK2wC+qJvgYbl5SJwXePu0f1XgCxoAg
P5/6ZnnXpo4gidVtxfUB68Ed5T6yxo23o0eI5gE= )
I get external dns answer with a nice dnssec. Can you do :
dig @172.16.208.10 tio.nl A +dnssec +multiline
to see if your internal dns answer the same rrsig
0 new messages