- Test - lists.nanog.org

DNS attacks evolve
by Joe Greco 11 Aug '08

11 Aug '08

It's usually interesting to be proven wrong, but perhaps not in this case. I was among the first to point out that the 11-second DNS poisioning claim made by Vixie only worked out to about a week of concentrated attack after the patch. This was a number I extrapolated purely from Paul's 11-second number and the factor-of-65000x introduced by port randomization. I am very, very, very disheartened to be shown to be wrong. As if 8 days wasn't bad enough, a concentrated attack has been shown to be effective in 10 hours. See http://www.nytimes.com/2008/08/09/technology/09flaw.html With modern data rates being what they are, I believe that this is still a severe operational hazard, and would like to suggest a discussion of further mitigation strategies. On my list of concepts: 1) Use of multiple IP addresses for queries (reduce success rate somewhat) 2) Rate-limiting of query traffic, since I really doubt many sites actually have recursers that need to be able to spike to many times their normal traffic, 3) Forwarding of failed queries (which I believe BIND doesn't currently allow) to a "backup" server (which would seem to be interesting in combination with 2) 4) I wonder if it wouldn't make sense to change the advice for large-scale recursers to run multiple instances of BIND, internally distribute the requests (random pf/ipfw load balancing) to present a version of 1) that would render smaller segments of the user base vulnerable in the event of success. It would represent more memory, more CPU, and more requests, but a smaller victory for attackers. 5) Modify BIND to report mismatch QID's. Not a log report per hit, but some reasonable strategy. Make the default installation instructions include a script to scan for these - often - and mail hostmaster. 6) Have someone explain to me the reasoning behind allowing the corruption of in-cache data, even if the data would otherwise be in-baliwick. I'm not sure I quite get why this has to be. It would seem to me to be safer to discard the data. (Does not eliminate the problem, but would seem to me to reduce it) 7) Have someone explain to me the repeated claims I've seen that djbdns and Nominum's server are not vulnerable to this, and why that is. It would seem that the floor is wide open to a large number of possibilities for mitigating this beyond the patch. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.

6 6

Solution vs. Implementation
by Bruuce Williams 11 Aug '08

11 Aug '08

Could someone who reads "the other lists" on the DNS problem mind posting a summery here? While this list is theorizing a solution, they may be theorizing implementation considerations, so a little back-and-forth communication might be useful. Just a thought... Bruce Williams the first principle is that you must not fool yourself, and you are the easiest person to fool -- Richard P. Feynman

1 0

Re: maybe a dumb idea on how to fix the dns problems i don't know....
by Chris Paul 11 Aug '08

11 Aug '08

