On 8.4.2014 15:20, Edward Lewis wrote:
From the linked message:
Let me quote very first part of the message to put it into context:
People start to disagree when it comes to questions like "Is it feasible to
rely on a local validating resolver in the near future? How can applications
detect that a validating resolver is not configured and that DNS responses
can't be trusted?"
Aim of the proposal below is to enable applications to stay safe on systems
>>>>>>>> without a validating resolver.
In other words, we are looking for a way how to augment current APIs to move
DNSSEC-related knobs from applications to system-wide level (so you don't need
to tweak OpenSSH config and Postfix config separately, for instance).
1) DNS-Architecturally speaking, this statement is incorrect:
*Local validating resolver is strongly recommended.*
What is needed is:
*Local validator is strongly recommended.*
Well, this is better:
*Local validator is required.*
Or "local validation is required in order to assess the level of trust in what
is received”. If the goal is being able to trust what is received, you have to have
validation, it’s not just a good idea.
Sure, I think that nobody opposes that. The problem is more about "How can an
application detect that validating resolver is in place?"
Note that this proposal is about declaring that answer is untrusted, never the
other way around. Declaring answer as trusted is *always* done by validator.
2) /etc/sresolv.conf.
- System-wide configuration format (e.g. modify resolv.conf vs. add a new file)
In 1998 I used “/etc/sresolv.conf” in the first prototype validator. It had
configuration lines for trust anchors and all the rest of /etc/resolv.conf.
There’s no reason you can’t reuse the existing file or soft link (/etc/resolv.conf
-> ../var/run/resolv.conf)
3) As far as AD bit stripping….
The question to ask is whether you trust the stub resolver’s (set of) sources
or not. If you trust the sources for all things other than DANE, why not trust
them for DANE too? Conversely, if you don’t trust them for DANE, why trust the
sources for anything?
One can view DNSSEC as a standalone application. The “server” is the dnssec
signer, the “client” is the validator. Those two act like IPSEC tunnel
endpoints.
Sure. The question is "How can an application detect that the IPSEC tunnel is
in place?"
I hope this clarifies purpose of the proposal.
Have a nice day!
Petr Spacek @ Red Hat
> What goes in one comes out the other unmolested. The fact that “below” the
DNSSEC plane is plain old DNS is irrelevant. I could take the results of the
signer and FTP them to the validator, rsync them, etc. DNSSEC only allows the
validator to determine if what it got was produced by an authorized(-by-the
DNS-zone-administrator) signer, operated in an authorized manner.
It is (or was) possible to tweak the DNSSEC to have the signer be in the hands
of whomever is responsible for DANE but not the DNS. That would be by
attaching RRSIGs generated by keys that are identified as DANE-not-DNS. (This
is in the concept, don’t know if it is in the software anymore.)
On Apr 8, 2014, at 7:38, Petr Spacek <[email protected]> wrote:
On 4.4.2014 00:42, Paul Hoffman wrote:
On Apr 3, 2014, at 2:50 PM, Andrew Sullivan<[email protected]> wrote:
On Thu, Apr 03, 2014 at 05:39:58PM -0400, Suzanne Woolf wrote:
operated on Internet networks. This will include root zone
name servers, TLD name servers, name servers for other DNS
zones, iterative DNS resolvers, and recursive DNS resolvers.
Is there a reason to call out these particular functions, or not to
include something like, "or any other resolver or server functioning
as part of the global DNS"? I'm just worried, for instance, that
stubs don't appear there, even though there might be advice I can
imagine the WG providing.
+1 to at least calling out stub resolvers, but Andrew's non-list formulation is
better.
I agree that including stub-resolvers and other DNS-related software sounds
like a good idea.
There were long threads about DNSSEC handling in stub-resolvers on dane-list
[0] but dnsop seems like a better place to discuss this matter.
Note that this discussion is not over so we can move it to dnsop if dnsop
agrees.
[0] http://www.ietf.org/mail-archive/web/dane/current/msg06658.html
--
Petr Spacek @ Red Hat
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
