[DNSOP] DNS over TCP *currently* does not scale
On Sun, Aug 17, 2008 at 11:42:39PM -0400, Dean Anderson wrote: TCP isn't susceptible to this kind of attack at all. TCP spoofing is While this is true, it turns out the current crop of authoritative nameservers, including mine, is not up to serving thousands of requests/second over TCP. Or at least not thousands of new sessions/second. I'm working on in-place spoofing countermeasures and I've already had to stop my tests because I ended up overloading the authentic authoritative servers with TCP queries. So TCP is not the end-all to our worries. Nor is DNSSEC however - the current crop of auth servers doesn't have that enabled or working either. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ 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 04:07:03PM -0700, David Conrad wrote: intervention) or they'll turn off DNSSEC. So, in the worst case, they'll get bitten and revert back to the same level of security (or lack thereof) they have today. Is this worth blocking DNSSEC deployment? It seems to me that that story is the one by which DNSSEC becomes permanently hobbled on the Interned, as various overworked or semi-incompetent system administrators make a mistake of this sort and cause sites to go dark for significant portions of the Internet. When the CTO receives the incident report, the CTO is going to say, So if we never turned on DNSSEC, this wouldn't have happened? Ok. New policy: no DNSSEC. At least, that's the way it would have worked in most large institutions I ever worked in/around. A -- Andrew Sullivan [EMAIL PROTECTED] +1 503 667 4564 x104 http://www.commandprompt.com/ ___ 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 Mon, 18 Aug 2008, Paul Wouters wrote: I wouldn't be using starbucks resolver, since i just installed my own DNSSEC-aware resolver? Ordinarilly , when you get a DHCP-supplied nameserver from starbucks, your stub resolver directs its requests to that caching server. It is indeed possible that your stub resolver could make its own queries, including to the root and TLD servers, but putting this non-cached end-user load on those servers is yet another unanticpated operational problem. No one has accounted for such increased load for DNSSEC. When the internal representation is updated, it is often done one RR at a time. So two responses updating the same two records could be interleaved. This is a simple database problem called a race condition. However, we have TTL's and signature life times, so older entries will only get updated with newer entries, so this race is not a problem. I don't think you understand the programming issues. This has nothing to do with TTLs or signature lifetimes. The point is that DNS servers don't currently perform transactions internally; normally, records don't depend tightly on other records (hence the term 'loosely coherent'). BTW, adding transaction capability greatly slows down database servers. This is probably one of the reasons people like to put stuff in DNS instead of databases. DNS is fast because of its stateless nature. DNSSEC changes that, and imposes speed-reducing demands on server architecture. Or else, won't work right. This change alters DNS from being loosely coherent to tightly coherent, with corresponding performance impacts to get correct operation. You lost me here. Sorry. When the RR isn't the same as the one for which the RRSIG was computed, the DNSSEC-aware stub resolver will reject the record. If it asks the caching server again, it gets the same records. So the resolver will fail, and will continue to fail until the TTL expires. The bad guy just creates two records with long TTL, and you have the DOS attack. Mark and Roy already explained why this is not the case. Who do you mean by 'Mark and Roy'? Mark Andrews and Roy Arends? When? If the caching server checks the signature of all records, its susceptible to a DOS attack by lots of DNSSEC queries that take a lot of computation to check. Seems to be no-win. That's not a DOS attack. That's the price of cryptogrpahically signing the DNS. When your server can't handle the load of all these calculations on millions of queries sent by the attacker, its a DOS attack. So is not getting any traffic because you lost .com due to cache poisoning. True enough. Same problem continues after all the DNSSEC effort, and now we have created the additional problems of the other DDOS attacks using the signed records. Seems to be a giant step backward, with no step forward. In fact, what I understood is that resolvers mostly have problems switching to DNSSEC not due to DNSSEC but due to DNSSEC requiring EDNS0. And mind you, the EDNS0 was released in what? 1999? It's not the crypto that's the resolvers issue. That's easilly solved by adding a cpu or a box. The transition issue you speak of is a different problem. The DOS attack I speak of is when your caching server gets lots of requests for DNSSEC records, which it then must verify. These requests aren't 'legitimate' in the sense that users made these queries genuinely trying to get information. These requests are bogus, generated only with the purpose of creating load on the server. Verifying the crypto keys is not easy. Verifying millions is impossible. Now imagine the target spoofed IP's are the nameservers of, say yourdomain.com. When the roots (or TLDs, etc) get millions of forged UDP packets, the roots can't block the incoming packets---that would severely harm the target IP addresses. On the other end, the target IP addresses can't block the root servers---that would also seriously harm the target IP addresses. The target just has to 'take it'. The greater the amplification factor (Response size / request size-- perhaps only 64 bytes), the more damaging this attack is. Since there are (or may be--probably will be) a number of additional (and large) DNSSEC records in a response, the response could get quite large, causing significant damage. So yes, that is a reason not to deploy DNSSEC. This has also been explained earlier. Just get a botnet that's 100x the size to accomplish the same. This argument amounts to something like let's not do HDTV because the home user DSL might not be able to download it in real time anyway. No, actually, it isn't like that at all. If there is no amplification, the botnet will simply use ICMP or something it already has a program to do. When there is amplification (perhaps up to 100x in this case) a very small botnet can do a very great deal of damage, for a much longer time. A great deal of effort
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
bert hubert wrote: On Mon, Aug 18, 2008 at 04:34:30PM +, Paul Vixie wrote: and let's also make explicit that TCP is not to be used unless UDP returns TC or unless QTYPE=AXFR or unless UDP QTYPE=IXFR returned only one SOA. This means disabling one of the more widely used MTAs. Could you please elaborate on this? Which MTA, how does it use DNS, and is the way it uses it intractable? It may require some work to beef up TCP support though, The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. So, short of dramatic changes to TCP that support better scalability and performance, it's kind of out of scope for DNS itself. Brian ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 05:27:24PM +, Paul Vixie wrote: TCP/53 a redheaded stepchild and its uses are all dangerous or unscalable. (that initiators do the close, and that responders have a minimum 2-minute timeout, says that any conformant implementation can be slapped down hard with a three line perl script running anywhere on the internet.) DNS over TCP is a damn sight easier than WWW over TCP. Ask the webserver guys about their query rates.. We've just had it easy over the past years, and it shows. The server I mean by the way is microsoft exchange, which likes to do DNS over TCP. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
On Mon, 18 Aug 2008, Jim Reid wrote: On 18 Aug 2008, at 05:11, Dean Anderson wrote: Ok, I agree that totally DNSSEC-oblivious servers won't be a problem for DOS, but of course remain susceptible to poisoning even if the stub resolver and the authority server both implement DNSSEC. Kindly explain how is this any different from when poisoning occurs when stub resolver and authority server don't implement DNSSEC. Its not any different; its exactly the same problem. And DNSSEC creates more problems, without solving any. The fact is DNSSEC is the *only* game in town for preventing cache poisoning. TCP is another 'game in town'. We may also be able to invent other 'games', as DJB suggests. So to go back to David's original question: will deploying DNSSEC break anything that's already in use that doesn't support DNSSEC? Yes: DNSSEC enables DDOS attacks that didn't exist before, and doesn't eliminate any attacks that previously existed. Now if that resolving server does pay attention to the DO bit, it will set it on the query it makes to the authoritative server. That makes the authoritative server return an answer which will contain the new RRSIG and the resolving server's cache is updated accordingly. Ok. So what about caching servers that do understand the DO bit but don't actually verify the responses? They just cache the response for the stub resolver to verify? These servers can still be poisoned with invalid record combinations that they pass on to stub resolvers, resulting in the DOS. Such servers may still be subject to the race condition I described. How is this different from a resolving server not getting the correct answer because it queried an authoritative server that hasn't seen the latest version of the zone on the master? In that scenario, the old data is consistent. In my scenario, poisoning has created inconsistent data on the non-verifying DNSSEC cache. In fact in the somewhat contrived scenario you pose, the stub resolver gets a validation failure. So they at least know something has gone wrong. Which has to be a great leap forward from getting bad (poisoned) data and not having the slightest clue that has happened. The resolver 'knows' perhaps, but the user doesn't know anything. They just know that they typed in 'www.yahoo.com' and got no IP address. That's a DOS. And its no leap forward. In the original cache poisoning case, the user either gets, nothing, a non-working IP or they get the wrong server. If they get the wrong server, their SSL verification and trust procedure will exclude that server from use. That's a DOS, too. Ahhh. I see it now. Someone will deploy DNSSEC in their stub resolver. But then they'll make that query a resolving server that doesn't speak DNSSEC whenever their stub resolver wants to do a DNSSEC-aware lookup. Right. Makes perfect sense. [Add scarcasm to taste.] No, I already agreed that a totally DNSSEC-oblivious wasn't going to pose a DNSSEC problem. Your sarcasm is misplaced. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Pointless FUD and confusion about DNSSEC deployment
On Mon, 18 Aug 2008, Paul Hoffman 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. If the DNSSEC cache doesn't verify the records it caches, it is still suceptible to poisoning. DNSSEC caches that verify are subject to a crypto-overload attack by large numbers of queries. Both kinds of attacks ultimately result in a DOS --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ___ 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
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 07:20:16PM +, Paul Vixie wrote: We've just had it easy over the past years, and it shows. it *can't* scale. laws of physics. 'When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong.' Consider this a compliment. The server I mean by the way is microsoft exchange, which likes to do DNS over TCP. so what does microsoft exchange do when it tries to talk to a tinydns service like everydns.net who doesn't implement TCP/53 at all? It doesn't need to - it speaks to resolvers. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: Pointless FUD and confusion about DNSSEC deployment
On Aug 18, 2008, at 12:51 PM, Joe Baptista wrote: No. I was thinking more of a smart porcupine with attitude. At least use the IDS to notify the system administrator an attack is in progress. I've attached a document that uses snort to log the event. That could be used to notify the system administrator. You can call it whatever you want, but whether the exterior is hard or spiny, if you depend on that for network security, you don't have much security. I mean, if you really think that's the way to go, tell me this: do you still use rsh to log into your servers? Because really that's what you're saying when you say that the security in DNSSEC or some other DNS security protocol isn't important. You're saying that authentication based on IP address is sufficient. If you really hate DNSSEC, I could be sympathetic to the idea of using TSIG to protect your resolvers. That's what started this whole long thread, if you remember. But what you're talking about is snake oil security. There's a lot of money in it, don't get me wrong. But it's not a solution the IETF should be promoting. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
Paul's original proposal, C (if I interpret it correctly) applies to resolver-authority-server communications, not stub-resolver communications. no, i was pretty much ruling them out period. especially (RA=1 AND RD=0). however, i could accept a SHOULD NOT for ADNS vs. a SHOULD for RDNS on TCP/53 as long as we also add a SHOULD on RDNS for accept only transactions from intended clients, most likely from within the same LAN, campus, or ISP. SHOULD is great since people who don't do it are still compliant. opendns wouldn't be in trouble. but vendors would become advised to set their defaults to a non-global ACL and then TCP/53 is safer. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote: The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 07:49:20PM +, Paul Vixie wrote: so what does microsoft exchange do when it tries to talk to a tinydns service like everydns.net who doesn't implement TCP/53 at all? It doesn't need to - it speaks to resolvers. what would it do if it had a TCP-forbidding firewall between it and its RDNS? Dunno, but when PowerDNS had TCP bugs in its resolver code, all the complaints I got were from Exchange users. What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. I worry because it turns out a single multiplexed connection between a resolver and an authoritative server is just the ticket for doing almost unspoofeable queries while under attack. It serves as a semi-persistent channel (few seconds, minutes perhaps) over which all the queries triggering the questions that are under attack can safely be answered. So I care about DNS over TCP as part of the entropy raising arsenal that is (mostly) available today. I'd hate to see it taken away! Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
what would it do if it had a TCP-forbidding firewall between it and its RDNS? Dunno, but when PowerDNS had TCP bugs in its resolver code, all the complaints I got were from Exchange users. they'll cope. What's the rush with deprecating DNS/TCP btw? It languished in the shade for 25 years.. that's what we said about udp port randomization after bernstein invented it. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Fwd: Pointless FUD and confusion about DNSSEC deployment
On Mon, 18 Aug 2008, Joe Baptista wrote: No. I was thinking more of a smart porcupine with attitude. At least use the IDS to notify the system administrator an attack is in progress. I've attached a document that uses snort to log the event. That could be used to notify the system administrator. But the vision I have is of an integrated DNS - IDS - Firewall solution with an appropriate rules base for known attack vectors. Okay. So now an attack is going on, and your pager told you. What are you going to do? 1) nothing 2) clean the cache every 5 minutes hoping the race won't do damage in between cleanups 3) drop all incoming DNS packets for the spoofed domain, effectively DOS'ing the domain under attack 4) enable DNSSEC to deal with the situation Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, 18 Aug 2008, bert hubert wrote: On Mon, Aug 18, 2008 at 01:45:43PM -0400, Brian Dickson wrote: The problem, I think, is TCP itself, not TCP support within implementations. E.g. resource limits per IP address (16 bits of port number) don't scale to current-size Internet scale. It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. Paul ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
On Mon, Aug 18, 2008 at 06:11:14PM -0400, Paul Wouters wrote: It is possible to host 10 connections on 1 IP address and 1 port, and this happens in practice. Think, again, of webservers, which all have to listen on port 80, yet support lots of clients simultaneously. Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. I must be more stupid than normal - care to elaborate how limitations (I wasn't aware of, btw) on virtual webhosting authenticated and encrypted using SSL certificates have any bearing on the suitability of TCP/IP for DNS levels of performance? Bert -- http://www.PowerDNS.com Open source, database driven DNS Software http://netherlabs.nl Open and Closed source services ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] deprecating dangerous bit patterns and non-TC non-AXFR non-IXFR TCP
Bad example. One of the reasons we don't see more crypto per default on web browsing is precisely the limitations of SSL/CA's on using SSL with virtual host web sites. I'd hardly call the lack of port 443 a success story. we don't need a reason to deprecate tcp/53 beyond what's written in rfc1035. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
David Conrad wrote: If a caching server is required to perform public key computation to verify RRs before caching, it can't support much clients and will be a so easy victim of DDOS. Hence, one of the reasons for the desire to push DNSSEC towards the end user. You mean all the DNSSEC clients should directly ask authoritative nameservers and all the firewalls preventing so should be modified. OK. Let's assume all the clients agree with you and start using DNSSEC and all the administrators of firewalls agree with you and perform modification (though I don't know how NAT can be modified). Then, the increased load is a very good reason for root servers not support DNSSEC. I am curious what you propose as an alternative. Abandon DNSSEC and accept the reality that, even with DNSSEC, management of DNS is not very secure. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
Paul Wouters wrote: (distributed) point to point encryption (or validation) is the future! It's no future. I see no problem for port 53 through NAT's. NAT often captures and modifies packet to port 53. But really, so many desktop applications do direct DNS now themselves with disregard of the OS, Today, most of them are using a DHCP-supplied server. Then, the increased load is a very good reason for root servers not support DNSSEC. I believe 99% of the load of root servers is bogus queries anyway. The amount of bogus queries will also increases, of course. Plus, I'm sure they wouldn't mind an increase to signal/noise ratio. Plus, those are addressed my things like anycast. It all scales fairly well, DNS being a distributed system and all. I'll take this argument as valid as soon as a root server operator comes forward and tells us this is a problem. For YOUR objections, let's stick to YOUR problems. FYI, root server load was my problem and anycast is my thing. More anycasting means more cost. Abandon DNSSEC and accept the reality that, even with DNSSEC, management of DNS is not very secure. That's not an alternative (nor correct) That's the reality with no alternatives. Masataka Ohta ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Cache poisoning on DNSSEC
On Aug 18, 2008, at 8:22 PM, Masataka Ohta wrote: You mean all the DNSSEC clients should directly ask authoritative nameservers Yes. and all the firewalls preventing so should be modified. The vast majority of firewalls allow 'connections' (even UDP ones) to be initiated from the inside. Those that prevent DNS from working correctly could be modified or upgraded or the administrators could trust in that firewall to protect the caching server used by multiple clients from the DDoS attacks you are concerned about. Let's assume all the clients agree with you and start using DNSSEC and all the administrators of firewalls agree with you and perform modification (though I don't know how NAT can be modified). NAT does not need to be modified. As I type this, I am behind a commercial (relatively low end -- an Apple Airport Extreme basestation) NAT with firewalling enabled. It works just fine. Then, the increased load is a very good reason for root servers not support DNSSEC. The root server operators have demonstrated that they are quite capable of ramping capacity to meet demand (actually, the root servers are wildly over provisioned to try to deal with DDoS attacks so I doubt the increase in load caused by what I'm suggesting would even be an issue). Alternatively, we could move to a more distributed model of DNS operations in which the caching servers that are doing DNSSEC cache the entire root zone, perhaps zone transferring the signed root zone from some authoritative and trusted place. Since the root trust anchor would be published, the root zone data would be verifiable so fears of a corrupted root zone would be eliminated. I suspect a combination of both would more than suffice. What's more, recent studies have indicated that approximately 98% of the traffic hitting the root servers is pure crap. Interestingly, when the L-root server was renumbered, it seems the quantity of traffic hitting that root server is significantly lower than the others. One possible reason for this could be that people just don't like ICANN. Another reason could be that a really tremendous amount of crap is being generated by servers that are so old that they don't notice a root server address change. In the latter case, pushing caching servers out towards the edges would almost certainly entail upgrading those name servers. As a result, the root servers might actually see a reduction in traffic. I am curious what you propose as an alternative. Abandon DNSSEC and accept the reality that, even with DNSSEC, management of DNS is not very secure. Ah. The Math is hard. Let's go shopping. alternative. Not sure this is particularly helpful. Regards, -drc ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
