On tisdag, maj 13, 2003, at 13:23 Europe/Stockholm, Edward Lewis wrote:
Speaking strictly as an engineer and not as font of policy
That is what I take for granted _anyone_ do on this list (unless very explicitly stated otherwise).
At 12:00 +0200 5/13/03, Patrik Fältström wrote:
- What is a proper set of requirements a registry set on operations of a child zone? (One can argue the registry should not care, BUT, in reality they do. The answer can be "do not care", but then it should be said very loud.)
That being said, the answer to this is quite policy specific. There is an element of technical data to the answer though, perhaps significant but not substantial.
The DNS protocol is defined to be quite robust in the face of misconfiguations (lameness is an exception). With that in mind, there's little technical justification to place a lot of overhead in 'policing' configurations. I'll repeat this - this does not limit what a registry may choose to do, but it limits our ability to point to a section of a standard and say "see, this is why we enforce a certain behavior."
Correct. The robustness is also not a degradation nowadays (Rickards talk during EOF showed that resolvers are pretty robust), but a step function. As long as one of the NS is not lame, you will get 100% clean "service" from the set of NS which together is the delegation. But, when the last non-lame server turns lame, the successrate turns to 0%. Because of this, the tests I do which show "errors" is listing possibly the wrong thing. With a similar reasoning you see most registries which require (all) NS responding is doing a questionable thing. The "DNS" will work. A different way of stating this is that a domain might have a too low number of NS records if less that 2 NS _respond_. This way, if the number of responding NS is as low as 1, then there is a big risk the service the delegation define will not work.
- Is the requirements different between in-addr.arpa delegations from the normal {cc,g}TLD delegations? If so, why?
The answer to this is buried in the debate over whether the reverse map "MUST" be supported. This debate is happening (dormantly for now) in the IETF DNSOP WG. I think the answer is yes - based on the observation that no one is debating whether the forward map is needed. ;) I can't offer a pat answer to "why?" (but where there's smoke there's either a fire or a troll). ;/
My personal view is that _if_ the IETF DNSOP WG is coming to the conclusion that there should be delegations there, the requirements and view on "what is good and what is bad" should be the same. DNS is DNS is DNS. paf