24 Kvě
2016
24 Kvě
'16
15:10
Hello everyone.
CZ.NIC Labs has just released a patched version of Knot DNS. The 2.2.1
version contains some important bug fixes and a few small improvements.
Let's jump directly into it:
- The previous version was inconsistent in setting the TC flag for
delegations with a glue. We have decided to modify the behavior
slightly and the TC flag is now set always if a complete glue doesn't
fit the response.
- Logging of individual categories (server or zone) didn't work in the
previous release. This problem is now resolved. Logging all categories
(any configuration option) was not affected.
- We have eliminated data race in the code responsible for zone file
flushing. When more zone files were flushed concurrently, flushing of
some zones could fail. This problem is fixed in the new release.
- If you are running Knot DNS on OpenWRT, we advise you to update to the
new release. There has been a critical bug possibly making the server
to crash.
- There had been several issues with the control utility: The timeout
for reconfiguration is now parsed correctly. The "maxreaders limit
reached" error is gone. And the interactive mode now completes
multiple zone names if allowed by the command. The server will also
refuse to perform the reload, if there is an active configuration
transaction.
- We have removed switch for Link Time Optimization from the configure
script, because LTO is still rather problematic. If you want to use
LTO, set the CFLAGS and LDFLAGS appropriately.
- We have improved the logging and status messages to differentiate
between an unavailable zone and a zone with zero serial.
- We have added a list of PKCS #11 devices which had been tested with
automatic DNSSEC signing.
We are looking forward to your feedback.
The sources are available as usual:
Full changelog:
https://gitlab.labs.nic.cz/labs/knot/raw/v2.2.1/NEWS
Sources:
https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz
GPG signature:
https://secure.nic.cz/files/knot-dns/knot-2.2.1.tar.xz.asc
Cheers,
Jan
--
Jan Včelák, Knot DNS
CZ.NIC Labs https://www.knot-dns.cz
--------------------------------------------
Milešovská 5, 130 00 Praha 3, Czech Republic
WWW: https://labs.nic.cz https://www.nic.cz
25 Kvě
25 Kvě
15:06
Hi Jan,
On 24 May 2016, at 15:10 , Jan Včelak <jan.vcelak(a)nic.cz> wrote:
Umm. I think that's in violation of the protocol, or at least a misinterpretation of
the protocol.
The coherency requirement for DNS is that the contents of the Answer and Authority
sections should be complete, otherwise set TC=1 to signal that they are not.
The Additional section is explicitly not part of the requirement, regardless of whether it
contains glue, DNSKEYs or something else. The reason is that different servers may have
different amounts of Additional data available, hence it is not possible to put the
Additional section under the coherency requirement.
What was the previous inconsistency that you needed to resolve?
Regards,
Johan
15:11
Johan,
basically it's possible to construct such zone (and/or tune the edns0 bufsize) to the
point that no GLUE is ever returned. We have decided that in this specific case (we are
just speaking about GLUE) it's much better to signal the information is incomplete.
I don't think this will cause any operational problems because it only covers a corner
case and any compliant resolver will just re-ask via TCP and be done with it.
We have been doing all kind of fancy stuff with +TC anyway in the last years (like RRL or
no-ANY) and this is not different in my eyes.
Cheers,
Ondrej
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
17:48
Hello Johan,
thank you for thinking about it and for challenging our decision. :-)
On 25.5.2016 15:06, Johan Ihrén wrote:
I don't think we are violating the protocol. The glue is required in the
response. At least this is how I understand the response processing
algorithm described in Section 4.3.2 of RFC 1045 [1].
[1] https://tools.ietf.org/html/rfc1034#section-4.3.2
The step 2.b (processing of referral) says:
| Put whatever addresses are available into the additional section,
| using glue RRs if the addresses are not available from authoritative
| data or the cache.
And compare that to the step 6 (processing of additionals):
| Using local data only, attempt to add other RRs which may be
| useful to the additional section of the query.
That's my interpretation of "put" vs "attempt to add".
What was the previous inconsistency that you needed to
resolve?
The potential problem was reported by John [2]. Previously, Knot DNS
didn't set the TC flag if no glue record fit the response. That was
inconsistent with BIND, which sets TC in the same case.
I personally think that BIND's logic in glue inclusion is needlessly
complicated. The new logic in Knot DNS is dead simple: Referral with
incomplete glue sets the TC flag.
[2] https://gitlab.labs.nic.cz/labs/knot/issues/459
Do you think this could cause some operational problems?
Cheers,
Jan
26 Kvě
26 Kvě
0:44
David,
it might in case EDNS0 is not used and >= 512b response would be generated.
We might revisit our approach is this poses a proven operational problem, but when I look
into DSC stats for .CZ I see <20% on non-EDNS0 queries and I am quite confident that
those queries are coming mostly from non-compliant clients that will never ask over TCP
again anyway. I'll ask Geoff whether he has some real-world numbers on that or if he
could run a quick test with his Google Ad Network Grand Abuse (GANGA :).
Cheers,
Ondrej
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
12:23
On 24/05/16 15:10, Jan Včelak wrote:
Hi Jan,
I appreciate the effort to fix this bug, but I would have preferred a
discussion if it, before you implemented it this way.
When a delegating server sends a delegation response, and the name
servers are all in-zone, and it cannot fit even one glue record into the
response, then the client cannot follow this delegation chain, so Knot
would need to set the TC bit.
However, if Knot is able to fit in at least one glue record into the
delegation response, then it doesn't make sense to set TC. That's
because the client can contact the glue address provided to discover the
missing A/AAAA records. A client needs to do this anyway, because the
glue records from the parent are not authoritative.
Now, with Knot setting TC in a delegation response, it has the potential
to cause clients make one more query to the parent server, and this
query, in my opinion, isn't necessary.
Having said this though, this is all a problem only for clients that
aren't using ENDS, or using EDNS with a small buffer (such as when BIND
falls back to small buffers to get around firewalls, for example).
I can see CZNIC's point of view in making this change to set TC always,
but I'm not yet convinced that this is a good idea.
Regards,
Anand
14:15
Hi,
On Thu, May 26, 2016 at 12:23:28PM +0200, Anand Buddhdev wrote:
And when that single "glue-provided-for" server is down, what do you do next?
Gert Doering
-- NetMaster
--
have you enabled IPv6 on something today...?
SpaceNet AG Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444 USt-IdNr.: DE813185279
14:22
Anand, John, et al,
would it be perhaps possible to conduct the experiment whether this has a real operational
impact at the root? Perhaps running Knot DNS 2.2.1 on a singular instance of the root
server for a set period of time and compare the numbers of TCP requests?
I suspect only a few non-EDNS0 clients will switch to TCP as dnscache from djb is not TCP
capable as far I as can remember.
Cheers,
--
Ondřej Surý -- Technical Fellow
--------------------------------------------
CZ.NIC, z.s.p.o. -- Laboratoře CZ.NIC
Milesovska 5, 130 00 Praha 3, Czech Republic
mailto:ondrej.sury@nic.cz https://nic.cz/
--------------------------------------------
----- Original Message -----
15:19
On 26/05/16 14:22, Ondřej Surý wrote:
Hi Ondrej,
I can't answer this immediately, but I would probably test this in a lab
by replaying captured queries, rather than doing it live :)
I suspect only a few non-EDNS0 clients will switch to
TCP as
dnscache from djb is not TCP capable as far I as can remember.
Actually my recollection is that dnscache *does* fall back to TCP if it
receives a response with TC set. So dnscache instances are the most
likely to do more TCP in response to delegation responses with TC.
Regards,
Anand
14:29
Hello.
Agreed. We didn't do it in Knot < 2.2.1. We do it now.
This raises many questions:
- How will the requester differentiate whether the provided glue is
complete or not?
- What if only the first A glue record fits the zone and the requester
is IPv6 only?
- What if only the first glue server fits but the server is unreachable
from requester?
- Are all the slave servers equal? Or should we prefer the first one?
I prefer giving the requester a complete information about the glue.
Otherwise the query resolution logic gets complicated both on the
authoritative and resolver part.
It seems that root servers are inconsistent as for the TC setting and
glue. The A root and J root are setting the TC flag as we do:
for server in {a..m}.root-servers.net; do
echo $server
kdig +notcp +dnssec +bufsize=512 @"$server" www.com | grep "^;;
Flags";
done
I wonder if it's desired. The glue for .com belongs to .net, so this
probably should not cause a truncation. (It would case TC with Knot
2.2.1 as well.)
Anand, do you have any estimation, what is the proportion of these clients?
I can see CZNIC's point of view in making this
change to set TC always,
but I'm not yet convinced that this is a good idea.
I understand this. And we can always change it again for everyone's
satisfaction. :-)
So what about the following: We will set TC in the response if complete
mandatory glue doesn't fit the response. Mandatory glue means that the
name servers reside within or bellow the delegated zone. Otherwise, we
will treat the glue records as optional.
Does it make sense?
Cheers,
Jan
16:31
On 26/05/16 14:29, Jan Včelak wrote:
Hi Jan,
The requester has a list of name servers, and if they're in-zone, and
there's no glue for them in additional, then the requestor knows that it
needs to fetch those missing addresses.
- What if only the first A glue record fits the zone
and the requester
is IPv6 only?
This is an interesting question. BIND >= 9.10.4, and NSD trunk both have
code that favours glue of the address family of the query. So if the
query comes in over IPv6, then the latest BIND and NSD both attempt to
fill the additional section with IPv6 glue, followed by IPv4 glue, and
vice versa. The logic here is that if the query came in over IPv6, then
it's possible that the resolver may be IPv6-only.
- What if only the first glue server fits but the
server is unreachable
from requester?
This is indeed a failure scenario. But it's not Knot's job to ensure
that all of a domain's name servers are reachable. So perhaps we should
not go down this route.
- Are all the slave servers equal? Or should we prefer
the first one?
Yes, in DNS, all NS records are equal :)
I do understand the motivation for this logic. But glue records in a
delegation response are hints. Does it make sense to spend effort
improving this? I'm aksing this to everyone, not just the Knot developers.
Thank you for highlighting this difference. Perhaps this is an argument
in favour of setting TC. As I said, I haven't made up my mind about this
change.
I don't, at the moment. Needs some measurement and investigation.
Don't make any changes just yet. I am just discussing this to understand
all the implications. I don't have a strong objection to this change.
Your change may still be the right one, so let's hear more opinions and
ideas :)
Regards,
Anand
19:20
Hello,
On 26/05/2016 13:29, Jan Včelak wrote:
Its worth mentioning this
is how NSD works. Im not sure which behavior
i prefer.
The authority section would still contain the full nsset so the
cache
would know if it did not have A/AAAA records for all records in the NS set
- What if only the first A glue record fits the zone
and the requester
is IPv6 only?
knot could try to include one AAAA record fi one exists, if not it
should add the single A record (the client may be dual stacked so may be
able to use the A record)
- What if only the first glue server fits but the
server is unreachable
from requester?
This is the down side to the way NSD operates the downside to
knot is
the potential increased TCP load.
- Are all the slave servers equal? Or should we prefer
the first one?
all equal IMO
I notice that the behavior for an in zone nsset is
different and glue is
added depending on the EDNS size.
e.g.
dig +dnssec ns example.com. @5.28.63.78 +bufsize=1680
dig +dnssec ns example.com. @5.28.63.78 +bufsize=1780
vs
dig +tcp +dnssec ns example.com. @5.28.63.78
I have also noticed inconsistencies in relation to when RRSIGs get added
to the additional section.
When running the following query i get inconsistent results
dig +dnssec ns nic.cz @194.0.12.1 +bufsize=600
This normally provides the following answer which seems to follow the
logic of add all the glue records then add the RRSIG's if they fit
-------------------------------------------------------------------
; <<>> DiG 9.10.3-P4 <<>> +dnssec ns nic.cz @194.0.12.1
+bufsize=615 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40303
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 8
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; NSID: 64 6e 73 2d 73 2d 30 31 2e 6e 69 63 2e 63 7a ("dns-s-01.nic.cz")
;; QUESTION SECTION:
;nic.cz. IN NS
;; ANSWER SECTION:
nic.cz. 1800 IN NS a.ns.nic.cz.
nic.cz. 1800 IN NS b.ns.nic.cz.
nic.cz. 1800 IN NS d.ns.nic.cz.
nic.cz. 1800 IN RRSIG NS 5 2 1800 20160608070658 20160525085002
37152
nic.cz. A5JPuZTPiZyY6QTz9k3DaS6kigPZf+3Exnchr1gQbu0dY4WwwrdbKGST
R9oT4dpPnq59kfPVehdDjFJJns9vUFOmQrh6SIB8oF3bS+GJwLttZU/z
gIe35hMLA6eDAYs5oUnFt4XTRf8W3E/0kJpaoGUdqQphapRaxrMzBdiC 2nw=
;; ADDITIONAL SECTION:
a.ns.nic.cz. 1800 IN A 194.0.12.1
a.ns.nic.cz. 1800 IN AAAA 2001:678:f::1
b.ns.nic.cz. 1800 IN A 194.0.13.1
b.ns.nic.cz. 1800 IN AAAA 2001:678:10::1
d.ns.nic.cz. 1800 IN A 193.29.206.1
d.ns.nic.cz. 1800 IN AAAA 2001:678:1::1
a.ns.nic.cz. 1800 IN RRSIG A 5 4 1800 20160607203614 20160525085002
37152 nic.cz. PXqbWak0/qU6g/P7Vm/XGjuwxTL8XiWLnlrTG5Z/g5XJhpknN/49MTtN
SeQ5LxryZojrvzyiKrauPFz6WWZmID8RUgRr95nC7pmZauilRAUVyRXR
q5tgvRKRIpoxp9hw+db/36HvZPr4CVSzscufEdVRiO8jliLfinIJu7r3 WZs=
;; Query time: 45 msec
;; SERVER: 194.0.12.1#53(194.0.12.1)
;; WHEN: Thu May 26 15:56:26 BST 2016
;; MSG SIZE rcvd: 569
-------------------------------------------------------------------
however i occasionally get the following (from dns-r-01.nic.cz) which
suggests that if you add a glue record then also its rrsig. if there is
more room add another glue record and its rrsig. swapping between a
bufsize of 617 and 615 suggests that glue will only be added if the
RRSIG also fits
-------------------------------------------------------------------
; <<>> DiG 9.10.3-P4 <<>> +dnssec ns nic.cz @194.0.12.1
+bufsize=615 +nsid
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54745
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 3
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; NSID: 64 6e 73 2d 72 2d 30 31 2e 6e 69 63 2e 63 7a ("dns-r-01.nic.cz")
;; QUESTION SECTION:
;nic.cz. IN NS
;; ANSWER SECTION:
nic.cz. 1800 IN NS a.ns.nic.cz.
nic.cz. 1800 IN NS b.ns.nic.cz.
nic.cz. 1800 IN NS d.ns.nic.cz.
nic.cz. 1800 IN RRSIG NS 5 2 1800 20160608070658 20160525085002
37152
nic.cz. A5JPuZTPiZyY6QTz9k3DaS6kigPZf+3Exnchr1gQbu0dY4WwwrdbKGST
R9oT4dpPnq59kfPVehdDjFJJns9vUFOmQrh6SIB8oF3bS+GJwLttZU/z
gIe35hMLA6eDAYs5oUnFt4XTRf8W3E/0kJpaoGUdqQphapRaxrMzBdiC 2nw=
;; ADDITIONAL SECTION:
a.ns.nic.cz. 1800 IN A 194.0.12.1
a.ns.nic.cz. 1800 IN RRSIG A 5 4 1800 20160607203614 20160525085002
37152 nic.cz. PXqbWak0/qU6g/P7Vm/XGjuwxTL8XiWLnlrTG5Z/g5XJhpknN/49MTtN
SeQ5LxryZojrvzyiKrauPFz6WWZmID8RUgRr95nC7pmZauilRAUVyRXR
q5tgvRKRIpoxp9hw+db/36HvZPr4CVSzscufEdVRiO8jliLfinIJu7r3 WZs=
;; Query time: 41 msec
;; SERVER: 194.0.12.1#53(194.0.12.1)
;; WHEN: Thu May 26 15:56:26 BST 2016
;; MSG SIZE rcvd: 453
-------------------------------------------------------------------
again im not sure which behavior i prefer but seems related to this thread
This is due to the
use of different daemons and configs. As far as i
know bind, nsd and knot all act differently in the way they handle glue
in the additional section. (although i haven't tested bind that much)
A much more interesting case is mn.
for server in {a..m}.root-servers.net;
do
echo $server;
kdig +notcp +dnssec +bufsize=512 @"$server" ns mn ;
done
This produces a referral with no glue from all servers accept A and J.
It would
however both net is still a child of . so i think the server should
still try to send at least one glue record.
clients?
l root still sees a lot of queries without EDNS
http://stats.dns.icann.org/plotcache/L-root/edns_version/2016-05-25T00:00-2…
This seems reasonable to me
3357
days inactive
3359
days old
13 comments
7 participants
participants (7)
-
Anand Buddhdev -
David Conrad -
Gert Doering -
Jan Včelak -
Johan Ihrén -
John Bond -
Ondřej Surý