Turning off lameness checks for reverse
All, Is there any support for disabling lameness checks for reverse DNS? 1. It seems that they cause some annoyance to administrators. 2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS). These two things suggest to me that the pro-active lameness checks should be disabled, at least until it is shown that lameness actually causes problems. Cheers, -- Shane
On Sat, Mar 28, 2009 at 7:55 PM, Shane Kerr <shane@time-travellers.org> wrote:
All,
Is there any support for disabling lameness checks for reverse DNS?
1. It seems that they cause some annoyance to administrators.
My feeling is that they only cause annoyance to administrators if the checks are not working correctly, personally if I have lame reverse zones I would be very happy if the NCC ran a service that warned me.
2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS).
I'm not aware of any study either but I think we are all aware that certain applications work much better if reverse DNS is setup and functioning correctly. If those applications no longer had a dependency on reverse dns working then I may find it easier to agree with your point of view.
These two things suggest to me that the pro-active lameness checks should be disabled, at least until it is shown that lameness actually causes problems.
As I remember there was a lot of support for this work around the time of the publication of ripe-400 and my feeling is that providing the checks are being done in a sensible way and they are documented that this support is still there. Brett
On 31 Mar 2009, at 08:32, B C wrote:
On Sat, Mar 28, 2009 at 7:55 PM, Shane Kerr <shane@time- travellers.org> wrote:
2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS).
I'm not aware of any study either but I think we are all aware that certain applications work much better if reverse DNS is setup and functioning correctly. If those applications no longer had a dependency on reverse dns working then I may find it easier to agree with your point of view.
A lame delegation (a delegation to a working nameserver which does not offer an authoritative answer to the question) might well have similar impact on application to the case where there is no delegation at all. In both cases you get some form of negative response that indicates that the reverse mapping is not available. Delegations to nameservers which don't respond probably cause more annoyance than lame delegations, since they involve a timeout. Note that if the nameserver doesn't respond you can't tell whether the delegation is lame or not. Encouraging peoople to fix unresponsive nameservers seems like a more obviously good idea than encouraging people to fix measurably-lame delegations. The other consideration that has come up in other regions (and which I have also not seen a study supporting) is that lame delegations caused increased traffic for the servers that publish them, and that the increased traffic presents an operational problem. Philosophically, it makes sense to me for the zone operator (the NCC) to care about the accuracy of the data published in the zone. It's not clear to me that doing so has any operational benefit to the NCC, however. What I hear Shane saying is that since he sees no operational benefit in the checks, as the operator of the number resource, he ought to have the option of opting out of them. I note that opting out of lame delegation checks is possible at ARIN (since I happened to get some robot lame delegation checker mail from them the other day, and the mail mentioned it). Joe
Joe, Joe Abley wrote:
Encouraging peoople to fix unresponsive nameservers seems like a more obviously good idea than encouraging people to fix measurably-lame delegations.
This is true. The current document (RIPE 400) does not make any distinction between timeouts and other responses. That probably be a nice improvement (and something that can be nicely measured to determine the scope of the lameness problem).
The other consideration that has come up in other regions (and which I have also not seen a study supporting) is that lame delegations caused increased traffic for the servers that publish them, and that the increased traffic presents an operational problem.
Which servers are supposed to be seeing increased traffic? The parent servers should have exactly the same number of queries. The non-lame servers in the NS-set will of course receive an increased number of queries - but this is the same amount as if you removed the lame servers from the set. The people who will see more traffic are people running recursive resolvers, due to failures. The RIPE document initiating the lame delegation mails says 11-13% of name servers are lame. We have no idea what the actual effect is of course, since this has not been measured. It could be more (if these lame servers are in heavily-queried zones), or it could be less (if these lame servers are in lightly-queried zones). Basically, we have no data at all.
Philosophically, it makes sense to me for the zone operator (the NCC) to care about the accuracy of the data published in the zone. It's not clear to me that doing so has any operational benefit to the NCC, however.
What I hear Shane saying is that since he sees no operational benefit in the checks, as the operator of the number resource, he ought to have the option of opting out of them. I note that opting out of lame delegation checks is possible at ARIN (since I happened to get some robot lame delegation checker mail from them the other day, and the mail mentioned it).
My basic position is that DNS works as good as it does because it allows an operator to spend as much time and money to provide DNS service as fast and reliable as it needs to be for their needs. The benefits go to the operator, and they pay the costs. If all the hosts in my domain run on a server at home at the end of a flaky DSL connection, I don't need multiple servers running from diverse autonomous systems. However, if I am running an online auctioning site where downtime means lawsuits then I *can* build an anycast cloud running with full redundancy in hundreds of sites around the world. I realize that this only works if all parent domains are also fast and reliable. But this is normally only the parent and a TLD, and these organizations tend to take DNS very, very seriously. What does this mean for lameness checking? If lameness causes problems for an operator, they will fix it. If it does not, they don't care (and that is OKAY). I am fully in favor of parent zones trying to help people keep their delegations working. The RIPE NCC already provides tools to check zone quality, and also checks the quality of delegations when you add or change reverse DNS configuration. Without actual evidence that there is a real problem that harms the user experience, anything else seems pointless. -- Shane
* Shane Kerr:
Which servers are supposed to be seeing increased traffic? The parent servers should have exactly the same number of queries.
Some recursors will consult the parent again, before the TTL expires, to check if the delegation has changed. This seems to happen when a referral returns only unreachable name servers. (When using DNSSEC, this is also the only way to recover from a spoofed referral.) I'm torn about the current lameness notifications. Even in the current form, they helped us to catch a rather embarrassing error. But I think the notifications should be based on current data, and the they should contain more information (timestamps, types of probes and responses). -- Florian Weimer <fweimer@bfk.de> BFK edv-consulting GmbH http://www.bfk.de/ Kriegsstraße 100 tel: +49-721-96201-1 D-76133 Karlsruhe fax: +49-721-96201-99
Shane,
Is there any support for disabling lameness checks for reverse DNS?
given that these warnings have just started being sent out, I believe such a drastic action is premature. As a matter of history, RIPE-400 <http://www.ripe.net/ripe/docs/ripe-400.html> was published in January 2007. The NCC had planned to start sending notifications mid 2008, but that was postponed partly due to "the" bug. In October 2008, a random sample was targeted with earlier attempts of the notifications, after which at the end of February this year, the first full run was executed.
1. It seems that they cause some annoyance to administrators.
I guess Wilfried has already kindly volunteered in public to collect some feedback to be able to quantify and qualify "seems" and "annoyance". Of course, the messages shouldn't be annoying, but it might just be that text can be improved.
2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS).
RFC 4697 is but one source of experiences with 3rd party annoyances caused by lame delegations.
These two things suggest to me that the pro-active lameness checks should be disabled, at least until it is shown that lameness actually causes problems.
I haven't seen reports of a desastrous failure. In the spirit of constructive discussion, could we give the NCC a chance to report experiences, collect feedback and improve the service when and where necessary? It's only been about four weeks. Regards, Peter
On 28.03.09 19:55, Shane Kerr wrote:
Is there any support for disabling lameness checks for reverse DNS?
1. It seems that they cause some annoyance to administrators.
2. As far as I know there has never been a study showing improvement for DNS users based on removing lameness in reverse DNS (or in any DNS).
These two things suggest to me that the pro-active lameness checks should be disabled, at least until it is shown that lameness actually causes problems.
It would be satisfying for me if those would go to the e-mail: addresses, since they seem to go to changed: addresses. In our company, different people care about DNS and RIPE, the RIPE contacts are making changes according to our requests, but notices are going to them, no to us.... -- Matus UHLAR - fantomas, uhlar@fantomas.sk ; http://www.fantomas.sk/ Warning: I wish NOT to receive e-mail advertising to this address. Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu. They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin, 1759
participants (6)
-
B C -
Florian Weimer -
Joe Abley -
Matus UHLAR - fantomas -
Peter Koch -
Shane Kerr