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

On Tue, 22 Oct 2013, Tony Finch wrote:

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

But you mostly cannot know. There is not much quering all possible zone
cuts of a.b.c.d.e.fg.h.i.j.k.l.com if the nameserver of l.com is
ns1.nohats.ca.

Now if l.com's NS records are ns1.nohats.ca, than sure we could add the
relatively small stuff for .ca and nohats.ca. to the additional section
as well. The question is where do you draw the line? I think latency is
a little more important than saving a few bytes, so I'd rather get some
redundant data. Can we leave that decision as a local policy, analogue
to a 'minimal responses' switch ?

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

But when you are hammering all imaginary zone cuts, and you really
needed .ca, that seems overly aggressive to me. The client does not have
a good idea what to ask. The server does have a good idea of what it
should return. Therefor I think the client should simply ask what it
wants to know, and the server should think about sending additional
data to satisfy the original question.

> 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'll try and write something up. But I hope the above explanation makes
sense to you?

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

What if it does know example.com, just not www.example.com. It puts in
www.example.com? And what is "knowing" with regard to RRtype? It might
not "know" something because it does not exist. I prefer chaining the
question to something we know exists.

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

I see. That's true. Let me think on this a bit more. I'm not sure if
this one corner case is important enough to matter. Let's see what
others have to say about this?

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

Will do.

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

We should probably take a look at some common resolves (on phones) and
see what dns data we currently have. google for instance has straight A
records for gmail.com but CNAMEs for mail.google.com.

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