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

Tony Finch dot at dotat.at
Wed Jan 30 11:16:26 MST 2013

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.

The question is, does this API need to include support for iterative

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

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

No, it never will.

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

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.

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.

More information about the getdns-api mailing list