On Wed, 19 Sep 2018, Paul Vixie wrote:
Tony Finch wrote:
Anthony Eden<[email protected]> wrote:
FWIW, there's still always
https://datatracker.ietf.org/doc/draft-dnsop-eden-alias-rr-type/
I get the impression that a lot of the objection to the current ANAME
draft is that it specifies that auth servers do ANAME target lookups and
record substitution; your draft says the same thing. I think those
objections are reasonable, but I don't think the problem lookups are
particularly important (or even helpful).
+1.
4. Security Considerations
To function properly with DNSSEC-aware resolvers, authoritative name
servers MUST sign the materialized records produced by the ALIAS
resolution.
Implementors MAY either materialize A and AAAA records offline and
sign the resulting records at that time, or sign the resulting
materialized records at request time.
This is not a proper Security Consideration section. Please see
https://tools.ietf.org/html/rfc3552
What is described here is a fundamental flaw in this proposal.
That fact is even more clear by the MAY in that section, which basically
says "you can address this security issue or not, whatever"
A mechanism could be designed that is more generally usable.
Forcing a authoritative servers to do DNS lookups is asking for trouble.
Some deployments combine auth+recursive and such a server now needs a
working resolv.conf, and one that cannot point to itself. Clearly this
is going to break stuff. We have known for decades that combining
authoritative plus recursive was a bad idea, yet here it is again
glueing these two parts together so the auth server needs resolving
code. The place to do anything is on the resolver, the authoritative
server should just serve blobs.
Synthesizing (here called "materialising" ?) records is awful. It does
not work with offline DNSSEC signers, and if we want to solve this
properly, we can do so easilly with a solution that does not have
this limitation.
The design goals of a solution in this space should be:
- Fully supports DNSSEC
- Does not require AUTH server changes other then supporting a new
RRTYPE presentation / wire format and/or serving a new RRTYPE as
Additional Data.
- All optimization work is done on the resolver. If this includes
'rewriting' A/AAAA records, DNSSEC proofs MUST be included for
stub clients doing validation.
for example, why not serve an ALIAS record as additional data to A/AAAA
queries? Then resolvers that dont support this are as bad of as now.
Resolvers supporting this, will pick up the ALIAS, resolve it, put those
A/AAAA records in cache, and serve any clients asking for these A/AAAA
with the A/AAAA, ALIAS and target A/AAAA records.
Paul
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
