# 3. Implementation ... # 3.1. Including DELEG RRs in a Zone # # A DELEG RRset MAY be present at a delegation point. The DELEG RRset # MAY contain multiple records. DELEG RRsets MUST NOT appear at a # zone's apex. # # A DELEG RRset MAY be present with or without NS or DS RRsets at the # delegation point. #
...the question is, during a search, where a domain name is the closest encloser in the zone for a query name and the domain name has a DELEG but no NS records, the authoritative server will respond with a referral, containing the DELEG in the authority section. The querier, if not DELEG-aware, can't be told what to do here (it if could, it'd probably just implement DELEG support) so it'll do what it does now. I'm sure this has been worked on (tested) and probably here would be a good place to include that, so that the implementer can have an idea of how the querier will react... The next paragraph doesn't belong here - either in section 2, semantically defining the record or in a separate part of section 3. # Construction of a DELEG RR requires knowledge which implies # communication between the operators of the child and parent zones. # This communication is an operational matter not covered by this # document. # # 3.1.1. Signing DELEG RRs # # A DELEG RRset MUST be DNSSEC signed if the zone is signed. # # If a signed zone contains DELEG records, the zone MUST be signed with # a DNSKEY that has the DELEG flag set. To start DELEG, a zone would have to first add a new DNSSEC (zone) key with the flag on, then add the first DELEG resource record set(s) and sign them, and then probably roll all the other signatures to the new key. I'm just a little concerned about adding key flags because that changes the key tag and validators would have to know how to match the keys with this new wrinkle. # 3.2. Authoritative Name Servers # # 3.2.1. Including DELEG RRs in a Response # ...assuming the QTYPE is not DELEG or AXFR or '*' (or anything that matches DELEG) which would cause the DELEG to be in the answer section: # If a DELEG RRset is present at the delegation point, the name server # MUST return both the DELEG RRset and its associated RRSIG RR in the # Authority section along with the DS RRset and its associated RRSIG RR # and the NS RRset. RRSIG RR - there could be multiple signature records. You need to account for having a DELEG resource record set, having a NS resource record set, and no DS resource record set, meaning, having to include proof of non-existence of a DS resource record set. And what happens if there is a DELEG resource record set, DS resource record set, and no NS resource record set? I would think this an anomaly, but I've seen many permutations of DNS configurations in the wild and a good spec will account for all cases. I would think that when there is an expectation of a DELEG record (deferring that definition for now), a referral has to include in its authority section these things: A DELEG resource record set or proof of non-existence, A NS resource record set, and A DS resource record set or proof of non-existence. To establish the expectation of DELEG, is it enough to require that at least one non-revoked zone key (key flag bit 7 is 1, key flag bit 8 is 0, with flag key flag bit 15 being 0 or 1) be included in the set? In terms of a "chain of security", if the parent state is secured, then the cut point DS (or DELEG) resource record set will refer to the apex DNSKEY resource record set and in there, a DNSKEY resource record with the DELEG-supporting bit can be seen. (I think section 1.5.1. of the document needs to be tightened up, perhaps to be as specific as the above paragraph.) # If no DELEG RRset is present at the delegation point, and the zone # was signed with a DNSKEY that has the DELEG flag set, the name server # MUST return the NSEC or NSEC3 RR that proves that the DELEG RRset is # not present including its associated RRSIG RR along with the DS RRset # and its associated RRSIG RR if present and the NS RRset, if present. # # Including these DELEG, DS, NSEC or NSEC3, and RRSIG RRs increases the # size of referral messages. If space does not permit inclusion of # these records, including glue address records, the name server MUST # set the TC bit on the response. # # 3.2.2. Responding to Queries for Type DELEG # # DELEG records, when present, are included in referrals. When a # parent and child are served from the same authoritative server, this # referral will not be sent because the authoritative server will # respond with information from the child zone. In that case, the # resolver may query for type DELEG. The above is hard-to-read. It's true that referrals are suppressed when a hierarchy is all on a server, but this has nothing to do with how a server responds to a QTYPE=DELEG, QTYPE=T_ANY (*), or QTYPE=AXFR, each of which put a DELEG in the answer section. (That's the distinction.) # The DELEG resource record type is unusual in that it appears only on # the parent zone's side of a zone cut. For example, the DELEG RRset # for the delegation of "foo.example" is part of the "example" zone # rather than in the "foo.example" zone. This requires special # processing rules for both name servers and resolvers because the name # server for the child zone is authoritative for the name at the zone # cut by the normal DNS rules, but the child zone does not contain the # DELEG RRset. # # A DELEG-aware resolver sends queries to the parent zone when looking # for a DELEG RR at a delegation point. However, special rules are # necessary to avoid confusing legacy resolvers which might become # involved in processing such a query (for example, in a network # configuration that forces a DELEG-aware resolver to channel its # queries through a legacy recursive name server). The rest of this # section describes how a DELEG-aware name server processes DELEG # queries in order to avoid this problem. # # The need for special processing by a DELEG-aware name server only # arises when all the following conditions are met: # # * The name server has received a query for the DELEG RRset at a zone # cut. # # * The name server is authoritative for the child zone. # # * The name server is not authoritative for the parent zone. # # * The name server does not offer recursion. # # In all other cases, the name server either has some way of obtaining # the DELEG RRset or could not have been expected to have the DELEG # RRset, so the name server can return either the DELEG RRset or an # error response according to the normal processing rules. # # If all the above conditions are met, however, the name server is # authoritative for the domain name being searching for, but cannot # supply the requested RRset. In this case, the name server MUST # return an authoritative "no data" response showing that the DELEG # RRset does not exist in the child zone's apex. I think the above section is pretty confusing. It should be written as "how to respond". If the QTYPE is DELEG, the server selects the best zone from which to answer as the parent zone of the QNAME. If the zone is available, then either the DELEG resource record set and it's signature set are placed into the answer section or the appropriate secured negative answer is (signed NXDOMAIN or signed NoError/NoData via NSEC/NSEC3). If the zone is below any zone the server has, a referral is sent. In all other cases, the server responds according to the rules for what were once called "lame servers". If the QTYPE is T_ANY (*), then none of this is special. If the QTYPE is AXFR, then DELEG resource record sets are included with all other contents of the zone. (And for IXFR). Perhaps there ought to be separate sections for QTYPE=DELEG and these other values... # # 3.2.3. Priority of DELEG over NS and Glue Address records This ought to be 3.3...3.2 is about authoritative servers and this is how a querier ought to react. (Besides this probably needing much more work - recognizing this is a -00 after all.) # # DELEG-aware resolvers SHOULD prioritize the information in DELEG # records over NS and glue address records. # _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
