Connected: An Internet Encyclopedia
5.4 Interaction of NXT RRs and Wildcard RRs

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2065
Up: 5. Non-existent Names and Types
Prev: 5.3 Example
Next: 5.5 Blocking NXT Pseudo-Zone Transfers

5.4 Interaction of NXT RRs and Wildcard RRs

5.4 Interaction of NXT RRs and Wildcard RRs

Since, in some sense, a wildcard RR causes all possible names in an interval to exist, there should not be an NXT RR that would cover any part of this interval. Thus if *.X.ZONE exists you would expect an NXT RR that ends at X.ZONE and one that starts with the last name covered by *.X.ZONE. However, this "last name covered" is something very ugly and long like \255\255\255....X.zone. So the NXT for the interval following is simply given the owner name *.X.ZONE and an RDATA of the next name after the wildcard. This "*" type owner name is not expanded when the NXT is returned as authority information in connection with a query for a non-existent name.

If there could be any wildcard RRs in a zone and thus wildcard NXTs, care must be taken in interpreting the results of explicit NXT retrievals as the owner name may be a wildcard expansion.

The existence of one or more wildcard RRs covering a name interval makes it possible for a malicious server to hide any more specifically named RRs in the internal. The server can just falsely return the wildcard match NXT instead of the more specifically named RRs. If there is a zone wide wildcard, there will be an NXT RR whose owner name is the wild card and whose RDATA is the zone name. In this case a server could conceal the existence of any more specific RRs in the zone. It would be possible to design a more strict NXT feature which would eliminate this possibility. But it would be more complex and might be so constraining as to make any dynamic update feature very difficult.


Next: 5.5 Blocking NXT Pseudo-Zone Transfers

Connected: An Internet Encyclopedia
5.4 Interaction of NXT RRs and Wildcard RRs