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
SIG
Click on the red underlined text to get to the source
... The SIG Resource Record ...
...
Every name in a secured zone will have associated with it at least
one SIG resource record for each resource type under that name except
for glue RRs ...
... RRs retrieved, the
corresponding SIGs. If a server does not support the protocol, the
resolver must retrieve all the SIG records for a name and select the
one or ones that sign the resource record(s) that resolver is
...
... CNAME as additional information. In particular, a specific retrieval
for type SIG will not get the SIG, if any, at the original CNAME
...
... CNAME as additional information. In particular, a specific retrieval
for type SIG will not get the SIG, if any, at the original CNAME
domain name ...
... these types as well as on retrieval of the type CNAME, and (3)
automatically return SIG RRs authenticating the CNAME or CNAMEs ...
...
There are two cases where a SIG resource record is signed by other
than the zone private key ...
... query it sent, and that these messages have not
been diddled in transit. This is accomplished by optionally adding a
special SIG resource record at the end of the reply which digitally
signs the concatenation ...
...
Requests can also be authenticated by including a special SIG RR at
the end of the request. Authenticating requests serves no function
...
... bit is off for a zone key, the zone should be assumed
secured by SIG RRs and any responses indicating the zone is not
secured should be considered bogus. If this bit ...
... RR, is only effective if the KEY RR is
appropriately signed by a SIG RR. The experimental bit ...
... This octet is the key algorithm parallel to the same field for the
SIG resource. The MD5/RSA algorithm described in this document is
...
... An explicit request for KEY RRs does not cause any special additional
information processing except, of course, for the corresponding SIG
RR from a security ...
... The SIG Resource Record ...
... SIG RDATA Format ...
... algorithm", is used when the expiration
date or other non-signature fields of the SIG are desired without any
actual security. It is anticipated that this algorithm ...
...
The "labels" octet is an unsigned count of how many labels there are
in the original SIG RR owner name not counting the null label for
root ...
... substitution. If the RR owner name appears to be shorter than the
labels count, the SIG RR must be considered corrupt and ignored. The
maximum number of labels allowed in the current DNS ...
... start of 1 January 1970, GMT,
ignoring leap seconds. (See also Section 4.4.) SIG RRs should not
have a date signed significantly in the future. To prevent
...
...
A SIG RR with an expiration date before the time signed must be
considered corrupt and ignored.
...
... algorithm number 253 where it is null, the actual
signature portion of the SIG RR binds the other RDATA fields to all
...
... concatenation, RDATA is all the RDATA fields in the SIG
RR itself before and not including the signature ...
... RR(s) of the type covered with the same owner name and class as
the SIG RR in canonical form and order. How this data sequence is
...
... similarly sorted by type and then RDATA as a left justified unsigned
octet sequence. EXCEPT that the type SIG RR(s) covering any
particular type appear immediately after the other RRs ...
... particular type appear immediately after the other RRs of that type.
(This special consideration for SIG RR(s) in ordering really only
applies to calculating the AXFR ...
... RR(s) in ordering really only
applies to calculating the AXFR SIG RR as explained in section 4.1.3
below.) Thus if at name a.b there are two A RRs ...
... class and type. However, to efficiently
assure the completeness and security of zone transfers, a SIG RR
owned by the zone name must be created ...
... that covers all zone signed RRs in the zone and their zone SIGs but
not the SIG AXFR itself. The RRs are ordered and concatenated for
...
...
The AXFR SIG must be calculated last of all zone key signed SIGs in
the zone. In effect, when signing ...
... hash. When the name or type changes
you calculate and insert the RRset zone SIG, clear the RRset hash,
...
... RR to calculate and
insert an AXFR SIG covering the zone. Of course any computational
technique producing the same results as above is permitted.
...
...
The AXFR SIG really belongs to the zone as a whole, not to the zone
name. Although it should be correct for the zone name, the labels
field of an AXFR ...
... name. Although it should be correct for the zone name, the labels
field of an AXFR SIG is otherwise meaningless. The AXFR SIG is only
...
... AXFR SIG is otherwise meaningless. The AXFR SIG is only
retrieved as part of a zone transfer. After validation of the AXFR ...
... validated.
The AXFR SIG SHOULD be transmitted first in a zone transfer so the
receiver can tell immediately that they may be able to avoid
...
... zone key (see Section 3.2) are not included in the AXFR SIG. They may
originate in the network and might not, in general, be migrated to
...
... RRs are not directly signed by the zone, are not included
in the AXFR SIG, and are protected against omission from zone
transfers only to the extent that the server and communication can be
trusted.
...
... response message from a security aware server may optionally
contain a special SIG as the last item in the additional information
section to authenticate the transaction ...
... are included in the "data" used to form any optional response
transaction SIG.
...
... authenticate
the requested RR. The following rules apply to the inclusion of SIG
RRs in responses:
...
... MUST be considered truncated except as provided in 2 below.
2. when a SIG RR is present in the zone for an additional information
section RR ...
... section RR, the response MUST NOT be considered truncated merely
because space does not permit the inclusion of its SIG RR.
...
... superzone's signature on the KEY MUST be included (unless the KEY
was additional information and the SIG did not fit).)
4. If a SIG ...
... SIG did not fit).)
4. If a SIG covers any RR that would be in the answer section of the
response, its automatic inclusion MUST be the answer section. If
...
... DNS transactions may be authenticated by a SIG RR at
the end of the response in the additional information section
...
... RR at
the end of the response in the additional information section
(Section 4.1.4). Such SIG RRs are signed by the DNS server
...
... transaction authentication is desired,
that SIG RR must be considered higher priority for inclusion than
...
... AD bit (see Section 6.1) set, MAY choose to accept the
RRs as received without verifying the zone SIG RRs.
...
... RRs of interest. This may involve initiating
additional queries for SIG or KEY RRs, especially in the case of
getting a response from an insecure server. (As explained in 4.2
...
... RRs are received in response to a user query explicitly
specifying the SIG type, no special processing is required.
...
...
If the message does not pass reasonable checks or the SIG does not
check against the signed RRs, the SIG ...
... SIG does not
check against the signed RRs, the SIG RR is invalid and should be
ignored. If all of the SIG ...
... SIG RR is invalid and should be
ignored. If all of the SIG RR(s) purporting to authenticate a set of
...
... authenticate any RRs in the message.
Only a proper SIG RR signed by the zone or a key tracing its
authority ...
... below. (It does not make sense to include a transaction or request
authenticating SIG RR in a file as they are a transient
authentication ...
... TTL, which applies to the type signed, is the same as
the TTL of the SIG RR itself, it may be omitted. The date field
which follows it is larger than the maximum possible TTL ...
... RR for a name interval containing the nonexistent name. A NXT RR and
its SIG are returned in the authority section, along with the error,
if the server is security ...
... Authenticated, Pending, or Insecure. There is also a
fourth transient state of Bad which indicates that all SIG checks
have explicitly failed on the data. Such Bad data is not retained at
...
... Authenticated means that the data has a
valid SIG under a KEY traceable via a chain of zero or more SIG and
KEY RRs ...
... valid SIG under a KEY traceable via a chain of zero or more SIG and
KEY RRs to a KEY configured at the resolver via its boot file.
...
... Pending data has no authenticated SIGs and at least one additional
SIG the resolver is still trying to authenticate. Insecure data is
data which it is known can never be either Authenticated ...
... Security aware resolvers will know that if data is Insecure versus
Authentic by the absence of SIG RRs. Security aware servers MAY
...
...
The file looks like a master file except that it can only contain KEY
and SIG RRs with the SIGs signed under a key configured with the
pubkey directive.
...
...
Coordinated interpretation of the time fields in SIG RRs requires
that reasonably consistent time be available to the hosts ...
... Otherwise, for example, a host could get its clock turned back and
might then believe old SIG and KEY RRs which were valid but no longer
...
...
However, larger keys increase the size of the KEY and SIG RRs. This
increases the chance of DNS ...
... secure machines only. Periodically an application can be run to add
authentication to a zone by adding SIG and NXT RRs and adding no-key
...
...
Minimal server compliance is the ability to store and retrieve
(including zone transfer) SIG, KEY, and NXT RRs. Any secondary,
...
... RRs in zone files and (2)
ability, given a zone file and private key, to add appropriate SIG
and NXT RRs ...
... NXT RRs, possibly via a separate application, (3) proper
automatic inclusion of SIG, KEY, and NXT RRs in responses, (4)
...
... authenticated, (3) performs additional
queries as necessary to attempt to obtain KEY, SIG, or NXT RRs
...