From pk at TechFak.Uni-Bielefeld.DE Tue Jun 15 18:01:48 2004 From: pk at TechFak.Uni-Bielefeld.DE (Peter Koch) Date: Tue, 15 Jun 2004 18:01:48 +0200 Subject: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Your message of "Tue, 15 Jun 2004 16:56:47 +0200." <20040615.165647.08709970.he@uninett.no> Message-ID: <200406151601.i5FG1m605126@grimsvotn.TechFak.Uni-Bielefeld.DE> Hello, {I'm copying this to the DNS wg list, since the protocol issues may probably be better discussed there. Hey, I *love* these [tags] :-(} [address allocation for anycast of DNS nameservers] Havard Eidnes wrote: > > ------------ snip ------------ > > "Operators providing DNS for a zone served by a number of name servers > > such that the total response size when including the list of > > nameservers for the zone is close to the UDP packet size limit may > > Hm, it's not "the UDP packet size limit", it is "the packet size limit > for DNS over UDP without the application of EDNS.0". I may not have > followed things too closely, but it makes me sort of wonder why a push towards EDNS.0 is not being advocated instead of polluting the routing > space to compensate for people who have not yet upgraded their > software... Of course, people may still dream up configurations which Isn't then the parent of those trying to do anycast suffering from those resolvers unaware of EDNS0? In other words: what could the applicant do? -Peter From jim at rfc1035.com Tue Jun 15 19:18:51 2004 From: jim at rfc1035.com (Jim Reid) Date: Tue, 15 Jun 2004 18:18:51 +0100 Subject: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: Message from Peter Koch of "Tue, 15 Jun 2004 18:01:48 +0200." <200406151601.i5FG1m605126@grimsvotn.TechFak.Uni-Bielefeld.DE> Message-ID: <7970.1087319931@gromit.rfc1035.com> Not having seen the whole discussion thread, it's a bit hard to make sense of what's been said. However it appears to be that someone is saying that the need for anycasting (and more specifically special address allocations for anycast name servers) can be discounted if ENDS0 was more widely used. This is a flawed argument IMO. As Peter has said, resolvers that aren't EDNS0-aware will still be pounding on the parent zone's name servers. [They're also much more likely to be the resolvers that are misconfigured to go to the root to reverse lookup RFC1918 addresses, don't implement negative caching and so on....] Simply adding more NS records and glue in the parent zone's delegation for a child zone is no help. For one thing, most name server implementations have a limit on the number of name servers they can handle for a delegation. Adding extra NS records is even less help when those servers have IPv6 addresses => yet bigger DNS payloads. In fact adding extra servers and/or IPv6 addresses may be worse because there's an increased likelihood of truncated responses getting sent to these non-EDNS0 resolvers, resulting in retried queries over TCP. Nasty. Aside from these DNS protocol issues, there are plenty of other good reasons for deploying anycasting for important DNS infrastructure. That's why lots of the root and TLD name server operators are doing this already. Ironically, these include the NCC's root name server. Anycasting provides increased robustness, extra redundancy, improved performance, better scalability, extra capacity/throughput, defence in depth from DDoS attacks, etc, etc. Anycasting isn't going to go away even if all the world's DNS software implemented EDNS0. Anycasting is a fact of life. And it will become more prominent in future. So if the address policy WG is reluctant to endorse special address allocations for DNS anycasting, I'd ask them to reconsider. If it helps, we could ask the DNS WG to discuss the issue and perhaps make a recommendation to the address policy WG. From Joao_Damas at isc.org Wed Jun 16 16:38:01 2004 From: Joao_Damas at isc.org (Joao Damas) Date: Wed, 16 Jun 2004 16:38:01 +0200 Subject: [dns-wg] Re: [address-policy-wg] Policy Change Request - Allow address allocations for anycast DNS operation In-Reply-To: <7970.1087319931@gromit.rfc1035.com> References: <7970.1087319931@gromit.rfc1035.com> Message-ID: wow, that was a dense mail, at least it's formatting :-) Just wanted to add, since there was a question about promoting the deployment of EDNS0, that some of us do indeed try to work on that line because it would make some matters simpler (eg. adding v6 glue without fear, having more root servers if needed, etc). DNSSEC requires the use of EDNS0 so maybe some people will migrate if DNSSEC takes off. Currently, some of us monitor the amount of queries using ENDS0 that reach the servers we operate. At least on F root this figure is more or less stable between 30-40% One thing to keep in mind is that there are products shipping today which are based on some version of BIND4, for instance, so they support DNS as it was known in the BIND 4 days. Although we have approached some of the manufacturers, they can't just "transition" in a short time. In the meantime life goes on and there is a need to cope with a growing Internet. Hope this helps clarify things a bit Joao On 15 Jun, 2004, at 19:18, Jim Reid wrote: > Not having seen the whole discussion thread, it's a bit hard to make > sense of what's been said. However it appears to be that someone is > saying that the need for anycasting (and more specifically special > address allocations for anycast name servers) can be discounted if > ENDS0 was more widely used. This is a flawed argument IMO. As Peter > has said, resolvers that aren't EDNS0-aware will still be pounding on > the parent zone's name servers. [They're also much more likely to be > the resolvers that are misconfigured to go to the root to reverse > lookup RFC1918 addresses, don't implement negative caching and so > on....] Simply adding more NS records and glue in the parent zone's > delegation for a child zone is no help. For one thing, most name > server implementations have a limit on the number of name servers they > can handle for a delegation. Adding extra NS records is even less help > when those servers have IPv6 addresses => yet bigger DNS payloads. In > fact adding extra servers and/or IPv6 addresses may be worse because > there's an increased likelihood of truncated responses getting sent to > these non-EDNS0 resolvers, resulting in retried queries over TCP. > Nasty. > > Aside from these DNS protocol issues, there are plenty of other good > reasons for deploying anycasting for important DNS infrastructure. > That's why lots of the root and TLD name server operators are doing > this already. Ironically, these include the NCC's root name server. > Anycasting provides increased robustness, extra redundancy, improved > performance, better scalability, extra capacity/throughput, defence in > depth from DDoS attacks, etc, etc. Anycasting isn't going to go away > even if all the world's DNS software implemented EDNS0. Anycasting is > a fact of life. And it will become more prominent in future. > > So if the address policy WG is reluctant to endorse special address > allocations for DNS anycasting, I'd ask them to reconsider. If it > helps, we could ask the DNS WG to discuss the issue and perhaps make a > recommendation to the address policy WG. > From jim at rfc1035.com Thu Jun 24 21:03:04 2004 From: jim at rfc1035.com (Jim Reid) Date: Thu, 24 Jun 2004 20:03:04 +0100 Subject: [dns-wg] IANA proposal for changing TLD delegations Message-ID: <1EEABF6D-C611-11D8-B778-000393A6DACE@rfc1035.com> IANA has published a proposal on how it plans to deal with changes in the root zone for TLD delegations. It's at http://www.iana.org/procedures/delegation-data.html. I would recommend that people read this and comment on it. TLD owners in particular might want to pay special attention to the part headed "IANA Procedures for Removing Problematic Delegation Data ". Unfortunately the closing date for comments was June 21st -- I've only just seen this document. However a revised version is promised for June 28th, so there may still be an opportunity to comment on the current one. From jaap at sidn.nl Fri Jun 25 00:53:07 2004 From: jaap at sidn.nl (Jaap Akkerhuis) Date: Fri, 25 Jun 2004 00:53:07 +0200 Subject: [dns-wg] IANA proposal for changing TLD delegations In-Reply-To: Your message of Thu, 24 Jun 2004 20:03:04 +0100. <1EEABF6D-C611-11D8-B778-000393A6DACE@rfc1035.com> Message-ID: <200406242253.i5OMr8AY025082@bartok.sidn.nl> Unfortunately the closing date for comments was June 21st -- I've only just seen this document. However a revised version is promised for June 28th, so there may still be an opportunity to comment on the current one. During a ISOC ccTLD wokshop late weekend, public statements have been made that, although there is a closing date, comments coming after the date wil still be taken in consideration. So, don't wait until June 28th. jaap From brad.knowles at skynet.be Fri Jun 25 01:06:39 2004 From: brad.knowles at skynet.be (Brad Knowles) Date: Fri, 25 Jun 2004 01:06:39 +0200 Subject: [dns-wg] IANA proposal for changing TLD delegations In-Reply-To: <1EEABF6D-C611-11D8-B778-000393A6DACE@rfc1035.com> References: <1EEABF6D-C611-11D8-B778-000393A6DACE@rfc1035.com> Message-ID: At 8:03 PM +0100 2004-06-24, Jim Reid wrote: > IANA has published a proposal on how it plans to deal with changes in > the root zone for TLD delegations. It's at > http://www.iana.org/procedures/delegation-data.html. I read the proposal on the web page. Except for their complete lack of discussion of things like IPv6, DNSSEC, etc..., I don't see anything specifically and obviously wrong with what they've got. Everything seems, more or less, fairly reasonable. Do you have some specific comments/views on the proposal? If so, could/would you be willing to share them with us? -- Brad Knowles, "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. SAGE member since 1995. See for more info. From jim at rfc1035.com Fri Jun 25 01:43:15 2004 From: jim at rfc1035.com (Jim Reid) Date: Fri, 25 Jun 2004 00:43:15 +0100 Subject: [dns-wg] IANA proposal for changing TLD delegations In-Reply-To: Message from Brad Knowles of "Fri, 25 Jun 2004 01:06:39 +0200." Message-ID: <24799.1088120595@gromit.rfc1035.com> >>>>> "Brad" == Brad Knowles writes: >> http://www.iana.org/procedures/delegation-data.html. Brad> I read the proposal on the web page. Except for their Brad> complete lack of discussion of things like IPv6, DNSSEC, Brad> etc..., I don't see anything specifically and obviously Brad> wrong with what they've got. Everything seems, more or Brad> less, fairly reasonable. Brad> Do you have some specific comments/views on the Brad> proposal? If so, could/would you be willing to share them Brad> with us? Well the section "IANA Procedures for Removing Problematic Delegation Data" suggests to me that IANA may unilaterally decide to change the delegation of a TLD without the consent of the TLD operator. And it's not at all clear what circumstances and criteria would prevail for IANA to justify taking that action. Not that this practice can ever be justified IMO. IANA can't possibly know what the best or correct name servers for some TLD will be. By definition only the TLD operator can decide that. I'm rather surprised that nobody seems to think this is part of the proposal could be more than a little controversial. And if IANA starts changing the root zone whenever it feels like doing so -- OK I exaggerate for effect -- that sets a very dangerous precedent. When it comes to the root zone, IANA must only act as the registry. It must always be someone/something else that decides what goes in the root zone. Of course this doesn't preclude IANA from checking delegations and making recommendations about changes. But there must be a seperate role that has the responsibility of instructing IANA to make changes to the root zone. IANA must not have that authority itself. Perhaps this section of the proposal is just badly written? However I fear it's badly thought out instead. From schneider at switch.ch Mon Jun 28 09:14:30 2004 From: schneider at switch.ch (Marcel Schneider) Date: Mon, 28 Jun 2004 09:14:30 +0200 Subject: [dns-wg] IANA proposal for changing TLD delegations In-Reply-To: Message from Jim Reid of "Thu, 24 Jun 2004 20:03:04 +0100." <1EEABF6D-C611-11D8-B778-000393A6DACE@rfc1035.com> References: <1EEABF6D-C611-11D8-B778-000393A6DACE@rfc1035.com> Message-ID: <12020.1088406870@switch.ch> On Thursday, 24 Jun 2004, Jim Reid writes: > IANA has published a proposal on how it plans to deal with changes in > the root zone for TLD delegations. It's at > http://www.iana.org/procedures/delegation-data.html. > I would recommend that people read this and comment on it. TLD owners > in particular might want to pay special attention to the part headed > "IANA Procedures for Removing Problematic Delegation Data ". We have been checking the document before and found nothing to worry about. The part you are referring to deals with restoring the DNS in case of emergency. The title is of course not well chosen - it could be interpreted in different ways, as suggested by Jim, but the measures are sound. Marcel