Re: help with BIND SRV
On Thu, Oct 07, 2004 at 08:23:31PM -0600, Nate Duehr wrote: Most people setting up round-robin DNS type setups for redundancy with scripts to change things for failover get bit by these things: [...] - They don't understand that there might be multiple DNS servers between their top-level and the machine they're servicing (3X and 4X TTL) RFC 1035 specifies in chapter 6.1.3. that requests served from a cache should return a TTL which has been decremented by the amount of seconds in cache, i.e. the TTL counts down in the cache. Therefore I consider any caching nameservers that do not do this broken. Are there a significant amount of such servers out there? Though I agree on most of the other points. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
Juha-Matti Tapio wrote: On Thu, Oct 07, 2004 at 08:23:31PM -0600, Nate Duehr wrote: Most people setting up round-robin DNS type setups for redundancy with scripts to change things for failover get bit by these things: [...] - They don't understand that there might be multiple DNS servers between their top-level and the machine they're servicing (3X and 4X TTL) RFC 1035 specifies in chapter 6.1.3. that requests served from a cache should return a TTL which has been decremented by the amount of seconds in cache, i.e. the TTL counts down in the cache. Therefore I consider any caching nameservers that do not do this broken. Are there a significant amount of such servers out there? Though I agree on most of the other points. Ahh... it's a trap. Think about this. 1 - Regular DNS server hosting something.com 2 - ISP's caching nameserver 3 - Your company's nameserver 4 - A caching nameserver on your desktop machine Now... add in here that let's say your company AND your ISP intercept all port 53 traffic and proxy all DNS requests through both of their servers. Not super-common -- but there ARE organizations and ISP's out there that do this for whatever convoluted security or other reasons. Depending on how the proxying is set up, each server can 100% implement the RFC you mention and a change on server 1 to a record that's cached on your local desktop machine's nameserver will take 3X TTL to show up at your desktop! (It also means that if machine 1 or one of the other NS's for that zone doesn't answer at all, it's 3X TTL to clear the negative cache also.) This of course, is NOT the norm -- but it's out there. (Think service providers and highly secured networks. I believe AOL's DNS implementation had this multiply-cascaded DNS server proxying problem for many years, but they cleaned it up in the mid-1990's.) People forget this type of setup is out there when they set their TTL times for quick changes. Of course, more common is: 1 - Machine hosting something.com 2 - Caching nameserver on your desktop that's allowed to make direct connections out port 53 to the world In that scenario, TTL's work as expected. Another common setup: 1 - Machine hosting something.com 2 - Company nameserver 3 - Your desktop machine NOT running a caching nameserver, just a resolver. Again, normal behaviour. Once during some re-IP'ing activities for a customer when I was working for a co-location/hosting company, we had an agreeable customer who wanted to make some IP addressing changes, and who would also work with me as the DNS guy to help him through his transition. Because he was very paranoid about the move, we actually set him up with dual-IP's for every box he had during the transition period, and then made the DNS changes. We found from looking at his server logs that there were still broken DNS servers and resolvers out there hitting the old IP addresses for 5 days. In this particular case, his TTL was set to 1 day. Hopefully that gives a better indication of how many layers or how many truly-broken DNS resolvers and server setups there are out there. With his TTL's at a very reasonable 1 Day, it still took a business-week to see all his traffic move over to the new IP's. Another week later we reclaimed the extra IP's and shut down the subinterfaces on his systems, and killed the routes -- at that point there was virtually no traffic hitting the old IP range, but the number was still not at zero. Of course if there is no negative cache entry for the zone anywhere, the fool-proof method of changing things is to provide a completely new A record name that has never been used before in your zone. That forces a lookup all the way back to your servers, and thus -- the freshest IP information. One way I've seen this effect used very effectively during a site move was that the company reissued the zone data immediately with their www.something.com record changed and also a new new.something.com A record both pointing at the new address. Then they set up a server at the old location that did nothing but have a redirect page from www to new. They then took the big server across town and plugged it in at the IP new pointed to. Client machines that had correct information quickly just went to www at the new address. Lagging machines and broken DNS architectures hit www at the old address and were redirected to new. Of course, this customer had to be careful about not using name-based virtual hosting on their webserver -- or making sure the big machine at the new site would answer correctly on both www and new. I forget which tactic they used. If you really think about the queries going on in DNS, there's plenty of ways to move things around safely without downtime -- I was always just floored when some dot.bomb company would decide to move IP's and leave nothing on the old IP, and just hope even with their 7 day or higher TTL time they'd set up long ago, that
Re: help with BIND SRV
On Thursday 07 October 2004 22:23, Nate Duehr wrote: - They don't understand that there might be multiple DNS servers between their top-level and the machine they're servicing (3X and 4X TTL) Let's say that I have my local (desktop if you prefer) resolver (which I'll call A is pointed to a caching nameserver B. Caching nameserver B forwards all of it's DNS requests to their ISP's larger caching server C. Caching server C makes queries to the appropriate authoritative server D. So the DNS query goes: A-B-C-D D replies to C with a record having TTL of 3600. C forwards request to B, B gives answer to A ... TTL 3600. In 1800 seconds the only server in the above loop that would serve a TTL of 3600 is D (since it is authoritative). B and C will both have decremented their TTL by 1800 seconds and will respond with a TTL of 1800 seconds. A should have decremented the TTL in it's resolver cache as well though some applications and/or operating systems are buggy in this regard. I have never seen behaviour that you are suggesting can happen nor can I imagine any way in which it can happen. We had a similar discussion not too long ago starting at http://www.mail-archive.com/debian-isp%40lists.debian.org/msg11986.html ... I never really followed up on that one, but I still believe you're wrong ;-) BTW, forwarding (to an appropriate server) is an excellent way to speed up DNS resolution, I use it frequently. -- Fraser Campbell [EMAIL PROTECTED] http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
Fraser Campbell wrote: On Thursday 07 October 2004 22:23, Nate Duehr wrote: - They don't understand that there might be multiple DNS servers between their top-level and the machine they're servicing (3X and 4X TTL) Let's say that I have my local (desktop if you prefer) resolver (which I'll call A is pointed to a caching nameserver B. Caching nameserver B forwards all of it's DNS requests to their ISP's larger caching server C. Caching server C makes queries to the appropriate authoritative server D. So the DNS query goes: A-B-C-D D replies to C with a record having TTL of 3600. C forwards request to B, B gives answer to A ... TTL 3600. You're talking about forwarding... like using the forwarders statement in Bind. I was talking about sites that have done it wrong (my opinion, and probably yours too - it's just not right...) so to speak, and are forcing port 53 traffic to different places than it was intended to go originally. Proxying would be the best phrase I could call it. Some commercial active firewall implementations do something similar. Nate -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
On Friday 08 October 2004 15:01, Nate Duehr wrote: I was talking about sites that have done it wrong (my opinion, and probably yours too - it's just not right...) so to speak, and are forcing port 53 traffic to different places than it was intended to go originally. So? If DNS requests are all redirected to a valid DNS server how would that result in bogus TTLs? Proxying would be the best phrase I could call it. Some commercial active firewall implementations do something similar. Perhaps you can point me at a DNS server that when queried for a non-authoritative answer does not lower TTL (within TTL period) on subsequent requests? If the problem that you describes does exist then it must be very rare, or really old and broken software. I still hear about people running their email system through mailgate on Windows 98 with dialup, at a certain point you just have to tell those people to get with the program. -- Fraser Campbell [EMAIL PROTECTED] http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
--Wednesday, October 06, 2004 21:28:10 -0700 Richard A Nelson [EMAIL PROTECTED]: On Wed, 6 Oct 2004, August MacBeth wrote: [...] Your next best bet is to probably rely on DNS round-robin and define a few addresses for your ftp server... Any decent client/server DNS will rotate the addresses automagically. With probably somewhat unpredictable results. Think IP-caching clients or OSs, caching nameservers... You have no real influence on the balacing and for failover it's worse. Cheers, Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
Thank you both for your replies. I've considered setting up a round-robin pool, but the host caching is the part i don't like. It seems like whatever i set the TTL to, windows 2000 cache's the address untill the next time i manually flush the dns cache. Surprisingly, Mac OSX (unix based) cache's DNS as well, which bum's me out. ~august * Marcel Hicking [EMAIL PROTECTED] |__ Thu, Oct 07, 2004 at 11:25:23AM +0200: --Wednesday, October 06, 2004 21:28:10 -0700 Richard A Nelson [EMAIL PROTECTED]: On Wed, 6 Oct 2004, August MacBeth wrote: [...] Your next best bet is to probably rely on DNS round-robin and define a few addresses for your ftp server... Any decent client/server DNS will rotate the addresses automagically. With probably somewhat unpredictable results. Think IP-caching clients or OSs, caching nameservers... You have no real influence on the balacing and for failover it's worse. Cheers, Marcel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- August MacBeth Systems Administrator HiP Design 824 N. Victory Blvd Suite 2A Burbank, CA 91502 http://www.hipdesign.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
On Thursday 07 October 2004 13:20, August MacBeth wrote: cache. Surprisingly, Mac OSX (unix based) cache's DNS as well, which bum's me out. That is surprising. Are you saying that Mac OSX caches the DNS permanently and/or for longer than the TTL supplied by Bind? -- Fraser Campbell [EMAIL PROTECTED] http://www.wehave.net/ Georgetown, Ontario, Canada Debian GNU/Linux -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
Fraser Campbell wrote: On Thursday 07 October 2004 13:20, August MacBeth wrote: cache. Surprisingly, Mac OSX (unix based) cache's DNS as well, which bum's me out. That is surprising. Are you saying that Mac OSX caches the DNS permanently and/or for longer than the TTL supplied by Bind? No. It doesn't. Most people setting up round-robin DNS type setups for redundancy with scripts to change things for failover get bit by these things: - They don't REALLY understand TTL - They don't understand that there might be multiple DNS servers between their top-level and the machine they're servicing (3X and 4X TTL) - They don't understand negative caching and how important it is to ALWAYS answer DNS queries. - They don't understand that some implementations of resolvers will refuse to update quickly if the TTL is set very very low -- and will cache for longer than the TTL time. (But OSX doesn't do this, as far as I can tell.) - They don't understand that it can take a very long time to fail-over when you factor in all of the above. DNS with low TTL times and the ability to be changed on the fly is really good for a secondary physical SITE, but in terms of server failover, virtual IP type solutions work much much better. Some really nifty solutions I've seen are the hardware load-balancers that publish all the SITES as round-robin'ed DNS entries and change on-the-fly to remove entries when a site isn't responding, while the load-balancer is actually the front-man for multiple servers at that location, with a single virtual IP on the front-side. Decent amount of redundancy in that setup, and still relatively cheap -- you don't HAVE to do that with a hardware load balancer, you can do that with IP takeover services and two single boxes that can individually handle all the load by themselves. At the point a single box can't do the job, it's a good idea to weigh the cost of hardware against having one box always doing nothing... although you could use it for cronjobs and things that would bog down the other box... DB cleanup, etc... Lots of options, always. -- Nate Duehr, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
Richard, thanks for your reply. I must have missed the section about how 'most' software doesn't support SRV (http://dns.vanrein.org/srv/tools/).. It seems like an incredible idea to me however, are there any alternatives you could suggest? I'm after some kind of software load balancing / fault tolerance.. thanks, ~august * Richard A Nelson [EMAIL PROTECTED] |__ Tue, Oct 05, 2004 at 06:42:58PM -0700: On Tue, 5 Oct 2004, August MacBeth wrote: server# host ftp3.domain.net server# telnet ftp3.domain.net 21 telnet: could not resolve ftp3.domain.net/21: No address associated with hostname server# I've tried changing around the format of the RR, but nothing seems to have an effect.. here's an example of my current setup: [...] host1 A 12.123.12.15 ftp CNAME host1 ftp2A 12.123.12.14 _ftp._tcp.ftp3SRV1 0 21 ftp _ftp._tcp.ftp3SRV2 0 21 ftp2 hrm, is the final '.ftp3' required ? Mine don't have it (but I don't have a client that supports SRV either). Does your client surely know about SRV records ? -- Rick Nelson But what can you do with it? -- ubiquitous cry from Linux-user partner. (Submitted by Andy Pearce, [EMAIL PROTECTED]) -- August MacBeth Systems Administrator HiP Design 824 N. Victory Blvd Suite 2A Burbank, CA 91502 http://www.hipdesign.com -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
On Wed, 6 Oct 2004, August MacBeth wrote: thanks for your reply. I must have missed the section about how 'most' software doesn't support SRV (http://dns.vanrein.org/srv/tools/).. It seems like an incredible idea to me however, are there any alternatives you could suggest? I'm after some kind of software load balancing / fault tolerance.. Yes, a very unfortunate issue - as SRV would handle balancing, failover, etc. :( Your next best bet is to probably rely on DNS round-robin and define a few addresses for your ftp server... Any decent client/server DNS will rotate the addresses automagically. If you need more, there are some Debian packages to handle balancing - but I've not yet had the need to investigate them; my setup is small. -- Rick Nelson As you journey through life take a minute every now and then to give a thought for the other fellow. He could be plotting something. -- Hagar the Horrible -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: help with BIND SRV
On Tue, 5 Oct 2004, August MacBeth wrote: server# host ftp3.domain.net server# telnet ftp3.domain.net 21 telnet: could not resolve ftp3.domain.net/21: No address associated with hostname server# I've tried changing around the format of the RR, but nothing seems to have an effect.. here's an example of my current setup: [...] host1 A 12.123.12.15 ftp CNAME host1 ftp2A 12.123.12.14 _ftp._tcp.ftp3SRV1 0 21 ftp _ftp._tcp.ftp3SRV2 0 21 ftp2 hrm, is the final '.ftp3' required ? Mine don't have it (but I don't have a client that supports SRV either). Does your client surely know about SRV records ? -- Rick Nelson But what can you do with it? -- ubiquitous cry from Linux-user partner. (Submitted by Andy Pearce, [EMAIL PROTECTED]) -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
