knot-dns-users

knot-dns-users@lists.nic.cz

6 participants
762 discussions

Re: [knot-dns-users] knot-dns-users Digest, Vol 28, Issue 9

by Maren S. Leizaola

On 2/24/2014 7:00 PM, knot-dns-users-request(a)lists.nic.cz wrote: > Date: Mon, 24 Feb 2014 09:16:27 +0100 > From: Jan Kadlec <jan.kadlec(a)nic.cz> > To: "Maren S. Leizaola" <leizaola(a)hk.com> > Cc: knot-dns-users(a)lists.nic.cz > Subject: Re: [knot-dns-users] GLUE and additional records. > Message-ID: > <1393229787.1717.12.camel(a)labs.jan.kadlec.ws.eth.1.office.nic.cz> > Content-Type: text/plain; charset="UTF-8" > > Hello Maren and thanks for your report. Knot normally sends glue records > in additional section, it seems as if you might have encountered a bug. > Could you provide more data? One NS, A (AAAA) combination and a dig > output for this combination should be enough. Thanks again, Jan. > The environment is as follows. I host hk.com on 6 DNS servers, right now 5 are bind and one is Knot. hk.com's name servers are a,b,c,d,e,f.udrtld.net b is running Knot. Try this link www.intodns.com/hk.com This reports that B provides no glue. Please ignore the errors on f. i've yet not setup urdtld.net on it. dig -cA hk.com @b.udrtld.net when I do a dig -cA hk.com @a.udrtld.net Am I making any mistakes here? Maren.

12 let, 4 měsíce

GLUE and additional records.

by Maren S. Leizaola

Hello, I am currently testing Knot on our zones and find that it does not give any of the additional records which contain the IP of the names servers ie knot servers donot provide Glue records. This is one good thing that Bind does at it reduces the number of queries a resolver has to make. Is there any way for us to be able to do this. Regards, Maren.

12 let, 4 měsíce

/help

by Maren S. Leizaola

/subscribe /list

12 let, 4 měsíce

Knot DNS 1.4.3

by Marek Vavruša

Hi Everyone, I think the time is ripe for a small status update, preview of things to come and a new patch release. Sounds good? So, at the moment, our team at the CZ.NIC Labs is working towards the next major thing, but I'd like to reiterate that we didn't forget about the 1.4 and as of today we have a new release with several important backported bugfixes, here's the brief version: * Two bugs related to authenticated denial of existence proof with a certain combination of wildcard expansions triggering an assertion failure * Comparison of $ORIGIN and zone file in configuration is case insensitive * Corrupted journal data caused a cleanup failure during the zone loading In addition to the bugfixes, we have also slipped in a small enhancement - "include" statement in the configuration can include whole directory, this is useful if you have really a lot of includes in one place. Now a brief status update on what are we working on and what can you expect in the next few weeks/months. The next major release is going to happen later this spring and it's going to be focused on three things mostly - covering the code by tests, cleaning up and polishing existing features. There's going to be a feature or two, but that is not the main focus. The reason is the functionality we have piled up over the time has taken it's toll and now is the right time to sit back and make the features leaner and meaner (that includes usability as well), as that was always an integral idea behind Knot DNS. Plus less things means less things to break, right? I'd like to thank namely Petr Stastny and Olafur Gudmundsson (among others) for bugreports, ideas and thoughts. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.3/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.3.tar.xz.asc Kind Regards, Marek -- Marek Vavrusa, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

12 let, 4 měsíce

Feature request: force zone retransfer

by Anand Buddhdev

Hi Knot developers, I have a feature request: I'd like a knotc command that will force Knot to transfer a zone that is configured as a slave. The only command I can issue at the moment is "refresh", but this will not transfer a zone if Knot has a higher serial than the master. Such a forced transfer command is useful to help recover from situations where due to some operational error on the master server, the serial number has gone back, and we deliberately need our Knot server to sync to that old serial number. Without this command, the only way to make Knot recover is to stop it, delete the zone file from disk and start it again. But this is not ideal on a running server with lots of zones, because the stop and start times can be quite high (in our case, 37s to stop, and 1m30s to start). Both BIND and NSD provide such commands to ignore the serial number check and force zone transfers. I'd love to see such a command for Knot too. Regards, Anand

12 let, 4 měsíce

Case handling of zone names and in $ORIGIN

by Olafur Gudmundsson

I started to play with the dnssec signing features in Knot. I had this in my .conf file B-100.tld { file "B-100.zone"; …. } In the B-100.zone file I had $ORIGIN B-100.tld. I get Jan 31 16:27:32 bigredone knot[31315]: [error] Zone 'B-100.tld.': mismatching origin in the zone file. Jan 31 16:27:32 bigredone knot[31315]: [error] Failed to load zone 'B-100.tld.'. When I changed to $ORIGIN b-100.tld. Same error When I changed the conf line for B-100 to b-100 zone got loaded, I when I changed Origin to upper case but kept the lower case in conf file then zone was loaded. Summary: conf file requires zone name to be lower case, origin can be either case. (not documented) I do not think this what users expect. Either respect the case that users present or downcase both zone name and name on $ORIGIN line Also I would be great to have knot-checkzone command that one can use to verify the syntax of zone with output to standard output. Olafur

