>… I do want to point out that Compact DoE handles wildcards quite differently, >and this may not be readily apparent to the casual observer.
FWIW, I noticed. (Not meaning to say “I’m not a casual observer” but…). This is something that was playing in my mind when reviewing the proposal. In basic DNS, if a name has no records and no descendants, then the responder looks for a relevant source of synthesis. Relevant means that it is “up the tree”, owner first label is “*” and there is no “blocking” name. (I won’t define “blocking here, there’s an RFC for that.) If a relevant source found, a response is cobbled from that. In year 2004 DNSSEC, the same process is followed, but the responder will add DNSSEC records to support the work it is doing. In essence, DNSSEC is “proving” that the responder followed the protocol faithfully in answering as it is. For zones using NSEC, this means showing the query name does not have records or descendants (NXDOMAIN) but there is a relevant source of synthesis and there is no blocking name. That can be done in one or two NSEC resource record sets. For zones using NSEC3, this means showing the name doesn’t exist, the showing the source of synthesis exists, and then showing there is no blocking - the three steps may each need their own NSEC3 resource record set. (Sorry, now I’m on a roll…) All of this is because of the way DNS has opted to implement synthesized responses. It was pointed out during the writing of the “Clarifications of Wildcards” there are many other ways to synthesize a response, “wildcards” was just one, the one publicly defined, method. This argument was from Dan Bernstein. For those who recall his years of participation, there was often frustration in understanding his points. He was correct in this instance. It just took a long time to understand what he meant. Instead of “wildcards are the way to synthesize” he wanted “wildcards are a way to synthesize”. I’m including this because the point is germane here. If a server is synthesizing responses on the fly according to other algorithms, then the NSEC/NSEC3 proofs do not apply. The server isn’t following the “standard” synthesis method. The server then just needs to figure out how to express its response. For a positive response, the label count has to be “right”. For negative responses, the server needs to decide how it wants to answer. In a purely on-the-fly, synthesizing responder, there may be no difference in response between a name not having any records nor descendants and a name not having what the query is seeking. For some part of me, I don’t understand why the original protocol distinguishes between name error (NXDOMAIN) and no error/no data. It’s been said that the DNS matching process has two phases, matching name first and then matching resource records. This is apparent in the protocols basic design. But why it is this way, I don’t know. I don’t see this as terribly significant - except when you try to understand how answer synthesis (“wildcards”) is done. Based on that, I can see that Compact denial of existence handles “wildcards” differently. I don’t think wildcards are integral elements of the protocol, but it is a defined mechanism. A zone administrator can elect to fully enumerate the names in the zone, and this can be implemented either by rote (explicitly listing all the names in a file) or by function (fully synthesizing). If the zone administrator elects either, and implements the protocol fully, they won’t have wildcards and no incidence of Name Error (NXDOMAIN). For any application relying on NXDOMAIN - such a zone has all names “existing” (in some sense), there simply will never be an NXDOMAIN. (There can be empty non-terminals, but if the zone is properly defined, all the leaf names - those without in-zone descendants - would have to own some record set.) So…that Compact Denial of Existence handles wildcards “differently” - this is significant…
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