list-nanog(a)pwns.ms wrote: >> (I know; you old folks that created this wonderful thing didn't think of >> that back then.... blah blah blah). >> > > If they had thought of it back then, they would have allowed for a larger TXID, not used TCP. TCP connection setup time is slow; TCP DNS is much slower than UDP DNS. Good point. But we only care about TCP connection setup time in *interactive* sessions (a human using something like the web). If you have a persistent connection to your dns server from your dns resolver on your browser machine, you just send the request.... no TCP setup there at all. You can even pool connections. We do this stuff in LDAP all the time. How does TCP resolution work in most resolver libraries? A TCP connection for each lookup? That is kind of dumb isn't it, speaking of dumb.... I actually don't know. Not much of a coder, so I'll let you coders check your code and get back to me on that... well.. maybe i'll fire up snort or wireshark and check it out later with some different dns libs.... CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul(a)rexconsulting.net web: http://www.rexconsulting.net phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to.

9 16

Re: Impossible Circuit
by Matt Rice 11 Aug '08

11 Aug '08

I am not sure about the loop, but wouldn't a static or default static route specifying an outbound interface rather than a next hop router ip address on a multi-access network like Ethernet, frame-relay or ATM with connections to 5 or more routers cause one router to output a stream of packets to a subnet and all five or more receiving routers receiving the packets possibly forwarding them separately causing the duplicate packets? Just a thought, Matt Rice Seattle ----- Original Message ----- From: <nanog-request(a)nanog.org> To: <nanog(a)nanog.org> Sent: Sunday, August 10, 2008 8:21 PM Subject: NANOG Digest, Vol 7, Issue 26 > Send NANOG mailing list submissions to > nanog(a)nanog.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mailman.nanog.org/mailman/listinfo/nanog > or, via email, send a message with subject or body 'help' to > nanog-request(a)nanog.org > > You can reach the person managing the list at > nanog-owner(a)nanog.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NANOG digest..." > > > Today's Topics: > > 1. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Chris Paul) > 2. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Chris Paul) > 3. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Cat Okita) > 4. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (Joe Greco) > 5. impossible circuit (Jon Lewis) > 6. Re: maybe a dumb idea on how to fix the dns problems i don't > know.... (William Herrin) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 10 Aug 2008 18:27:29 -0700 > From: Chris Paul <chris.paul(a)rexconsulting.net> > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: nanog(a)nanog.org > Message-ID: <489F9581.4010801(a)rexconsulting.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Joe Greco wrote: >>>> Pretending for a moment that it was even possible to make such large >>>> scale changes and get them pushed into a large enough number of clients >>>> to matter, you're talking about meltdown at the recurser level, because >>>> it isn't just one connection per _computer_, but one connection per >>>> _resolver stub_ per _computer_ (which, on a UNIX machine, would tend to >>>> gravitate towards one connection per process), and this just turns into >>>> an insane number of sockets you have to manage. >>>> >>> >>> Couldn't the resolver libraries be changed to not use multiple >>> connections? >>> >> >> I think that the text I wrote clearly assumes that there IS only one >> connection per resolver instance. The problem is that hostname to IP >> lookup is pervasive in a modern UNIX system, and is probably pretty >> common on other platforms, too, so you have potentially hundreds or >> thousands of processes, each eating up additional system file descriptors >> for this purpose. > > Well how I read what you first wrote implied that the resolvers are now > going to DOS servers with millions of connections due to each resolver > stub making a TCP connection... I say this is something that if true, > can and should be changed. > > Now you say that file descriptors on the client are going to run out > Isn't that changing the topic? And is that even really a problem? > > So each process that needs to do a lookup opens a file descriptor for a > TCP connection, right? Whereas with UDP we don't have to do this. Is > this what I'm hearing you say? That I understand. (Hmm don't udp > connections take sockets too? Not sarcastic here.. just asking...) > > And it is a good point but is this client file descriptor an > insurmountable problem? Also, what about the millions of connections to > the server? Is that really necessary for a dns resolver on one system to > open more than one TCP connection to its caching dns server? > > I'm not saying that caching dns servers should keep open TCP connections > to authoritative name servers! OK? But how much latency do you increase > e on that uncached recursive lookup by changing to TCP? > > CP > > -- > Chris Paul > Rex Consulting, Inc > email: chris.paul(a)rexconsulting.net > phone, direct: +1, 831.706.4211 > phone, toll-free: +1, 888.403.8996 > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, > or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. > Rex Consulting, Inc. is a California Corporation. > > P Please don't print this e-mail, unless you really need to. > > > > > > ------------------------------ > > Message: 2 > Date: Sun, 10 Aug 2008 18:29:00 -0700 > From: Chris Paul <chris.paul(a)rexconsulting.net> > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: nanog(a)merit.edu > Message-ID: <489F95DC.4010403(a)rexconsulting.net> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Victor Jerlin wrote: >>>> >>> Couldn't the resolver libraries be changed to not use multiple >>> connections? >> >> And we'll change to IPv6 tomorrow! > Total apples and oranges. We all have to patch anyhow. This is just code > and firewall rules. IPv6 is way more complicated, friend. > > > -- > Chris Paul > Rex Consulting, Inc > email: chris.paul(a)rexconsulting.net > phone, direct: +1, 831.706.4211 > phone, toll-free: +1, 888.403.8996 > > The information transmitted is intended only for the person or entity to > which it is addressed and may contain confidential and/or privileged > material. Any review, retransmission, dissemination or other use of, > or taking of any action in reliance upon, this information by persons > or entities other than the intended recipient is prohibited. > Rex Consulting, Inc. is a California Corporation. > > P Please don't print this e-mail, unless you really need to. > > > > > > ------------------------------ > > Message: 3 > Date: Sun, 10 Aug 2008 21:34:26 -0400 (EDT) > From: Cat Okita <cat(a)reptiles.org> > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: Chris Paul <chris.paul(a)rexconsulting.net> > Cc: nanog(a)merit.edu > Message-ID: <20080810213344.D15677(a)gecko.reptiles.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > On Sun, 10 Aug 2008, Chris Paul wrote: >>> And we'll change to IPv6 tomorrow! >> Total apples and oranges. We all have to patch anyhow. This is just code >> and >> firewall rules. IPv6 is way more complicated, friend. > > No - IPv6 is just code (and not even firewall rules). > > cheers! > ========================================================================== > "A cat spends her life conflicted between a deep, passionate and profound > desire for fish and an equally deep, passionate and profound desire to > avoid getting wet. This is the defining metaphor of my life right now." > > > > ------------------------------ > > Message: 4 > Date: Sun, 10 Aug 2008 21:35:58 -0500 (CDT) > From: Joe Greco <jgreco(a)ns.sol.net> > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: chris.paul(a)rexconsulting.net (Chris Paul) > Cc: nanog(a)nanog.org > Message-ID: <200808110235.m7B2Zwxn028353(a)aurora.sol.net> > Content-Type: text/plain; charset=us-ascii > >> > I think that the text I wrote clearly assumes that there IS only one >> > connection per resolver instance. The problem is that hostname to IP >> > lookup is pervasive in a modern UNIX system, and is probably pretty >> > common on other platforms, too, so you have potentially hundreds or >> > thousands of processes, each eating up additional system file >> > descriptors >> > for this purpose. >> >> Well how I read what you first wrote implied that the resolvers are now >> going to DOS servers with millions of connections due to each resolver >> stub making a TCP connection... I say this is something that if true, >> can and should be changed. > > Sure. We can introduce a new feature, called a "local recurser," which > will do unified name resolution for all lookups asked for by any process > on the box. > > Now, of course, the box enjoys certain benefits, such as being able to > remember who "MX nanog.org" is for the second time without having to > bother an external recurser. And a hypothetical ability to forward all > requests via TCP to the external recurser. Except, why bother, now that > you have the capability right on the box, why be dependent on anything > else? Might as well just let it resolve all by itself. > > Of course, the box also enjoys certain other liabilities, such as the > next time that all the name servers in the world need to be upgraded, > you now have just that many more recursers that are running on unattended > autopilot (because heaven knows, most PC's run without a professional > admin to keep things up to snuff, and this last problem wasn't exactly > the sort of thing you can just "auto update," because someone actually > has to verify that there aren't externalities such as NAT devices, etc!) > > Sounds like a real fun time. > >> Now you say that file descriptors on the client are going to run out >> Isn't that changing the topic? And is that even really a problem? > > Actually, it's quite a problem, for the server. Try, sometime, having a > few thousand file descriptors all open, and then running select() on that > fdset. But it's not even really that pleasant on many clients. It's a > kernel consumable. You try to avoid introducing additional requirements > without a good reason. > >> So each process that needs to do a lookup opens a file descriptor for a >> TCP connection, right? Whereas with UDP we don't have to do this. Is >> this what I'm hearing you say? That I understand. (Hmm don't udp >> connections take sockets too? Not sarcastic here.. just asking...) > > You open and then close it for UDP. You can do that for TCP, too, at a > substantial penalty. > >> And it is a good point but is this client file descriptor an >> insurmountable problem? Also, what about the millions of connections to >> the server? Is that really necessary for a dns resolver on one system to >> open more than one TCP connection to its caching dns server? > > There is no "DNS resolver on one system" unless you put one there. At > which point, you can safely ask the question of why would you then connect > to a caching server (there are good reasons, in some cases). > > The way libresolv works is that it takes those "nameserver" things listed > in resolv.conf and sends requests to them. Since any program that uses > the network is likely to be linked to libresolv, you can have lots of > different programs on a system, each of which may want to resolve > different name resources. There is no monolithic "thing" on a box to do > name resolution unless you put one there. > >> I'm not saying that caching dns servers should keep open TCP connections >> to authoritative name servers! OK? But how much latency do you increase >> e on that uncached recursive lookup by changing to TCP? > > Since latency would not be extremely high on my list of concerns with this > plan, I'll pass and say "I don't really care to speculate." There are > many > other ways you'll have lit your hair on fire before latency is a big > concern. > > ... JG > -- > Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net > "We call it the 'one bite at the apple' rule. Give me one chance [and] > then I > won't contact you again." - Direct Marketing Ass'n position on e-mail > spam(CNN) > With 24 million small businesses in the US alone, that's way too many > apples. > > > > ------------------------------ > > Message: 5 > Date: Sun, 10 Aug 2008 23:15:47 -0400 (EDT) > From: Jon Lewis <jlewis(a)lewis.org> > Subject: impossible circuit > To: nanog(a)nanog.org > Message-ID: <Pine.LNX.4.61.0808102146400.5503(a)soloth.lewis.org> > Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed > > After all the messages recently about how to fix DNS, I was seriously > tempted to title this messsage "And now, for something completely > different", but impossible circuit is more descriptive. > > Before you read further, I need everyone to put on their thinking WAY > outside the box hats. I've heard from enough people already that I'm nuts > and what I'm seeing can't happen, so it must not be happening...even > though we see the results of it happening. > > I've got this private line DS3. It connects cisco 7206 routers in > Orlando (at our data center) and in Ocala (a colo rack in the Embarq CO). > > According to the DLR, it's a real circuit, various portions of it ride > varying sized OC circuits, and then it's handed off to us at each end the > usual way (copper/coax) and plugged into PA-2T3 cards. > > Last Tuesday, at about 2:30PM, "something bad happened." We saw a serious > jump in traffic to Ocala, and in particular we noticed one customer's > connection (a group of load sharing T1s) was just totally full. We > quickly assumed it was a DDoS aimed at that customer, but looking at the > traffic, we couldn't pinpoint anything that wasn't expected flows. > > Then we noticed the really weird stuff. Pings to anything in Ocala > responded with multiple dupes and ttl exceeded messages from a Level3 IP. > Traceroutes to certain IPs in Ocala would get as far our Ocala router, > then inexplicably hop onto Sprintlink's network, come back to us over our > Level3 transit connection, get to Ocala, then hop over to Sprintlink > again, repeating that loop as many times as max TTL would permit. Pings > from router to router crossing just the DS3 would work, but we'd see 10 > duplicate packets for every 1 expected packet. BTW, the cisco CLI hides > dupes unless you turn on ip icmp debugging. > > I've seen some sort of similar things (though contained within an AS) with > MPLS and routing misconfigurations, but traffic jumping off our network > (to a network to which we're not directly connected) was seemingly > impossible. We did all sorts of things to troubleshoot it (studied our > router configs in rancid, temporarily shut every interface on the Ocala > side other than the DS3, changed IOS versions, changed out the hardware, > opened a ticket with cisco TAC) but then it occurred to me, that if > traffic was actually jumping off our network and coming back in via > Level3, I could see/block at least some of that using an ACL on our > interface to Level3. How do you explain it, when you ping the remote end > of a DS3 interface with a single echo request packet and see 5 copies of > that echo request arrive at one of your transit provider interfaces? > > Here's a typical traceroute with the first few hops (from my home internet > connection) removed. BTW, hop 9 is a customer router conveniently > configured with no ip unreachables. > > 7 andc-br-3-f2-0.atlantic.net (209.208.9.138) 47.951 ms 56.096 ms > 56.154 ms > 8 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 56.199 ms 56.320 ms > 56.196 ms > 9 * * * > 10 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 80.774 ms 81.030 ms > 81.821 ms > 11 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 75.731 ms 75.902 ms > 77.128 ms > 12 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 46.548 ms > 53.200 ms 45.736 ms > 13 vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.918 ms > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 55.438 ms > vlan69.csw1.Washington1.Level3.net (4.68.17.62) 42.693 ms > 14 ae-81-81.ebr1.Washington1.Level3.net (4.69.134.137) 48.935 ms > ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 49.317 ms > ae-91-91.ebr1.Washington1.Level3.net (4.69.134.141) 48.865 ms > 15 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 59.642 ms 56.278 ms > 56.671 ms > 16 ae-61-60.ebr1.Atlanta2.Level3.net (4.69.138.2) 47.401 ms 62.980 ms > 62.640 ms > 17 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 40.300 ms 40.101 ms > 42.690 ms > 18 ae-6-6.car1.Orlando1.Level3.net (4.69.133.77) 40.959 ms 40.963 ms > 41.016 ms > 19 unknown.Level3.net (63.209.98.66) 246.744 ms 240.826 ms 239.758 ms > 20 andc-br-3-f2-0.atlantic.net (209.208.9.138) 39.725 ms 37.751 ms > 42.262 ms > 21 ocalflxa-br-1-s1-0.atlantic.net (209.208.112.98) 43.524 ms 45.844 ms > 43.392 ms > 22 * * * > 23 sl-bb20-dc-6-0-0.sprintlink.net (144.232.8.174) 63.752 ms 61.648 ms > 60.839 ms > 24 sl-st20-ash-10-0.sprintlink.net (144.232.20.152) 66.923 ms 65.258 ms > 70.609 ms > 25 te-10-1-0.edge2.Washington4.level3.net (4.68.63.209) 67.106 ms > 93.415 ms 73.932 ms > 26 vlan99.csw4.Washington1.Level3.net (4.68.17.254) 88.919 ms 75.306 ms > vlan79.csw2.Washington1.Level3.net (4.68.17.126) 75.048 ms > 27 ae-61-61.ebr1.Washington1.Level3.net (4.69.134.129) 69.508 ms 68.401 > ms ae-71-71.ebr1.Washington1.Level3.net (4.69.134.133) 79.128 ms > 28 ae-2.ebr3.Atlanta2.Level3.net (4.69.132.85) 64.048 ms 67.764 ms > 67.704 ms > 29 ae-71-70.ebr1.Atlanta2.Level3.net (4.69.138.18) 68.372 ms 67.025 ms > 68.162 ms > 30 ae-1-8.bar1.Orlando1.Level3.net (4.69.137.149) 65.112 ms 65.584 ms > 65.525 ms > > Our circuit provider's support people have basically just maintained that > this behavior isn't possible and so there's nothing they can do about it. > i.e. that the problem has to be something other than the circuit. > > I got tired of talking to their brick wall, so I contacted Sprint and was > able to confirm with them that the traffic in question really was > inexplicably appearing on their network...and not terribly close > geographically to the Orlando/Ocala areas. > > So, I have a circuit that's bleeding duplicate packets onto an unrelated > IP network, a circuit provider who's got their head in the sand and keeps > telling me "this can't happen, we can't help you", and customers who were > getting tired of receiving all their packets in triplicate (or more) > saturating their connections and confusing their applications. After a > while, I had to give up on finding the problem and focus on just making it > stop. After trying a couple of things, the solution I found was to change > the encapsulation we use at each end of the DS3. I haven't gotten > confirmation of this from Sprint, but I assume they're now seeing massive > input errors one the one or more circuits where our packets were/are > appearing. The important thing (for me) is that this makes the packets > invalid to Sprint's routers and so it keeps them from forwarding the > packets to us. Cisco TAC finally got back to us the day after I "fixed" > the circuit...but since it was obviously not a problem with our cisco > gear, I haven't pursued it with them. > > The only things I can think of that might be the cause are > misconfiguration in a DACS/mux somewhere along the circuit path or perhaps > a mishandled lawful intercept. I don't have enough experience with either > or enough access to the systems that provide the circuit to do any more > than speculate. Has anyone else ever seen anything like this? > > If someone from Level3 transport can wrap their head around this, I'd love > to know what's really going on...but at least it's no longer an urgent > problem for me. > > ---------------------------------------------------------------------- > Jon Lewis | I route > Senior Network Engineer | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > > > > ------------------------------ > > Message: 6 > Date: Sun, 10 Aug 2008 23:21:01 -0400 > From: "William Herrin" <herrin-nanog(a)dirtside.com> > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > To: nanog(a)merit.edu > Message-ID: > <3c3e3fca0808102021q5f64733em4cde0b8e00ffb697(a)mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On Sat, Aug 9, 2008 at 5:18 PM, Chris Paul <chris.paul(a)rexconsulting.net> > wrote: >> Sorry if this is real stupid for some reason because I don't think about >> DNS >> all day (I'm the ldap dude) but since we have faster networks and faster >> cpus today, what would be the harm in switching to use TCP for DNS >> clients? >> The latency on the web isn't dns anymore ever it seems to me..... > > Latency on in-addr lookups where you typically traverse multiple > forward trees to find the NS servers would seriously suck. At best, a > TCP-based lookup performs at about a third of the speed of a UDP > lookup. Worse unless your implementation is carefully optimized and > you make sure that the OS isn't adding options to the front of the > handshake. You have at least the whole syn/synack/ack handshake before > you can even ask the question. > > Then there's the server cost associated with keeping that much state... > > > On Sat, Aug 9, 2008 at 6:10 PM, Matt F <matt(a)credibleinstitution.org> > wrote: >> Why not just require TCP for a lookup if a response with an incorrect >> TXID >> is received? You could require TCP for just the one lookup or for some >> configured interval, say 1 hour. That should slow attackers down >> substantially. > > Because the attacker is using a sequence of lookups in order to hit > one that lets him poison the cache. That is, he looks up a.google.com, > then he looks up b.google.com, then c.google.com, etc. until he gets > one where the server accepts his fake DNS server record for > google.com. > > To be an effective defense, you'd have to do TCP lookups for the whole > scope ({anything}.google.com) for some period of time following the > bad ID. That in turn would open up a potential DOS where an attacker > could force the DNS server to fall back on TCP for essentially > everything, overwhelming it. > > > On Sat, Aug 9, 2008 at 8:25 PM, brett watson <brett(a)the-watsons.org> > wrote: >> On Aug 9, 2008, at 3:48 PM, Chris Paul wrote: >>> Hey authority DNS server operators. Can you make a change to your >>> servers >>> to always allow TCP client connections? Would this be difficult? What >>> would >>> be the harm? >> >> SYN flooding? > > SYN flooding is a solved problem. > > > On Sat, Aug 9, 2008 at 6:04 PM, Joe Abley <jabley(a)ca.afilias.info> wrote: >> TCP works pretty well with anycast too, if you're careful. It's helpful >> if >> your transactions are short-lived. > > Define "careful." It's always possible for someone to find themselves > with an equal cost path to two different servers in the anycast set. > Add per-packet load balancing at the fork (which is outside the > control of the server operator) and what happens is the request times > out and the resovler fails over to the other NS record that isn't > anycasted. > > Though the protocol is simple enough that it might be possible to fake > it. Build yourself a DNS-only stateless TCP stack for the anycasted > address. Have the server send the syn-ack without creating any state. > The request will almost certainly be entirely contained in one packet, > so when it arrives reply to it without creating any state. Ship off as > many packets as you need to reply followed by a Fin. Blindly ack any > packet that looks like it needs it. If any packets are lost, there > won't be any retransmit (you haven't really established a TCP > connection) so the query will time out and retry. > > Regards, > Bill Herrin > > -- > William D. Herrin ................ herrin(a)dirtside.com bill(a)herrin.us > 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> > Falls Church, VA 22042-3004 > > > > ------------------------------ > > _______________________________________________ > NANOG mailing list > NANOG(a)nanog.org > http://mailman.nanog.org/mailman/listinfo/nanog > > > End of NANOG Digest, Vol 7, Issue 26 > ************************************

