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

[Phillip Hallam-Baker]

On Wed, Jan 30, 2013 at 1:16 PM, Tony Finch <dot at dotat.at> wrote:

> Phillip Hallam-Baker <hallam at gmail.com> wrote:
>
> > 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.
>
> You are mixing up separate issues:
>
> (1) Does a validator need to talk to the authoritative servers? No, by
> design. See the big list of classes of DNS software in RFC 4033.
>
> (2) Does a validator need to walk the chain of trust? Yes.
>
> Also we are not using the terminology quite correctly. A recursive server
> (RA=1) is a server that handles recursive queries (RD=1) from (usually
> stub) resolvers. Recursive servers perform iterative resolution: they
> follow referrals from one authority to another. Stub resolvers make
> recursive queries: they expect the server to handle the resolution for
> them. See RFC 1034 section 2.3 point 6.
>
> A validator needs to make a load of extra queries to get the chain of
> trust but they can be recursive (stub) queries that are oblivious of
> NS records.
>

I don't see how not handling NS records is going to simplify the code of
the stub. Yeah you could leave that to the DNS Proxy (in network terms, its
a proxy, calling it a recursive server only confuses). But you still have
to check the work and it really does not buy you much.




> The question is, does this API need to include support for iterative
> resolution.
>
> > Not being recursive capable is likely to result in flakyness.
>
> Yes, as we have learned from dnssec-trigger. The main problem is dealing
> with security-oblivious recursors that fail to fetch and/or pass on DNSSEC
> RRs and that don't know where to find DS records.


It was the finding of such data that made me think that the recursive
capability was going to be essential.



> > Given the relative complexity of DNS recursive resolution vs DNSSEC, I
> > can't see why recursive resolution would be an issue.
>
> Firewalls.
>
> > If I can't even do the recursive resolution locally then I should
> > probably forget about DNSSEC locally.
>
> If dnssec-trigger is faced with a security-oblivious resolver and a
> firewall that blocks DNS, then it can fall back to DNS-over-TLS to a
> known recursive server.


I would rather the API supported a (configurable) range of guerilla tactics.

Why would the fallback server need to be recursive here? Unless it was
going to return the whole DNSSEC chain.


Tony.
> --
> f.anthony.n.finch  <dot at dotat.at>  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.
>



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