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

Phillip Hallam-Baker hallam at gmail.com
Wed Jan 30 19:08:38 MST 2013

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.

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

More information about the getdns-api mailing list