12 let, 4 měsíce

DS records

by Sime Ramov

Hello, I'm using Knot DNSSEC automatic signing and all is well and working. How would one go about obtaining proper DS records for registrar glue with least amount of trouble? Thanks for Knot DNS, by far the most pleasant experience in comparison with all other DNS servers. I've had zero issues with it, flawless operation from the start!

12 let, 4 měsíce

Knot DNS 1.4.2 patch release

by Jan Včelák

Hello List! We really appreciate your feedback on the previous release - both positive and negative. Thank you for that, it motivates us to make Knot DNS even better. Today, CZ.NIC Labs proudly announce the Knot DNS 1.4.2. There are quite a lot of changes: * The new release includes a compatibility fix for the AXFR/IXFR issues, which occurred when accepting transfers from tinydns/axfrdns. * In some cases, a TSIG did not fit into the outgoing transfer causing the transfer to be terminated. This problem was addressed as well. * Also, journal files are newly created only when necessary. It means that some disk space is spared when IXFR, DDNS, and DNSSEC signing are disabled. Feel free to delete the existing journal files if the zones fits into this category. * In addition, problems with incorrect logging categories regarding zones were reported. The logging was reviewed and should be appropriate with the new release. * We also fixed several problems in DNSSEC. Firstly, the 'knotc signzone' command was broken and caused a deadlock of the main server thread. It does not happen with the new version. Secondly, prior to this release, the signatures were refreshed two hours before their expiration, which was found to be extremely insufficient. With the new release, signatures are refreshed one tenth of the signature lifetime before their expiration. With the default configuration, the signature lifetime is 30 days, which implies that the signatures are refreshed three days before the expiration. * Moreover, RRSIGs in the additional records not-fitting into the DNS message do not cause packet truncation, but are simply skipped. We are looking forward to your reactions and comments. Full changelog: https://gitlab.labs.nic.cz/labs/knot/blob/v1.4.2/NEWS Sources: https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz GPG signatures: https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.gz.asc https://secure.nic.cz/files/knot-dns/knot-1.4.2.tar.xz.asc Best Regards, Jan -- Jan Včelák, Knot DNS CZ.NIC Labs http://www.knot-dns.cz ------------------------------------------- Americká 23, 120 00 Praha 2, Czech Republic WWW: http://labs.nic.cz http://www.nic.cz

12 let, 4 měsíce

RRSIG in additional section: reason for TC?

by Hauke Lampe

Hello. I configured "max-udp-payload 1464" and noticed that Knot 1.4 sets tc if it can't fit RRSIGs for records in the additional section while 1.3.4 didn't. I was wondering what the reasoning is behind this behaviour. Shouldn't validating resolvers ignore unsigned record sets in the additional section anyway? In my tests, Knot 1.4 almost always sets tc unless it can fit all DNSKEYs, nameserver addresses and their signatures in the additional section. That seems a bit excessive. There are only a few narrow buffer sizes ranges that don't result in a truncated response, depending on the reply content: > $ l=""; i=1800; j=$i; while [ "$i" -lt "4097" ]; do n="`dig +bufsize=$i +ignore +norec +dnssec openchaos.org soa @nsig17.openchaos.org |grep ";; flags:"`"; [ "$l" != "$n" ] && { echo "$j - $(($i-1)): $l"; l=$n; j=$i; }; i=$(($i+1)); done; echo "$j - $(($i-1)): $n" > 1883 - 1898: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 4 > 2102 - 2129: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 6 > 2333 - 2348: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 8 > 2552 - 2567: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 10 > 2771 - 2798: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 12 > 3002 - 3017: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 14 > 3221 - 3236: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 16 > 3440 - 3455: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 18 > 3659 - 3686: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 20 > 3890 - 4096: ;; flags: qr aa; QUERY: 1, ANSWER: 2, AUTHORITY: 7, ADDITIONAL: 22 FWIW, the attached patch works for me. It should remove the last additional record if its RRSIG doesn't fit. Hauke

12 let, 5 měsíců

Warning messages does not contain domain name

by Petr Šťastný

Hi, the majority of warning messages does not contain particular domain name (zone name), so it is impossible to figure which zone file is wrong. For example: > 2014-01-23T20:13:07 [warning] encountered identical extra SOA record > 2014-01-23T20:13:07 [warning] encountered identical extra SOA record > 2014-01-23T20:13:07 [warning] TTL does not match TTL of its > RRSet.Changing to 19200 Can you please add zone names into all error and warning messages related to one zone? Thanks Petr Šťastný

12 let, 5 měsíců

← Newer
1
...
62
63
64
65
66
67
68
...
77
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

knot-dns-users