(Apologies for neither top- nor bottom- posting, i.e. not quoting any other
emails.)

There are corner cases which exist, where desired behavior of some
resolvers is not possible to achieve.

This mostly has to do with constraints where "local policy" may have more
than one scope.

I.e. Inside a big enough org, there may be a "large" local policy which
conflicts with local policy of  smaller sub-orgs.

Here's an example:
- Suppose an enterprise E has perimeter resolvers, which do not validate
DNSSEC.
- Suppose that E blocks DNS traffic to the outside world, except from those
perimeter resolvers.
- Now suppose a small org within E, call it E-prime, deploys DNSSEC using
its own local trust anchor.

The issue has to do with not only which trust anchor is preferred for any
given portion of the DNS tree, but also whether the policy of "validation"
applies, and with what scope.

There may be other corner cases, but the main point is that the above
scenario does not depend on any notion of "split DNS" per se. The E-prime
element is, for sake of argument, still globally resolvable, but happens to
be an "island of security". There is no split DNS.

I think the question may boil down to the following:
- What local policies might operators need to configure?
- What advice to implementers can be provided, given the possible
complexities of what operators need?
- Does it make sense to formalize (or at least categorize) policy logic?
- What defaults are likely to maximize "correct" behavior, and/or minimize
failures?
- E.g. suppose the presence of trust anchors in non-5011 configuration
files, vs trust anchors in 5011 configuration files, and suppose multiple
trust anchors. Is the mere existence of a trust anchor sufficient to signal
intent, or is it always the case that some policy needs to be declared over
the combination of all existing trust anchors?

Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to