26 Kvě
2016
26 Kvě
'16
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 -----
From: "Anand Buddhdev"
<anandb(a)ripe.net>
To: knot-dns-users(a)lists.nic.cz
Sent: Thursday, May 26, 2016 12:23:28 PM
Subject: Re: [knot-dns-users] Knot DNS 2.2.1 patch release
On 24/05/16 15:10, Jan Včelak wrote:
Hi Jan,
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.
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
_______________________________________________
knot-dns-users mailing list
knot-dns-users(a)lists.nic.cz
https://lists.nic.cz/cgi-bin/mailman/listinfo/knot-dns-users