26 Kvě
2016
26 Kvě
'16
14:29
Hello.
Agreed. We didn't do it in Knot < 2.2.1. We do it now.
- 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.
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.
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.
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.
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.)
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).
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