Re: clueing in TLD registries for delegations to non-BIND servers
"Stefan" == Stefan Paletta <stefanp@cabal1.com> writes:
Stefan> All, good to see nsd make progress (played with it a litte Stefan> while ago, but tinydns continues to serve me best). Oh dear. It seems that the behaviour of tinydns is preventing you from registering domains in some TLDs. That wouldn't appear to be "serving you best", at least not to me anyway. Stefan> Some TLD registries, however, make unreasonable demands Stefan> regarding the behaviour of servers to which they delegate Stefan> zones. Most notably the .fr and .it registries, which Stefan> apparently demand that servers return a Stefan> (non-authoritative!, in the case of .it) referral to the Stefan> root servers when they are lame. These demands are highly Stefan> questionable -to say the least- and are hard and sometimes Stefan> impossible to follow for users of at least tinydns and Stefan> nsd. While I am not speaking on behalf of these registries -- they can do that themselves -- I believe they're acting out of enlightened self-interest. Many people think a registration entitles them to hours of free consultancy from the registry on how to set up and configure their name servers. [I have been in several registries and overheard the helpdesk staff answer floods of these calls.] Expecting a customer to have name servers that answer authoritatively and/or know about the root servers goes a long way to reducing the number of these misdirected requests for help. "Don't come to us until your name servers are working" is not an unreasonable stance IMO. Stefan> I was wondering if RIPE or a group from the RIPE community Stefan> might appeal to those registries and try to make them stop Stefan> acting stupid. First or all, you do not do your cause any good by spreading insults. This is not constructive or helpful. Secondly, you should be aware that it's not for RIPE or the DNS WG to dictate policy to a ccTLD registry -- that's a national matter -- or tell anyone how to run their name servers. How an organisation chooses to operate its infrastructure is up to them. The WG can produce recommendations or a best common practice (eg RIPE-192) but that's it. People are free to accept or reject or ignore that advice as they see fit. If you wish to prepare such a recommendation, go ahead. The matter can be discussed on this list and I'll be happy to arrange discussion time for the subject at future sessions of the WG. As WG chair, I would welcome a wider analysis of the registration policies of the TLD registries in the RIPE region (and beyond?) and try to see if some common guidelines can be established. This could be a worthwhile subject for a WG recommendation. The topic has exercised you, so I think you'd be an ideal candidate to get that work under way. :-) And if I can be provocative, why don't you ask the author of djbdns to make the software do the Right Thing and at least *respond* whenever it gets a query for something it's not authoritative for?
[please do not explicitly send copies of followups to me] Jim Reid wrote/schrieb/scripsit:
"Stefan" == Stefan Paletta <stefanp@cabal1.com> writes:
Stefan> All, good to see nsd make progress (played with it a litte Stefan> while ago, but tinydns continues to serve me best).
Oh dear. It seems that the behaviour of tinydns is preventing you from registering domains in some TLDs. That wouldn't appear to be "serving you best", at least not to me anyway.
Bait not taken; rest assured, my choice of nameserver software has never hindered any registration (at least not yet) and I will never hesitate a second to cheat around useless requirements if necessary. I believe that diversity of software is actually a strong requirement for the stability of the Internet (but then I'm not geeting paid by a company that makes and sells nameserver software---SCNR!) and I welcome the effort RIPE has made to contribute to that. A simple, reliable and fast nameserver that groks BIND zonefiles is a good thing to have. What concerns me, though, is a possible limitation of use- fulness of NSD and I would expect RIPE to actually care about that, too (I am aware that this list is not authoritative wrt. this). Anyway, just let me know if that is not the case and I will shut up. (Though I might then -- at another place -- raise the question why RIPE is purposely wasting my money making nameserver software that is not usable for domains in some TLDs.)
Stefan> Some TLD registries, however, make unreasonable demands Stefan> regarding the behaviour of servers to which they delegate Stefan> zones. Most notably the .fr and .it registries, which Stefan> apparently demand that servers return a Stefan> (non-authoritative!, in the case of .it) referral to the Stefan> root servers when they are lame. These demands are highly Stefan> questionable -to say the least- and are hard and sometimes Stefan> impossible to follow for users of at least tinydns and Stefan> nsd.
While I am not speaking on behalf of these registries -- they can do that themselves -- I believe they're acting out of enlightened self-interest. "Don't come to us until your name servers are working" is not an unreasonable stance IMO.
It is entirely reasonable. Altough I firmly believe Darwinism is much better in selecting those who know DNS and those who don't, actively giving people clues about how to do it right is probably more within the spirit of the Internet. The problem here is just that the definition of 'working' is too often less than helpful. As I have already explained briefly -- and I think we will see more thoroughly later -- some checks are nonsensical in a technical way, actively hindering e.g. deployment of standards conformant software, and most of them fail to provide a continued use because they are nonrevisable, unenforcable and singular, i.e. people can screw up in wonderful ways once a zone has been delegated anyway.
Secondly, you should be aware that it's not for RIPE or the DNS WG to dictate policy to a ccTLD registry -- that's a national matter -- or tell anyone how to run their name servers. How an organisation chooses to operate its infrastructure is up to them. The WG can produce recommendations or a best common practice (eg RIPE-192) but that's it. People are free to accept or reject or ignore that advice as they see fit.
I was not asking for anyone to dictate policy at all. It is just that registries have a habit of not listening to their customers (esp. not those who apparently cannot get their nameserver to work 'correctly'). That is where a RIPE document at least gives people something in their hands to take to a registry and (hopefully) make them listen.
If you wish to prepare such a recommendation, go ahead. The matter can be discussed on this list and I'll be happy to arrange discussion time for the subject at future sessions of the WG. As WG chair, I would welcome a wider analysis of the registration policies of the TLD registries in the RIPE region (and beyond?) and try to see if some common guidelines can be established. This could be a worthwhile subject for a WG recommendation. The topic has exercised you, so I think you'd be an ideal candidate to get that work under way. :-)
Well first of all I am not familiar with the guidelines of such an undertaking (you probably guessed that ;-) ), but nonetheless, I am willing to collect, analyze and then evaluate such policies, given the necessary input from the community. As for a recommendation on reg. policies I have to say that probably my ideas about that, while being -- as far as I know -- well thought out, might simply be too radical to be suitable for inclusion in a document approved by this WG. For example quite a few registries have the requirement for at least two independent nameservers and that those have addresses not within the same /24. This can be replaced by one completely different re- quirement that, in contrast, is revisable, enforcable and actually useful. By all means, if someone wants to hear I will be happy to write this up and have it discussed and, for that matter, proven wrong.
And if I can be provocative, why don't you ask the author of djbdns to make the software do the Right Thing and at least *respond* whenever it gets a query for something it's not authoritative for?
Bait not taken again; there is, however, some truth in your statement. I agree that djbdns servers must respond in any case, and I found it not too hard to configure my servers to do the Right Thing and fall back to SERVFAIL. The method of adding a referral to the roots is also documented. Again, others may operate their servers the way they choose. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}
At 5:40 PM +0100 2003/02/11, Stefan Paletta wrote:
Bait not taken; rest assured, my choice of nameserver software has never hindered any registration (at least not yet) and I will never hesitate a second to cheat around useless requirements if necessary.
If you choose to "cheat around requirements" that you consider to be useless, do not be surprised if you find yourself summarily disconnected and treated as a true net.pariah.
I believe that diversity of software is actually a strong requirement for the stability of the Internet (but then I'm not geeting paid by a company that makes and sells nameserver software---SCNR!) and I welcome the effort RIPE has made to contribute to that.
As far as this statement goes, I think everyone on this list will agree -- regardless of who their employer may or may not be. Before you casually dismiss us, you should at least check to see if we actually support whatever it is that you abhor so much. Throwing mud at people you do not know sufficiently well to determine whether or not they agree or disagree with your statements is not a particularly effective manner of convincing people that you're right.
A simple, reliable and fast nameserver that groks BIND zonefiles is a good thing to have. What concerns me, though, is a possible limitation of use- fulness of NSD and I would expect RIPE to actually care about that, too (I am aware that this list is not authoritative wrt. this).
One of the fundamental design criteria for nsd was to eliminate all possible operations that were not strictly required for the proper functioning of a TLD nameserver. However, this does limit the functionality of nsd with regard to regular authoritative functioning.
Anyway, just let me know if that is not the case and I will shut up. (Though I might then -- at another place -- raise the question why RIPE is purposely wasting my money making nameserver software that is not usable for domains in some TLDs.)
This is a design choice made by the authors. I don't think there's any chance of getting them to change their minds about eliminating all functions not strictly necessary for a TLD nameserver.
It is entirely reasonable. Altough I firmly believe Darwinism is much better in selecting those who know DNS and those who don't, actively giving people clues about how to do it right is probably more within the spirit of the Internet.
Regretfully, there are many people who can cause much damage to the DNS and the Internet as a whole, without actually being eliminated themselves. This is kind of the same problem as you have with drunk drivers -- they usually cause far more damage to others than to themselves.
i.e. people can screw up in wonderful ways once a zone has been delegated anyway.
Sure, that's always possible. Indeed, this sort of problem is possible in most human endeavours. However, it's also possible for people like Rob Thomas or someone else to put into place procedures that will periodically check for a variety of DNS configuration problems, and then we can publicly name and shame them. There's little more we can do, but there is at least the chance that this might do some good.
I was not asking for anyone to dictate policy at all. It is just that registries have a habit of not listening to their customers (esp. not those who apparently cannot get their nameserver to work 'correctly'). That is where a RIPE document at least gives people something in their hands to take to a registry and (hopefully) make them listen.
Things like this are also useful to take to program authors who insist on implementing b0rken behaviour in their software, just because they think it's right.
For example quite a few registries have the requirement for at least two independent nameservers and that those have addresses not within the same /24. This can be replaced by one completely different re- quirement that, in contrast, is revisable, enforcable and actually useful. By all means, if someone wants to hear I will be happy to write this up and have it discussed and, for that matter, proven wrong.
I would be curious to know what your proposed alternative is. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
Brad Knowles wrote/schrieb/scripsit:
At 5:40 PM +0100 2003/02/11, Stefan Paletta wrote:
I believe that diversity of software is actually a strong requirement for the stability of the Internet (but then I'm not geeting paid by a company that makes and sells nameserver software---SCNR!) and I welcome the effort RIPE has made to contribute to that.
As far as this statement goes, I think everyone on this list will agree -- regardless of who their employer may or may not be. Before you casually dismiss us, you should at least check to see if we actually support whatever it is that you abhor so much.
Throwing mud at people you do not know sufficiently well to determine whether or not they agree or disagree with your statements is not a particularly effective manner of convincing people that you're right.
That was just a cynical response to Jim's fallacious assumption about my motivation and of course not to be taken seriously. If someone took it for that, I am sorry. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}
On Tue, Feb 11, 2003 at 05:40:11PM +0100, Stefan Paletta <stefanp@cabal1.com> wrote a message of 109 lines which said:
I will never hesitate a second to cheat around useless requirements if necessary
IANAL but I believe that the after-the-fact discovery of cheating is a sufficient reason to delete a domain in '.fr'...
The problem here is just that the definition of 'working' is too often less than helpful. As I have already explained briefly -- and I think we will see more thoroughly later -- some checks are nonsensical in a technical way,
As I said, AFNIC is working on a new version of ZoneCheck, rewritten from scratch, free software and, more important, completely modular: tests can be added easily and a configuration file allows to suppress a test without source code modification. Advices on the current set of tests is welcome. Input from the community is also welcome: if you have ideas of nice tests, please write AFNIC or myself (I'll forward).
people can screw up in wonderful ways once a zone has been delegated anyway.
Right. Unlike the '.de' and '.br' registries, AFNIC does not check once the delegation is made. But it will be done in '.eu' with the ZoneCheck tool.
registries have a habit of not listening to their customers (esp. not those who apparently cannot get their nameserver to work 'correctly').
We received two weeks ago a complaint from a potential customer (a big software company, people who should be technically savvy) saying that we had no business testing the connectivity on port 53 with TCP and that we disturbed their firewall. They added that TCP was only for zone transfers. The idiot^H^H^H^H^Hcustomer requested my supervisor's name and address when I told him he knew nothing about DNS :-)
For example quite a few registries have the requirement for at least two independent nameservers and that those have addresses not within the same /24.
Funny, you do not mention of the biggest bugs of the present ZoneCheck: it is still classful and complains if your two nameservers are in the same former class A...
quirement that, in contrast, is revisable, enforcable and actually useful. By all means, if someone wants to hear I will be happy to write this up and have it discussed and, for that matter, proven wrong.
Please do because I do not have many good ideas on how to test this. Do you plan to use BGP announces?
Stephane Bortzmeyer wrote/schrieb/scripsit:
On Tue, Feb 11, 2003 at 05:40:11PM +0100, Stefan Paletta <stefanp@cabal1.com> wrote a message of 109 lines which said:
I will never hesitate a second to cheat around useless requirements if necessary
IANAL but I believe that the after-the-fact discovery of cheating is a sufficient reason to delete a domain in '.fr'...
Because I changed the software my name server runs? (That is a hypothetical me.) Maybe 'cheating' was not the right word - 'using tools more creatively than the rule-makers thought of'. Anyway.. -Stefan -- junior guru SP666-RIPE SMP@{IRC,SILC}
Stefan Paletta wrote:
Maybe 'cheating' was not the right word - 'using tools more creatively than the rule-makers thought of'.
this is really not a race "those stupid rule makers" vs "oh-so-creative zone administrators". First, the "creativity" of the latter very often is detrimental to DNS operational quality and second, registries have to cope with a high volume of changes every day while having to ensure technical quality without the ability of in-depth case studies. So, while those rules probably won't be fair to every single case, they will - if applied reasonably - ensure a high quality system for the average zone. I guess the discussion of what are "reasonable" pre- and post-delegation checks is well inside the scope of this working group and I'd be looking forward to see (and contribute to) some activity in this direction. Still, the RIPE DNS WG is neither the network policy nor a supervisory body for registry operations, i.e. there will be a "grey area" of tests which a registry may want to apply which are neither "necessary" nor "nonsense". We should discuss the technical merits and the pros and cons of such tests. -Peter
participants (5)
-
Brad Knowles -
Jim Reid -
Peter Koch -
Stefan Paletta -
Stephane Bortzmeyer