Re: [dns-operations] Geoff Huston on DNS-over-TCP-only study.
On 2013-08-21 19:36, Geoff Huston wrote: ... truncated TCP. 0.4% of them appear to have some inbound TCP-blocking firewall/filter. ... ... I may have missed this in the original posting and this thread, but this is the first time I've seen this brought up here. This is a particular problem I've noticed. In certain security-conscious networks firewalls or filtering routers block all TCP DNS (It's only used for zone transfers anyway) and UDP packets with a payload greater than 512 bytes. In fact, at least one major company's filtering firewalls and routers come set to do the latter (Cisco). Persuading checklist-followers that this is what is causing them problems is sometimes more effort than it's worth. I'm pleased to see that indiscriminate TCP DNS blocking seems not to be as prevalent on the particular part of the public Internet on which this test was conducted. Joe Yao ___ 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] Geoff Huston on DNS-over-TCP-only study.
On 21 Aug 2013, at 11:00, Geoff Huston g...@apnic.net wrote: Yes, our goal was to test out the asserting in RFC5966 that: The majority of DNS server operators already support TCP and we wanted to see if we could quantify what that majority actually was. [I've been on holiday, so apologies for being late to the party] FWIW, when I wrote that I was mostly considering _authoritative_ servers, although I omitted to say so explicitly. Thanks for running the experiment and writing the report! kind regards, Ray ___ 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] Geoff Huston on DNS-over-TCP-only study.
+1 I would love to see more discussion on the implication of it's findings than the semantics of how they were presented. There is a lot to learn from the information the measurement has delivered. On 8/22/13 2:14 PM, Fred Morris m3...@m3047.netmailto:m3...@m3047.net wrote: On Wed, 21 Aug 2013, Dobbins, Roland wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ While I'm not entirely sure I'm onboard with the conclusions, the study is really interesting and deserves a bookmark and will possibly be forewarded to people not on this list. ;-) -- Fred Morris ___ dns-operations mailing list dns-operations@lists.dns-oarc.netmailto: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 ___ 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] Geoff Huston on DNS-over-TCP-only study.
Thanks for the clarification. We did in fact detect initial configuration issues with the default TCP 3 backlog, but once we'd put this up to 2000 we only had one brief window of RST congestion as detected by a simple TCP filter. This test was for a domainspace which serves around 250,000 experiments per day, each representing 4 DNS queries, none of which could be cached. So it was at 1,000,000 q/day which is obviously a low sustained query rate of around 10 q/sec. I suspect with better kernel knowledge we could have avoided any server forced RST and serve a higher load. Certainly, a TCP based DNS service faces a lot of questions about how its designed and scaled. I believe our goal was to find out how many clients, measured by resolver, failed to complete a TCP forced DNS query. Other people will be looking at the server side, that wasn't what we were primarily exploring. People who want to consider TCP based DNS need both sides of the questionspace filled, so choosing to analyse client failure isn't the whole picture, but it is part of the picture. Your canard reply makes much better contextual sense now cheers -george On Wed, Aug 21, 2013 at 4:16 PM, Paul Vixie p...@redbarn.org wrote: George Michaelson wrote: ... So, while I understand we're not DNS experts and we may well have made some mistakes, I think a one word 'canard' isn't helping. there is no way to either get to or live in a world where dns usually requires tcp. there would be way too much state. most people are capable of writing the one-line perl script that will put a dns responder into tcp exhaustion and keep it there at very little cost to the attacker, but those same people can read section 5 of RFC 5966 and not see the threat. granted that if all name servers miraculously implemented the recommendation servers MAY impose limits on the number of concurrent TCP connections being handled for any particular client then the perl script would have to be longer than one line, there's just no world there. had the original dns tcp protocol been structured so that the server closes and the clients won't syslog anybody or otherwise freak out when the server closes, we could imagine a high transaction rate on short-lived connections. tcp's 3xRTT and 7-packet minimum would seem harsh but at least we'd have some hope of goodput during deliberate congestion attacks. an experiment that looks at this from the client's point of view tells us nothing about the server's availability during congestion. i could wish that measurements of tcp dns performance would include a caveat such as this has not been tested at internet scale or even internet-wide dependence on dns tcp may be vulnerable to trivial denial of service attacks. almost everybody who looks at this says just use TCP. if the solution to the bcp38 problem in DNS were that easy, we would not have written https://www.usenix.org/legacy/publications/login/2009-12/openpdfs/metzger.pdf and william would not have written RFC 6013. it's also worth looking again to http://tools.ietf.org/html/draft-eastlake-dnsext-cookies-02. vixie ___ 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] Geoff Huston on DNS-over-TCP-only study.
Yes, our goal was to test out the asserting in RFC5966 that: The majority of DNS server operators already support TCP and we wanted to see if we could quantify what that majority actually was. What we found out was that of the DNS resolvers that were visible to the authoritative name server, some 83% of them did use TCP following the reception of a truncated UDP response, and the failing 17% of these visible resolvers were used by 6% of the end clients. Of these affected clients, 2/3 of them then used alternate resolvers that did perform TCP, while the remaining 2% were stranded and were unable to complete the name resolution process. But that is just one part of the total story, and a TCP-based resolver is more vulnerable to various forms of SYN flooding attacks as Paul points out. Of course you could always turn to stateless TCP (http://www.potaroo.net/ispcol/2009-11/stateless.html) but while that effort was a more light hearted response to the issue, the issue of TCP server scaling and vulnerability to SYN attack is nevertheless a serious one. On the other hand its no more serious than any other form of small TCP transaction based services that are subjected to massive volumes, such as, say, a search engine front end. We've seen a variant of this scaling discussion in a number of domains, and there is a common theme running along here: as the internet grows the servers that support its function need to grow as well. While part of the answer may well be selective TCP session rate limiting and other TCP smarts that reduce the per-TCP-session resource footprint in the server, another part of the answer may simply be that being a DNS authoritative server today simply needs more grunt than yesterday. (Its not just the population of clients and the query loads that can be imposed on servers - its also related to our efforts to increase the information load in the DNS. As an illustration of this in the context of DNSSEC I did some measurements on the amount of additional queries and additional traffic we see from a DNSSEC-signed name as compared to a unsigned name earlier this year when using the client - our results and estimates of the increase in traffic and query loads are at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf) Geoff On 21/08/2013, at 4:27 PM, George Michaelson g...@apnic.net wrote: I believe our goal was to find out how many clients, measured by resolver, failed to complete a TCP forced DNS query. Other people will be looking at the server side, that wasn't what we were primarily exploring. People who want to consider TCP based DNS need both sides of the questionspace filled, so choosing to analyse client failure isn't the whole picture, but it is part of the picture. ___ 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] Geoff Huston on DNS-over-TCP-only study.
http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ them aussies certainly know how to do a nice bit of wide-scale measurement. now we can descend into the religions un-asserted implications violate. randy ___ 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] Geoff Huston on DNS-over-TCP-only study.
On Wed, 21 Aug 2013, Dobbins, Roland wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ I didn't even get far enough to get to the parts Vixie seems to object to. It was too painful to read. It's in desperate need of proof-reading and copy editing. Was this translated (poorly) from some other language to English? -- Jon Lewis, MCP :) | I route | therefore you are _ http://www.lewis.org/~jlewis/pgp for PGP public key_ ___ 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] Geoff Huston on DNS-over-TCP-only study.
http://www.circleid.com/posts/20130820_a_question_of_dns_protocols disappointed me with this characterization of RRL: There is a conversation thread that says that resolvers should implement response rate limiting (RRL), and silently discard repetitive queries that exceed some locally configured threshold. That ignores the slip parameter. That is irritating given the relevant implications of slip=2 as the default in one RRL implementation and the popular alternative of slip=1. I was also disappointing that it failed to mention the crushing costs of DNS/TCP. jeezus! it was a *measurement* study. that it did not parade your or someone elses banner is irrelevant. randy ___ 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] Geoff Huston on DNS-over-TCP-only study.
From: Geoff Huston g...@apnic.net On the other hand its no more serious than any other form of small TCP transaction based services that are subjected to massive volumes, such as, say, a search engine front end. Isn't that why HTTP, SMTP, and other TCP transaction services have been changed to reduce the ratio of TCP connections to transactions? Isn't it also true that DNS transactions are much lighter weight than HTTP, SMTP, ando other TCP transaction applications? Could the gTLD roots exist in anything like their current forms if DNS transactions cost as many CPU and stable storage computrons as an HTTP GET of a purely static page (even without TLS)? 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] Geoff Huston on DNS-over-TCP-only study.
BTW, The goal of OpenResolverProject was to have an inventory so folks could measure against attacks and determine what % of attacks utilized them. The list is available in weekly format to security teams to download in bulk so they can use tools like GrepCidr to perform this cross-reference. The unexpected results of the data were knowing that ~46% are just a broken CPE device that does something weird with DNS packets. BCP-38 isn't going to resolve the DDoS threat, but does close some of the attack surface. A number of folks are doing derivative research with the data as well. You can use the broken CPE devices to measure BCP-38 compliance, and I've been working with at least two different university research teams to help them understand the data. I'd love for more people to dive into it, and any help I can provide in collecting better data (some folks want the UDP reply TTLs captured for example) I'm interested to know about. I've also thought about doing an actual TCP/53 scan as well and send the query over TCP to measure how many reply there. (I have some TC=1 responses in my weekly scan results). The name and shame side-effect is helpful to drive interest, as well as presentations at various meetings. Personally, I see some of the larger threats being the lack of rigorous CPE testing, the fact that many want to be your DNS proxy, and unmanaged VPS/VM solutions that exist out there. - Jared On Aug 21, 2013, at 6:00 AM, Geoff Huston g...@apnic.net wrote: Yes, our goal was to test out the asserting in RFC5966 that: The majority of DNS server operators already support TCP and we wanted to see if we could quantify what that majority actually was. What we found out was that of the DNS resolvers that were visible to the authoritative name server, some 83% of them did use TCP following the reception of a truncated UDP response, and the failing 17% of these visible resolvers were used by 6% of the end clients. Of these affected clients, 2/3 of them then used alternate resolvers that did perform TCP, while the remaining 2% were stranded and were unable to complete the name resolution process. But that is just one part of the total story, and a TCP-based resolver is more vulnerable to various forms of SYN flooding attacks as Paul points out. Of course you could always turn to stateless TCP (http://www.potaroo.net/ispcol/2009-11/stateless.html) but while that effort was a more light hearted response to the issue, the issue of TCP server scaling and vulnerability to SYN attack is nevertheless a serious one. On the other hand its no more serious than any other form of small TCP transaction based services that are subjected to massive volumes, such as, say, a search engine front end. We've seen a variant of this scaling discussion in a number of domains, and there is a common theme running along here: as the internet grows the servers that support its function need to grow as well. While part of the answer may well be selective TCP session rate limiting and other TCP smarts that reduce the per-TCP-session resource footprint in the server, another part of the answer may simply be that being a DNS authoritative server today simply needs more grunt than yesterday. (Its not just the population of clients and the query loads that can be imposed on servers - its also related to our efforts to increase the information load in the DNS. As an illustration of this in the context of DNSSEC I did some measurements on the amount of additional queries and additional traffic we see from a DNSSEC-signed name as compared to a unsigned name earlier this year when using the client - our results and estimates of the increase in traffic and query loads are at http://www.iepg.org/2013-07-ietf87/2013-07-28-dnssec.pdf) Geoff On 21/08/2013, at 4:27 PM, George Michaelson g...@apnic.net wrote: I believe our goal was to find out how many clients, measured by resolver, failed to complete a TCP forced DNS query. Other people will be looking at the server side, that wasn't what we were primarily exploring. People who want to consider TCP based DNS need both sides of the questionspace filled, so choosing to analyse client failure isn't the whole picture, but it is part of the picture. ___ 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 ___ 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] Geoff Huston on DNS-over-TCP-only study.
On Wed, Aug 21, 2013 at 03:14:59PM +, Vernon Schryver wrote: HTTP, SMTP, ando other TCP transaction applications? Could the gTLD roots exist in anything like their current forms if DNS transactions cost as many CPU and stable storage computrons as an HTTP GET of a purely static page (even without TLS)? Excellent questions! Imagine if we measured stuff and found out! A -- Andrew Sullivan a...@anvilwalrusden.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] Geoff Huston on DNS-over-TCP-only study.
Moin! On 21.08.2013, at 08:18, Jared Mauch ja...@puck.nether.net wrote: The unexpected results of the data were knowing that ~46% are just a broken CPE device that does something weird with DNS packets. Well they mostly proxy that query to their ISPs resolver, who as it came from an address on his network answers it and send it back to the CPE. The CPE being a DNS proxy then sends the answer back to the victim. The problem as you correctly point out is the CPE and given that people do upgrade there CPEs less often than there PCs, if at all the problem will stay around for some time. Looking forward to your research on that. So long -Ralf --- Ralf Weber Senior Infrastructure Architect Nominum Inc. 2000 Seaport Blvd. Suite 400 Redwood City, California 94063 ralf.we...@nominum.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] Geoff Huston on DNS-over-TCP-only study.
Vernon Schryver wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols disappointed me with this characterization of RRL: There is a conversation thread that says that resolvers should implement response rate limiting (RRL), and silently discard repetitive queries that exceed some locally configured threshold. that wording did not leap out at me at the time, but, is factually wrong. RRL is on the server side not the resolver side. vixie ___ 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] Geoff Huston on DNS-over-TCP-only study.
And furthermore, it is my understanding that in RRL no queries are ever discarded. Only the response is throttled. Alan V. Shackelford Senior Systems Software Engineer The Johns Hopkins University and Johns Hopkins Medical Institutions Baltimore, Maryland USA mailto:ashac...@jhmi.edu ashac...@jhmi.edu 410-735-4773 From: dns-operations-boun...@lists.dns-oarc.net [mailto:dns-operations-boun...@lists.dns-oarc.net] On Behalf Of Paul Vixie Sent: Wednesday, August 21, 2013 12:43 PM To: Vernon Schryver Cc: dns-operations@lists.dns-oarc.net Subject: Re: [dns-operations] Geoff Huston on DNS-over-TCP-only study. Vernon Schryver wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols disappointed me with this characterization of RRL: There is a conversation thread that says that resolvers should implement response rate limiting (RRL), and silently discard repetitive queries that exceed some locally configured threshold. that wording did not leap out at me at the time, but, is factually wrong. RRL is on the server side not the resolver side. vixie smime.p7s Description: S/MIME cryptographic signature ___ 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] Geoff Huston on DNS-over-TCP-only study.
On 22/08/2013, at 9:36 AM, Geoff Huston g...@apnic.net wrote: On 22/08/2013, at 12:36 AM, Jon Lewis jle...@lewis.org wrote: On Wed, 21 Aug 2013, Dobbins, Roland wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ I didn't even get far enough to get to the parts Vixie seems to object to. It was too painful to read. It's in desperate need of proof-reading and copy editing. Was this translated (poorly) from some other language to English? My apologies - english is spoken and written in so many styles and I know that my written style can be considered as turgid, particularly when I was not intending to write for a highly expert specialist technical audience such as are on this mailing list. So here is what I would say to this audience: - How many resolvers and their clients will resolve a DNS name to an address if they are forced to use TCP? - Our experiment used a modified DNS server that truncated all UDP at 512 bytes, and over 10 days we enlisted some 2 million end clients to perform a set of tests by using online ads. The ad used a very wide geographic and network variety, so there is good grounds to see this set as a reasonable representative sample of the internet's end user population. - The authoritative nameserver saw 80,000 visible resolvers. 17% of them (13,400) did not switch to TCP and re-query upon receipt of truncated TCP. 0.4% of them appear to have some inbound TCP-blocking firewall/filter. The rest simply did not respond in TCP - These 13,400 resolvers were used by 6% of the end clients. - 2/3 of these affected end clients switched to use an alternative resolver that was able to pose the query using UDP. sigh pose the query using UDP and fall back to TCP upon receipt of the truncated UDP response - the rest (2%, or 50,000 end clients) were unable to complete the DNS query at all. - we retested, using a slightly different DNS nameserver configuration with a smaller UDP truncation threshld, over a further 700,000 end clients and saw a similar outcome. regards, Geoff ___ 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] Geoff Huston on DNS-over-TCP-only study.
Geoff Huston wrote: ... So here is what I would say to this audience: ... thank you geoff, i understand it now. vixie ___ 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] Geoff Huston on DNS-over-TCP-only study.
Geoff, I personally think this is really interesting work. A question about methodology: On Aug 21, 2013, at 4:36 PM, Geoff Huston g...@apnic.net wrote: - Our experiment used a modified DNS server that truncated all UDP at 512 bytes, and over 10 days we enlisted some 2 million end clients to perform a set of tests by using online ads. The ad used a very wide geographic and network variety, so there is good grounds to see this set as a reasonable representative sample of the internet's end user population. If I recall correctly, you're using a Flash thingie to do this. Is that right? If so, have you looked at how platforms that don't do Flash (notably, Apple IOS-based devices by default) behave (at least in a lab)? I know those devices had an ... interesting impact on the IANA servers providing the root trust anchor... Thanks, -drc signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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] Geoff Huston on DNS-over-TCP-only study.
On 22/08/2013, at 10:32 AM, David Conrad d...@virtualized.org wrote: Geoff, I personally think this is really interesting work. A question about methodology: On Aug 21, 2013, at 4:36 PM, Geoff Huston g...@apnic.net wrote: - Our experiment used a modified DNS server that truncated all UDP at 512 bytes, and over 10 days we enlisted some 2 million end clients to perform a set of tests by using online ads. The ad used a very wide geographic and network variety, so there is good grounds to see this set as a reasonable representative sample of the internet's end user population. If I recall correctly, you're using a Flash thingie to do this. Is that right? If so, have you looked at how platforms that don't do Flash (notably, Apple IOS-based devices by default) behave (at least in a lab)? I know those devices had an ... interesting impact on the IANA servers providing the root trust anchor... We have used flash becuase flash is used by Google Ads and we use Google's ad distribution network to feed the ads. I've seen work by a research crew at UCSD who mounted an ad using iframes and javascript, but their usenix paper did not name their ad distribution network, so I am trying to see if we can target the non-flash platforms (i.e. Apple i* devices) using a different ad network. Parenthetically, I see my vanilla Mac (OSX 10.8.4) does not use extended UDP sizes in its queries to the local resolver, so it needs these local resolvers to pass back large queries using TCP. Geoff ___ 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] Geoff Huston on DNS-over-TCP-only study.
Geoff's original article is here (in potaroo.net) A Question of DNS Protocols http://www.potaroo.net/ispcol/2013-09/dnstcp.html It also describes the open resolver project as a name and shame approach. (I have quoted below, and IMHO, certainly this approach is effective) The open resolver project is working on a name and shame approach to the problem, and is hopeful that by allowing individual resolver operators to check their own status, that these resolvers will be closed down. -- Orange From: Dobbins, Roland rdobb...@arbor.net Date: Wed, 21 Aug 2013 04:41:49 + http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ --- 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 ___ 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] Geoff Huston on DNS-over-TCP-only study.
Dobbins, Roland wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ canard. ___ 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] Geoff Huston on DNS-over-TCP-only study.
On 21/08/2013, at 3:23 PM, Paul Vixie p...@redbarn.org wrote: Dobbins, Roland wrote: http://www.circleid.com/posts/20130820_a_question_of_dns_protocols/ canard. We invested quite a lot of time re-checking things with a shorter EDNS0 limit coded into bind, to confirm the TCP failure rate, without the use of the CNAME to force the initial response over the limit. (ie, removing the complication of the CNAME intermediary) It was interesting that even when the A record information appears to be in the TC response, people ignore it and fall back to TCP anyway. I had worried the presence of valid answer and truncate in additional would cause some number of tested people to take the pre-truncation data anyway. it doesn't appear to happen. The results with a simpler A-only forced TC test the same: we see a gross rate of resolver failure to complete at 17% and a user rate of 2% bearing in mind the extensive use of google 8.8.8.8 and in general, 2+ resolvers per client. So, while I understand we're not DNS experts and we may well have made some mistakes, I think a one word 'canard' isn't helping. -G ___ 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
