[dns-wg] Delegation checking policy/procedure at ARIN

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