1 - 2 - 8 - A - B - C - D - E - F - G - H - I - K - L - M - N - O - P - Q - R - S - T - U - V - W - Z
signature
Click on the red underlined text to get to the source
...
Section 4 discusses the SIG digital signature resource record, its
structure, use in DNS responses ...
... resource records in
the DNS cryptographically generated digital signatures. Commonly,
there will be a single private key that signs for an entire zone. If
...
... public key of one zone that it can
use to authenticate signatures. From there, it can securely read the
public keys of other zones, if the intervening zones in the DNS tree ...
... integrity requires no change to
the "on-the-wire" DNS protocol beyond the addition of the signature
resource type and, as a practical matter, the key resource type
needed for key distribution ...
...
If signatures are always separately retrieved and verified when
retrieving the information they authenticate, there will be more
...
... security aware servers mitigate that degradation by always attempting
to send the signature(s) needed.
...
... The syntax of a SIG resource record (signature) is described in
Section 4. It includes the type of the RR(s) being signed, the name
...
... RR(s) being signed, the name
of the signer, the time at which the signature was created, the time
it expires (when it is no longer to be believed), its original time
to live ...
... be shorter), the cryptographic algorithm in use, and the actual
signature.
...
...
A digital signature will fail to verify if any change has occurred to
the data between the time it was originally signed and the time the
signature ...
... digital signature will fail to verify if any change has occurred to
the data between the time it was originally signed and the time the
signature is verified. This conflicts with our desire to have the
time-to-live field tick down when resource records ...
...
This could be avoided by leaving the time-to-live out of the digital
signature, but that would allow unscrupulous servers to set
arbitrarily long time to live values undetected. Instead, we include
...
... time to live values undetected. Instead, we include
the "original" time-to-live in the signature and communicate that
data in addition to the current time-to-live. Unscrupulous servers
...
... aware resolver will bound the TTL value it uses at the original
signed value. Separately, signatures include a time signed and an
expiration time. A resolver that knows the absolute time can
determine securely whether a signature ...
... signatures include a time signed and an
expiration time. A resolver that knows the absolute time can
determine securely whether a signature has expired. It is not
possible to rely solely on the signature expiration as a substitute
...
... determine securely whether a signature has expired. It is not
possible to rely solely on the signature expiration as a substitute
for the TTL, however, since the TTL ...
... server. In particular, an initial retrieval for the CNAME or any
other type will not retrieve any associated signature, key, or NXT
RR. For types other than CNAME, it will retrieve that type at the
...
... separated substrings, down to single base 64 digits, which are
concatenated to obtain the full signature. These substrings can span
lines using the standard parenthesis.
...
... TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| signature expiration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| time signed |
...
... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| /
+- signature /
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...
...
The algorithm number is an octet specifying the digital signature
algorithm used parallel to the algorithm ...
... private use and will not be assigned a specific algorithm. For
number 254, the "signature" area shown above will actually begin with
a length byte followed by an Object Identifier (OID ...
... known as the "expiration date algorithm", is used when the expiration
date or other non-signature fields of the SIG are desired without any
actual security ...
... DNS dynamic update. For number
253, the signature field will be null. Values 0 and 255 are
reserved.
...
... retrieval is the result of wild card substitution, it is necessary
for the resolver to use the original form of the name in verifying
the digital signature. This field helps optimize the determination
of the original form thus reducing the effort in authenticating
signed data ...
... be expanded to 255 labels. The following table gives some examples.
The value of "labels" is at the top, the retrieved owner name on the
left, and the table entry is the name to use in signature
verification except that "bad" means the RR is corrupt.
...
... real TTL field. This original TTL is protected by the signature
while the current TTL field is not.
...
... TTL" must be restored into the covered RRs when
the signature is verified. This implies that all RRs for a
particular type, name, and class ...
... The SIG is valid until the "signature expiration" time which is an
unsigned number of seconds since the start of 1 January 1970, GMT ...
... as a quick check that a public key about to be used for the
computationally expensive effort to check the signature is possibly
valid. Its exact meaning is algorithm ...
... RSA
algorithm, it is the next to the bottom two octets of the public key
modulus needed to decode the signature field. That is to say, the
most significant 16 of the lest significant 24 bits of the modulus in
...
... public KEY RR that can be used
to verify the signature. It is frequently the zone which contained
the RR(s) being authenticated ...
...
The structure of the "signature" field is described below.
...
... Signature Data ...
... Except for algorithm number 253 where it is null, the actual
signature portion of the SIG RR binds the other RDATA ...
... RR in canonical form and order. How this data sequence is
processed into the signature is algorithm dependent.
...
...
A public exponent of 3 minimizes the effort needed to decode a
signature. Use of 3 as the public exponent may be weak for
confidentiality uses since, if the same data can be collected
...
... RRs for subzones) are unnecessary and MUST NOT be sent. (Note
that KEYs for subzones are controlling in a superzone so the
superzone's signature on the KEY MUST be included (unless the KEY
was additional information and the SIG did not fit).)
...
... information section and has a type covered of zero, it is a
transaction signature of the response and the query that produced the
response. It MAY be optionally checked and the message rejected if
...
... RR to be
authenticated after its signatures have expired. Within that
constraint, servers should continue to follow DNS TTL ...
... TTL should be trimmed so
that current time plus the TTL does not extend beyond the signature
expiration time. Thus, in general, the TTL on an transmitted RR ...
...
However, the signature itself can be very long. It is the last data
field and is represented in base 64 (see Appendix) and may be divided
up into any number of white space separated substrings ...
... substrings, down to
single base 64 digits, which are concatenated to obtain the full
signature. These substrings can be split between lines using the
standard parenthesis.
...
... NXT 1 3 ( ;type-cov=NXT, alg=1, labels=3
19960102030405 ;signature expiration
19951211100908 ;time signed
21435 ;key footprint
...
... signer
MxFcby9k/yvedMfQgKzhH5er0Mu/vILz45IkskceFGgiWCn/GxHhai6VAuHAoNUz4YoU
1tVfSCSqQYn6//11U6Nld80jEeC8aTrO+KKmCaY= ;signature (640 bits)
)
...
...
The proper validation of signatures requires a reasonably secure
shared opinion of the absolute time between resolvers and servers as
described in Section 6.4.
...
...
Signature expiration times must be set far enough in the future that
it is quite certain that new signatures can be generated before the
...
... Signature expiration times must be set far enough in the future that
it is quite certain that new signatures can be generated before the
old ones expire. However, setting expiration too far into the future
could, if bad data ...
... old ones expire. However, setting expiration too far into the future
could, if bad data or signatures were ever generated, mean a long
time to flush such badness.
...
... root, such as .aq, .edu, or .arpa.
Implementations MAY reject as bogus any purported root signature of
records with a name more than one level below root. The root ...