Warren wrote:
> how do they know they
> can trust the zone file before loading it?
And Joe Abley commented about non-apex NS records and glue, not being part
of the current DNSSEC design/goals/requirements.
I'll start my questions/proposal(s) with a scope question:
- Is it a safe assumption, that we're all talking about loading a zone
that is used by an authority server instance, that only gets queried by a
validating resolver?
- I.e. The loaded zone data never gets used directly, even if both
the resolver and authority server are local on a single machine?
- I.e. The loaded data goes through DNSSEC validation if it is
signed, by the resolver, even if the authority server doesn't validate it
first?
- Thus, if everything in the zone were signed, the worst that would
happen is that for a given record in the zone, if it were tampered with,
the resolver would treat the validation failure as SERVFAIL, and try
another server for the zone. Is that sufficient protection,
without having
to add further whole-zone signature(s)?
- If that assumption is correct, there some follow-on questions:
- Hypothetically speaking, if everything in the zone was signed (or
somehow did not require a signature to validate), would that solve the
underlying problem?
- Practically speaking, what would the consequences be, of having a
zone operator produce RRSIGs for non-apex, non-authoritative, NS sets
(parent side of zone cuts)?
- Is it ever the case that a DNS response (qr=1) can ever contain
both the parent-side and child-side NS RRs for a given owner
name, e.g. if
the server is authoritative for both, in response to any
particular kind of
query?
- If the answer is "No", is the "aa" bit and/or location of the
NS record(s) in the response, sufficient to disambiguate
whether the NS RRs
are parental or child?
- On the parent side, if the response included an RRSIG over
the NS RRset, how would that be handled by a (validating) resolver?
- Is this specified in any RFCs?
- The answer may differ by implementation; has anyone
experimented with this?
- My hypothesis is that the RRSIG will either be validated,
or ignored, but unless the RRSIG fails validation,
should not adversely
affect the acceptance/use of the NS RRset for its
original purpose, and
should not cause it to be mistreated as if it were the
authoritative
(child) NS RRset
- To be clear, I'm suggesting only the (opportunistic)
addition of such RRSIGs, not changing the requirements
to do so, or the
exclusion of NS entries in NSEC/NSEC3 records even if
the NS RRSIG exists,
or anything else about the DNSSEC core standards
- Since the NS records on the parent side of a zone cut are
non-authoritative:
- It might be interpreted that modifying the NS records is benign,
so long as:
- The NS name->A and NS name->AAAA relationship(s) are preserved
- Any substitution done on NS names is consistent and
universal (for
scaling reasons)
- I.e. if "owner1 NS ns-serverJ" and "owner2 NS ns-serverJ"
originally existed:
- Changing "owner1 NS substitute-serverX" is done only if
"ownerN NS substitute-serverX" is done for all such
N, with the same (J ,X)
pairs used
- The A and/or AAAA record RDATA for ns-nameserverJ and
substitute-serverX are identical
- These kinds of substitutions could, hypothetically, be
done by the zone operator, rather than e.g. individual
registrants, on a
systematic basis
- It would remove the need for the updates to glue A/AAAA
records in zones, entirely, which I believe is a
separate problematic area
for the root zone and TLDs
- It would also eliminate the glue-induced "phantom
name/domain" problem, where a name used as an NS name,
can persist beyond
the NS name's registration expiring (indefinitely)
- If the substitute names were in-zone, then they would be
eligible (in fact, required) to be signed, if the zone were DNSSEC
- Any substitution scheme that converts NS names into "in-zone"
names would have this benefit, obviously
- See below for another very specific idea/suggestion for what
to substitute, that scales better than lots of additional
signed glue
records for such replacement NS names
- Adding an RRSIG on the original NS RRset (on the parental side)
or on a modified NS RRset, would have the same effect (since
the assumption
above is NS name -> A/AAAA resolution returns the same results with or
without the substitution)
The *additional* idea, is to have the ability to use "special" (reserved)
names with new, special meaning, plus backward-compatible A/AAAA RRs, and
when in-zone, backward-compatible RRSIGs.
The purpose of the names, is to be able to use them in NS RRsets so as to
eliminate the need for glue usage by resolvers, by making the names used be
(special, reserved) transliterations of IPv4 or IPv6 addresses.
When combined with RRSIGs on non-authoritative NS RRsets, this would close
the current hole, I believe. I'm not sure if there would be other
particular benefits, but it is possible there may be some.
The use of a new special prefix is necessary to avoid colliding with
registered or reserved names in any zone. I believe it's the case that
there is a prohibition of using any owner name that starts with
"<char><char>--" (dash in third and fourth position of the name), for
anything other than already-standardized prefixes such as the IDNA ACE
prefix, "XN--".
Regardless of the new prefix value, PRFX, the encoding I'm suggesting would
be:
- {PRFX}{8 hex digits} for IPv4-encoding
- (yes, I know, no dotted-quad, but this isn't meant for human use at
all, or at least not without updates to software doing queries manually)
- {PRFX}{32 hex digits} for IPv6 addresses, which are the fully expanded
addresses with no :, ::, and all leading zeros included, i.e. fixed-size
IPv6 addresses without any colons.
- Suggestion for {PRFX}: "IP--" (for its obvious meaning)
- This would work for any addressing scheme <= 59 hex digits.
- I'm not aware of any addressing scheme bigger than that
currently... certainly not MAC-48 or MAC-64, and I don't think even NSAP.
There is one benefit to this name/address mapping, in that it is a fixed
mapping. Even if RRSIGs are generated for them, and if they are added to
the zone explicitly, the RDATA for any given such label is deterministic
and never changes. E.g. for NSEC, the whole range of NSEC records would be
static, except the last one, if they were added to a zone. Also e.g. those
could be stuffed into a child zone on the same set of servers, with
arbitrarily long signature validity periods, to avoid re-signing....
ever....
If a resolver sees an NS RR RDATA of {PRFX}{encoding of A.B.C.D}, it can
safely assume that the name server's IP address is A.B.C.D, with no further
action (or parsing of the ADDITIONAL section or RRSIG validation beyond the
original NS RRSIG).
Upgraded resolvers would be able to either validate or ignore supplied glue
record RDATA and/or RRSIG data, since the NS RDATA name->IP{v4|v6} would be
entirely deterministic.
As long as the NS records are signed, there would not be any need to sign
the {PRFX}{ipv4|ipv6} records, as their contents could be deterministically
(and securely) synthesized without needing to refer to any DNS data.
Since using these in substituted non-authoritative NS RRsets largely
depends on being able to sign the former, that use case depends on the
questions at the beginning of this email.
Thoughts on these ideas?
Is there value in this, either generally, or for the root zone?
Brian
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
