Re: Fwd: New Version Notification for draft-wouters-edns-tcp-chain-query-01.txt (fwd)

On Sat, 19 Oct 2013, Tony Finch wrote:

> This feature could be hugely beneficial

Great, I think so too :)

> The first paragraph of section 3 is saying that in practice, validating
> resolvers (BIND, Unbound) are not currently optimized to minimize latency.
> This ought to be fixed, but it does not imply that you have to suffer many
> RTTs without edns-tcp-chain-query.

There is not much they can do to fix it if I'm using a phone over 3g
with a validator on the phone.

> Editorial suggestions: I think section 1 and section 3 are doing basically
> the same job and should be merged into one section. The term "Resolving
> Nameserver" is peculiar and isn't defined in the terminology section.

Thanks will look into that.

> In principle you can send all the queries and get all the responses needed
> for validation in one RTT, or two if the answer contains a CNAME chain,
> because you need the validation chain for the CNAME targets and you don't
> know the targets until you get the response. So I think the key benefit of
> edns-tcp-chain-query is not so much latency, but reducing the amount of
> data sent and received to get a validation chain.

I figure when it comes to bytes send/received, if DNS is your issue you
have bigger problems with what's asking the DNS questions. It's nice to
reduce the size if we can, but I don't think there is much impact with
reduced size?

> That's about half a second of data at GPRS speeds.

Well, I guess it you meassure at GPRS speeds.... :)

> Section 5.2 generating a query:
>
> I think the Last Known Query Name needs to be the First Unknown Query
> Name.

I was avoiding that because the client does not know what it doesn't
know. There might not be zone cuts on every dot. Which is why I opted
for it to convey that it did know.

> In the empty cache case, the client only has a root trust anchor so
> it needs the root DNSKEY RRset. So when it sends . in the edns-chain-query
> option it wants to get everything up to and including the root.

Yes. Was this not clear in the draft?

> Section 5.3 generating a response:
>
> Why include the NS RRsets? The client is making forwarding queries to an
> upstream recursive server, so it doesn't need to know the names or
> addreses of the authoritative servers. Those are only useful for direct
> iterative resolving.

Because roaming devices run the risk of changing to a network where they
have to operate without forwarder. In which case it would be really nice
to already have those NS records validated and ready. It seemed like an
optimization that might cause more problems than it solves.

> I think more needs to be said about additional section processing. It
> seems sensible to me to do additional section processing only for direct
> answers to the client's query, not for the validation chain (i.e. omit the
> NS RRsets and their targets). For instance if the client asks for the MX,
> include the MX target RRs in the additional section.

I guess that depends on how the resolver is configured. unbound seems to
be minimal responses, while my old named seems to add it A records to
the additional section. So I think that would be out of scope for this
draft, but perhaps a mention that it would be recommended not to
configure resolvers with minimum responses (unlike authoritative
servers?)

> What about the MX target validation chain(s)? If I query for example.ac.uk
> and they have outsourced mail to example.net, I can put ac.uk in
> edns-chain option, but I don't know in advance that the response will have
> anything to say about example.net, and I can't tell the server that I
> already have example.net in my cache. (There's a similar problem for CNAME
> responses.)

I don't think there is a principle reason why not to add those to the
additional section. In fact, I had thought about a special query that
would signal to the upstream resolver "give me your 1% hot cache
entries with a TTL of more then 5 minutes".

> So the server has a dilemma: include everything to ensure that the client
> doesn't have to make any more queries, which is a waste of bandwidth if
> the client's cache is populated, or make the client suffer another round
> trip to deal with the targets if the cache isn't populated?

right. so we can either make an option, or not optimize here.

I'd say that MX is not that important because it is not very interactive
(but a background process) and that CNAME/DNAME could be avoided if
people cared about the extra 1 RTT for the followup (TCP keepalive) query.

> Perhaps it would make sense to send the validation chain for CNAME targets
> and additional records only if the client's edns-chain domain is a parent
> of the target. The server can then be sure it only sends records the
> client does not have. If the targets are not under the client's edns-chain
> domain, then the client might have to send a follow-up query.

I think that's what Jelte was hinting at too. I think I'll try to write
this up for the next version. It covers a quite common case, and without
the risk of needing to include a whole new hierarchy of which we don't
know if the client knows it or not.

> Section 6.5 anycast considerations:
>
> Again I think this is too pessimistic about the anycast and TCP.

I can tone it down a bit and just state implementors should be careful.

> Section 4 option format:
>
> Why use the term FQDN? This is a domain name in wire format, right? (which
> will compress nicely since it is a parent of the QNAME)

You are right, will fix in next draft.

thanks for the feedback!

Paul
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext