blank.gif (43 bytes)

Church Of The
Swimming Elephant

Search:
4.2 SIG RRs in the Construction of Responses Connected: An Internet Encyclopedia
4.2 SIG RRs in the Construction of Responses

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2065
Up: 4. The SIG Resource Record
Prev: 4.1.4 Transaction and Request SIGs
Next: 4.3 Processing Responses and SIG RRs

4.2 SIG RRs in the Construction of Responses

4.2 SIG RRs in the Construction of Responses

Security aware DNS servers MUST, for every authoritative RR the query will return, attempt to send the available SIG RRs which authenticate the requested RR. The following rules apply to the inclusion of SIG RRs in responses:

  1. when an RR set is placed in a response, its SIG RR has a higher priority for inclusion than other additional RRs that may need to be included. If space does not permit its inclusion, the response 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, the response MUST NOT be considered truncated merely because space does not permit the inclusion of its SIG RR.

  3. SIGs to authenticate non-authoritative data (glue records and NS 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).)

  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 it covers an RR that would appear in the authority section, its automatic inclusion MUST be in the authority section. If it covers an RR that would appear in the additional information section it MUST appear in the additional information section. This is a change in the existing standard which contemplates only NS and SOA RRs in the authority section.

  5. Optionally, DNS transactions may be authenticated by a SIG 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 originating the response. Although the signer field MUST be the name of the originating server host, the owner name, class, TTL, and original TTL, are meaningless. The class and TTL fields SHOULD be zero. To conserve space, the owner name SHOULD be root (a single zero octet). If transaction authentication is desired, that SIG RR must be considered higher priority for inclusion than any other RR in the response.


Next: 4.3 Processing Responses and SIG RRs

Connected: An Internet Encyclopedia
4.2 SIG RRs in the Construction of Responses

Cotse.Net

Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

 
.
www.cotse.com
Have you gone to church today?
.
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 Cotse.com.
Cotse.com is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609