25 Kvě
2016
25 Kvě
'16
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:
On 24 May 2016, at 15:10 , Jan Včelak
<jan.vcelak(a)nic.cz> 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".
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.
Umm. I think that's in violation of the protocol, or at least a misinterpretation of
the protocol. 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