26 Kvě
2016
26 Kvě
'16
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.
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
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?
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 prefer giving the requester a complete information
about the glue.
Otherwise the query resolution logic gets complicated both on the
authoritative and resolver part.
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.
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.