Commit df4c2090 authored by Mark Andrews's avatar Mark Andrews
Browse files

new draft

parent 365ca350
Internet Engineering Task Force Alain Durand
INTERNET-DRAFT SUN Microsystems
Feb 21, 2003
Expires Aug 2, 2003
Dynamic reverse DNS for IPv6
<draft-durand-dnsop-dynreverse-00.txt>
Status of this memo
This memo provides information to the Internet community. It does
not specify an Internet standard of any kind. This memo is in full
conformance with all provisions of Section 10 of RFC2026 [RFC2026].
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes a method to dynamically generate PTR records
and corresponding A or AAAA records when the reverse path DNS tree is
not populated.
A special domain dynrev.arpa. is reserved for that purpose.
1. Introduction
In IPv4, the reverse path tree of the DNS under in-addr.arpa.
although not perfectly maintained, is still mostly usable and its
existence is important for a number of applications that relies on
its existence and decent status. Some applications performs some
(very) weak security checks based on it. Mail relays relies on it for
some anti-spams checks an some FTP server will not let you in unless
your IP address resolve properly with a PTR record.
IPv6 addresses being much longer (and cumbersome) than IPv4
addresses, it is to fear that the reverse path tree under ip6.arpa.
would not be as well maintained. Also, tools like 6to4, Isatap and
others have made creative use of the 128 bits of an IPv6 address to
automatically embed an IPv4 address to enable seamless connection to
the IPv6 Internet. However, no provision has been made to make sure
the reverse path tree gets automatically updated as well for those
new IPv6 addresses. One step furter, RFC3041 describes a mechanism
to basically use random bits in the bottom part of an IPv6 address to
preserver anonymity. If those addresses are to resolve in the reverse
path tree, it obviously has to be with anonymous data as well.
Another point to note is that home customer ISPs in IPv4 have a
current practice to pre-populate the reverse path tree with names
automatically derived from the IP addresses. This practice is no
longer possible in IPv6, where IP address allocation is not dense as
it is the case in IPv4. The mere size of typical customer allocation
(2^48 according to the recommendation of RFC3177) makes it
impossible.
Applications that check the existence of PTR records usually follow
this by checking if the name pointed by the PTR resolve in a A (or
AAAA for IPv6) that match the original IP address. Thus the forward
path tree must also include the corresponding data.
One simple approach of this problem is to simply declare the usage of
the reverse path DNS as described above obsolete. The author believe
this is too strong an approach for now.
Similarly, a completely different approach would be to deprecate the
usage of DNS for the reverse tree altogether and replace it by
something inspired from ICMP name-info messages. The author believes
that this approached is an important departure from the current
practise and thus not very realistic. Also, there are some concerns
about the the security implications of this method as any node could
easily impersonate any name. This approach would fundamentally change
the underlying assumption of "I trust what has been put in the DNS by
the local administrators" to "I trust what has been configured on
each machine I query directly".
2. Dynamic record generation
If static pre-population of the tree is not possible anymore and data
still need to be returned to applications using getnameinfo(), the
alternative is dynamic record generation. This can be done is two
places: in the DNS servers responsible for the allocated space (/64
or /48) in the ip6.arpa. domain. or in the DNS resolvers (either the
sub resolver library or the recursive DNS server).
2.1. On the resolver side.
The resolver, either in the recursive DNS server or in the stub
library could theoretically generate this data.
In case DNSsec is in place, the recursive DNS server would have to
pretend these records are authentic.
If the synthesis is done in the stub-resolver library, no record
needs to be actually generated, only the right information needs to
be passed to getnameinfo() and getaddrinfo(). If the synthesis is
done in the recursive DNS server, no modification is required to
existing stub resolvers.
2.2. On the server side.
PTR records could be generated automatically by the server
responsible for the reverse path tree of an IPv6 prefix (a /64 or /48
prefixes or basically anything in between) when static data is not
available.
There could be impact on DNSsec as the zone or some parts of the zone
may need to be resigned each time a DNS query is made for an
unpopulated address. This can be seen as a DOS attack on a DNSsec
zone, so server side synthesis is not recommended if DNSsec is
deployed.
3. Synthesis
The algorithm is simple: Do the normal queries. If the query returns
No such domain, replace this answer by the synthetized one if
possible.
3.1. PTR synthesis
The synthetized PTR for a DNS string [X] is simply [X].dynrev.arpa.
where [X] is any valid DNS name.
The fact that the synthetized PTR points to the dynrev.arpa. domain
is an indication to the applications that this record has been
dynamically generated.
3.2. A synthesis
If [X] is in the form a.b.c.d.in-addr.arpa, one can synthetized an A
record for the string [X].dynrev.arpa. which value is d.c.b.a. with
a,b,c & d being integer [0..255]
3.3. AAAA synthesis
If [X] is in the form
a.b.c.d.e.f.g.h.i.j.k.l.m.n.o.p.q.s.t.u.v.w.x.y.z.A.B.C.D.E.F.in-
addr.arpa, one can synthetized a AAAA record for the string
[X].dynrev.arpa. which value is
FEDC:BAzy:xwvu:tsrq:ponm:lkji:hgfe:dcba with
a,b,c....x,y,z,A,B,C,D,E,F being hexadecimal digits.
3.4. Server side synthesis
If synthesis is done on the server side, PTR could be set not to use
the dynrev.arpa domain but the local domain name instead. It culd be
for instance dynrev.mydomain.com.
Note also that server side synthesis is not incompatible with
resolver side synthesis.
4. IANA considerations
The dynrev.arpa. domain is reserved for the purpose of this document.
5. Security considerations
Section 2. discusses the the interactions with DNSsec.
6. Authors addresses
Alain Durand
SUN Microsystems, Inc
17, Network Circle
UMPK17-202
Menlo Park, CA 94025
USA
Mail: Alain.Durand@sun.com
Internet Draft Johan Ihr‰n
draft-ietf-dnsop-interim-signed-root-01.txt Autonomica
February 2003
Expires in six months
An Interim Scheme for Signing the Public DNS Root
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo documents a proposed mechanism for a first stage of a
transition from an unsigned DNS root to a signed root, such that
the data in the root zone is accompanied by DNSSEC signatures to
allow validation.
The underlying reason for signing the root zone is to be able to
provide a more secure DNS hierarchy, where it is possible to
distinguish false answers from correct answers.
For the special case of the DNS root zone, an interim scheme is
proposed. This scheme is mostly aimed at securing the root zone
itself for technical and operational reasons, and to give
operational experience of DNSSEC.
1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
and "MAY" in this document are to be interpreted as described in
RFC 2119.
The term "zone" refers to the unit of administrative control in the
Domain Name System. "Name server" denotes a DNS name server that is
authoritative (i.e. knows all there is to know) for a DNS zone,
typically the root zone. A "resolver", finally, is a DNS "client",
i.e. an entity that sends DNS queries to authoritative nameservers
and interpret the results.
2. Motivation for signing the DNS root
In the special case of the root zone there are very strong reasons
to take a slow and conservative approach to any changes with
operational impact. Signing the root is such a change.
DNSSEC[RFC2535, RFC3090] has been in development for a number of
years now and still has not reached the point where the last flag
day is behind us.
However, during the years of DNSSEC development and refinement
[RFC2930, RFC3007, RFC3008, RFC3110, RFC3225, RFC3226, AD-secure,
Opt-in, Wild-card-optimize], the Internet has matured and more and
more businesses and other organizations have become dependent on
the stability and constant availability of the Internet.
It is therefore prudent to do everything in our power to ensure
that the DNS infrastructure works as well as possible and, when
appropriate and possible, adding enhancements and functionality.
The time is now right for yet another step of improvement by
signing the root zone. By doing that any Internet user that so
wishes will obtain the ability of verifying responses received from
the root nameservers.
Since this is new operational ground the objective is not maximum
security but rather an "Internet-wide" controlled experiment with a
signed root zone, where the trade off is that we utilize the fact
that there are operators in place that can help even though they
are not sufficiently staffed to do off-line signing in a 24x7
mode. For this reason it is fully possible to even do automatic
signing, since the purpose is to ensure that DNSSEC works
operationally with a signed root zone and gain experience from the
exercise.
It should be pointed out, however, that the experimental part is
only the added DNSSEC records. The traditional records in the root
zone remain unchanged and the new records will only be visible to
DNSSEC-aware resolvers that explicitly ask to see these new
records.
2.1. Motivation for signing the root zone now
The reason DNSSEC is not yet widely deployable is that the problem
of key management remains unsolved, especially where communication
between the zone administrators for a parent zone and child zone is
required.
However, during the past year a solution to this problem has been
found (in the form of a new record type, DS aka Delegation Signer)
[DS], discussed, implemented and tested. Therefore, it is finally
reasonable to consider DNSSEC deployment to be a real possibility
within the next 12 months.
In the case of the root zone the particular importance of managing
the transition with zero operational mistakes is a strong reason to
separate the signing of the zone itself, with the associated key
management issues, from the future management of signed delegations
(of top level domains).
Although support for Delegation Signer has been implemented and
tested it is not yet generally available except experimentally. For
this reason signed delegations for productions zones will have to
wait a bit longer. Furthermore, it will take some time to ensure
that the entire RSS aka Root Server System is capable of supporting
the protocol changes that accompany the new support for Delegation
Signer.
By signing now it will be possible to work through the operational
issues with signing the zone itself without at the same time having
to manage the additional complexity of signed delegations. Also, by
explicitly not supporting any signed delegations, it is also
possible to recover in a graceful way should new operational
problems turn up.
Because of these operational and technical issues there is a
"window of opportunity" to sign the root zone before the status of
implementation of "full DNSSEC", including Delegation Signer
support, change to "generally available", thereby increasing the
pressure for signed delegations from the root zone.
3. Trust in DNSSEC Keys
In the end the trust that a validating resolver will be able to put
in a key that it cannot validate within DNSSEC will have to be a
function of
* trust in the key issuer
* trust in the distribution method
* trust in extra, out-of-band verification
For any security apex, i.e. a node in the DNS hierarchy that issues
out-of-band "trusted keys", it is of critical importance that this
function produces a positive result (i.e. the resolver gains
sufficient confidence in the keys to decide to trust them). The
particular case of the root zone is no different, although possibly
it is more crucial than many other security apexes.
To ensure that the resulting trust is maximized it is necessary to
work with all the parameters that are available. In the case of the
key issuer there is the possibility of chosing a key issuer that
has a large "trust base" (i.e. is already trusted by a large
fraction of the resolver population). However, it is also possible
to expand the aggregated trust base by using multiple simultaneous
key issuers, as described in [Threshold-Validation].
Furthermore, with multiple trusted keys it will be possible for a
validating resolver to optimize for the "right compromise" between
* maximum security (as expressed by all available signatures by all
available keys verifying correctly
* maximum redundancy (as in the DNS lookup being validated if there
is any signature by any trusted key available)
Without multiple, independent trusted keys the rollover operation
will always be a dangerous operation where it is likely that some
fraction of the resolver population lose their ability to verify
lookups (and hence start to fail hard). I.e. the validating
resolver will be forced to adopt the "maximum security" policy,
since there is no alternative.
With multiple, independent trusted keys, however, it is possible to
design for improved redundancy by trusting lookups that are only
validated against a subset of the available keys. This will make
rollovers much less risky to the extent that it will be possible to
"survive" even emergency rollovers without any immediate
configuration chagnes in the validating resolver.
4. Interim signing of the root zone
At present all the authoritative servers for the root zone pull the
zone from a primary master. I.e. any changes at the primary master
will propagate via NOTIFY[RFC1996] and subsequent
AXFR/IXFR[RFC1995, AXFR-clarify] to the slave servers.
Between the primary master and the slaves transactions are signed
with TSIG[RFC2845] signatures. This mechanism is already in place,
and there is operational experience with periodic key rollover of
the TSIG keys.
4.1. Design philosophy
By introducing a signing step into the distribution of the zone
file complexity is increased. To avoid introducing new single
points of failure it is therefore important to ensure that any
added or changed steps are as redundant as possible.
The assumption is that the operators of the root servers are
trusted and that consistency of the zone among the root servers is
a crucial property that MUST be preserved in emergencies.
To ensure that consistency is maintained new single points of
failure SHOULD NOT be introduced by the signing step. Therefore a
structure where several parties have the ability to sign the zone
is proposed. Furthermore, such a design helps avoid any individual
party becoming a de facto single zone signing authority.
4.2. Proposed new management structure for the root zone
Taking into account the already existing infrastructure for
management of TSIG keys and rollover of these keys the following
structure is proposed:
* Day-to-day signing of the root zone is performed by a subgroup of
the root server operators referred to as "signing operators". For
this task individual, per-operator, Zone Signing Keys, ZSKs, are
used.
* The set of Zone Signing Keys are signed by several Key Signing
Keys, KSKs, at any particular time. The public part of KSKs in
use have to be statically configured as "trusted keys" in all
resolvers that want to be able to perform validation of
responses.
* Key rollover, the operation when an old KSK is exchanged for a
new KSK, is managed with minimal overlap and on a frequent basis
of no less than three times per year per KSK. The rollover
schedule is chosen to be frequent enough to not make long-term
trust possible while being low enough to not become operationally
infeasible.
4.2.1. Management and distribution of the zone file
The present, unsigned zone is published by the official slaves, the
"root nameservers", transferring the zone securely from a primary
master and subsequently using the data to respond to queries. This
mechanism is changed into:
* The unsigned root zone is transferred securely from the primary
master to a set of "signing primaries" managed by the operators
participating in signing the zone. This is done via the
traditional mechanisms NOTIFY + AXFR/IXFR + TSIG.
* The root nameservers change their configuration so that they
replace the present, single, primary master as the source of the
zone with a set of multiple possible "signing primaries" as
masters that provide the signed zone.
* When a new, unsigned zone, is published by the primary master it
will automatically be transferred to the pre-signing servers. The
responsible operator will then sign the new zone and publish it
from his signing primary. Since the serial number is higher than
what the official root nameservers presently have the official
root nameservers will all transfer the zone from this source
(because of the redundant configuration with multiple possible
masters for the signed zone).
* The operators that participate in signing rotate the signing
responsibility among themselves. Should the responsible operator
be unable to do this for any reason then any of the others are
able to do the signing instead. Traceability is maintained since
the zone signing keys are individual.
* To avoid having several "backup signing operators" possibly sign
at exactly the same time backups are allocated "time windows"
within which they are allowed to publish a signed zone.
With N signers, each signer is assigned a unique number R in
[1..N].
T = 2*k*((S-R) mod N)
T is time to wait in seconds, S current serial number. The length
of the window is k, thereby separating each signing window with
an interval where signing is not allowed.
The constant k is used to create sufficient separation of the
signers with respect to time used to sign and time needed to
distribute the zone. A reasonable value for k would be in the
order of 1800 seconds.
* Because the digital signatures in the signed root zone MUST NOT
expire it is necessary to ensure that the unsigned zone does
change sufficiently often to cause new signing to occur within
the validity period of the old signatures. This is most easily
accomplished by a dummy update that only increments the serial
number in the SOA record.
This new requirement will not cause any operational problems,
since in fact the root zone is maintained this way since several
years back.
4.2.2. Management of the Key Signing Keys
Key Signing Keys, KSKs, are periodically issued by a several "Key
Signing Key Holders", KSK holders, individually. These KSKs consist
of a private part that should always be kept secret and a public
part that should be published as widely as possible since it will
be used as a "trusted key" in resolver configurations.
The public part of each KSK should be included in the keyset for
"." as described in [Threshold-Validation]. I.e. the keyset will be
the union of the public parts of all KSKs and all ZSKs, Zone
Signing Keys.
* Each KSK holder should generate a sequence of KSKs where the
public parts will be used to include in the keyset for "." and
the private parts will be used for signing the keyset.
* Each KSK holder should, on request from the signing operators,
send in the public part of the KSK. The union of the public parts
of KSKs and the corresponding public parts of ZSKs, as collected
by the signing operators, constitute a "keyset".
* Each KSK holder should, on request from the signing operators,
sign the complete keyset with the private part of the associated
KSK and send in the resulting signature to the signing operators
for inclusion in the signed zone.
4.2.3. Management of the Zone Signing Keys and the keyset signatures
A subgroup of the root operators that choose to participate in
signing the zone each hold an individual "Zone Signing Key",
ZSK. The subgroup of operators may include all operators, but that
is not necessary as long as a sufficient number to achieve
redundancy in "signing ability" participates.
* The complete keyset (i.e. all the public parts of KSKs and ZSKs)
should be signed by each KSK holder individually, generating a
new signature for the keyset which is sent back to the signing
operators via an out-of-band mechanism.
* The signing operators should verify each received signature
against the corresponding key in the keyset and, unless invalid,
accept the signature into the set of signatures associated with
this keyset as described in [Threshold-Validation].
* The signing operators should include one of the keysets together
with all the KSK signatures in the zone file according to an
agreed upon rotation schedule.
4.2.4. Management of key rollover
The Key Signing Keys should, for this interim scheme, be relatively
short-lived and rolled over frequently. The direct intent is that
it should not be possible to put long term trust in the keys.
Therefore, by design, every resolver that chooses to configure
these as "trusted keys" (to be able to validate lookups) will have
to change the configuration periodically.
This is, after all, only an interim method of root zone signing.
* Key rollover is executed by changing from one signed keyset to
another. I.e. from a keyset signed by one set of KSKs to a keyset
signed by a partially different set of KSKs. By not rolling all
the KSKs at the same time redundancy is improved.
* Technically the signing operators are able to initiate key
rollover, although except for the case of a suspected key
compromise (with subsequent immediate key rollover) this ability
should only be used according to an established schedule.