Re: Bogus nic.fr behavior

[Jerry Scharf <scharf@vix.com>]

We have a couple things overlaying here, and I think it's worth splitting them 
out.

Dan, I think I agree with you on the TCP issue, but I have an operational 
question for your server. If I turn off TCP, then put in a record that is too 
long to be answered in 512 wire bytes, what happens? If you could demonstrate 
to me that you fail to load the zone in that case, then I would consider 
granting a waiver. If you don't do this, I think there is an operational issue 
for the zone operator that makes me want to not grant a waiver. There is no 
way for me to test that the domain will attempt to send longer answers in the 
future and fail, so you need to demonstrate to me that it can't happen. 
(Personally, I wouldn't turn off TCP for anything. Since my goal is to make 
sure everyone who wants to talk to foo can, I want to cover the case where 
some client decided to just use TCP to me or fail. I don't care whether it's 
right, just that I get them the answers.)

I really don't know why a authoritative server needs to answer for 127.0.0.1. 
I haven't seen anyone really defend this.  Answering for the roots in case of 
an errant query seems reasonable to me, but it should be best effort and 
should only require correctness. I see no reason for currency to be enforced, 
just no non-functional addresses. The "do this script" thing asssumes that 
scrips never break and that the testing coincide with the script cycle, both 
of which are questionable.

Finally, there is the issue of testing and testing waivers. There has been a 
great deal of discussion about protecting clueless people from themselves for 
the good of the Internet. If you delegate foo and it doesn't work, foo and the 
clients of foo are harmed. The pain is localized the the participating 
parties, so the degree to which this should have limits, IMO. Having tests 
that forces people get thier nameservers right is a good thing. What I'm 
hearing underneath all this is that nic.fr has no policy/ability to grant 
technical waivers for anything, or does not believe that there any need to. 
What would be needed to develop a wiaver policy for nic.fr? I would add the 
clause that there is the right to publicly riducle the person/group if they 
screw up after being given a waiver. :-)

Dan clearly knows DNS well, and if the zone in question wants to operate on 
correct terms but not to the letter of the nic.fr testing, why should that not 
be allowed. It's not for the "I'm too lazy to do DNS right crowd", it's for 
the "I'm clueful and want my server to run this legal way" group.

jerry