[getdns-api] EDNS options are for server to server communications

[Willem Toorop]

op 14-02-14 15:40, Andrew Sullivan schreef:
> On Fri, Feb 14, 2014 at 10:38:27AM +0100, Willem Toorop wrote:
>> Well, the library is either in stub mode (for which setting specific
>> EDNS0 options makes perfect sense, because we're talking to a peer) or
>> in recursive mode.
> 
> But in "recursive mode", you're quite right that the communication
> between the nameserver side and the resolver side maybe doesn't need
> the EDNS0 options (are you sure?  What about DNSSEC options?).

About the DNSSEC option (DO bit):
The specification states that DNSSEC is performed when one or more of
the DNSSEC-related extensions is set.  The library, in recursive mode,
does then whatever necessary to perform DNSSEC, like requesting the
DSses and DNSKEYs around the zone-cuts and also setting the DO bit in
transactions with the authoritatives to indicate it wants the RRSIGs  as
well and an authenticated "proof" if a name doesn't exist.
And cache it!

Setting the DO bit is integral part of doing the DNSSEC.  And sometimes
the recursive doesn't need to set it at all, because an answer (or
information needed to validate the answer) is cached.

> But
> the resolver side is then going to send more queries.  You'll need a
> (possibly disjoint) set of EDNS0 options there, too, no?

Yes, but the recursive's intelligence is needed to decide what to send
to who.  The extensions in the spec just set different aspects of the
OPT RR.  So they can have value in stub (peer-to-peer) mode, but don't
fit in the recursive modus operandi.

-- Willem