Re: [DNSOP] AS112 for TLDs
Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, "boutique" TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's ".local"), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is one of the newest. In fact if as per the ICANN blog this data was collected on November 26 then it would of come from IP 199.7.83.42 that was implemented on 1 November 2007 and replaced the previous IP address of 198.32.64.12. http://l.root-servers.org/ip-change-26nov07.htm The data is unclear if it was collected from 199.7.83.42 or 198.32.64.12. In any case what is certain is that both versions of the L.root run by ICANN are very new and that means the amount of traffic to them would be very low in comparison to f.root - which in my opinion provides a more accurate reflection of traffic patterns on the net. So in conclusion is this data in any way reflective of the impact of Karl, "boutique" TLDs? The answer in this case would be NO. It is however reflective of the data one would associate with a recently launched root server that few people are yet dependent on. Hope my comments help you interpret the data. kindest regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
John Crain wrote: Hi Joe, It is exactly reflective of traffic as seen at l.root-servers.net and measured by DSC. there is no trickery, plots or evil schemes involved. Shame that your paranoia gets the better of you;) Your right. There is no trickery, plots or evil schemes involved. I misspoke in the message to the GA. The only one misleading us using the data was stephane and I doubt that was intentional. We are having a discussion concerning TLDs there and the data was used to make a point, which on reflection does not exist due to the particulars made in my reply. Those are percentages not queries indeed. Total queries varies between 8Kq/s and 10Kq/s on a normal day. So you can do the math if you really want to see it by q/s. Also it only shows the TOP scores, not all TLDs. For clarity: The data is from both current and old IPv4 addresses (Across all instances of L) I know - in both cases recent deployments of a root server. It would be very beneficial to see this data across the other roots for comparison. As I have said the L.root is not reflective of the overall traffic patterns to all the roots as L is a very new instance of a root, either old or new IPv4 address. Incidentally - just how much traffic is this representative of? How many queries came in during the period the data was captured? Thanks for the clarification. regards joe baptista regards joe baptista I have already spoken to CAIDA about supplying them with L-root data for future projects and we will be taking part in their "day in the life of" project so you should see L-root included in their future analysis. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 08:07, Joe Baptista wrote: Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, "boutique" TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's ".local"), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/ dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages. This data was obtained from f.root. f.root is one of the oldest roots on the net while l.root is one of the newest. In fact if as per the ICANN blog this data was collected on November 26 then it would of come from IP 199.7.83.42 that was implemented on 1 November 2007 and replaced the previous IP address of 198.32.64.12. http://l.root-servers.org/ip-change-26nov07.htm The data is unclear if it was collected from 199.7.83.42 or 198.32.64.12. In any case what is certain is that both versions of the L.root run by ICANN are very new and that means the amount of traffic to them would be very low in comparison to f.root - which in my opinion provides a more accurate reflection of traffic patterns on the net. So in conclusion is this data in any way reflective of the impact of Karl, "boutique" TLDs? The a
Re: [DNSOP] AS112 for TLDs
John Crain wrote: Hi Joe. I didn't do the math, I was using DSC. I'm sure I could figure it out with some DSC tweaking... However with beign completely unscientific and measuring rates averaging from 8kq/s (low) to 10kq/s (high) over a 24hr period it's between 691.2 million and 864 million queries. So a fairly big sample.. I would estimate that it is somewhere inbetween at about 750 million. Interesting. Just doing some more estimating - what percentage of those queries, or how are they divided between the old and new IP. regards joe baptista I'll leave more in depth analysis to the likes of CAIDA, they're better at it than me. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 14:05, Joe Baptista wrote: John Crain wrote: Hi Joe, It is exactly reflective of traffic as seen at l.root-servers.net and measured by DSC. there is no trickery, plots or evil schemes involved. Shame that your paranoia gets the better of you;) Your right. There is no trickery, plots or evil schemes involved. I misspoke in the message to the GA. The only one misleading us using the data was stephane and I doubt that was intentional. We are having a discussion concerning TLDs there and the data was used to make a point, which on reflection does not exist due to the particulars made in my reply. Those are percentages not queries indeed. Total queries varies between 8Kq/s and 10Kq/s on a normal day. So you can do the math if you really want to see it by q/s. Also it only shows the TOP scores, not all TLDs. For clarity: The data is from both current and old IPv4 addresses (Across all instances of L) I know - in both cases recent deployments of a root server. It would be very beneficial to see this data across the other roots for comparison. As I have said the L.root is not reflective of the overall traffic patterns to all the roots as L is a very new instance of a root, either old or new IPv4 address. Incidentally - just how much traffic is this representative of? How many queries came in during the period the data was captured? Thanks for the clarification. regards joe baptista regards joe baptista I have already spoken to CAIDA about supplying them with L-root data for future projects and we will be taking part in their "day in the life of" project so you should see L-root included in their future analysis. John L. Crain Chief Technical Officer I.C.A.N.N. On 27 Nov 2007, at 08:07, Joe Baptista wrote: Phil Regnauld wrote: Stephane Bortzmeyer (bortzmeyer) writes: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. I'm posting the comments made to you on the GA/GNSO. Since I have pointed out to you there that this data from L.root is not very reflective of network traffic. Stephane Bortzmeyer wrote: I cannot find another report about the TLDs most often queried at a root name server. Other reports I've seen aggregated data, while this small glimpse, however partial, at least *names* the TLDs. It has been said sometimes that dummy (sorry, Karl, "boutique" TLDs) were present in requests to the root name servers. This is clearly false, all the non-existing TLDs queried are local domains (such as Apple's ".local"), leaking through a configuration error. http://blog.icann.org/?p=240 Thanks for that Stephane. It would look to me like things are getting better. This root where the data originates seems to get less errors then that reported in 2003 which data mainly came from f.root. Thats a significant improvement however after careful inspection we begin to see the flaws in this data. If this were f.root data then I would be very impressed. Because the data would show a significant decrease in error traffic. That would be amazing. In fact the data looks alot like that I have seen for public roots I have setup. Like the one now used in Turkey. However this is data from the L.root run by ICANN and i'm not so amazed anymore. I speculate this is just a little bit of ICANN nonsense designed to once again mislead the public. Shame. Now the problem as I see it here is that this data is very limited in scope. I don't dispute the first chart on popular TLDs. What i'm interested to see are the popular TLDs that result in errors (NXDOMAIN) as per the original 2003 report methodology. Next there is nothing in the data that states the number of queries received at the root servers. Only percentages are used in the metrics. The articles I wrote http://www.theregister.co.uk/2003/02/05/ dud_queries_swamp_us_internet/ show us that CAIDA conducted an analysis on 152 million messages.
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
Yes - many questions and few answer and very little data available for the community to figure out those answers. John Crain should publish stats more often. Why indeed does root behave so strangely. That little 40 percentage thingy indeed does raise alotof questions. John can you speculate for us? Whats going on. Another very interesting thing is the incredible power behind one IP number when it has experienced root activity. It only takes one rogue root to highjack the entire root system. Its been done twice now in internet history. How is that possible? regards joe baptista JINMEI Tatuya / 神明達哉 wrote: At Wed, 28 Nov 2007 10:55:44 +0100, Peter Koch <[EMAIL PROTECTED]> wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due to old hints files, but priming was actually supposed to accelerate the migration. 40% of total L traffic seems a bit much for 1/13 of the priming traffic? BIND9 also uses the root hint when it finds necessary glue is missing. For example, consider the following delegation: child.foo.example. NS 86400 ns.child.foo.example. ns.child.foo.example. A 3600 192.0.2.1 When the (recursive) resolver first visits the child.foo.example zone, it caches both the NS and A records. The glue (A) record will expire in 1 hour. When the resolver tries to visit the zone after that while still keeping the NS record, it tries to fetch the missing glue from the root using the hint file, regardless of whether it has the root NS and the root server addresses in its cache. This would be another reason for the queries to the old L-root address, though I don't think it makes the 40% of total traffic unless the vast majority of hint files aren't updated. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
[EMAIL PROTECTED] wrote: old "B" topolgy didnt change... :) hmm. very demure, and i mean that in a coyly decorous sober sort of way. i've have an ip range that had roots running on it since the days of the ORSC. those roots to this day get traffic. Lots of DNS traffic across all the range numbers used for root service. And I have taken extreme steps to drop this traffic - including interception, I basically sent all traffic to one box, and even that did not stop the traffic. Alot of programs out in the wild running on automation without any human supervision whatsoever. what is really strange is that icann and the community have not learned from this and continue to replace root IP numbers in what is a static root system. indeed very demure mr manning. cheers joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: L-Root address change [Re: [DNSOP] AS112 for TLDs]
John Crain wrote: Speculation is all it is and I probably have no better ideas than many folks here. Be better to try and figure out what is really happening... I think this is just a knock on effect from the fact that many folks don't keep their systems up to date, especially smaller networks. Typically they turn something on and just leave it until it stops working. Just like they don't update any other software if it isn't done for them automatically. That shouldn't come as a surprise to anyone. No it does not. That in fact is a big problem. I used to do scans of DNS servers over the years. And one interesting thing I have found is there are still servers out there using the very old legacy roots. When they had five root servers. I think because of the fact that what you say above is so true - people install dns and then forget it - then maybe it is time for ICANN to consider a root policy that goes something like this - to have a stable internet you don't go around changing your roots ip numbers. I look forward to more reports and data sharing from L root. But to be frank it would be alot of fun to see that same data compared to data from f.root. f.root is a true legacy root system. I think it's been around from the beginning and may be an excellent comparison to the progress of the L root fragmentation. cheers joe baptista It's nice to think that resolvers will automatically fix themselves when priming but I think the stats show this not to be solving the issue. It's too early from the L-root perspective to really see what is happening. Less than a month since renumbering, long term trends will be more interesting. We'll start to analyze some of the big hitters on the old address. Once we have some long term data I will publish something. Luckily the folks who gave us DSC made it easy for me to do just that. Big thanks to Duane and co!!! John L. Crain Chief Technical Officer I.C.A.N.N. On 28 Nov 2007, at 11:02, Joe Baptista wrote: Yes - many questions and few answer and very little data available for the community to figure out those answers. John Crain should publish stats more often. Why indeed does root behave so strangely. That little 40 percentage thingy indeed does raise alotof questions. John can you speculate for us? Whats going on. Another very interesting thing is the incredible power behind one IP number when it has experienced root activity. It only takes one rogue root to highjack the entire root system. Its been done twice now in internet history. How is that possible? regards joe baptista JINMEI Tatuya / 神明達哉 wrote: At Wed, 28 Nov 2007 10:55:44 +0100, Peter Koch <[EMAIL PROTECTED]> wrote: Currently about 60% New IP to 40% old IP... and rising slowly So clearly a lot of folks still need to up date their hints files :( part of that traffic will be due to old hints files, but priming was actually supposed to accelerate the migration. 40% of total L traffic seems a bit much for 1/13 of the priming traffic? BIND9 also uses the root hint when it finds necessary glue is missing. For example, consider the following delegation: child.foo.example. NS 86400 ns.child.foo.example. ns.child.foo.example. A 3600 192.0.2.1 When the (recursive) resolver first visits the child.foo.example zone, it caches both the NS and A records. The glue (A) record will expire in 1 hour. When the resolver tries to visit the zone after that while still keeping the NS record, it tries to fetch the missing glue from the root using the hint file, regardless of whether it has the root NS and the root server addresses in its cache. This would be another reason for the queries to the old L-root address, though I don't think it makes the 40% of total traffic unless the vast majority of hint files aren't updated. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop -- Joe Baptistawww.publicroot.org PublicRoot Consortium
Re: [DNSOP] AS112 for TLDs
Mark Andrews wrote: We should be looking at mechanisms to allow the root zone to be distributed to every iterative resolver in the world. You then don't have to use AS112 to absorb the load. The local resolver will answer the query. For the last two years we have been advocating just that. Root should be broadly distributed. But even with that AS112 would still be needed to redirect some errors. If only ICANN used AS112 to redirect bogus request they would see less of a load. Right now AS112 is mainly available to those who willing participate. Not many do. Not many know about AS112. regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: AS112 for TLDs
Paul Vixie wrote: [EMAIL PROTECTED] (Joe Baptista) writes: No it can't be done with BIND. Very lame. It would be a big asset to root technology of the entire "*." wildcard TLD label could be pointed to AS112. AS112 is truly the blackhole of this universe we call the internet. AS112 - the internet garbage can. I support using AS112 for that. Great way to reduce the error traffic at root-servers.net. wildcards can't be cname's or ns's. (of the many important reasons why the suggestion is terrible, that's the first/simplest that comes to mind.) Actually no. That is not correct. I did some experimentation using BIND 8 and 9 as root servers. BIND 8 does not support *. CNAME some.host.name. But BIND 9 does. I know it sounds terrible to you but I think the RFC is flexible on that. Your the expert - you look into it. So it would be so nice if I could under BIND 9 do: *. NS some.host.name. Paul - make it so. It would really cut down on root traffic and we could use AS112 as the garbage can of bin bucket heaven. Be a sport - push the buttons and make it so. regards joe baptista P.S. Alot of servers already wildcard *. NS back to the IANA servers. -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: AS112 for TLDs
Stephane Bortzmeyer wrote: On Wed, Dec 05, 2007 at 02:28:53AM +0100, Mohsen Souissi <[EMAIL PROTECTED]> wrote a message of 25 lines which said: OK for the first querie, but as the referal to AS112 NS's will lead to a lame delegation If the AS112 servers' configuration is not modified. But if they have some sort of wildcard themselves? (I do not think it can be done with BIND but it is possible.) No it can't be done with BIND. Very lame. It would be a big asset to root technology of the entire "*." wildcard TLD label could be pointed to AS112. AS112 is truly the blackhole of this universe we call the internet. AS112 - the internet garbage can. I support using AS112 for that. Great way to reduce the error traffic at root-servers.net. regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: AS112 for TLDs
Mark Andrews wrote: Actually no. That is not correct. I did some experimentation using BIND 8 and 9 as root servers. BIND 8 does not support *. CNAME some.host.name. Actually all versions of BIND support "* CNAME". Sorry - your right - its DNAME it does not do. But BIND 9 does. I know it sounds terrible to you but I think the RFC is flexible on that. Your the expert - you look into it. So it would be so nice if I could under BIND 9 do: *. NS some.host.name. Wildcard matching has the wrong semantics (1 vs many labels) for NS records. Even if the semantics where addressed you then have to set up nameservers to do wildcard processing while looking for the relevent zone. This implies having a copy of the parent zone so you can know what query names don't match the wildcard. Ya I know. Thats the whole point behind what i'm advocating for AS112. Those are the servers I would wildcard too. At least i would like to run the experiment. I have found some servers that do *. NS - or so i'm told by their support tech community. But not BIND. BIND should be flexible and allow that. regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Re: AS112 for TLDs
Mark Andrews wrote: It's been done. IT DOES NOT WORK. named has code to prevent the records being added because IT DOES NOT WORK and we got sick and tired of telling people who ran up against sites that did it that IT DOES NOT WORK. It's better to prevent than to spend repeated amounts of time dealing with the repercussions. Can't we make it work? I appreciate your honesty. But there are other dns packages that do allow it. I'm looking for the flexibility to extra-zone so i can manage root traffic in bind. Its obvious root get bugus traffic - i advocate a traffic can to send those bogus tlds too. I would love an AS112 stop sign. That also eliinate the legal liability to me as a commercial operator of root. It's easy to remove the checks but then you need to make sure all clients will work with the resultant mess. It already is a mess. has been for years. What we are doing is fixing the mess using AS112. I know alot of root operators who would welcome that friendly terminator for wayward traffic. But I need bind to terminate *. NS. I feel sorry it does not. Wildcard is defined for intra-zone use. It is not defined for extra-zone use. Lets define it. Just call it experimental. or something convenient. i think its needed for root services. I am told it works under Dr. Bernstein's named daemon. I still have not tested that myself. But will eventually. I pray it is the case. Any root operator would welcome a trash can for bogus traffic. and its christmas time. what a wonderful gift. regards joe baptista -- Joe Baptistawww.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (202) 517-1593 Fax: +1 (509) 479-0084 begin:vcard fn:Joe Baptista n:Baptista;Joe org:PublicRoot Consortium adr:;;963 Ford Street;Peterborough;Ontario;K9J 5V5 ;Canada email;internet:[EMAIL PROTECTED] title:PublicRoot Representative tel;fax:+1 (509) 479-0084 tel;cell:+1 (416) 912-6551 x-mozilla-html:FALSE url:http://www.publicroot.org version:2.1 end:vcard ___ DNSOP mailing list DNSOP@ietf.org https://www1.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Fri, Apr 4, 2008 at 7:07 PM, Mark Andrews <[EMAIL PROTECTED]> wrote:
> > Mark made the claim that a local copy of the root would stop the
> > traffic, which is false. a local copy of the root simply diffuses
> > the traffic.
Depends on the root you use. If you use an inclusive name space root you
will see a significant reduction in traffic. If you use the iana root thats
when you'll diffuse the traffic.
Also of interest, If you answer the localhost TLD you'll reduce alot of
traffic. And if you can redirect a wild card in the root to AS112 you'll be
ahead on NXDOMAIN.
> > ) the IANA sanctioning alternate roots/namespaces ... "let a
> > thousand roots bloom..."
yes - while you eliminate dependence on the legacy root. i think thats the
best approach. one thing is clear from all these errors to the root is that
the icann root has withered. let a million roots bloom.
Dependence on a central root is illogical. Very soviet era.
> > ) just how is the poor application/end user supposed to know
> > or discriminate some local, walled garden root varient from
> > the one true ICANN root varient?
ICANN is not a functional root anymore. It does not see all of the
Internet. Can't see china. Has no idea of the arab tlds. Can't see
India. Can't see turkey or the Netherlands. Lots of TLDs on the Internet
and ICANN can't see them. Thats why you have so much bogus root traffic.
>
>
>I said COPY. I did not say "THEIR OWN ROOT". A copy needs to
>be kept up to date or it ceases to be a copy. It becomes a
>snapshot.
>
>zone "." {
>type slave;
>masters { ; };
>};
Just AXFR.
regards
joe baptista
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Sun, Apr 6, 2008 at 8:43 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: > Or sign the root and use aggressive negative caching (which is currently > prohibited by the RFCs, I'm told). Think extra zone :) > I agree that information leakage is a problem. Curiously enough, no > root server or TLD operators that I know of has published some sort of > privacy statement that underlines how they deal with this issue. They are not the ones generating this traffic. Its users as they cross over dns zones. i.e. travelers from china staying at a hotel in the USA who can't access their language script idn national china tlds via the legacy IANA root. > It's > also the reason why I think that AS112 for TLDs will not fly. It will. Makes the perfect dns equivalent of the bin bucket trash can. However the question remains - does it help the user in the end. Would it be more appropriate in my example above that the legacy root simply recognize Chinese national tlds? That would get rid of some of the error traffic of the root and do a service to travelers from china. Think users - not roots. cheers joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Sun, Apr 6, 2008 at 9:15 AM, Florian Weimer <[EMAIL PROTECTED]> wrote: > It means that everybody who can make a BGP announcement can legitimately > hijack DNS traffic to those TLDs. Is this really what we want? > Thats an AS112 security issue. Are they to be trusted? Maybe? Maybe not. AS112 can be easily replicated to operate on any dns servers including local roots. So that issue can be put to rest. Like I said before - it makes a great trash can. Now should you trust the communal trash can. Those who don't can run heir own AS112, and those who do can point to AS112. What we want and need is stability and world wide resolvability. What were getting is a revolution. regards joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] AS112 for TLDs
On Mon, Apr 7, 2008 at 3:36 PM, Andrew Sullivan <[EMAIL PROTECTED]> wrote: > non-IANA-root entries. This scheme more or less guarantees the end of > the pretense of a unified namespace (which is related, I think, > to the arguments elsewhere in this thread that such has already > happened anyway). Exactly - such happened a long time ago - the multi root universe. regards joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List
Gerv: I asked you a question earlier in this conversation but have yet to get a response. So I will ask it again. What happens if a TLD is not on the Public Suffix list? regards joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Wed, Jun 11, 2008 at 11:18 AM, Gervase Markham <[EMAIL PROTECTED]> wrote: > I must confess it is somewhat frustrating when, having put up a website > explaining what this is all about, and having had a long discussion on > this list, people continually misunderstand the point while having shown > no evidence of attempting to read the existing explanations. > > I even got one (private) mail basically saying "I can't be bothered to > read all that. Tell me, what are you trying to do?" > Listening would you mind explaining something here. Do we work for you? I'm pretty sure your being paid to promote your public suffix idea but we are not. There are many here who are too busy to spend time reading your stuff, let alone go back to the web site for updates. Now if you want to start paying for my time and the time of the group - we'll gladly work for you. Now Gerv focus. You have come here for a reason and that is to promote a protocol. The people ere are giving very good advice. It would be prudent you pay attention and answer their questions. Obviously this process is having some benefit because it is forcing you to update your web site. Gerv focus. Kindly remember your position in his affair. You are here on behalf Mozilla to sell an idea and we are the people who have to be sold. And it is in bad form for a salesman to complain. You goal is to provide us with the best customer service on behalf of Mozilla. And if that means going the extra mile - then go the extra mile. Don't complain - that looks bad. A lot of people here are well known experts in their fields who are taking the time to ask you questions. You got to respect that and in turn respect their time constraints. Incidentally - have you answered by question yet - or put it on the web site? What happens to your web browsers behavior if I try to surf a TLD not on the list? cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Public Suffix List - Please move discussion to dnsop
On Wed, Jun 11, 2008 at 12:26 PM, Gervase Markham <[EMAIL PROTECTED]> wrote: > > Incidentally - have you answered by question yet - or put it on the web > > site? What happens to your web browsers behavior if I try to surf a TLD > > not on the list? > > I've answered it once to you privately and once to the list. Third time: > "the same thing as now". > We must be having email issues. Because I have neither received a private email from you that I can find. Will check my spam folder in case it ended up there. And I have not seen a response to my question on the list. Its been pretty busy here since you dropped this little bomb that has gotten us so excited. So please help me out here, I didn't get that answer. So what is the answer to the question ??? What happens to your web browsers behavior if I try to surf a TLD not on the list? Thanks in advance for your answer. Joe Baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Why deny AXFR from root servers?
On Wed, Jun 25, 2008 at 7:06 PM, Joe Abley <[EMAIL PROTECTED]> wrote: > a.root-servers.net does not leave AXFR wide open, at least for this client > b.root-servers.net does leave AXFR wide open, at least for this client > c.root-servers.net does leave AXFR wide open, at least for this client > d.root-servers.net does not leave AXFR wide open, at least for this client > e.root-servers.net does not leave AXFR wide open, at least for this client > f.root-servers.net does leave AXFR wide open, at least for this client > g.root-servers.net does leave AXFR wide open, at least for this client > h.root-servers.net does not leave AXFR wide open, at least for this client > i.root-servers.net does not leave AXFR wide open, at least for this client > j.root-servers.net does not leave AXFR wide open, at least for this client > k.root-servers.net does leave AXFR wide open, at least for this client > l.root-servers.net does not leave AXFR wide open, at least for this client > m.root-servers.net does not leave AXFR wide open, at least for this client > Thats not bad. I remember a time when only the f root would AXFR. 5 out of 13 is not bad. -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Is it possible to force bind to use TCP exclusively?
Are there any configuration changes that can be made to bind to force it to only use TCP as opposed to UDP? regards joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
On Sun, Aug 17, 2008 at 8:23 PM, Jim Reid <[EMAIL PROTECTED]> wrote: > I suspect you're talking about the absurdly hypothetical scenario where > someone gets a non DNSSEC-aware resolving server to lookup some RRSIG, then > the zone is resigned, then they ask that server for the QTYPE that the > already cached RRSIG once signed. Not that hypothetical. Its just another attack vector. And one that would work well against non signed zones. A non DNSSEC resolver could be used to poison DNSSEC aware resolvers. In any case - DNSSEC is a dead issue. The problem here is UDP. We have to move to a more reliable transport. TCP with UDP fallback? Thats easy to do and will still take years to deploy. The network is slow when it comes to upgrading. Just imagine the impact DNSSEC will have. Not very much. The large corporations who swallow the commercial BIND fud will be first to deploy. But most of the world won't bother and once the world discovers DNSSEC give root control over to ICANN the net result will be a black eye for ICANN. Poor little ICANN can't afford more scrutiny. Their market share in root services has gone from 100% to 70%. Thats not impressive. If it were not for my putting an end to the European HEX that amount today would be more like 40%. Back then the HEX accounted for a 5% drop in ICANN's market share of root services. later joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] A different question (was Re: Kaminsky on djbdns bugs (fwd))
On Fri, Aug 15, 2008 at 4:51 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote: > security layers are good. If we don't give those people the right tools to > properly configure and properly maintain those configurations, there will be > stability issues, as I listed earlier. Let me tell you something. All this DNSSEC fud has been very very good for DNS consultants. One thing I make clear to the client base is that DNSSEC is just more bad patching on top of more bad patching. The BIND boys are patching freaks and have yet to build a BIND version that is stable. My advise to them is to watch the developments in DNSSEC and not believe everything they read. The solution I like implementing instead of DNSSEC is an IPS monitoring the resolver. And of course making sure their resolvers don't act as authoritative primaries or secondaries. One things for sure - many businesses are going to end up paying big bucks to protect themselves and even bigger bucks to deploy the DNSSEC patch. The BIND boys are marketing gurus. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Fwd: Pointless FUD and confusion about DNSSEC deployment
On Mon, Aug 18, 2008 at 12:02 PM, Paul Hoffman <[EMAIL PROTECTED]>wrote: > At 1:27 PM +0100 8/18/08, Jim Reid wrote: > >> The fact is DNSSEC is the *only* game in town for preventing cache >> poisoning. >> > > Note the subject of this particular thread. A more carefully-worded > sentence would be "The fact is DNSSEC is the *only* game in town for > completely preventing cache poisoning." We have methods to reduce an > attacker's ability to poison caches effectively. No it is not so little grasshopper. The best way to secure DNS recursive servers is to integrate a smart IDS and firewall solution. Commerce needs solutions - not more patches to patch the patches that should have been patched years ago. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] Another TLD intending to sign soon
On Tue, Aug 26, 2008 at 11:26 AM, Paul Hoffman <[EMAIL PROTECTED]>wrote: > <http://www.gcn.com/online/vol1_no1/46987-1.html> > > >Government agencies must take new measures by January 2009 to ensure > >the Domain Name System security extensions on top level .gov Web > >site domains are signed, and that processes for securing sub-domains > >are developed, according to a memorandum released today by the White > >House Office of Management and Budget. The top level .gov domain > >includes the registrar, registry and DNS server operations. > > > >In addition, agencies must develop a plan of action and milestones > >for deploying DNS Security extensions to "all applicable information > >systems"; and "capabilities must be operational by December 2009," > >the memo said. This will be a very interesting experiment. And finally a good test of DNSSEC. Great for consultants. cheers joe baptista -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Another TLD intending to sign soon
On Tue, Aug 26, 2008 at 1:10 PM, Roy Arends <[EMAIL PROTECTED]> wrote: > > This will be a very interesting experiment. And finally a good test of >> DNSSEC. Great for consultants. >> > > Why would this be experimental or test? Why 'finally'. This implies DNSSEC > has not been deployed or been tested 'good' before. It hasn't. And anyone who thinks it has is living in la la land. I think it will be a good test because .gov domain holders will be forced to give it a try. There is no other TLD operator with the power to enforce a transition to DNSSEC of all domains like this will. I wish them luck and look forward to the results of this modest experiment. regards joe baptista Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] DS vs DNSKEY trust anchors, was Re: Truncation...
You poor souls. The DNSSEC monster is vast and complex. So much easier just to fix the problem instead of this endless gibberish. It's so complex it's funny when you consider a simple solution like DNSCURVE - http://dnscurve.org/ - and so much more secure. No man in the middle issues. Oh well - sorry for the interruption - and carry on. cheers joe baptista On Wed, Mar 11, 2009 at 10:57 AM, Edward Lewis wrote: > At 8:19 +1100 3/11/09, Mark Andrews wrote: > >> In message , Edward Lewis writes: >> > > record involves less typing than a DNSKEY, I'd want to work with a DS >>> record. >>> >> >>Has anyone on this list ever typed in a DNSKEY or DS as a >>trust anchor? I would presume that most (99.%) people >> > > "work with" != type in > > At 10:40 +1100 3/11/09, Mark Andrews wrote: > >>I have a new key I want to introduce. I add the DS to the >>parent zone at least the ttl(ds) before I start using that >>key in the zone. After the DS has been published for ttl(ds) >>I can then replace the DNSKEY referred to by the old DS >>with that of the new DS and re-sign the DNSKEY RRset. Once >>the ttl(dnskey) has expired I can remove the old DS from >>the parent zone. >> >>I wish to be able to do something similar with trust anchors. >>Publishing DS prevents me from doing so. >> > > There is more than one way to do a key supersession. I'll describe one > assuming DS records are installed as trust anchors. > > DS(KEY1) is in my validator. The owner of KEY1 distributes DS(KEY2) with a > note that it should be installed "by the 15th." On the 15th, DNSKEY(KEY2) > is placed in the zone and KEY2 only is used to sign the keyset. With a 1 > week TTL on the key set's RRSIG RR, a week later DNSKEY(KEY1) is removed > from the set. At some point after that I can remove DS(KEY1) from my > validator. > > Perhaps the special case here is that the keyset is unique in that the > signatures for SEP/KSK's are "tied" to the where the key data is. I.e., if > you have something signed by KEY1, then you have KEY1 because that something > has to be the key set. > > If the zone is not run with a KSK/ZSK split, then the removal of KEY1 is > triggered by signing the last RR set by KEY2 and then the TTL. > > The principle here is that there is no error if "for a DS record there is > no corresponding DNSKEY" and vice versa. All that is needed for validation > is one "chain of trust." Accepting dangling references is not optimal but > provides robustness. > > -- > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- > Edward Lewis > NeuStarYou can leave a voice message at +1-571-434-5468 > > Getting everything you want is easy if you don't want much. > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > -- Joe Baptista www.publicroot.org PublicRoot Consortium The future of the Internet is Open, Transparent, Inclusive, Representative & Accountable to the Internet community @large. Office: +1 (360) 526-6077 (extension 052) Fax: +1 (509) 479-0084 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Signing the root == end of ITAR?
On Wed, Oct 7, 2009 at 9:32 AM, joao damas wrote: > > Since a date was announced yesterday (July 1st) for a fully deployed signed >> root, can we expect ITAR to Go Away on Januari 1st 2011 ? >> > > I would hope it stays around. Having an "out of band" way of contrasting > the info in the root zone is a valuable service to have. > Don't expect that to happen. Once the root is signed it is prudent to remove DLV so as to ensure complete root slavery. regards joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: Re: Roll Over and Die ?
not bad for two cents. worth a lot more in advice. Heres my two cents. DNSSEC is broken. DNSSEC will cause economic harm as it adds to business costs. There's one liability. And DNSSEC is not needed. We have options. DNSCurve works http://bit.ly/cjmH2n - let's try something that works? That would certainly be an innovative move forward for the ietf. cheers joe baptista On Thu, Feb 18, 2010 at 10:54 AM, Todd Glassey wrote: > The real answer Tony is coming out of left field and it is the legal > claims being asserted against people intentionally fielding code they know > is broken and for which they refused to accept criticism's about that code > (oddly enough from people like Dean and I and a number of others. > > The real fun part is the legal liability this is creating for people who in > this list claim they have a right to ignore whatever they want, and its > coming... > > So the real issue is whether there is a class action matter coming against > the ISC and a number of the projects it operates per this new accountability > push. > > This is NOT good for any of these projects so I suggest that the proper > response is a new level of transparency in who is making what decisions for > the WG and how they are made regarding design testing and otherwise. > > Just my two cents as a civilian. > > Todd Glasssey > > Original Message Subject: Re: [DNSOP] Roll Over and Die > ? Date: Thu, 18 Feb 2010 13:35:59 + From: Tony Finch > To: > George Barwood > CC: > dnsop@ietf.org > > On Thu, 18 Feb 2010, George Barwood wrote: > > > Any reaction to this CircleID article ? > > > > http://www.circleid.com/posts/dns_resolvers_and_dnssec_roll_over_and_die/ > https://www.isc.org/announcement/response-to-concerns10Febhttp://unbound.net/pipermail/unbound-users/2010-February/001031.html > > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Hues
On Tue, Feb 23, 2010 at 4:26 PM, wrote: > > within the IETF, which also of course brings us to the question of how > > many people of color are management within the IETF?. > >All of them. No person that I am aware of in the ietf management >chain are transparent - all reflect light at various points on >the spectrum. With this information, you may now make the claim >that the IETF management is opaque, lacking transparency... and >you would be technically correct. > > Bill. You disappoint me. Your being evasive. Todd is asking you how many people in management positions at the IETF are black. Or as they used to call them in the ol south - People of "color" or "Negroes" or the more vulgar derisive and offensive term "niggers". regards joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] OpenDNS today announced it has adopted DNSCurve to secure DNS
Have you boys seen this yet? http://twitter.com/joebaptista/status/9555178362 regards joe baptista ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Should root-servers.net be signed
My recommendation - upgrade your NAT. regards joe baptista On Sun, Mar 7, 2010 at 3:06 AM, George Barwood < george.barw...@blueyonder.co.uk> wrote: > I have been wondering about this. > > For a resolver behind a NAT firewall that removes port randomization, > it is possible for an attacker to spoof the priming query ( only 16 bits of > ID protection ). > > If root-servers.net is unsigned, it's not possible for the resolver to > validate > the set of root IP addresses, meaning that > > (a) An attacker can control every unsigned zone. > > (b) An attacker can monitor every request to a signed zone ( no privacy ). > > (c) An attacker can deny service to any zone, on a selective basis. > > Apparently there are currently no plans to sign root-servers.net > > The main argument against seems to be that the priming query > response size (with DO=1) would be greatly increased. > > Any thoughts? > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
