Re: [dns-wg] Delegation checking policy/procedure at ARIN
"JFC" == JFC (Jefsey) Morfin <jefsey@jefsey.com> writes:
JFC> When I cannot register a ".fr" or a ".tp" name because of the JFC> retsrictions imposed by their NICs I am upset. I would prefer JFC> - and I would be gratefull - if they told me what is wrong I JFC> could correct when I want, but securing the DN in the JFC> meanwhile? This is really something to discuss with the registry concerned. There should be some forum where its customers -- or stakeholders -- can influence policy. However registries don't usually run DNS consultancy businesses, so there will be limits on what they can and cannot do. It's hard to see where chatty help messages for the DNS-clueless would stop and DNS consulting starts: how much help and advice is "enough"? And how much of that consultancy can a registry afford to do when it's only getting a few bucks for the registration? JFC> Example: when the nameserver is on the same machine as the JFC> site, I never understood why I would need two name servers. Read section 3.3 of RFC2182. In fact, read the whole RFC. JFC> I would be really interested if Patrick's work permitted JFC> that: to tell me what may be wrong in my files and to teach JFC> me to correcty right them? Well, someone from AFNIC will be talking about their new delegation checking tools and processes at the WG tomorrow. The presentation should be on the RIPE web site by early next week at the latest. I'm hoping the WG will use tomorrow's session on delegation checking to work on this topic: perhaps produce a BCP or something like that. If this gets under way, it would be useful to get contributions on things like the nature of error messages and so on.
On 14 May, Jim Reid wrote: | >>>>> "JFC" == JFC (Jefsey) Morfin <jefsey@jefsey.com> writes: | | JFC> When I cannot register a ".fr" or a ".tp" name because of the | JFC> retsrictions imposed by their NICs I am upset. I would prefer | JFC> - and I would be gratefull - if they told me what is wrong I | JFC> could correct when I want, but securing the DN in the | JFC> meanwhile? | | This is really something to discuss with the registry concerned. There | should be some forum where its customers -- or stakeholders -- can | influence policy. However registries don't usually run DNS consultancy | businesses, so there will be limits on what they can and cannot do. | It's hard to see where chatty help messages for the DNS-clueless would | stop and DNS consulting starts: how much help and advice is "enough"? | And how much of that consultancy can a registry afford to do when it's | only getting a few bucks for the registration? ==> The registry concerned for instance does provide a public tool that gives information _verbose enough_ to understand what is being tested and what is going wrong if DNS configuration is deemed bad (according to DNS RFCs, BCP documents and the registry's policy). As Jim said it below, the new version of the same tool will be presented at the DNS-wg session and everybody can try (http://zonecheck.afnic.fr/v2/) and give us (zonecheck@afnic.fr) feedback whether something is missing or not clear enough. | | JFC> Example: when the nameserver is on the same machine as the | JFC> site, I never understood why I would need two name servers. | | Read section 3.3 of RFC2182. In fact, read the whole RFC. | | JFC> I would be really interested if Patrick's work permitted | JFC> that: to tell me what may be wrong in my files and to teach | JFC> me to correcty right them? | | Well, someone from AFNIC will be talking about their new delegation | checking tools and processes at the WG tomorrow. The presentation | should be on the RIPE web site by early next week at the latest. | | I'm hoping the WG will use tomorrow's session on delegation checking | to work on this topic: perhaps produce a BCP or something like that. If | this gets under way, it would be useful to get contributions on things | like the nature of error messages and so on. ==> Hope so. Mohsen.
Dear Jim and Mohsen, On 16:25 14/05/03, Jim Reid said:
"JFC" == JFC (Jefsey) Morfin <jefsey@jefsey.com> writes:
JFC> When I cannot register a ".fr" or a ".tp" name because of the JFC> retsrictions imposed by their NICs I am upset. I would prefer JFC> - and I would be gratefull - if they told me what is wrong I JFC> could correct when I want, but securing the DN in the JFC> meanwhile?
This is really something to discuss with the registry concerned.
We are just talking of restrictions imposed by registry BPs. BPs should say that restrictions are to be documented both in plain text and decribing case per case the tested reasons of a denial so one can document when the testing is wrong. BPs should also say that the intended registration should be valid when the denial of registration is due to its wrong analysis of the registrant configuration. There is no reason why the first come first served rule would defeated by an error of the Registry. BPs could say that the registry should provide its proposed DNS configuration, so the Registrant could implement it to get registered.
JFC> Example: when the nameserver is on the same machine as the JFC> site, I never understood why I would need two name servers.
Read section 3.3 of RFC2182. In fact, read the whole RFC.
This is exactly the section I find inadequate to the case. We all know that. The problem is that some Regustries want to enforce it without discrimination. If the secondary is on the same machine - as I documented - or on the next one or at the other end of the world. It will _not_ improve the average response time to get the information, and will only disseminate a _wrong_ information when the master and the host on the same machine are down. Registry BP should force Registries to accept such registration under the responsiblity of the Registrant as does ".ws". We are talking about BPs you are going to discuss. Good BPs should not lead registrants to trick the Registry: it should consider all the cases and best support the Registrant in every case IMHO.
JFC> I would be really interested if Patrick's work permitted JFC> that: to tell me what may be wrong in my files and to teach JFC> me to correcty right them?
Well, someone from AFNIC will be talking about their new delegation checking tools and processes at the WG tomorrow. The presentation should be on the RIPE web site by early next week at the latest.
I'm hoping the WG will use tomorrow's session on delegation checking to work on this topic: perhaps produce a BCP or something like that. If this gets under way, it would be useful to get contributions on things like the nature of error messages and so on.
Certainly ready to help there. Will you address IDNA? jfc http://eurolinc.org
On Wed, May 14, 2003 at 07:24:44PM +0200, JFC (Jefsey) Morfin <jefsey@jefsey.com> wrote a message of 64 lines which said:
BPs should say that restrictions are to be documented both in plain text and decribing case per case the tested reasons of a denial so one can document when the testing is wrong.
They are. Any one can see it by itself at http://zonecheck.nic.fr/v2/.
BPs should also say that the intended registration should be valid when the denial of registration is due to its wrong analysis of the registrant configuration. There is no reason why the first come first served rule would defeated by an error of the Registry.
It is not (the ticket is not closed immediately when there is a configuration error).
BPs could say that the registry should provide its proposed DNS configuration, so the Registrant could implement it to get registered.
For which software? BIND8, BIND9, nsd, PowerDNS?
Will you address IDNA?
Yes.
Dear Stephane, thank you for your remarks. I must say that I did not validate many ".fr" due to the AFNIC resales organization, naming structure and my own users orientations, so my experience with your (our fr) program is limited (and no-experience since IDNA). But we are talking about BPs and my point is certainly that the Registry community should take advantage from AFNIC's efforts (may be smoothing some rigidities - but maybe this has been done?). I want to incitate this experience to be used when considerng BPs. There is no reason when something good is made by some not to tell it. My other point is that such proposed BPs draft should be reveiwable by the @large community(ies). Thank you. jfc At 09:34 15/05/03, Stephane Bortzmeyer wrote:
On Wed, May 14, 2003 at 07:24:44PM +0200, JFC (Jefsey) Morfin <jefsey@jefsey.com> wrote a message of 64 lines which said:
BPs should say that restrictions are to be documented both in plain text and decribing case per case the tested reasons of a denial so one can document when the testing is wrong.
They are. Any one can see it by itself at http://zonecheck.nic.fr/v2/.
BPs should also say that the intended registration should be valid when the denial of registration is due to its wrong analysis of the registrant configuration. There is no reason why the first come first served rule would defeated by an error of the Registry.
It is not (the ticket is not closed immediately when there is a configuration error).
BPs could say that the registry should provide its proposed DNS configuration, so the Registrant could implement it to get registered.
For which software? BIND8, BIND9, nsd, PowerDNS?
Will you address IDNA?
Yes.
--- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.478 / Virus Database: 275 - Release Date: 06/05/03
participants (4)
-
JFC (Jefsey) Morfin -
Jim Reid -
Mohsen Souissi -
Stephane Bortzmeyer