Re: bind9 and dns forward
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. 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 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1232 ; COOKIE: b5616e99dab9dfa201006479183bc71c1f369d50dcb2 (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 ( 2023061500 2023052500 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
RE: bind9 and dns forward
Hi, @Tim, If I use the dnssec-validation no; option then indeed it all works. Just tested it again to make sure. And as a final solution to this problem I might accept it, but I would rather not. @Michel, > I reread all our mails and I miss to ask you this one (as answers via > external dns masked the real problem) : > dig tio.nl NS +cd Ok, with /etc/resolv.conf pointing only to localhost and option dnssec-validation auto; - linbobo:/etc/bind# dig tio.nl NS +cd ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS +cd ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 8565 ;; flags: qr rd ra cd; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: f9edf2abbc6bb1b401006478e3bce0244f2a98d3724c (good) ;; QUESTION SECTION: ;tio.nl.IN NS ;; ANSWER SECTION: tio.nl. 3600IN NS amsstuddc-04.student.tio.nl. [... snip ...] tio.nl. 3600IN NS rtmstuddc-05.student.tio.nl. ;; Query time: 28 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 01 20:30:20 CEST 2023 ;; MSG SIZE rcvd: 568 linbobo:/etc/bind# dig tio.nl NS ; <<>> DiG 9.16.37-Debian <<>> tio.nl NS ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 57482 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: eeb3f3a1c2495cf501006478e3c58effeec3959e9ccc (good) ;; QUESTION SECTION: ;tio.nl.IN NS ;; Query time: 188 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jun 01 20:30:29 CEST 2023 ;; MSG SIZE rcvd: 63 linbobo:/etc/bind# - > 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. [...] > And it's definitely not the good solution but you could transfer the full > zone (or get a copy of the file) and serve it as master. Nah, I do not want to do that. Too many updates on the internal zone, I would need to copy at least every 5 min. Also other reasons. Bonno Bloksma
Re: bind9 and dns forward
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? I reread all our mails and I miss to ask you this one (as answers via 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? I am not sure but I think bind only cache in memory. 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.
RE: bind9 and dns forward
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.
RE: bind9 and dns forward
Hi,
>> 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.
I can do that, it is just default to listen on all local ip's.
But that is also just inbound traffic as far as I know, that has nothing to do
with what ip number bind itself uses to get info from other (company) dns
servers.
> But you don't have real ipv6 on tun0. fe80:: is only assigned when there is
> no adress assigned for an interface.
Correct, the VPN tunnel is IPv4 only at this moment as the company network has
only partial IPv6 set up and is not using it over the whole network yet.
I am only sure to reach all servers via IPv4, including the dns servers. Which
is why I forward to the relevant ipv4 addresses.
> Usually fe80:: are local only and not routed.
Correct
> And bind use ipv6 first.
Yes, first, but not only. Also, there is no IPv6 address in the forward
statements.
> So I suspect that your vpn block ipv6 from your tun0 fe80::. Check your vpn
> configuration to setup a real ipv6 adress.
I cannot setup IPv6 on the VPN tunnel as the other side has no IPv6 address
yet. Also there is no route to the dns servers on ipv6 yet.
> Meanwhile change /etc/bind/named.conf.options to select only your good ip
>
> listen-on port 53 {
[]
>};
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.
We are still left with the problem shown in the syslog:
--
Jun 1 09:25:45 linbobo named[554]: validating tio.nl/NS: got insecure
response; parent indicates it should be secure
Jun 1 09:25:45 linbobo named[554]: insecurity proof failed resolving
'tio.nl/NS/IN': 172.16.128.40#53
Jun 1 09:25:45 linbobo named[554]: validating tio.nl/NS: got insecure
response; parent indicates it should be secure
Jun 1 09:25:45 linbobo named[554]: insecurity proof failed resolving
'tio.nl/NS/IN': 172.16.208.10#53
--
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?
Bonno Bloksma
Re: bind9 and dns forward
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
};
RE: bind9 and dns forward
Hi,
> resolv.conf must have only one search entry. And you don't want to resolv
> with google directly. So you should have :
Ok, I have the google dns commented. Alhough Now I remember why I had the
google dns in there. ;-)
For my machine to create the VPN it needs to know the ip number of the gateway.
I fixed that for now with an entry in the /etc/hosts file. :-)
>> 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.
Ok, I get it.
--
linbobo:~# rndc flush
linbobo:~# dig tio.nl NS
; <<>> DiG 9.16.37-Debian <<>> tio.nl NS
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 49974
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: 52571ae710dcd2cc01006478463be41c8b3a2afd14a5 (good)
;; QUESTION SECTION:
;tio.nl.IN NS
;; Query time: 244 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Thu Jun 01 09:18:19 CEST 2023
;; MSG SIZE rcvd: 63
--
Hmm, no answer, that is weird.
--
linbobo:~# ss -nap | grep named
u_dgr UNCONN0 0 * 17532
* 12035 users:(("named",pid=554,fd=3))
u_str ESTAB 0 0 * 17082
* 17525
users:(("named",pid=554,fd=2),("named",pid=554,fd=1))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=83))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=85))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=84))
udp UNCONN0 0172.16.1.138:53
0.0.0.0:* users:(("named",pid=554,fd=82))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=49))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=50))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=51))
udp UNCONN0 0 172.16.17.1:53
0.0.0.0:* users:(("named",pid=554,fd=52))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=39))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=38))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=40))
udp UNCONN0 0 127.0.0.1:53
0.0.0.0:* users:(("named",pid=554,fd=37))
udp UNCONN0 0 [::1]:53
[::]:* users:(("named",pid=554,fd=60))
udp UNCONN0 0 [::1]:53
[::]:* users:(("named",pid=554,fd=58))
udp UNCONN0 0 [::1]:53
[::]:* users:(("named",pid=554,fd=59))
udp UNCONN0 0 [::1]:53
Re: bind9 and dns forward
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
RE: bind9 and dns forward
Hi, Been a few busy week, that is why I only respond now, sory. Also as there is a lot of sensitive info in this mail, like a complete lost to domain controllers to be hacked, ;-) I am sending it direct. I will send a redacted version to the list >> 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 Aha, ok clear. > can you give full /etc/resolv.conf > from your result you should have 127.0.0.1 in it but just to be sure 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 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. > and also : > dig tio.nl NS > dig @172.16.208.10 tio.nl NS 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 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: bfc026467d702f7d01006467377dffdb068b3e9c0a69 (good) ;; QUESTION SECTION: ;tio.nl.IN NS ;; Query time: 32 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Fri May 19 10:46:53 CEST 2023 ;; MSG SIZE rcvd: 63 linbobo:~# dig @172.16.208.10 tio.nl NS ; <<>> DiG 9.16.37-Debian <<>> @172.16.208.10 tio.nl NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13283 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 18, AUTHORITY: 0, ADDITIONAL: 19 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;tio.nl.IN NS ;; ANSWER SECTION: tio.nl. 3600IN NS hgltiodc-04.tio.nl. [] tio.nl. 3600IN NS amsstuddc-04.student.tio.nl. ;; ADDITIONAL SECTION: hgltiodc-04.tio.nl. 3600IN A 172.16.128.40 [...] amsstuddc-04.student.tio.nl. 1200 INA 172.16.196.11 ;; Query time: 20 msec ;; SERVER: 172.16.208.10#53(172.16.208.10) ;; WHEN: Fri May 19 10:48:07 CEST 2023 ;; MSG SIZE rcvd: 816 Bonno Bloksma
Re: bind9 and dns forward
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
RE: bind9 and dns forward
Hi, >> linbobo:/etc/bind# cat named.conf.local > > You have only zone blocks in this file, right ? Yes, > And you don't use views ? I have no idea what they would do, but no. The word view is not in that file. > 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... :) Just did a flush and then a query. It still seems to query the public dns and not (exclusively) forward the request. linbobo:/etc/bind# dig einsccmdp-01.tio.nl +trace +cd ; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl +trace +cd ;; global options: +cmd . 279702 IN NS c.root-servers.net. . 279702 IN NS m.root-servers.net. . 279702 IN NS k.root-servers.net. . 279702 IN NS a.root-servers.net. . 279702 IN NS b.root-servers.net. . 279702 IN NS i.root-servers.net. . 279702 IN NS e.root-servers.net. . 279702 IN NS g.root-servers.net. . 279702 IN NS d.root-servers.net. . 279702 IN NS h.root-servers.net. . 279702 IN NS j.root-servers.net. . 279702 IN NS f.root-servers.net. . 279702 IN NS l.root-servers.net. . 279702 IN RRSIG NS 8 0 518400 2023051805 2023050504 60955 . Yz1mgXTG4kStmPrjvxu3iQsekhdLfu3KeyZT26ebRPDeUnRUz/ajenhi jNj4FA6krNnCI1hfU0htq/10iADDnc35NTtGA6PodoTa8qf75l9UZ/Cc 59FRaH7sEDgjXcvts0X2R85aHofogRRcp77ufoetwSS0KZRsbJ5vBbq2 J4UIbKNHCZP0anl8+qmDmiMNy3VJYcUwePT6qDUBMe2fhktmU6w1RLSe 3xGV1dIFONSdZJeQxsJkWBXa5HnBN1Vl8iw6eDKauJDw6LL41fd8XzSk CYfl79f92z2tVv5q3l1G8fN3C+KJ33J1Y/hivBSe2FmVuwRkbr1mddH0 4m4LLw== ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms nl. 172800 IN NS ns1.dns.nl. nl. 172800 IN NS ns3.dns.nl. nl. 172800 IN NS ns4.dns.nl. nl. 86400 IN DS 34112 8 2 3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22 nl. 86400 IN RRSIG DS 8 1 86400 2023052105 2023050804 60955 . ORTn1H1ik3trq8VJQAVQ1nx4rrVZNEpoy9JZ/23pOjysRe9BWlXcCIK4 9LO3olfaXGFMDMWT3RtlSO3XFc7gPw38y2yfSRN8LWMkY0LzmOoLNxLO owY9dqQDfrvZK++EsWWmen0db3u/G07/cVWgb3IO0W9OVioQqko6ryes S9rlwbZY7lrPcohjWbUQ/uKBnhyN9yQs0sU8b+v3EbIudSzAa2zz5Bep ZA/XcnP+I9KNHqOREEfAuUG8moCP3VYFwarIkAgQeg/pE/typQZuxHUS QYY6LEfUpZVVO6i0NAHmqRlOZe2LmIHPWO7FBjK6YZtxyLbNkjyWjjvr kf4bVg== ;; Received 573 bytes from 192.58.128.30#53(j.root-servers.net) in 92 ms tio.nl. 3600IN NS ns3.argewebhosting.nl. tio.nl. 3600IN NS ns1.argewebhosting.eu. tio.nl. 3600IN NS ns2.argewebhosting.com. tio.nl. 3600IN DS 33829 8 2 81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3 tio.nl. 3600IN RRSIG DS 8 2 3600 20230522040659 20230508070836 50076 nl. kTSEJYjimMe4Kvdl6kc4gPF2OLn04nhuGDp4ppYbfxwPKZEzXb3GSY68 3SPqHYTuOvwTeDnGQ1brG7l9N6EJRdgy9rG69/Irj1/aUZT27M5BBN3h r9y7dZQAfdZVDSy7zXUgAYy9AdOf+JeLhIeVhrbxD+NYBXaJOe9r3gtj F6s= ;; Received 408 bytes from 2620:10a:80ac::200#53(ns4.dns.nl) in 12 ms tio.nl. 3600IN SOA ns1.argewebhosting.eu. hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600 tio.nl. 3600IN RRSIG SOA 8 2 3600 2023051800 2023042700 11454 tio.nl. JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0= kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs +XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg= oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi Mpqu1Dw/NSuWgfYvhtfG5KFqlqyuH88pKJtt5mra6+c3NRi1F6yu4TYS
Re: bind9 and dns forward
Le 5 mai 2023 Bonno Bloksma a écrit : > linbobo:/etc/bind# cat named.conf.local You have only zone blocks in this file, right ? 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 ?
RE: bind9 and dns forward
Hi, > In fact you don't resolv at all. Can you provide: > dig einsccmdp-01.tio.nl +trace +cd - linbobo:~# dig einsccmdp-01.tio.nl +trace +cd ; <<>> DiG 9.16.37-Debian <<>> einsccmdp-01.tio.nl +trace +cd ;; global options: +cmd . 430791 IN NS i.root-servers.net. . 430791 IN NS a.root-servers.net. . 430791 IN NS c.root-servers.net. . 430791 IN NS e.root-servers.net. . 430791 IN NS b.root-servers.net. . 430791 IN NS m.root-servers.net. . 430791 IN NS k.root-servers.net. . 430791 IN NS d.root-servers.net. . 430791 IN NS j.root-servers.net. . 430791 IN NS f.root-servers.net. . 430791 IN NS l.root-servers.net. . 430791 IN NS h.root-servers.net. . 430791 IN NS g.root-servers.net. . 430791 IN RRSIG NS 8 0 518400 2023051705 2023050404 60955 . euvMHZqurPBykFmPr1OYrEWd3ZIP2l3skATDF8FxfGFfEZmBl/NIn+lu 463u/qxl9F3NYoxN7ANmZyJFMoDhCVpRMEk9mRimctn9fj+6B1EiG02g vUiMKSBPrv/gWbZZcXobaE/F99WYV0xnWNWAKJqRO52YRXqvqltvcjNM FnreCFXRPLFKJ6jqortPA8XfDEUeyt2oFnNZFy9aVqBSGsIqT2gaqX++ 6CXeemp5SSX1YHBxVVWnI6FWw7FjPBRNa485e0RmTi/0WdTTaYd2Eh5u Sfbpn4OzAgOkGJEU0J45Z4nO8j8M8PpRIW8xh7muW/pLUL6x3FsRsf2s scKr8w== ;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms nl. 172800 IN NS ns4.dns.nl. nl. 172800 IN NS ns1.dns.nl. nl. 172800 IN NS ns3.dns.nl. nl. 86400 IN DS 34112 8 2 3C5B5F9B3557455C50751A9BE9EBE9238C88E19F5F07F930976917B5 1B95CD22 nl. 86400 IN RRSIG DS 8 1 86400 2023051805 2023050504 60955 . n2RgQwHUOPq0Kfit0Fs3PJx+xiSsSeZqOtzw0oq5BU0CBhM6WN75Gw/T u+PIFd4NEFoS2T3Y+mGuQb7PfvGNOFHbRzp1rwHrgj5GzgS3nCih9jOF wPNytFVYhJ/RqfD80dMwShZAs2OxlVIfD7UYEjUs/ZC38PreGAoHedQI wp8lECv80cr+zFHtPHh5RiW1Clg4TDWmlzOsa8y9FOH3acTM+kFjnnaQ se2p0ZciZk8B7aNoxG468JQnQHHKRbxQgn8wxM0ttHKkpmwZHvL7bfhE CH+akGcz/g4TFQA88B9eHTe0AqcUcHsPhBmB/uySv3FAiO0myKsQwuC+ 8vORCg== ;; Received 605 bytes from 192.36.148.17#53(i.root-servers.net) in 0 ms tio.nl. 3600IN NS ns1.argewebhosting.eu. tio.nl. 3600IN NS ns2.argewebhosting.com. tio.nl. 3600IN NS ns3.argewebhosting.nl. tio.nl. 3600IN DS 33829 8 2 81029E0FCAA9E0C8B2C599485634C0BD006607BAE31F51A48AF0B3A7 EBDBB8E3 tio.nl. 3600IN RRSIG DS 8 2 3600 20230516084745 20230501190734 50076 nl. HU8NwsPjKyakNkwXofrXCi6myG361X7PYkKbenuMz+idBTsOJxQDGmVp QAGsuI35V0zDKV4qhjCXH9DLfoPhktYMvQF1S87OrAVT8EKVMYOEbzmH e1KyXWXFIYoJnZxjL+peKL4KMKmlBn2ZbAZ2CjrEaCQU+JoQNK/rjL61 y+g= ;; Received 408 bytes from 2620:10a:80ac::200#53(ns4.dns.nl) in 12 ms tio.nl. 3600IN SOA ns1.argewebhosting.eu. hostmaster\@argeweb.nl. 2023021412 10800 3600 604800 3600 tio.nl. 3600IN RRSIG SOA 8 2 3600 2023051800 2023042700 11454 tio.nl. JxpppR49YY6NXXJStWmSmQyE1CUNBS6UVQ56WUeZUL3Hs0+ADoQ/Jr6A lo00s+d8yNg6zoMqVOCSp0yKmrSJQ1bbX3jsbyJjryL0YuDnu6sZz4ZE JsQw4xhewJhXw9MDen2UjB0TPRp+j6N2RPgdE9dtzqYddAdmqNyE0QNu fE0= kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN NSEC3 1 0 1 AB KGKAK3FDJ7OR1SLCGL2M254C661KKVCU A NS SOA MX TXT RRSIG DNSKEY NSEC3PARAM kehjo2i9ccgil56qqhgo4o6j7igguuks.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. mSK7JoJp+VyXIOTeW1jMndxc3l2li7uj+uwf+9/ZT1/wIqb9fCcHiITk ET4c3JR5VUa+Mq0rUrwCPUZ0DzXFmvvp0yrYoleoczsdgMxKgyfjpqgs +XaElHEF2LWzA33CNkDO8kxaXAfTXNYaGMfTzVMOi+9NYEB3n5tjGBqJ Wcg= oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN NSEC3 1 0 1 AB OORJ40BKUP0NDMA08HQO9NS6EMNVIKTH A RRSIG oji66ft00rg1tjd4kc30vno3gbkruu91.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. VY387t4VXyf55HF9EK5l5BJupdO65JBccwQ4AAQJZ6eI/8iYak5H73Wi Mpqu1Dw/NSuWgfYvhtfG5KFqlqyuH88pKJtt5mra6+c3NRi1F6yu4TYS owv7naAaZy4Tv83zMcNYjivcM2wV4PCKX9nM1TQieRwB9nBx5+QnvUkX KvI= o4n6i0v019dpao7abq7mfor6a1543t6g.tio.nl. 3600 IN NSEC3 1 0 1 AB OJI66FT00RG1TJD4KC30VNO3GBKRUU91 CNAME RRSIG o4n6i0v019dpao7abq7mfor6a1543t6g.tio.nl. 3600 IN RRSIG NSEC3 8 3 3600 2023051800 2023042700 11454 tio.nl. FGm7FofqjWiWd+9Bj7oNaLqraLyajz7rugO7N7ctd8ZKT14qcEfGkrgV zghw+Zpnda4Hb7aGomdsZ/XdiJorXRZRWQD5Qcirm1YEoZwAAbLyyJK0 qfn3g8SRuVH51nVOOr7WfeZRMVXOlgYSrRnYGlsGQfg/y7or/1qrGnxM 8gM= ;; Received 1029 bytes from 2a05:1500:702:0:1c00:eff:fe00:ce#53(ns1.argewebhosting.eu) in 8 ms - And just to make sure it
Re: bind9 and dns forward
Le 2 mai 2023 Bonno Bloksma a écrit :
> linbobo:/etc/bind# cat named.conf.local
> ---
> []
> 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 ?
RE: bind9 and dns forward
Hi, Lots of info and log quotes. I hope you can find the "normal" text. >> 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 dig > @172.16.128.10 vijl.staf.tio.nl Yes I also have dig. About your 4 dig statements. Like I wrote the problem with office365 is not MY problem, that is a Microsoft problem. And even though I have a working ipv6 environment at home I do not have a working ipv6 VPN tunnel to work, nor do we use ipv6 there internally. So here are the ipv4 results. As you can see there is a working dns server at those 2 ip numbers. -- linbobo:/etc/bind# dig @172.16.128.40 vijl.staf.tio.nl A ; <<>> DiG 9.16.37-Debian <<>> @172.16.128.40 vijl.staf.tio.nl A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61639 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;vijl.staf.tio.nl. IN A ;; ANSWER SECTION: vijl.staf.tio.nl. 1200IN A 172.16.72.97 ;; Query time: 8 msec ;; SERVER: 172.16.128.40#53(172.16.128.40) ;; WHEN: Tue May 02 11:20:52 CEST 2023 ;; MSG SIZE rcvd: 61 linbobo:/etc/bind# dig @172.16.208.10 vijl.staf.tio.nl A ; <<>> DiG 9.16.37-Debian <<>> @172.16.208.10 vijl.staf.tio.nl A ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 12968 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4000 ;; QUESTION SECTION: ;vijl.staf.tio.nl. IN A ;; ANSWER SECTION: vijl.staf.tio.nl. 1200IN A 172.16.72.97 ;; Query time: 16 msec ;; SERVER: 172.16.208.10#53(172.16.208.10) ;; WHEN: Tue May 02 11:21:04 CEST 2023 ;; MSG SIZE rcvd: 61 -- But if I query my own bind server... -- linbobo:~# dig vijl.staf.tio.nl ; <<>> DiG 9.16.37-Debian <<>> vijl.staf.tio.nl ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 16945 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 1232 ; COOKIE: 63ecb9edc2f5036e01006450d2a73c1c133db0bfc629 (good) ;; QUESTION SECTION: ;vijl.staf.tio.nl. IN A ;; Query time: 12 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Tue May 02 11:06:47 CEST 2023 ;; MSG SIZE rcvd: 73 And from /var/log/syslog May 2 11:06:32 linbobo named[574]: DNS format error from 172.16.128.40#53 resolving vijl.staf.tio.nl/ for 127.0.0.1#56241: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response May 2 11:06:32 linbobo named[574]: FORMERR resolving 'vijl.staf.tio.nl//IN': 172.16.128.40#53 May 2 11:06:32 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:32 linbobo named[574]: no valid RRSIG resolving 'staf.tio.nl/DS/IN': 172.16.128.40#53 May 2 11:06:32 linbobo named[574]: DNS format error from 172.16.208.10#53 resolving vijl.staf.tio.nl/ for 127.0.0.1#56241: Name tio.nl (SOA) not subdomain of zone staf.tio.nl -- invalid response May 2 11:06:32 linbobo named[574]: FORMERR resolving 'vijl.staf.tio.nl//IN': 172.16.208.10#53 May 2 11:06:32 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:32 linbobo named[574]: no valid RRSIG resolving 'staf.tio.nl/DS/IN': 172.16.208.10#53 May 2 11:06:32 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl/A/IN': 172.16.128.40#53 May 2 11:06:35 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:35 linbobo named[574]: no valid RRSIG resolving 'student.tio.nl/DS/IN': 172.16.128.40#53 May 2 11:06:35 linbobo named[574]: validating tio.nl/SOA: got insecure response; parent indicates it should be secure May 2 11:06:35 linbobo named[574]: no valid RRSIG resolving 'student.tio.nl/DS/IN': 172.16.208.10#53 May 2 11:06:35 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl.student.tio.nl/A/IN': 172.16.128.40#53 May 2 11:06:35 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl.student.tio.nl//IN': 172.16.128.40#53 May 2 11:06:47 linbobo named[574]: validating vijl.staf.tio.nl/A: bad cache hit (staf.tio.nl/DS) May 2 11:06:47 linbobo named[574]: broken trust chain resolving 'vijl.staf.tio.nl/A/IN': 172.16.128.40#53
Re: bind9 and dns forward
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 dig @172.16.128.10 vijl.staf.tio.nl > Apr 28 12:07:53 linbobo named[546]: DNS format error from 172.16.128.40#53 > resolving staf.tio.nl/ 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.