1 0

maybe a dumb idea on how to fix the dns problems i don't know....
by Chris Paul 11 Aug '08

11 Aug '08

Paul, Sorry if this is real stupid for some reason because I don't think about DNS all day (I'm the ldap dude) but since we have faster networks and faster cpus today, what would be the harm in switching to use TCP for DNS clients? The latency on the web isn't dns anymore ever it seems to me..... Wouldn't that eliminate the ability to poison clients' caches? any why wouldn't persistent client-server dns connections make sense? any stupid little bsd or linux box can handle several thousand connections today pretty easily if tuned correctly by some reasonably competent primate CP -- Chris Paul Rex Consulting, Inc 157 Rainbow Drive #5703, Livingston, TX 77399-1057 email: chris.paul(a)rexconsulting.net * web: http://www.rexconsulting.net* phone, direct: +1, 831.706.4211 phone, toll-free: +1, 888.403.8996 The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. Rex Consulting, Inc. is a California Corporation. P Please don't print this e-mail, unless you really need to.

10 18

FW: maybe a dumb idea on how to fix the dns problems i don't know....
by Tomas L. Byrnes 10 Aug '08

10 Aug '08

-----Original Message----- From: Tomas L. Byrnes Sent: Saturday, August 09, 2008 9:01 PM To: 'Chris Paul' Subject: RE: maybe a dumb idea on how to fix the dns problems i don't know.... Actually, the RFCs (RFC-1034 3.7RFC-1035 4.2, ref RFC-793; Implementation spec in RFC-1035 4.2.2; RFC-2136 2.1 says TCP is "at the discretion of the requestor";) say TCP "Should" be supported. It's optional, but recommended. The source of the guidance to block TCP is misguided "security" folks who confuse self-denial of service with policy enforcement. When security breaks functionality, it usually fails to secure, as users circumvent it, in my not so humble experience. BTW: In RFC 1034 5.3.1 PVM tipped to some of the issues that we are now dealing with, under the title of "Stub Resolvers". > -----Original Message----- > From: Chris Paul [mailto:chris.paul@rexconsulting.net] > Sent: Saturday, August 09, 2008 3:49 PM > Cc: nanog(a)merit.edu > Subject: Re: maybe a dumb idea on how to fix the dns problems i don't > know.... > > > Paul Vixie wrote: > > because TCP is considered optional by many authority DNS > server operators. > > > Hey authority DNS server operators. Can you make a change to your > servers to always allow TCP client connections? Would this be > difficult? > What would be the harm? > > it's only required if you expect AXFR or if you ever emit a > TC bit. > > if you don't want to do TCP then you can rule out the TC > bit and AXFR > > and just not do TCP, and you'll be dead-to-rights within > the various DNS protocol RFCs. > > > what RFCs forbid TCP for clients? I thought TCP was an option for > clients. I'm not spending the rest of my sunday though reading > rfcs....... and sure as hell not joining another list because to tell > you the truth, I don't really care as much about the typical angry > Sunday list poster (talk about redundant statement....) > > thanks for the thoughts, though Paul. I'll leave the rest of this > discussion (should it exist) to others in their forum of choice.... > I'm thinking of nice insalade caprese with true mozarella di bufalo > right now.... now That's A Sunday!" > > CP > > -- > Chris Paul > Rex Consulting, Inc > 157 Rainbow Drive #5703, Livingston, TX 77399-1057 > email: chris.paul(a)rexconsulting.net > web: http://www.rexconsulting.net > phone, direct: +1, 831.706.4211 > phone, toll-free: +1, 888.403.8996 > > The information transmitted is intended only for the person or entity > to which it is addressed and may contain confidential and/or > privileged material. Any review, retransmission, dissemination or > other use of, or taking of any action in reliance upon, this > information by persons or entities other than the intended recipient > is prohibited. > Rex Consulting, Inc. is a California Corporation. > > P Please don't print this e-mail, unless you really need to. > > > >

