Re: [dns-operations] Cloudflare TYPE65283
viktor> Do the CPU and packet size reductions justify the additional viktor> protocol complexity? As IPv6 slowly creeps up in usage amongst folks not well versed in PMTUD and such (particularly more and more smaller middleware/firewall vendors or crap consumer routers), I think keeping response packet size down wherever we can is prudent. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Looking for zones using white lies (RFC 4470)
shuque> The UltraDNS implementation doesn't use the more precise white shuque> lies epsilon function defined in the spec, but it is probably shuque> good enough for all practical purposes. shuque> And it's much closer to white lies than "black" lies, because it shuque> preserves the correct semantics of NXDOMAIN. That's actually a pretty good summary already. Basically a "loose" white lies that was computationally less intensive while trying to be as close to the RFC as was practical. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Looking for zones using white lies (RFC 4470)
shuque> UltraDNS (Neustar Security Services) is known to use NSEC White shuque> Lies. I have a test zone there, shuque> which you can examine: "[[ultratest.huque.com]]". My recollection is that the NSS implementation is really grey lies, i.e. not quite RFC white lies but not fully black like cloudflare. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Full-service resolver - Pending Upstream Query behaviour
fneves> I would like to start a discussion or to hear implenters and fneves> operators of Full-service resolvers on what would be the best fneves> software architecture or best current configuration practice to fneves> handle a traffic pattern when a very popular name enters a fneves> scenario were all the auth-servers are timing-out or network fneves> unreachable. vcunat> I'm not sure if there can be *one* BCP way. Definitely would need to be more a bag of tricks that operators can mix/match based on their actual environment, customer base, etc. Paid vs free probably have different concerns and obligations. Folks with lots of smaller sites with lower qps rates per server vs folks with a few much larger sites will have different pain points and remediations. I'd suspect that there are very few things that are always a good idea for everyone everywhere. I think there is value in discussing what zone/RRset timers, cache sharing, stale serve, response rate limiting and other things are already out there, issues/benefits and what gaps aren't being currently well addressed. Might eventually make a good RFC too. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] slack.com bogus
pe> If NASA borks their DNSSEC, the large recursive resolvers eat huge pe> customer support costs but NASA is mostly unscathed (and may not pe> even notice immediately). So the incentive to do better pe> operationally is light for NASA but the resolver operators have very pe> little leverage to encourage them to do better. dukhovni> That was true then, but the pain felt by auth server operators dukhovni> has growing a bunch as over time more of the world is doing dukhovni> validation. Which is actually impeding DNSSEC for domains where outages of DNS instantly cause revenue issues. Knowing you're off the air in a significant part of the world means a good deal of the alexa 1000 still won't sign their "money" domains. NTAs as a option (along with public "flush this domain" for large recursives) blunt the arguments of DNSSEC haters that DNSSEC is too fragile for valuable domains. Not saying NTAs are wonderful. Just saying that they are a necessary evil until we have better DS handling, key rollover software, industry experience in operations. We did it (mostly) with certs and HTTPS and we can do it with DNSSEC, but we're not there yet. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] slack.com bogus
pe> NTAs in production use aren't even vaguely new. They've been in wide pe> use for 8-10 years that I'm aware of. They are part of why folks pe> like google, cloudflare, comcast et al are willing to do DNSSEC pe> validation in production. paul> i know that. i just don't like it. without backpressure, paul> sloppiness will normalize. (always.) Not always. Sometimes, pain teaches avoidance, not improvement. We already have a slow enough rollout of DNSSEC as it is. One of the things I've never been happy about with DNSSEC (but admit no brilliant alternate solution for) is that the cost/pain are in the wrong place. If NASA borks their DNSSEC, the large recursive resolvers eat huge customer support costs but NASA is mostly unscathed (and may not even notice immediately). So the incentive to do better operationally is light for NASA but the resolver operators have very little leverage to encourage them to do better. I hold up most of .milnet as an example of years of DNSSEC breakage making very little headway in operational improvements. While a lot of that is due to it being an unfunded mandate for years, breakage certainly hasn't improved things much faster. NTAs shouldn't be over-used/abused but there's no question they have significantly moved the needle in getting recursive operators to validate, which is a huge part of what's needed in wide scale DNSSEC deployment being useful. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] slack.com bogus
pounsett> Negative Trust Anchors, most probably. paul> i hope not. because if true, there's no backpressure on sloppy paul> operations. are we really introducing a new animal to this paul> ecosystem that has no predators trying to kill or eat it? NTAs in production use aren't even vaguely new. They've been in wide use for 8-10 years that I'm aware of. They are part of why folks like google, cloudflare, comcast et al are willing to do DNSSEC validation in production. Doing it automatically is bad, as per RFC 7646, but it is a valid response if it's a large site and mistake rather than malicious. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
dukhovni> A client using 8.8.8.8 as its iterative resolver and dukhovni> delegating all input validation to that upstream becomes dukhovni> vulnerable not only to data forgery, but also to validation dukhovni> bypass if an MiTM pretending to be 8.8.8.8 returns unvalidated dukhovni> data. In a perfect world, sure. But the reality is that much of the world's devices use their ISP or google or their company resolver and accept whatever those resolvers say without doing validation in the OS. dukhovni> The only stub resolver one can expect to not be bypassed is dukhovni> the stub resolver in the OS libraries. These stub resolvers dukhovni> vary from OS to OS, and don't get a lot of maintainer dukhovni> attention. And that lack of love is why expecting the OS stub to be the good actor isn't a quick fix. dukhovni> So whether you like it or not, the burden is on the dukhovni> application, and any higher level libraries known to deliver dukhovni> syntactically validated results. Nothing to do with what I like. It's what the majority of the world does that we have to deal with. Asking the world to do better is worth trying but how many OS stub resolvers validate? How many in-browser stubs validate? On the other side, how many apps just take whatever the OS stub hands them and how many OS stubs just take whatever the upstream resolver hands them? We can't ignore reality and we must do what we can now. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
pe> DNS is a complicated, esoteric knowledge set. The reason apps, pe> middleware and various other boxes mucking with DNS in transit tend pe> to suck is exactly because the programmers on those boxes don't have pe> this expertise and make all sorts of bad assumptions about what is pe> safe/sane. pe> Resolver coders are vastly more likely to have knowledge of what pe> might break, what is unsafe, etc. And if they miss a check, the odds pe> of said resolver coders finding this out quickly, and fixing it and pe> getting it deployed, are much better than expecting apps or pe> middleware box developers to do so. dukhovni> The middleboxes will get it wrong, and will have stale dukhovni> firmware for decades. Do not place your trust in middleboxes. Read what I wrote above. I pointed out middleware boxes as places with mistake, not as where to try to fix it. dukhovni> The sanest viable place to do *some* common validation is in dukhovni> stub resolvers that support type-specific lookup functions dukhovni> above the basic (qname, qtype) interface, also perhaps in the dukhovni> system nsswitch and getaddrinfo()). The sanest but far less likely to be implemented in apps or apps libraries. Resolvers doing validation are far more likely to have current code and DNS aware developers. It would be lovely if that were in devices but is far more likely in the recursive resolvers they talk to. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
pe> Resolver coders are vastly more likely to have knowledge of what pe> might break, what is unsafe, etc. And if they miss a check, the odds pe> of said resolver coders finding this out quickly, and fixing it and pe> getting it deployed, are much better than expecting apps or pe> middleware box developers to do so. Just to be clear, I don't think this is the best architecture in a perfect world. I'd love to see all apps using a solid DNS library, like getdnsapi, doing their own validation, etc. and knowing what is/isn't valid data. I just don't see that as a reasonable expectation any time soon... ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Injection Attacks Reloaded: Tunnelling Malicious Payloads over DNS
dukhovni> I am far from convinced that it is the resolvers job to dukhovni> enforce RDATA syntax restrictions beyond what is required for dukhovni> a valid wire form. dukhovni> If applications make unwarranted assumptions about the syntax dukhovni> of DNS replies, that's surely an application bug, rather than dukhovni> an issue in DNS. ler762> I disagree. Programmers f**k up _all the time_ [...] ler762> M$ is still shipping buggy software; blaming programmers hasn't ler762> helped. I'm with Lee. DNS is a complicated, esoteric knowledge set. The reason apps, middleware and various other boxes mucking with DNS in transit tend to suck is exactly because the programmers on those boxes don't have this expertise and make all sorts of bad assumptions about what is safe/sane. Resolver coders are vastly more likely to have knowledge of what might break, what is unsafe, etc. And if they miss a check, the odds of said resolver coders finding this out quickly, and fixing it and getting it deployed, are much better than expecting apps or middleware box developers to do so. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] [Ext] DNS Flag Day 2020 will become effective on 2020-10-01
bsomers> My argument goes something like this. When a DNS request is bsomers> sent, the client (whether a stub or a resolver) is the most bsomers> qualified to know specifics about the "connection" and is also bsomers> the target of fragmentation attacks. I'd go the other end of the spectrum. I'd argue that neither client nor server has any clue of what horrible network crap lies in the path. There are so many badly implemented boxes built on the assumption that they have some right to muck with packets passing through them but with no skin in the game that end to end has to work. If you buy that assumption, smaller default is less operational risk. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] New OARC Chat Platform
warren> We've often discussed if the tools are useful / doing what we warren> want. My concern with this is that it requires yet another app warren> installed for people to communicate; I'm one of the first to bitch about this when I have to install yet another app. However, mattermost works fine in a browser, no app required. I was on firefox for the last OARC virtual meeting and had no issues with that method. dougb> I ask because OARC is taking on a lot, and from my naive and dougb> distant view seems to have developed a bit of NIH dougb> syndrome. Looking at the migration of dnsviz for example, it's dougb> not clear to me why OARC volunteered to take that project on dougb> without adequate resourcing. And subsequently it wasn't clear why dougb> cloud solutions weren't utilized, which I imagine could have been dougb> cheaper, and faster. To my knowledge the historical data is still dougb> missing, is that correct? I'd guess you're not a member and don't get the detailed breakdown of this in the member reports? Short version is that many of the decisions (including why cloud frequently isn't an option) boil down to member survey responses and restrictions in the data sharing agreements. Keith and the OARC staff evaluate choices based on these restrictions and then solicit member input before making final decisions. What you are seeing is not unilateral decisions by the staff but the staff implementing membership wishes. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] A strange DNS problem (intermittent SERVFAILs)
matthew-l> I wonder whether the first one (SERVFAIL for NS) is a clue. matthew-l> bcpe.fr is delegated to the same servers which do not answer matthew-l> NS queries. Thus, NS RRSET is only available from the parent matthew-l> (.fr) and not the child. Maybe this upsets child-centric matthew-l> resolvers. Likely. Comcast is using nominum, which is parent-centric. Works on their resolvers: $ dig @75.75.75.75 banquepopulaire.fr ns ; <<>> DiG 9.12.2 <<>> @75.75.75.75 banquepopulaire.fr ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62340 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;banquepopulaire.fr.IN NS ;; ANSWER SECTION: banquepopulaire.fr. 3600IN NS dns2.bpce.fr. banquepopulaire.fr. 3600IN NS dns1.bpce.fr. ;; Query time: 367 msec ;; SERVER: 75.75.75.75#53(75.75.75.75) ;; WHEN: Sat May 30 11:30:55 MDT 2020 ;; MSG SIZE rcvd: 90 ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Google DNS Admin
daniel> Thank you for this. Is there any chance at all I can get you to daniel> do a traceroute to daniel> 185.203.205.10 and 2a0c:d2c4::53:5:7335 daniel> And if you have access to a bgp speaking peer, show ip bgp daniel> 185.203.204.0/22 and show bgp ipv6 unicast 2a0c:d2c4::/32 (or daniel> whatever the equivalent commands are for your NOS). No access to BGP at home (on comcast) but traceroutes you requested, plus traceroute to the google DNS cluster I hit. I'm still getting SERVFAIL with google but answers with BIND on my home machine, 1.1.1.1, 9.9.9.9 and 75.75.75.75 (A 185.203.204.80). $ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 64 hops max, 52 byte packets 1 192.168.53.1 (192.168.53.1) 1.444 ms 0.753 ms 0.815 ms 2 cm-1-acr01.monument.co.denver.comcast.net (96.120.13.101) 9.467 ms 13.449 ms 10.993 ms 3 ae-251-1204-rur02.monument.co.denver.comcast.net (96.110.242.77) 12.304 ms 10.990 ms 9.913 ms 4 ae-2-rur01.monument.co.denver.comcast.net (68.86.128.53) 15.052 ms 11.507 ms 11.005 ms 5 ae-12-ar01.denver.co.denver.comcast.net (162.151.50.41) 11.986 ms 12.230 ms 16.904 ms 6 be-33652-cr02.1601milehigh.co.ibone.comcast.net (68.86.92.121) 14.233 ms 14.285 ms 13.753 ms 7 be-12176-pe02.910fifteenth.co.ibone.comcast.net (68.86.83.94) 12.938 ms 13.302 ms 12.611 ms 8 50.248.118.30 (50.248.118.30) 11.972 ms 12.271 ms as20940-2-c.nota.fl.ibone.comcast.net (23.30.207.162) 12.960 ms 9 * 108.170.252.193 (108.170.252.193) 11.656 ms 108.170.254.81 (108.170.254.81) 11.365 ms 10 72.14.238.163 (72.14.238.163) 12.465 ms 216.239.49.43 (216.239.49.43) 18.664 ms dns.google (8.8.8.8) 11.642 ms $ traceroute 185.203.205.10 traceroute to 185.203.205.10 (185.203.205.10), 64 hops max, 52 byte packets 1 192.168.53.1 (192.168.53.1) 2.224 ms 0.993 ms 0.827 ms 2 cm-1-acr01.monument.co.denver.comcast.net (96.120.13.101) 10.931 ms 10.939 ms 10.984 ms 3 ae-251-1204-rur02.monument.co.denver.comcast.net (96.110.242.77) 11.550 ms 11.297 ms 10.809 ms 4 ae-2-rur01.monument.co.denver.comcast.net (68.86.128.53) 11.324 ms 10.585 ms 9.765 ms 5 ae-12-ar01.denver.co.denver.comcast.net (162.151.50.41) 18.877 ms 11.066 ms 12.070 ms 6 be-33652-cr02.1601milehigh.co.ibone.comcast.net (68.86.92.121) 11.978 ms 13.961 ms 12.772 ms 7 be-12021-cr01.champa.co.ibone.comcast.net (68.86.84.225) 14.146 ms 14.047 ms 15.034 ms 8 be-11020-cr02.sunnyvale.ca.ibone.comcast.net (68.86.84.9) 37.075 ms 38.210 ms 47.025 ms 9 be-11025-cr01.9greatoaks.ca.ibone.comcast.net (68.86.87.158) 39.143 ms 39.997 ms 39.976 ms 10 be-11525-cr02.losangeles.ca.ibone.comcast.net (68.86.84.149) 46.988 ms 46.361 ms 48.798 ms 11 be-11599-pe01.losangeles.ca.ibone.comcast.net (68.86.84.194) 44.940 ms 45.188 ms 45.073 ms 12 50.248.117.226 (50.248.117.226) 45.797 ms 44.782 ms 45.995 ms 13 * * * 14 * * * 15 * * * 16 185.203.205.10 (185.203.205.10) 44.633 ms 110.503 ms 45.418 ms $ traceroute 2a0c:d2c4::53:5:7335 traceroute: unknown host 2a0c:d2c4::53:5:7335 [ebersman@fafnir:5683] traceroute6 2a0c:d2c4::53:5:7335 traceroute6 to 2a0c:d2c4::53:5:7335 (2a0c:d2c4::53:5:7335) from 2601:285:4000:35ec:10bc:cb08:9b23:8878, 64 hops max, 12 byte packets 1 2601:285:4000:35ec::1 0.857 ms 1.708 ms 0.831 ms 2 2001:558:4070:7d::1 9.935 ms 11.153 ms 11.007 ms 3 ae-251-1203-rur01.monument.co.denver.comcast.net 10.166 ms 10.597 ms 12.064 ms 4 2001:558:1c0:96::1 11.988 ms 12.044 ms 11.755 ms 5 be-33652-cr02.1601milehigh.co.ibone.comcast.net 13.001 ms 12.720 ms * 6 be-12021-cr01.champa.co.ibone.comcast.net 12.934 ms * * 7 be-11020-cr02.sunnyvale.ca.ibone.comcast.net 41.738 ms 37.761 ms * 8 * * * 9 * * * 10 be-11599-pe01.losangeles.ca.ibone.comcast.net 46.210 ms 44.872 ms 46.165 ms 11 2001:559:0:80::38a 46.795 ms 48.914 ms 45.955 ms 12 ethernetae1-er1-q8.lax3.choopa.net 48.152 ms 45.335 ms 44.977 ms 13 * * * 14 * * * 15 2a0c:d2c4::53:5:7335 47.064 ms 52.341 ms 46.048 ms ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
jreid> In principle, they could all change at once, In reality, they jreid> don't. dot> But they do. Vanuatu did yesterday, and I mentioned some other dot> recent examples in this thread a couple of weeks ago: dot> https://lists.dns-oarc.net/pipermail/dns-operations/2019-November/019486.html Yup. Especially with DNSSEC, where a mix and match of signatures is a complete nightmare, it's actually cleaner to have dual DS, both sets of keys in both providers' zones but only one set of NS in the parent, not mix and match. See Shumon's draft on multiprovider. It will make your eyes bleed but is so far the cleanest way we've found of doing provider changes too. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
mallman> I wonder if we're ever allowed to just decide this sort of mallman> thing is ridiculous old shit and for lots of reasons we can and mallman> should just garbage collect it away. ebersman> We aren't allowed as IETF/engineers. The world sort of is. ;) tale> I see the :) but I'm thinking the first sentence is serious. tale> Given the consensus model of the IETF, I absolutely think we're tale> allowed to decide we no longer have to be backwards compatible with tale> everything in perpetuity. Should have been clearer. My point is that we as the IETF can recommend and specify but we have no control over what users/companies/vendors do with it. And operationally, we have to be sympathetic to legacy and obsolescence needs. Things like DNS flag day are a good start, assuming we do stay flexible with respect to such user needs. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
ebersman> IPv4 reachable traditional DNS servers for some tiny group of ebersman> antique folks will be needed for years, even if we get 99+% of ebersman> the world to some new system. mallman> I wonder if we're ever allowed to just decide this sort of mallman> thing is ridiculous old shit and for lots of reasons we can and mallman> should just garbage collect it away. We aren't allowed as IETF/engineers. The world sort of is. ;) Eventually, someone wonders why they're burning money on something they don't see a need for any more. Sadly, based on the number of IBM AS400s in service, the COBOL programs with no source still being used, SNA, X.25 and all sorts of other stuff that you'd think would have been dead decades ago, I'm not betting on this happening any time soon. mallman> To me, this whole notion is that we can in fact get rid of this mallman> giant network service. If we don't get rid of it then what is mallman> the incentive to move one's own resolver away from using the mallman> root nameservers? But what would we replace it with? Who would run it? How would we get uniqueness, data integrity, high availability, decent coherence? How would we get something the entire world would use? Part of why DNS is so abused and misused is that it's already here and it mostly scales/works. We did it before the world knew about the internet. Now there's way more attention, money, and politics that get in the way of truly massive changes. If DNS started from scratch today, it's not clear it would happen. Not saying it's impossible but it will be a daunting task and will have to be really really compelling (or be the next user loved shiny-ball/Pokemon). Look at how much fun and progress there is moving from IPv4 to IPv6. mallman> Maybe 99% lets us draw down the size of the root mallman> infrastructure...I dunno. But, if we don't say something like mallman> "it's going to go away" then I am not sure resolvers will move mallman> away from it. The problem/load isn't the folks that would upgrade. It's crap broken code/devices that are in many cases forgotten in closets or under desks. The magic blue smoke will have to pour out the back before they stop sending useless crap to the root servers. A6 records were never officially "blessed". We went with . We were all pretty sure they would never be used. But last I heard, the root servers still see A6 queries. Google for Geoff Huston's zombie DNS preso for more scary/bad stories. Love to see your proposal for a replacement. Just be prepared to have to support whatever that is and DNS both for a very long time. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
mallman> Setting aside history and how things have been done and why mallman> (which I am happy to stipulate is rational)... At this point, mallman> are there tangible benefits for getting information about the mallman> TLD nameservers to resolvers as needed via a network service? The biggest problem I see here is the legacy/long-tail problem. As of a few years ago, I bumped into BIND 4 servers still active. Wouldn't be shocked to hear they are still being used. IPv4 reachable traditional DNS servers for some tiny group of antique folks will be needed for years, even if we get 99+% of the world to some new system. Doesn't mean we shouldn't be thinking about a better way to do it for that 99% though. mallman> Are there fundamental problems that would arise in recursive mallman> resolvers if the information about TLD nameservers was no mallman> longer available via a network service, but instead had to come mallman> from a file that was snarfed periodically? /etc/hosts.txt via bittorrent instead of ftp from sri-nic? :) The DNS is only billed as loosely coherent, so conceptually this could work. But I'd have to be convinced it was enough better in terms of data integrity, coherence and availability than the current DNS/DNSSEC to be worth the pain of changing that much code on all those devices/servers. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
ebersman> Actually, it's a great argument for longer TTLs and caching ebersman> doing what they're supposed to. jim> It would be if the root only got queries from well behaved jim> recursive resolvers. But we both know Paul that simply isn't true. jim> Well over 90% of the query traffic at the root has no reason to be jim> going there at all. For instance stub resolvers that don't care jim> about TTLs or do any sort of caching, Chrome's 10-character nonce jim> strings to detect NXDOMAIN rewriting, CPE querying for .home, jim> enterprises leaking queries for .corp, etc, etc. You cut off the last line of my post: ebersman> But compared to a large corp DNS server farm, the root servers ebersman> shovel a lot of bits. Some of it even valid DNS queries and ebersman> responses. ;) Yes. Most of it is crap and the normal DNS rules don't apply. But TTLs and caching do help (less with root than TLD due to garbage problem) and the orders of magnitude differences in size of traffic between root/TLD and large recursive farms is still valid. We started this with "what's a lot of traffic" and I think you and I would agree defining "lots" is very dependent on what DNS role you play. And we've both been around long enough to agree that even if well behaved and well designed DNS start shifting to local root and similar, there's enough just crap and enough legacy/old folks needing traditional root that we're going to be upgrading the traditional root architecture for a long long time. But every bit helps, so local root, saner TTLs, solid caching layer are all still worth building as well. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] root? we don't need no stinkin' root!
jim> What do you consider to be a lot of queries? The root server system jim> collectively handles 500K-1M queries per second. That seems rather jim> a lot to me. YMMV. fw> But globally? For the entire planet? fw> It's certainly beyond what I can run out of my basement using spare fw> parts, but it's also not a mindbogglingly huge number. I would have fw> expected something that's clearly impossible to handle from a single fw> box. Actually, it's a great argument for longer TTLs and caching doing what they're supposed to. The root zones and most TLDs tend to have longer, non trendy (over 5 minute) TTLs, so root servers, TLDs and other auth servers get orders of magnitude less queries than large recursive farms, which cache and then get cache hits. Comcast & Google get 2-3 orders of magnitude more than large TLD servers and 4-5 orders of magnitude more than the root servers and these two probably represent something like 1/3 of public recursive server traffic. The largest Chinese ISP used to do more traffic then either of the above. But compared to a large corp DNS server farm, the root servers shovel a lot of bits. Some of it even valid DNS queries and responses. ;) ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Link-local IP addresses for a resolver?
ebersman> No need to shout... And the same could be said of RFC 1918 but ebersman> ISPs have used that for thousands of homes, crossing thousands ebersman> of CPEs. Not the best choice and not your choice but it does ebersman> work for some folks. marka> Advertising RFC 1918 address as DNS servers by the ISP is also marka> wrong as the ISP has zero knowledge of which addresses are in use marka> by the customer and is actually prohibited by RFC1918 as they are marka> being advertised outside of the site. It doesn't mean that marka> there are not ISP's that do that but it isn't expected to marka> work. Comcast pushed for IPv6 to avoid this but was up to a 3rd round use of all of 10.x.x.x before that happened. So it can work and even scale, even if it's not optimal. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Link-local IP addresses for a resolver?
marka> When a *ISP* advertises a DNS server to its *customers* IT SHOULD marka> WORK FOR ALL OF THE CUSTOMER'S MACHINES! That doesn't mean it can't be ULA. And it would be hideous but you can use LL if you flatten the broadcast domain. There are lots of reasons why this isn't the best idea but you don't know everyone's network, so saying "that's bad and I'd never do it so we shouldn't support it" at the network layer isn't a reasonable answer. marka> The CPE is a SITE boundary. It is also a Link-Local marka> Boundary. ULA source packets DO NOT cross the CPE by default it marka> the CPE is properly configured. Link-Local packets should NEVER marka> cross the CPE as it is NOT A BRIDGE/SWITCH but is a router. No need to shout... And the same could be said of RFC 1918 but ISPs have used that for thousands of homes, crossing thousands of CPEs. Not the best choice and not your choice but it does work for some folks. "site boundary" and what is "local" in ULA have never been well defined because of this. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
Re: [dns-operations] Link-local IP addresses for a resolver?
marka> DNS servers that are expected to be reached across sites need to marka> be globally unique addresses which ULA and LL are not. The IP address clients use to reach the resolver doesn't have to be the same one that the resolver uses as source address when it queries. And it's not uncommon to have an externally exposed recursive resolver on the public side of a corporate firewall with queries from an internal resolver being forwarded. Using ULA/LL for the clients doesn't mean it can't be a used as a functional resolver via said forwarding/alternate address. Not saying I think using LL/ULA is a more secure architecture but it can be functional and should work on the local broadcast domain/LAN. ___ dns-operations mailing list dns-operations@lists.dns-oarc.net https://lists.dns-oarc.net/mailman/listinfo/dns-operations
