Hi Ivo,
thanks for information. I suspect there might be problem with particular
domain and configuration combination.
Unfortunatelly it is hard to give any advice if we do not have exact
steps to reproduce including real domain name because we cannot see
what's visible in real DNS. Please provide real domain names so we can
have a look.
Petr Špaček @ CZ.NIC
On 03. 11. 18 14:39, Ivo Panáček wrote:
> Hi,
>
> I have also added logging:
>
> policy.add(policy.suffix(
> policy.QTRACE,{
> todname('sub1.company.cz <http://sub1.company.cz>'),
> todname('sub2.company.cz <http://sub2.company.cz>')
> }
> ))
>
> and I include relevant part of /var/log/syslog
> ... just names are not real company.cz <http://company.cz> etc.
> and our domain has not (yet) DS record.
> To me it seems that kresd finds real record for company.cz
> <http://company.cz>
> and then does NOT honor my policy for it's subdomains.
>
> Nov 3 08:26:24 ud kresd[1293]: [ 0][plan] plan
> 'machine.sub1.company.cz <http://machine.sub1.company.cz>.' type 'A'
> Nov 3 08:26:24 ud kresd[1293]: [17479][iter] 'machine.sub1.company.cz
> <http://machine.sub1.company.cz>.' type 'A' id was assigned, parent id 0
> Nov 3 08:26:24 ud kresd[1293]: [17479][cach] => no NSEC* cached for
> zone: company.cz <http://company.cz>.
> Nov 3 08:26:24 ud kresd[1293]: [17479][cach] => skipping zone:
> company.cz <http://company.cz>., NSEC, hash 0;new TTL -123456789, ret -2
> Nov 3 08:26:24 ud kresd[1293]: [17479][cach] => skipping zone:
> company.cz <http://company.cz>., NSEC, hash 0;new TTL -123456789, ret -2
> Nov 3 08:26:24 ud kresd[1293]: [17479][plan] plan '.' type 'DNSKEY'
> Nov 3 08:26:24 ud kresd[1293]: [46470][iter] '.' type 'DNSKEY' id
> was assigned, parent id 17479
> Nov 3 08:26:24 ud kresd[1293]: [46470][cach] => satisfied by exact
> RRset: rank 060, new TTL 125366
> Nov 3 08:26:24 ud kresd[1293]: [46470][iter] <= answer received:
> Nov 3 08:26:24 ud kresd[1293]: ;; ->>HEADER<<- opcode: QUERY; status:
> NOERROR; id: 46470
> Nov 3 08:26:24 ud kresd[1293]: ;; Flags: qr aa QUERY: 1; ANSWER: 0;
> AUTHORITY: 0; ADDITIONAL: 0
> Nov 3 08:26:24 ud kresd[1293]: ;; QUESTION SECTION
> Nov 3 08:26:24 ud kresd[1293]: .#011#011DNSKEY
> Nov 3 08:26:24 ud kresd[1293]: ;; ANSWER SECTION
> Nov 3 08:26:24 ud kresd[1293]: .
> #011125366#011DNSKEY#011256 3 8
> AwEAAdp440E6Mz7c+Vl4sPd0lTv2Qnc85dTW64j0RDD7sS/zwxWDJ3QRES2VKDO0OXLMqVJSs2YCCSDKuZXpDPuf++YfAu0j7lzYYdWTGwyNZhEaXtMQJIKYB96pW6cRkiG2Dn8S2vvo/PxW9PKQsyLbtd8PcwWglHgReBVp7kEv/Dd+3b3YMukt4jnWgDUddAySg558Zld+c9eGWkgWoOiuhg4rQRkFstMX1pRyOSHcZuH38o1WcsT4y3eT0U/SR6TOSLIB/8Ftirux/h297oS7tCcwSPt0wwry5OFNTlfMo8v7WGurogfk8hPipf7TTKHIi20LWen5RCsvYsQBkYGpF78=
> Nov 3 08:26:24 ud kresd[1293]: .
> #011125366#011DNSKEY#011257 3 8
> AwEAAagAIKlVZrpC6Ia7gEzahOR+9W29euxhJhVVLOyQbSEW0O8gcCjFFVQUTf6v58fLjwBd0YI0EzrAcQqBGCzh/RStIoO8g0NfnfL2MTJRkxoXbfDaUeVPQuYEhg37NZWAJQ9VnMVDxP/VHL496M/QZxkjf5/Efucp2gaDX6RS6CXpoY68LsvPVjR0ZSwzz1apAzvN9dlzEheX7ICJBBtuA6G3LQpzW5hOA2hzCTMjJPJ8LbqF6dsV6DoBQzgul0sGIcGOYl7OyQdXfZ57relSQageu+ipAdTTJ25AsRTAoub8ONGcLmqrAmRLKBP1dfwhYB4N7knNnulqQxA+Uk1ihz0=
> Nov 3 08:26:24 ud kresd[1293]: .
> #011125366#011DNSKEY#011257 3 8
> AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTOiW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLYA4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
> Nov 3 08:26:24 ud kresd[1293]: .
> #011172800#011RRSIG#011DNSKEY 8 0 172800 20181121000000 20181031000000
> 20326 .
> V2mFe8AVsbdN0t7lZQz9uxIN0PUmb5xR9e70Hm07sgPkqerHKdBqXZjTTfwnixLkyiCP43zTJhBZH8OQbTy9aCI6P0FxjPV4qPdEdb4L+3c8bybYMdFtUgI3JFmJcTVtaibgtCZjLjZIXsbdbwOS2Ukm0Py2zHA6TGDVxG1M7BerTPLYCGNMuEhL8dvMegWZDbVcCfxrLTIl/smTTMfMz88/2QMMlIILENFn2HGxn6n9KGFGSM9fnvIuoSltt+BFYaxKdxjF02vM4/Ea6ZJ4PZhU1wGmedxoqoJYKgJYnrMmvhZEUyAhTP3w/ikPhmucA3OZkMJbxOvephxZSuMtQw==
> Nov 3 08:26:24 ud kresd[1293]: [46470][iter] <= rcode: NOERROR
> Nov 3 08:26:24 ud kresd[1293]: [46470][vldr] <= parent: updating DNSKEY
> Nov 3 08:26:24 ud kresd[1293]: [46470][vldr] <= answer valid, OK
> Nov 3 08:26:24 ud kresd[1293]: [58698][iter] 'machine.sub1.company.cz
> <http://machine.sub1.company.cz>.' type 'A' id was assigned, parent id 0
> Nov 3 08:26:24 ud kresd[1293]: [58698][plan] plan 'cz.' type 'DS'
> Nov 3 08:26:24 ud kresd[1293]: [49896][iter] 'cz.' type 'DS' id was
> assigned, parent id 58698
> Nov 3 08:26:24 ud kresd[1293]: [49896][cach] => satisfied by exact
> RRset: rank 060, new TTL 24337
> Nov 3 08:26:24 ud kresd[1293]: [49896][iter] <= answer received:
> Nov 3 08:26:24 ud kresd[1293]: ;; ->>HEADER<<- opcode: QUERY; status:
> NOERROR; id: 49896
> Nov 3 08:26:24 ud kresd[1293]: ;; Flags: qr aa QUERY: 1; ANSWER: 0;
> AUTHORITY: 0; ADDITIONAL: 0
> Nov 3 08:26:24 ud kresd[1293]: ;; QUESTION SECTION
> Nov 3 08:26:24 ud kresd[1293]: cz.#011#011DS
> Nov 3 08:26:24 ud kresd[1293]: ;; ANSWER SECTION
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #01124337#011DS#01120237 13 2
> CFF0F3ECDBC529C1F0031BA1840BFB835853B9209ED1E508FFF48451D7B778E2
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #01186400#011RRSIG#011DS 8 1 86400 20181115050000 20181102040000 2134 .
> y34iT/kNbVTU3joieB2yxbOGxHhv4xt6YrfdnfKEMfQLgyrxyvbHNRUQ3eeYheLh/jzbAqmWhynL28FcGbCe31GQV+gRLMRObMrhxTDvLMYgpekWl37f0JmVXhsFLlhsz4j0ylkeukrIjOtXP5o/tHeSdQpb9nM+ceOV9+Ziqmq8PTP1diXOwravepD3sKuER+GzFEQkreL+g/UCLuH6O+5mswRZUUsu2KInY9eaE4V49J5kFtnox92yR7sxYeadzPv9a/6HyME82nz5s5z8aUjajlNHV26eEJlfl8JQB6q1f/x0Kpqwofur/dioFKxtmF/QNum+pn9P7RAu0XxGSA==
> Nov 3 08:26:24 ud kresd[1293]: [49896][iter] <= rcode: NOERROR
> Nov 3 08:26:24 ud kresd[1293]: [49896][vldr] <= DS: OK
> Nov 3 08:26:24 ud kresd[1293]: [49896][vldr] <= parent: updating DS
> Nov 3 08:26:24 ud kresd[1293]: [49896][vldr] <= answer valid, OK
> Nov 3 08:26:24 ud kresd[1293]: [17264][iter] 'machine.sub1.company.cz
> <http://machine.sub1.company.cz>.' type 'A' id was assigned, parent id 0
> Nov 3 08:26:24 ud kresd[1293]: [17264][plan] plan 'cz.' type 'DNSKEY'
> Nov 3 08:26:24 ud kresd[1293]: [46784][iter] 'cz.' type 'DNSKEY' id
> was assigned, parent id 17264
> Nov 3 08:26:24 ud kresd[1293]: [46784][cach] => satisfied by exact
> RRset: rank 060, new TTL 17183
> Nov 3 08:26:24 ud kresd[1293]: [46784][iter] <= answer received:
> Nov 3 08:26:24 ud kresd[1293]: ;; ->>HEADER<<- opcode: QUERY; status:
> NOERROR; id: 46784
> Nov 3 08:26:24 ud kresd[1293]: ;; Flags: qr aa QUERY: 1; ANSWER: 0;
> AUTHORITY: 0; ADDITIONAL: 0
> Nov 3 08:26:24 ud kresd[1293]: ;; QUESTION SECTION
> Nov 3 08:26:24 ud kresd[1293]: cz.#011#011DNSKEY
> Nov 3 08:26:24 ud kresd[1293]: ;; ANSWER SECTION
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #01117183#011DNSKEY#011256 3 13
> GrWu3AwLX3b2yEVeTN4wvllu7Kay3roEADrhYloX9Y+KpJEqVp3gTt/eKBZboTl2pFy2rZFUfPGDGZWAlsLIGg==
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #01117183#011DNSKEY#011257 3 13
> nqzH7xP1QU5UOVy/VvxFSlrB/XgX9JDJzj51PzIj35TXjZTyalTlAT/f7PAfaSD5mEG1N8Vk9NmI2nxgQqhzDQ==
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #01118000#011RRSIG#011DNSKEY 13 1 18000 20181115000000 20181101000000
> 20237 cz.
> uTYoVTcosQoaR/3NUDP25JSlzRf8XGJN+wdxQni9q3mmCx8SzpotoLyYmOnkuj9dORXDVrPW+TCGEiQwfoq9mg==
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #01118000#011RRSIG#011DNSKEY 13 1 18000 20181116125037 20181103053521
> 42928 cz.
> 7BG7Wwz2RMxyni7xcuCmIUKoypTeDAxn+/yqtFbWZi6gci8cDYuO6vsm4FVa6GN+R0bBEwQMxeTHi7hDYExDRA==
> Nov 3 08:26:24 ud kresd[1293]: [46784][iter] <= rcode: NOERROR
> Nov 3 08:26:24 ud kresd[1293]: [46784][vldr] <= parent: updating DNSKEY
> Nov 3 08:26:24 ud kresd[1293]: [46784][vldr] <= answer valid, OK
> Nov 3 08:26:24 ud kresd[1293]: [54031][iter] 'machine.sub1.company.cz
> <http://machine.sub1.company.cz>.' type 'A' id was assigned, parent id 0
> Nov 3 08:26:24 ud kresd[1293]: [54031][plan] plan 'company.cz
> <http://company.cz>.' type 'DS'
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][iter] 'company.cz
> <http://company.cz>.' type 'DS' id was assigned, parent id 54031
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][cach] => skipping exact
> packet: rank 025 (min. 030), new TTL -58245
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][cach] => trying zone: cz.,
> NSEC3, hash 46c3ca06
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][cach] => NSEC3 depth 1: hash
> fqs41urr02n4up4lv57mkp9lh7psa9ba
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][cach] => NSEC3 sname: match
> proved NODATA, new TTL 83
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][cach] => SOA missed
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][resl] => querying:
> '10.0.0.1' score: 950 zone cut: 'cz.' qname: 'company.Cz.' qtype: 'DS'
> proto: 'udp'
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][iter] <= answer received:
> Nov 3 08:26:24 ud kresd[1293]: ;; ->>HEADER<<- opcode: QUERY; status:
> NOERROR; id: 1812
> Nov 3 08:26:24 ud kresd[1293]: ;; Flags: qr rd ra cd QUERY: 1; ANSWER:
> 0; AUTHORITY: 1; ADDITIONAL: 1
> Nov 3 08:26:24 ud kresd[1293]: ;; EDNS PSEUDOSECTION:
> Nov 3 08:26:24 ud kresd[1293]: ;; Version: 0; flags: do; UDP size: 4096
> B; ext-rcode: Unused
> Nov 3 08:26:24 ud kresd[1293]: ;; QUESTION SECTION
> Nov 3 08:26:24 ud kresd[1293]: company.cz.#011#011DS
> Nov 3 08:26:24 ud kresd[1293]: ;; AUTHORITY SECTION
> Nov 3 08:26:24 ud kresd[1293]: cz.
> #0113600#011SOA#011a.ns.nic.cz <http://011a.ns.nic.cz>.
> hostmaster.nic.cz <http://hostmaster.nic.cz>. 1541228723 900 300 604800 900
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][iter] <= rcode: NOERROR
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][resl] <= server: '10.0.0.1'
> rtt: 10 ms
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][resl] => resuming yielded answer
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][vldr] <= bad NODATA proof
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][cach] => stashed packet:
> rank 025, TTL 900, DS company.cz <http://company.cz>. (105 B)
> Nov 3 08:26:24 ud kresd[1293]: [ 1812][resl] finished: 0, queries:
> 3, mempool: 65600 B
>
>
> I have access to both DNS servers = our internal (bind9) and our
> external (knot).
>
> Ivo Panáček
>
>
> so 3. 11. 2018 v 2:14 odesílatel Petr Špaček <petr.spacek@nic.cz
> <mailto:petr.spacek@nic.cz>> napsal:
>
> Hi Ivo,
>
> what are symptoms? Does the query time out? Do you see anything in
> verbose log? (Use journalctl.)
>
> It is not clear what problem you see so it is hard to give any advice.
>
> Petr Špaček @ CZ.NIC
>
>
> On 02. 11. 18 22:05, Ivo Panáček wrote:
> > Hi,
> >
> > I am not able to force knot-resolver to forward some queries.
> >
> > I have real DNS zone and in internal network I have few 3rd level
> subzones.
> > For them I would like to make my kresd forward queries to our internal
> > DNS server (bind9).
> >
> > My computer is not inside company nework - connected via openvpn.
> > System is ubuntu 18.04.1 (up-to-date) and knot-resolver 3.0.0.
> >
> > Relevant part of kresd.conf is:
> >
> > policy.add(policy.suffix(
> > policy.FORWARD('10.0.0.1'),{
> > todname('sub1.company.cz <http://sub1.company.cz>
> <http://sub1.company.cz>'),
> > todname('sub2.company.cz <http://sub2.company.cz>
> <http://sub2.company.cz>')
> > }
> > ))
> >
> > dig machine.sub1.company.cz <http://machine.sub1.company.cz>
> <http://machine.sub1.company.cz> @127.0.0.53 <http://127.0.0.53>
> > <http://127.0.0.53> does NOT work,
> > dig machine.sub1.company.cz <http://machine.sub1.company.cz>
> <http://machine.sub1.company.cz> @10.0.0.1 <http://10.0.0.1>
> > <http://10.0.0.1> DOES work
> >
> > I have set verbose(true) but with no help.
> > kresd queries 10.0.0.1 for 'company.cz <http://company.cz>
> <http://company.cz>' only, but
> > that's all.
> >
> > I am just working on it on my ubuntu workstation,
> > but real target will be turris omnia with its kresd,
> > which connects via openvpn to company network.
> >
> > --
> > Sincerely
> > Ivo Panacek
>
> --
> https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users
>
>
>
> --
> Sincerely
> Ivo Panacek
--
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-resolver-users