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

Paul Wouters <[email protected]> wrote:

> On Sat, 19 Oct 2013, Tony Finch wrote:
>
> > 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.

If they care about latency they should send all the necessary queries at
once, as in the example I posted. It seems to me that edns-chain-query is
just a more concise way to express this basic strategy. A client that is
adapted to use edns-chain-query can equally well be adapted to make
equivalent concurrent queries.

That is, whenever you would like to send an edns-chain-query, you can get
roughly the same latency if you send the basic query and at the same time
send queries for DS and DNSKEY for every domain name from your QNAME to
its topmost uncached parent domain.

So I think the draft should be more clear about the benefits of this
protocol change, relative to the backwards-compatible concurrent query
strategy. I say "roughly" above since the option might allow you to save
the second round trip for validating out-of-zone CNAME targets.

> > 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.

If the client is querying for www.example.com and it knows com, and it
knows it doesn't know example.com, it should put example.com in the
option. It doesn't matter if that is a zone cut or not.

> > 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?

But as currently written, the client will not get the . DNSKEY RRset,
because the option says it knows the root. If it only has a trust anchor,
not the complete . DNSKEY RRset, it won't be able to validate the TLD DS
record. It will have to make a separate query for the . DNSKEY RRset.

If you change it to be the last unknown domain name, then this problem
goes away.

> > 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.

Oh, that makes sense. It would be helpful to have that rationale in the
NS record considerations section of the draft.


And now to additional validation chains outside the client's last known
name...

> 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".

Sounds like a self-ddos option to me :-)

> > 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.

Note that (when comparing with clients that don't use this option and just
send all the necessary queries at once) this second RTT for CNAME
validation is the one that the option can eliminate.

> > 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.

Cool.

I still have a nagging question if there is a better way to eliminate
more of these follow-up queries.

Tony.
-- 
f.anthony.n.finch  <[email protected]>  http://dotat.at/
Forties, Cromarty: East, veering southeast, 4 or 5, occasionally 6 at first.
Rough, becoming slight or moderate. Showers, rain at first. Moderate or good,
occasionally poor at first.
_______________________________________________
dnsext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsext