Re: [dns-operations] a question about the nameservers
On Fri, Oct 26, 2012 at 10:11:33AM +, Lutz Donnerhacke l...@iks-jena.de wrote a message of 65 lines which said: For the first query the glue data will be used (NS in the parent zone). For later queries the resolver should requery the NS from the authorititve servers. And, at the expiration of the data, the resolver should go back to the parent (to avoid the ghost domain attack). ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Roland, On Friday, 2012-10-26 01:48:44 +, Dobbins, Roland rdobb...@arbor.net wrote: On Oct 26, 2012, at 8:33 AM, Mark Andrews wrote: We essentially have the infrastructure to do this today. Not all (not even most) network infrastructure is connected to or even has connectivity to the public Internet. Yeah, that's not the infrastructure we care about, since that is not spoofing source addresses on the public Internet. -- Shane ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 6:04 PM, Shane Kerr wrote: Yeah, that's not the infrastructure we care about, since that is not spoofing source addresses on the public Internet. The point is that the network infrastructure vendors will not invest a lot of time and resources, at least not given the current state of affairs, in trying to tie their network infrastructure gear into any kind of delegation certification PKI infrastructure, as most of the gear they sell isn't connected to the Internet and hasn't any way to connect to the putative delegation PKI system. Another point is that, given the various controversies in the 'classic' DNS space with regards to various domain takedowns for reasons other than straightforward abuse, the benefits of such a system vs. its potential susceptibility to legislative and regulatory incursions isn't a settled issue (the same concerns apply in the routing space, as well as with regards to DNSSEC). --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 7:24 PM, wbr...@e1b.org wrote: If so, why can't they block anything outside that range. This is the perpetual refrain questioning why BCP84 hasn't been universally implemented. Lack of clue, lack of perceived economic incentive, lack of infrastructure capability (though the natural cycle of equipment upgrades has largely eliminated this issue on networks running even semi-modern gear), apathy, sloth, venality. In the main, it isn't a question of 'can't' - it's a question of 'won't'. Which is why Paul was saying that network infrastructure vendors should by default enable various anti-spoofing mechanisms on the gear they well. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] a question about the nameservers
On 26/10/2012 05:43, Feng He wrote: Hi, If the nameservers in parent is different from the ones in auth-servers, what will happen? For example, with this case you can see the difference. Take a look at this: https://www.dns-oarc.net/files/workshop-201103/ICANN-SF-Looking-at-DNS-traces.pdf There is difference in how resolvers behave some resolvers will store the first NS set they see and use that one (Parent centric resolvers) Others will accept NS set from child and over ride the first one (Child centric) If the child use minimal answer may resolvers are forced into Parent centric mode as they NEVER ask the child what its NS set is. There are resolvers out there that use the Parent NS for the first query but explicitly ask one of the name servers in the Parent NS set what the child version is. In short there are multiple behaviors out there and disagreement on what the correct behavior is. The child's interest are best served if the Parent and Child NS sets are identical. Olafur ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
From: Dobbins, Roland rdobb...@arbor.net this sounds like a new application of 'the chemical polluter business model'. There's more to it than that, though. It's important to understand that those who are purchasing and deploying network gear often are nonspecialists, and so frustrations, project delays, etc. would crop up in the customer organizations - who would then complain... but that *IS* 'the chemical polluter business model' which is also the spam problem which is also the tragedy of too many sheep on the commons. It's cheaper and easier in the short term to pollute, ignore spammers, and over graze the commons. The bosses of the shepherds, abuse desks, and refinery engineers hear only about the costs and problems of not overgrazing, terminating profitable accounts, and not polluting. Vernon Schryverv...@rhyolite.com ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
paul vixie p...@redbarn.org wrote on 10/26/2012 10:32:57 AM: i just don't see it. there isn't more to it than that. from the point of view of everyone on the connected internet, it is a bad idea to let some new person connect some new router that forwards packets, if that person is unaware of the s.a.v. issue. if a vendor won't make s.a.v. the default because they need the new business and they don't want the training burden of making sure they understand the issues of s.a.v., then they are following the 'chemical polluter business model' where the money is made here and the impact is only felt over there. I'm not an internet routing guru, so I must not be seeing something. When my organization connects to an upstream provider, they know we have a block of addresses assigned (Actually, we have more than one). They know that we connect to their switch in rack X, switch Y, port Z. If they see a packet with a source address of 8.8.8.8 appearing on that port, what possible reason could they have for allowing it through? Obviously, that's a Google address, and possibly forged a lot. I just don't see why a packet claiming to be from an address we do not own should be coming from our net. Can anyone explain why that would happen (other than forgery)? I looked at BCP84/RFC3704, but as a non-networking person, it was brushing the bald-spot. I know this is drifting from the list topic, so thank you for the indulgence. Confidentiality Notice: This electronic message and any attachments may contain confidential or privileged information, and is intended only for the individual or entity identified above as the addressee. If you are not the addressee (or the employee or agent responsible to deliver it to the addressee), or if this message has been addressed to you in error, you are hereby notified that you may not copy, forward, disclose or use any part of this message or any attachments. Please notify the sender immediately by return e-mail or telephone and delete this message from your system. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
Original Message- From: paul vixie p...@redbarn.org Date: Friday, October 26, 2012 10:32 AM To: Dobbins, Roland rdobb...@arbor.net Cc: DNS Operations List dns-operati...@mail.dns-oarc.net Subject: Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks On 10/26/2012 7:11 AM, Dobbins, Roland wrote: On Oct 26, 2012, at 11:19 AM, paul vixie wrote: this sounds like a new application of 'the chemical polluter business model'. There's more to it than that, though. It's important to understand that those who are purchasing and deploying network gear often are nonspecialists, and so frustrations, project delays, etc. would crop up in the customer organizations - who would then complain vociferously to the network infrastructure vendors and/or simply switch to a vendor which didn't enable anti-spoofing as a default. i just don't see it. there isn't more to it than that. from the point of view of everyone on the connected internet, it is a bad idea to let some new person connect some new router that forwards packets, if that person is unaware of the s.a.v. issue. if a vendor won't make s.a.v. the default because they need the new business and they don't want the training burden of making sure they understand the issues of s.a.v., then they are following the 'chemical polluter business model' where the money is made here and the impact is only felt over there. i kinda see both sides, but then i'm not in the argument. :-) i think there's a reason OSS (let's forget commercial interests for a moment) distributions ship with firewalls that have been standard for years either disabled or running entirely open... despite many documented best practices you don't want to keep most systems running that way for long. some might even argue narrow windows of time with open firewall rules allow the determined attacker (or botnet worms) to access available attack vectors, such that locking down hosts as an afterthought doesn't add much value. to further the analogy, new users are the ones who would be most confused by a freshly installed OSS distribution that won't connect to anything...but it doesn't at all negate the necessity of a properly configured firewall -- especially for new users who might do things like connect their shiny new laptop to a insert_favorte_coffee_shop access point full of evil hackers and then carry it inside the shroud of corporate security (this of course isn't limited to OSS, with BYOD and iWhatzits and droids). so i appreciate both sides, but i think there's something larger afoot...human psychology perhaps. i do plan to raise this (to the best of my ability) through engineering management and at least start a discussion. challenging current norms is always a healthy exercise that at least gets people thinking. as mentioned, i came to cisco through acquisition (like so many others), and am positioned in the security BU...so i can at least present both sides to folks higher up the food chain (and smarter than me) then let them make an informed decision. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On Oct 26, 2012, at 9:32 PM, paul vixie wrote: i just don't see it. Ah, but I *did* see it when I worked for a major vendor of telecommunications equipment. I agree with you - I wish anti-spoofing were enabled by default. I'm not defending the status quo, just trying to explain why it isn't enabled by default, as well as why it isn't likely to be enabled by default anytime soon, absent some significant technical innovation (which I don't see happening due to the nature of TCP/IP) or major catastrophe which changes the perceived economics of the current situation both for network infrastructure vendors as well as for customer organizations. --- Roland Dobbins rdobb...@arbor.net // http://www.arbornetworks.com Luck is the residue of opportunity and design. -- John Milton ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] First experiments with DNS dampening to fight amplification attacks
On 10/26/2012 3:15 PM, wbr...@e1b.org wrote: paul vixie p...@redbarn.org wrote on 10/26/2012 10:32:57 AM: ... they are following the 'chemical polluter business model' where the money is made here and the impact is only felt over there. I'm not an internet routing guru, so I must not be seeing something. When my organization connects to an upstream provider, they know we have a block of addresses assigned (Actually, we have more than one). They know that we connect to their switch in rack X, switch Y, port Z. If they see a packet with a source address of 8.8.8.8 appearing on that port, what possible reason could they have for allowing it through? the cost of finding out from you which source ip address ranges are valid for your interface, programming their routing equipment, dealing with the error rate inevitable in all human-related systems, and auditing all of this is measurably non-zero. this is what experienced providers call a 'one-off'. to the extent that they can make your interface with what many providers call a 'cookie cutter' -- that is, all alike -- they will spend measurably less money delivering their service to you. ... I looked at BCP84/RFC3704, but as a non-networking person, it was brushing the bald-spot. the non-networking person version (sometimes called the 'pointy haired boss version') is called 'SAC004' and was written by me ten years ago (october 2002): http://archive.icann.org/en/committees/security/sac004.txt. I know this is drifting from the list topic, so thank you for the indulgence. source address validation is very important to dns operations; i don't consider this thread off-topic. paul ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
Any ideas what I can do to help my customer? This is the first time we've ever had something like this... Tim Huffman Director of Engineering Business Only Broadband 777 Oakmont Lane, Suite 2000, Westmont, IL 60559 Direct: 630.590.6012 | Main: 630.590.6000 | Fax: 630.986.2496 thuff...@bobbroadband.com | http://www.bobbroadband.com/ Cell: 630.340.1925 | Toll-Free Customer Support: 877.262.4553 Follow Us on LinkedIn | Follow Us on Twitter please consider the environment prior to printing -Original Message- From: Phil Pennock [mailto:dnsop+p...@spodhuis.org] Sent: Friday, October 26, 2012 11:14 PM To: Tim Huffman Cc: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] ATT DNS Cache Poisoning? On 2012-10-27 at 03:36 +, Tim Huffman wrote: We are the primary DNS servers for the ben.edu domain. We seem to be having an issue with an ATT server that is responding with incorrect A records for www.ben.edu and ben.edu. Definitely looks like a cache-poisoning attack. Further, compare and contrast: curl -vH Host: www.ben.edu http://208.91.197.132/ ua=Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648) curl -vH Host: www.ben.edu -H User-Agent: $ua http://208.91.197.132/ There's some JavaScript fetching images via fwdservice.com ... looks like it might be Google click-fraud? -Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
Re: [dns-operations] ATT DNS Cache Poisoning?
On 2012-10-27 at 04:23 +, Tim Huffman wrote: Any ideas what I can do to help my customer? This is the first time we've ever had something like this... Continue trying to reach ATT and the other operators of DNS servers in that link? You can look at deploying DNSSEC for their domain, so that those DNS resolver operators who deploy validating caches will be immune to this. The .edu zone is signed. If you get ben.edu signed as well, then you've done everything technical to help resolvers only get valid data. -Phil ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