2 1

IPv6 FAQ
by Deepak Jain 10 Aug '08

10 Aug '08

According to: http://www.netbsd.org/docs/network/ipv6/ * Larger IP address space. IPv4 uses only 32 bits for IP address space, which allows only 4 billion nodes to be identified on the Internet. 4 billion may look like a large number; however, it is less than the human population on the earth! IPv6 allows 128 bits for IP address space, allowing 340282366920938463463374607431768211456 (three hundred forty undecillion) nodes to be uniquely identified on the Internet. A larger address space allows true end to end communication, without NAT or other short term workarounds against the IPv4 address shortage. (These days NAT is a headache for new protocol deployment and has scalability issues; we really need to decommission NAT networks for the Internet to grow further). * Deploy more recent technologies. After IPv4 was specified 20 years ago, we saw many technical improvements in networking. IPv6 includes a number of those improvements in its base specification, allowing people to assume these features are available everywhere, anytime. "Recent technologies" include, but are not limited to, the following: o Autoconfiguration. With IPv4, DHCP exists but is optional. A novice user can get into trouble if they visit another site without a DHCP server. With IPv6, a "stateless host autoconfiguration" mechanism is mandatory. This is much simpler to use and manage than IPv4 DHCP. RFC2462 has the specification for it. o Security. With IPv4, IPsec is optional and you need to ask the peer if it supports IPsec. With IPv6, IPsec support is mandatory. By mandating IPsec, we can assume that you can secure your IP communication whenever you talk to IPv6 devices. o Friendly to traffic engineering technologies. IPv6 was designed to allow better support for traffic engineering like diffserv or intserv (RSVP). We do not have a single standard for traffic engineering yet, so the IPv6 base specification reserves a 24-bit space in the header field for those technologies and is able to adapt to coming standards better than IPv4. o Multicast. Multicast is mandatory in IPv6, which was optional in IPv4. The IPv6 base specifications themselves extensively use multicast. o Better support for ad-hoc networking. Scoped addresses allow better support for ad-hoc (or "zeroconf") networking. IPv6 supports anycast addresses, which can also contribute to service discoveries. o and more. * A cure to routing table growth. The IPv4 backbone routing table size has been a big headache to ISPs and backbone operators. The IPv6 addressing specification restricts the number of backbone routing entries by advocating route aggregation. With the current IPv6 addressing specification, we will see only 8192 routes on the default-free zone. * Simplified header structures. IPv6 has simpler packet header structures than IPv4. It will allow future vendors to implement hardware acceleration for IPv6 routers easier. * Allows flexible protocol extensions. IPv6 allows more flexible protocol extensions than IPv4 does, by introducing a protocol header chain. Even though IPv6 allows flexible protocol extensions, IPv6 does not impose overhead to intermediate routers. It is achieved by splitting headers into two flavors: the headers intermediate routers need to examine, and the headers the end nodes will examine. This also eases hardware acceleration for IPv6 routers. * Smooth transition from IPv4. There were number of transition considerations made during the IPv6 discussions. Also, there are large number of transition mechanisms available. You can pick the most suitable one for your site. * Follows the key design principles of IPv4. IPv4 was a very successful design, as proven by the ultra large-scale global deployment. IPv6 is "new version of IP", and it follows many of the design features that made IPv4 very successful. This will also allow smooth transition from IPv4 to IPv6. * and more. What I'd like to say is that someone here is playing fast and loose with "mandatory" and "required" (or its true for same definitions of mandatory or required). A couple of these jumped out at me like, "Only 8192 routes on the DFZ" and other things. Rather than jumping down someone's throat here, are these assumptions rampant (or even accurate)? We came across this as we were trying to enhance our own Ops groups documents to share with customers, and well, I don't think we want to share this. ;) Deepak

5 4

UK DNS server
by Blake Pfankuch 09 Aug '08

09 Aug '08

Hello. Looking for a UK based DNS server that allows open relay. Please contact me off list, using it to test a slightly problematic geo dns system.

1 0

Verizon Contactg
by Alan Halachmi 09 Aug '08

09 Aug '08

Would someone from Verizon please contact me? Or, if you know of a technical contact for Verizon, please pass it along. Thanks. Best, Alan

3 2

Re: facebook worm
by Paul Ferguson 09 Aug '08

09 Aug '08

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -- Gadi Evron <ge(a)linuxbox.org> wrote: >At least unlike blackworm, this one's damage could be measured. Actually, BlackWorm was measured -- I have the CAIDA poster in my cube. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.6.3 (Build 3017) wj4DBQFInTtbq1pz9mNUZTMRAlvOAJ4ntljT/bbS2pJ+K78M2EzwsS7dUACWNGVu mDIH8oOFa6nhjccw7Es3xA== =P/Kv -----END PGP SIGNATURE----- -- "Fergie", a.k.a. Paul Ferguson Engineering Architecture for the Internet fergdawg(at)netzero.net ferg's tech blog: http://fergdawg.blogspot.com/

1 0