Re: Delegation questions
Forwarding is more similar to how some other systems work. But it's not how DNS naturally works. I think the biggest source of "forwarding = natural" is perhaps from admins coming from other parts of IT, rather than any regional difference. But I could be wrong. From a technical perspective, in addition to the performance factor that Kevin described, there is the fact that forwarding is inherently brittle. (So are stub zones, for different reasons.) So the more you forward, the harder it becomes to troubleshoot the inevitable problems that will arise, because you have more systems to check and more ways for things to go wrong. Regards, Chris Sent from my iPhone > On Aug 12, 2016, at 5:11 PM, Darcy Kevin (FCA) > wrote: > > True, strictly from a per-hop latency standpoint, there shouldn't be much > difference between forwarding a packet or forwarding a DNS query. > > Having said that -- and I'm sure the BIND developers could elaborate further > on this -- I know that there's big difference between processing *packets*, > from, say, a routing standpoint, which customized ASIC-level hardware can do > to the tune of millions per second, and processing *queries*, which are much > higher-level constructs, with a lot more variation, more levels of parsing, > disassembly, re-assembly, validation, etc. When you have multi-hop DNS > forwarding, you're using up significant resources on multiple computing > devices at once, in ways that don't necessarily lend themselves to > optimization in hardware. It ends up being the opposite of parallelism, i.e. > using the resources of multiple devices to accomplish something that could, > with only configuration changes, be accomplished with the resources of only > one device. > > At the risk of sounding xenophobic, there seems to be a mindset among certain > cultures that forwarding is "natural", and, in contrast, having DNS instances > talk to each other directly is somehow "artificial". I've had this > conversation many times with many of my European counterparts over the years, > and we just seem to view things differently. One could speculate on the > difference in world view -- submission to higher authority, perhaps? > Hierarchical social organization? I don't know -- I don't claim any expertise > whatsoever in sociology, cognitive psychology, or related fields. But for me, > and I think most people in my (North American) culture -- possibly because we > tend more towards individualism and/or egalitarianism? -- having DNS > instances talk *directly* to each other, as "equals" or "peers", is much more > natural than one DNS instance relying upon another to handle all of its > resolution needs (thus making the first instance subservient, in a sense, to > the second), which then relies on another, and to another, and so on, in a > daisy chain. > > Again, maybe it's just a different mindset/world-view. Or, perhaps I'm > over-generalizing a cultural difference from a relatively-small sample of > conversations. But, as I touched on in my second paragraph, there may be some > objective reasons to eschew forwarding, particularly multi-hop forwarding. > >- Kevin > > > -Original Message- > From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of > Willmann, Robert > Sent: Friday, August 12, 2016 1:33 AM > To: bind-users@lists.isc.org > Subject: RE: Delegation questions > > Kevin Darcy wrote: >> >> In any case, multi-hop forwarding is always the least-preferred option. > > I wonder for which reason do you think this. > > Of course, any forwarding adds a additional hop and therefore additional > delay and an additional possible point of failure. > But this is true for any network-connection. > > So, what do you think are the DNS-specific downsides of forwarding? > The only thing that comes to mind if I think about downsides of forwarding is > that, if something goes wrong, the client only gets a generic SERVFAIL as > errormessage instead of a specific explanation what exactly went wrong. > > Do you see other downsides to forwarding? > > > Mit freundlichen Grüßen > Robert Willmann > > -- > Commerzbank AG > Group Information Technology > GS-IT 8.2.3 Core Services > > Postanschrift: 60261 Frankfurt am Main > Geschäftsräume: Mainzer Landstr. 151, 60327 Frankfurt am Main > Tel.:+49 69 136 - 290 71 > Fax:+49 69 136 - 590 71 > robert.willm...@commerzbank.com > > Commerzbank AG, Frankfurt am Main http://www.commerzbank.de Pflichtangaben > http://www.commerzbank.de/pflichtangaben > > > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe > from this list > > bind-users mailing list > bind-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/bind-users > ___ > Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsub
RE: Delegation questions
True, strictly from a per-hop latency standpoint, there shouldn't be much difference between forwarding a packet or forwarding a DNS query. Having said that -- and I'm sure the BIND developers could elaborate further on this -- I know that there's big difference between processing *packets*, from, say, a routing standpoint, which customized ASIC-level hardware can do to the tune of millions per second, and processing *queries*, which are much higher-level constructs, with a lot more variation, more levels of parsing, disassembly, re-assembly, validation, etc. When you have multi-hop DNS forwarding, you're using up significant resources on multiple computing devices at once, in ways that don't necessarily lend themselves to optimization in hardware. It ends up being the opposite of parallelism, i.e. using the resources of multiple devices to accomplish something that could, with only configuration changes, be accomplished with the resources of only one device. At the risk of sounding xenophobic, there seems to be a mindset among certain cultures that forwarding is "natural", and, in contrast, having DNS instances talk to each other directly is somehow "artificial". I've had this conversation many times with many of my European counterparts over the years, and we just seem to view things differently. One could speculate on the difference in world view -- submission to higher authority, perhaps? Hierarchical social organization? I don't know -- I don't claim any expertise whatsoever in sociology, cognitive psychology, or related fields. But for me, and I think most people in my (North American) culture -- possibly because we tend more towards individualism and/or egalitarianism? -- having DNS instances talk *directly* to each other, as "equals" or "peers", is much more natural than one DNS instance relying upon another to handle all of its resolution needs (thus making the first instance subservient, in a sense, to the second), which then relies on another, and to another, and so on, in a daisy chain. Again, maybe it's just a different mindset/world-view. Or, perhaps I'm over-generalizing a cultural difference from a relatively-small sample of conversations. But, as I touched on in my second paragraph, there may be some objective reasons to eschew forwarding, particularly multi-hop forwarding. - Kevin -Original Message- From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Willmann, Robert Sent: Friday, August 12, 2016 1:33 AM To: bind-users@lists.isc.org Subject: RE: Delegation questions Kevin Darcy wrote: > > In any case, multi-hop forwarding is always the least-preferred option. > I wonder for which reason do you think this. Of course, any forwarding adds a additional hop and therefore additional delay and an additional possible point of failure. But this is true for any network-connection. So, what do you think are the DNS-specific downsides of forwarding? The only thing that comes to mind if I think about downsides of forwarding is that, if something goes wrong, the client only gets a generic SERVFAIL as errormessage instead of a specific explanation what exactly went wrong. Do you see other downsides to forwarding? Mit freundlichen Grüßen Robert Willmann -- Commerzbank AG Group Information Technology GS-IT 8.2.3 Core Services Postanschrift: 60261 Frankfurt am Main Geschäftsräume: Mainzer Landstr. 151, 60327 Frankfurt am Main Tel.: +49 69 136 - 290 71 Fax:+49 69 136 - 590 71 robert.willm...@commerzbank.com Commerzbank AG, Frankfurt am Main http://www.commerzbank.de Pflichtangaben http://www.commerzbank.de/pflichtangaben ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation questions
Am 12.08.2016 um 11:07 schrieb Willmann, Robert: Hi Harald, Do you see other downsides to forwarding? you get the lowest TTL in the whole chain and god beware none of the multi-hop forwarders have a cache hit so it makes it to the last in chain doing then recursion - it's a simple "worst case math" Do you ever have seen a significant issue with this in real life? frankly i have seen so many problems caused by forwarding at all (at random times websites not reachable due dns errors) and never faced after switched anything to either recursion or authoritative Some companies I forward queries t, even give back their answers with a TTL of zero that's not smart to do, even RBL's like Spamhaus have 5 seconds and when you think about a client running in a loop you may understand why it's better have it only once every 5 secods on the DNS server so there is not even a theoretical difference in the TTL between forwarding and other means of resolution in these cases. that is not a typical real life case signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Delegation questions
Am 12.08.2016 um 07:32 schrieb Willmann, Robert: Kevin Darcy wrote: In any case, multi-hop forwarding is always the least-preferred option. I wonder for which reason do you think this. Of course, any forwarding adds a additional hop and therefore additional delay and an additional possible point of failure. But this is true for any network-connection. So, what do you think are the DNS-specific downsides of forwarding? The only thing that comes to mind if I think about downsides of forwarding is that, if something goes wrong, the client only gets a generic SERVFAIL as errormessage instead of a specific explanation what exactly went wrong. Do you see other downsides to forwarding? you get the lowest TTL in the whole chain and god beware none of the multi-hop forwarders have a cache hit so it makes it to the last in chain doing then recursion - it's a simple "worst case math" signature.asc Description: OpenPGP digital signature ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
RE: Delegation questions
Hi Harald, > > Do you see other downsides to forwarding? > > you get the lowest TTL in the whole chain and god beware none of the > multi-hop forwarders have a cache hit so it makes it to the last in chain > doing then recursion - it's a simple "worst case math" Do you ever have seen a significant issue with this in real life? Some companies I forward queries t, even give back their answers with a TTL of zero - so there is not even a theoretical difference in the TTL between forwarding and other means of resolution in these cases. Mit freundlichen Grüßen Robert Willmann -- Commerzbank AG Group Information Technology GS-IT 8.2.3 Core Services Postanschrift: 60261 Frankfurt am Main Geschäftsräume: Mainzer Landstr. 151, 60327 Frankfurt am Main Tel.: +49 69 136 - 290 71 Fax:+49 69 136 - 590 71 robert.willm...@commerzbank.com Commerzbank AG, Frankfurt am Main http://www.commerzbank.de Pflichtangaben http://www.commerzbank.de/pflichtangaben ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
