[getdns-api] Stub vs. recursive, DNSSEC, and design goals for this API

[Phillip Hallam-Baker]

Actually recursive is an essential DNSSEC requirement without any
qualifications. You can't do DNSSEC unless you have full recursion.

Unless you query the root zone you have no way to know if .com has DNSSEC
deployed and without querying .com you can't tell if google.com has DNSSEC
deployed.

If you don't know if the zone should be signed, you have no way to know
that the signatures in the zone are invalid.


On Wed, Jan 30, 2013 at 12:35 PM, Phillip Hallam-Baker <hallam at gmail.com>wrote:

>
>
> On Wed, Jan 30, 2013 at 12:07 PM, Tony Finch <dot at dotat.at> wrote:
>
>> Paul Hoffman <paul.hoffman at vpnc.org> wrote:
>> >
>> > The big hangup here is that if an application that wants DNSSEC is
>> > reliant on a stub resolver, it is simply hosed. A stub resolver that is
>> > DNSSEC-aware can send queries to an upstream recursive, but those
>> > queries have to be integrity protected and message authentication.
>> > Currently, the only methods to do that that are in use (and even then,
>> > very thin use) are SIG(0) and TSIG, both of which require out-of-band
>> > agreement between the stub and the recursive.
>>
>> SIG(0) and TSIG are useful when the client and server have some kind
>> of trust relationship. But the client doesn't need to trust its recursor
>> very much if it is doing its own DNSSEC validation.
>>
>> > - The API definition requires an implementation to be able to be a
>> > recursive resolver in addition to the existing requirement that it be
>> > DNSSEC-validating
>>
>> I don't believe it is necessary for a validator to be a recursor: a stub
>> can validate replies from a minimally-trusted recursor (received via a
>> minimally-trusted network) provided the recursor is at least
>> security-aware.
>>
>> It probably is necessary for a validator to have a cache.
>>
>
> Not being recursive capable is likely to result in flakyness.
>
> As with all things DNSSEC, you don't get any more security from checking
> signatures. You only get more security from taking a different course of
> action when a signature validation fails.
>
>
> If the authoritative server for domain X.com is doing its job right it
> *may* return all the records that a stub client needs for it to check the
> DNSSEC path on its own.
>
> If not, the stub client is going to have to go looking for the data. And
> once it does that it is looking more like a recursive resolver than a stub.
>
>
> Given the relative complexity of DNS recursive resolution vs DNSSEC, I
> can't see why recursive resolution would be an issue.
>
> If I can't even do the recursive resolution locally then I should probably
> forget about DNSSEC locally.
>
>
> --
> Website: http://hallambaker.com/
>



-- 
Website: http://hallambaker.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.vpnc.org/pipermail/getdns-api/attachments/20130130/735f001a/attachment.html>