Re: dns authority changes and lame servers
On Friday 19 October 2007 01:03, Paul Vixie wrote: i agree that it's something BIND should do, to be comprehensive. if someone is excited enough about this to consider sponsoring the work, please contact me ([EMAIL PROTECTED]) to discuss details. Sounds like a really bad idea to me. The original problems sound like management issues mostly. Why are they letting customers who don't understand DNS update their NS records, and if they do, why is it a problem for them (and not just the customer who fiddled and broke stuff). Similarly we'll provide authoritative DNS for a zone as instructed (and paid for), even if it isn't delegated, if that is what the customer wants. For as long as one doesn't mix authoritative and recursive servers, it matters not a jot what a server believes it is authoritative for, only what is delegated. Hence one can't graph the mistakes as one would have to be psychic to find them. Perhaps they need to provide DNS status reports to clients, so the clients know if things are misconfigured? Monitoring/measuring is the first step in managing most things. But I think far more important to find and fix what is broken, than to try and let the machines prune it down when something is wrong, although I guess breaking things that are misconfigured is a good way to get them fixed ;)
RE: dns authority changes and lame servers
1) Does anyone else find this flaw in the DNS system as annoying as I do? If authority is to be regularly moved around between ISPs (who may be hosting thousands As an operator of both free and paid DNS services, I wish there was a quick and easy way to pull a list of all of the zones that were delegated to a specific IP address. I say IP because people can now register their own DNS name servers at the registrar and use our IP addresses, so using the official hostname isn't even fool-proof. Being able to pull such an official list for forward DNS zones would certainly make life easier. We also have home-grown scripts that figure out whether a domain is delegated to us or not and flag the ones that aren't. In the case of the free service we flag them for two weeks and if they still aren't delegated to us after that period we disable them on the DNS servers but leave the domain in their account. In the case of the paid service we make a note of the status in the database but do not make any changes to the account (they're paying us, after all, to have it there). We don't do recursive lookups so it's not an issue (even though it's technically an RFC violation, if I remember correctly). I suppose the problem with having an official list to query would be getting all of the various registries to participate and keep it regularly updated. I personally qualify this as a slight inconvenience, but I'm not sure I would call it a flaw in the DNS system. -Justin Scott
Re: dns authority changes and lame servers
This report used to be quite useful in that regard: http://www.cymru.com/DNS/lame.html Perhaps Rob needs a coffee injection to get that going again? (BTW: Need/want some more of our famous Colo Blend Mr. Thomas?) --chuck
Re: dns authority changes and lame servers
Justin Scott wrote: I suppose the problem with having an official list to query would be getting all of the various registries to participate and keep it regularly updated. I personally qualify this as a slight inconvenience, but I'm not sure I would call it a flaw in the DNS system. If we just call DNS a distributed database, then it is easy to see that when the keys (glue at root) get updated, the relations to those keys *should* all reflect that change. The flaw is that the system creates cruft almost continuously. I'd love to see a graph of the cruft on a global scale, because I'm positive that over time it is growing (though in ways that are not always operationally impactful since most of it will be dead and abandoned zones still sitting in our named.conf). And I'll admit, I'm not sure how to properly fix it either. My first thought was a BIND directive to expire-stale-zones interval; so that every interval the server might check to be sure it is still auth, and if it has found authority changed, would stop giving out AAs for it. But I see all kinds of operational issues arising from that too (such as, how do we gracefully setup new customer's zone before it has transitioned here). Really, in my ideal Internet, once my server was notified that it was no longer authoritative, it would have an option to do a reverse xfer to the new auth servers (who would then be free to accept/reject the old information as necessary - can't count the number of times I've tried to get customers to provide zone file records in advance and failed because they don't know how/where to get them from). But that's an ideal Internet that will never exist, I know.
Re: dns authority changes and lame servers
Hi, Chuck! This report used to be quite useful in that regard: http://www.cymru.com/DNS/lame.html Perhaps Rob needs a coffee injection to get that going again? Oh, my, I'd totally forgotten about that report. I do need to get that going again. I'll dig around now to see what we can produce in short order. (BTW: Need/want some more of our famous Colo Blend Mr. Thomas?) That was some of the best joe I've had, and I'd welcome another batch! Just don't tell the rest o' Team Cymru about it - it's mine, all mine! Muahaha! :) Thanks! Rob. -- Rob Thomas Team Cymru http://www.cymru.com/ cmn_err(do_panic, Out of coffee!);
Re: dns authority changes and lame servers
Justin Scott wrote: As an operator of both free and paid DNS services, I wish there was a quick and easy way to pull a list of all of the zones that were delegated to a specific IP address. I say IP because people can now register their own DNS name servers at the registrar and use our IP addresses, so using the official hostname isn't even fool-proof. Being able to pull such an official list for forward DNS zones would certainly make life easier. How annoying or frustrating is it for people? Is it so annoying that you'd be willing to pay for a list of every public-facing NS record pointed at a given IP? I should also mention the related work starting over here: http://www.nanog.org/mtg-0710/presentations/Vixie-lightning.pdf -David
RE: dns authority changes and lame servers
How annoying or frustrating is it for people? Is it so annoying that you'd be willing to pay for a list of every public-facing NS record pointed at a given IP? Nope. As I mentioned earlier, I qualify this as a minor inconvenience on the servers that I manage. It may be for someone who manages more zones than I do though. -Justin Scott
Re: dns authority changes and lame servers
Justin Scott wrote: We also have home-grown scripts that figure out whether a domain is delegated to us or not and flag the ones that aren't. In the case of the free service we flag them for two weeks and if they still aren't delegated to us after that period we disable them on the DNS servers but leave the domain in their account. In the case of the paid service we make a note of the status in the database but do not make any changes to the account (they're paying us, after all, to have it there). We don't do recursive lookups so it's not an issue (even though it's technically an RFC violation, if I remember correctly). We use home-grown scripts to follow the NS trail and verify that we are listed in some form or fashion. If we aren't, we handle the problem based on the criteria. If the domain is listed elsewhere, we immediately remove and notify. If the domain isn't listed in TLD, we notify yet hold the domain for I think 30 days before removing it; unless the status changes. Jack
Re: dns authority changes and lame servers
[EMAIL PROTECTED] (David Ulevitch) writes: I should also mention the related work starting over here: http://www.nanog.org/mtg-0710/presentations/Vixie-lightning.pdf indeed. while i don't have even a tenth of the analysis expertise of someone like robt, wessels, florian, or april, i am most assurely going to gather the raw data and make it available to those folks and similar folks. (noting that i've got 5Mbit/sec now and am hoping for 1000X that much a year from now, and noting that robt, wessels, florian, april, paul laudanski, and jeff chan have already got dedicated or shared hosts connected to the rebroadcast switch, and that more are welcome.) we may yet publish a top-500-domains web page, since that's a fairly easy thing to build using this raw data. current zonecuts, and nameserver name or address deltas, may also come from us, though i think it'll come sooner from wessels, april, or florian. if you're not submitting data yet, i hope you'll decide to do so, and drop me some e-mail ([EMAIL PROTECTED]) to discuss details. -- Paul Vixie
Re: dns authority changes and lame servers
On Thu, 18 Oct 2007, Jack Bates said: We use home-grown scripts to follow the NS trail and verify that we are I do something similar with a nagios plugin (perl script). It reports lameness and serial mismatch. I've put it online here: http://www.life-gone-hazy.com/src/nagios/check_zone_auth Duane W.
Re: dns authority changes and lame servers
The correct way to change a delegation is to: * add the new servers as stealth servers for the current zone. * if the old master is to be removed, make it a slave of the new master. * add the new NS records to the zone. * wait for all the slaves to have the new zone. * inform the parent zone of the new NS records. * wait until all the old NS RRsets have expired from caches (implies waiting for the parent's changes to propagate). * remove the old NS records from the zone. * wait for all the slaves to update. * inform the parent zone of the new NS records. * wait until all the intermediate NS RRsets have expired from caches (implies waiting for the parent's changes to propagate). * any slaves that are not being remove and that are still using the old master (or slave that is going away) need to be configured to use the new master by this point. * stop serving the zone on the old servers. Note: all through this process the namesevers listed in the NS records are answering for the zone in a consistant manner. Note: even if the parents informed you that the delegation was removed you still have to wait for the records to expire from caches *before* you can stop serving the zone. One can collapse the above slightly by informing the parent of the final NS RRset, rather than the intermediate NS RRset, but that won't work with registrars that check the childs NS RRset. One way to get around this would be to charge a cleanup fee that only gets charged when the client fails to notify you in advance that they are going change delegations. Mark
Re: dns authority changes and lame servers
[EMAIL PROTECTED] (Mike Lewinski) writes: Justin Scott wrote: I suppose the problem with having an official list to query would be getting all of the various registries to participate and keep it regularly updated. I personally qualify this as a slight inconvenience, but I'm not sure I would call it a flaw in the DNS system. If we just call DNS a distributed database, then it is easy to see that when the keys (glue at root) get updated, the relations to those keys *should* all reflect that change. ... And I'll admit, I'm not sure how to properly fix it either. My first thought was a BIND directive to expire-stale-zones interval; so that every interval the server might check to be sure it is still auth, and if it has found authority changed, would stop giving out AAs for it. But I see all kinds of operational issues arising from that too (such as, how do we gracefully setup new customer's zone before it has transitioned here). as duane said, it's possible to accomplish this with creative nagios plugins. however, i agree that it's something BIND should do, to be comprehensive. if someone is excited enough about this to consider sponsoring the work, please contact me ([EMAIL PROTECTED]) to discuss details. Really, in my ideal Internet, once my server was notified that it was no longer authoritative, it would have an option to do a reverse xfer to the new auth servers (who would then be free to accept/reject the old information as necessary - can't count the number of times I've tried to get customers to provide zone file records in advance and failed because they don't know how/where to get them from). But that's an ideal Internet that will never exist, I know. it's because we didn't know exactly how to scope this problem that RFC 2136 does not permit the insertion or deletion of authority zones. noting that the ideal internet you want is within our grasp if we can only define it and sponsor it, i recommend taking up this thread on [EMAIL PROTECTED] or [EMAIL PROTECTED] -- Paul Vixie
