{"type":"rich","version":"1.0","author_name":"npub1t6suh64e65qzzjtthffl6sa3cagp6k9usnx4qev4jsjzf7xud8psdhe2py","author_url":"https://nostr.ae/npub1t6suh64e65qzzjtthffl6sa3cagp6k9usnx4qev4jsjzf7xud8psdhe2py","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-05-19\n📝 Original message:On Mon, 19 May 2014 19:49:52 -0400, Jeff Garzik wrote:\n\u003e On Mon, May 19, 2014 at 4:36 PM, Robert McKay \u003crobert at mckay.com\u003e \n\u003e wrote:\n\u003e\u003e It should be possible to configure bind as a DNS forwarder.. this \n\u003e\u003e can\n\u003e\u003e be done in a zone context.. then you can forward the different zones \n\u003e\u003e to\n\u003e\u003e different dnsseed daemons running on different non-public IPs or two\n\u003e\u003e different ports on the same IP (or on one single non-public IP since\n\u003e\u003e there's really no reason to expose the dnsseed directly daemon at \n\u003e\u003e all).\n\u003e\n\u003e Quite the opposite.  dnsseed data rotates through a lot of addresses\n\u003e if available.  Using the bind/zone-xfer system would result in fewer\n\u003e total addresses going through to the clients, thanks to the addition\n\u003e of caching levels that the bind/zone-xfer system brings.\n\u003e\n\u003e That said, if the choice is between no-service and bind, bind it is \n\u003e ;p\n\nSetting it up as a zone forwarder causes each request to go through to \nthe dnsseed backend for each request.\n\nRob"}