User Tools

Site Tools


infoblox_nios:dns

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision
Previous revision
infoblox_nios:dns [2025/07/18 22:47] – [Anycast] bstaffordinfoblox_nios:dns [2025/12/18 11:00] (current) – [External DNS] bstafford
Line 98: Line 98:
 ===== Anycast ===== ===== Anycast =====
 Remember, for Anycast, you need to setup the Anycast IP on the member, then edit the member's DNS properties and configure it to accept queries on the Anycast IP (General > Basic tab). It may then take a minute to apply. Remember, for Anycast, you need to setup the Anycast IP on the member, then edit the member's DNS properties and configure it to accept queries on the Anycast IP (General > Basic tab). It may then take a minute to apply.
 +
 +
 +The default values  for BGP timers as per RFC 4271 is Keepalive=60 seconds and Hold Timer=180 seconds, as Hold timer is recommended to be 3x of the Keepalive per RFC.
 +
 +Consider using 4 seconds for Keepalive and 16 seconds for Hold Timer as the industry recommendation for faster convergence (e.g. in data centres and high-performance networks) is between 3-10 for keep alive and hold timer between 9-30 (3x of keep alive).
 +
 +The higher values are usually kept in consideration for stable, low-bandwidth or high-latency networks (usually for long-distance peerings).
 +
 +
  
  
Line 130: Line 139:
 Don't put a second anycast IP on all the same Anycast servers. E.g. Say you had two DNS servers in AMER, two in EMEA, and two in APAC. You would put one Anycast IP on the first server in every GEO and a second Anycast IP on the second server in every GEO. Make sure that the two Anycast IP addresses cannot be summerised in teh same route internally. Exactly how far appart the two IP's should be depends on how far you summarise the routes internally. Don't put a second anycast IP on all the same Anycast servers. E.g. Say you had two DNS servers in AMER, two in EMEA, and two in APAC. You would put one Anycast IP on the first server in every GEO and a second Anycast IP on the second server in every GEO. Make sure that the two Anycast IP addresses cannot be summerised in teh same route internally. Exactly how far appart the two IP's should be depends on how far you summarise the routes internally.
  
-If you have one anycast IP and want to use a secondary IP that is non-anycast as backup, make sure that the secondary IP is NEVER in the same DC as the endpoint's given the secondary IP. For example, if you have three datacenters, if you have endpoints in DC1 that use the DC1 local DNS IP and the Anycast IP, then if anything happens to the DNS server in DC1, routing won't update immediatley (BFD can help keep route converging to a few seconds) so both the primary and secondary DNS servers queried will both go to the (faulty) DNS server in DC1. Causing an outage for endpoints in DC1. This is why DC1 should have Anycast + a local IP from a DC in another data center.+If you have one anycast IP and want to use a secondary IP that is non-anycast as backup, make sure that the secondary IP is NEVER in the same DC as the endpoint's given the secondary IP. For example, if you have three datacenters, if you have endpoints in DC1 that use the DC1 local DNS IP and the Anycast IP, then if anything happens to the DNS server in DC1, routing won't update immediately (BFD can help keep route converging to a few seconds) so both the primary and secondary DNS servers queried will both go to the (faulty) DNS server in DC1. Causing an outage for endpoints in DC1. This is why DC1 should have Anycast + a local IP from a DC in another data center.
  
 +Some notes on restart times:
 +  * With NIOS 8.6.x BIND waited 5 seconds for idle tasks to disappear and 20 seconds for active task before it forces a restart
 +  * With NIOS 9.0.x BIND does a graceful restart and doesn’t quit until all references have been released.
 +  * This results in a much longer restart of named
 +  * But, Starting with NIOS 9.0.3-CHF3 and later, we can change the behavior of BIND to match the NIOS 8.6.x behavior:
 +    * You will need to SSH to the Grid and login with your credentials
 +    * You will enter the NIOS CLI where you can execute the following command:
 +    * set named_max_exit_wait 5
 +    * With this configuration change the BIND restart behavior has changed and new named restarts will be faster to avoid the long dns restart and the long DNS service disruption
 +    * Note: look for the message "all zones loaded" to see when BIND has fully restarted.
 +        
 +        
 ===== LAN2 ===== ===== LAN2 =====
 To get a NIOS appliance to receive DNS queries on LAN1 but then send queries (i.e. recursion) on LAN2 (e.g. in a bridged DMZ where LAN1 = internal network and LAN2 = external network), then under the member properties in Grid go to General > Basic and toggle "Send queries from" LAN2 interface. And "Send notify messages and zone transfer requests from" LAN2 interface. To get a NIOS appliance to receive DNS queries on LAN1 but then send queries (i.e. recursion) on LAN2 (e.g. in a bridged DMZ where LAN1 = internal network and LAN2 = external network), then under the member properties in Grid go to General > Basic and toggle "Send queries from" LAN2 interface. And "Send notify messages and zone transfer requests from" LAN2 interface.
Line 138: Line 159:
  
 ISP's might implement this to help mitigate (i.e. continue with cache responses in case of massive Authoritative failure) the end user impact of incidents such as the [[https://en.wikipedia.org/wiki/2021_Facebook_outage|Facebook BGP/DNS outage]] in November 2021. ISP's might implement this to help mitigate (i.e. continue with cache responses in case of massive Authoritative failure) the end user impact of incidents such as the [[https://en.wikipedia.org/wiki/2021_Facebook_outage|Facebook BGP/DNS outage]] in November 2021.
 +
 +===== TCP Client Limit =====
 +TCP DNS is "more expensive" than UDP DNS, with session stand-up/tear-down, but it is no where close to the resource needed for DoT/DoH.
 +
 +Max number of TCP DNS clients is 1,000 by default and this is enough for a lot of organizations. 25k is the max you can set it to.
 +
 +You may need to change quota for TCP clients in two parts (assuming NIOS 9)
 +  - adjusting the named_tcp_clients_limit
 +  - ensure that there are enough sockets available. By default (again, NIOS 9), the number of sockets is 21,000 and thus your adjustment will be in range. Unfortunately, the value for sockets is dictated by recursive client quote and is recursive client quote + 1,000, except when at 1,000 where it's + 20,000. If the recursive client quota has been adjusted, and there aren't going to be enough sockets, there's also a command to adjust the max sockets that DNS can use ''set named_tcp named_max_socket N'' Note that you should ONLY adjust the ''named_max_socket'' value if you know the value is too low; check the logs when named starts to see how many sockets are being allocated -- if it's less than recursive_client_quota + named_tcp_clients_limit + 1,000, it's too small.
 + 
 +
  
 ===== External DNS ===== ===== External DNS =====
-To hide private IP of LAN1 interface when NIOS is externally facing,+To hide private IP of LAN1 interface when NIOS is externally facing (e.g. in Azure),
  
-Data Management->DNS->Members, edit member, Views. +Data Management->DNS->Members, edit member, (advanced) > DNS Views > (basic tab)
  
-Click on "Interface IP Address" for the view, change it to "Other IP Address", then type in the IP you want published for glue in the view for the member.+In the appropriate View, click on "Interface IP Address" for the view (it doesn't look 'clickable' until you actually click it), change it to "Other IP Address", then type in the IP you want published for glue in the view for the member. In this case it is likely to be the public IP of the DNS server. This will automatically update the SOA record as well as the IP addresses for the associated NS and A records.
  
 Or you can make the NIOS entries in the Name Server Group to be "Stealth" and then add the external IP addresses as External Secondaries. Or you can make the NIOS entries in the Name Server Group to be "Stealth" and then add the external IP addresses as External Secondaries.
 +
 +
 +Remember, if you have a third party DNS transferring from your NIOS external DNS servers, if the Grid Primary goes offline, the Grid Secondary will still get updated (via Grid Transfer). Enable Grid secondaries to notify external secondaries. 
 +
 +Data Management > DNS > Grid DNS Properties > General > Advanced > 
 +  * [[https://docs.infoblox.com/space/nios90/281182286/Notifying+External+Secondary+Servers|Enable Grid secondaries to notify external secondaries]]: This option is enabled by default.
 +  * Notify Delay: Specify the number of seconds that the Grid secondary servers delays sending notification messages to the external secondaries. The default is five seconds.
 +
 +"Enable grid secondaries to notify external secondaries: Select this check box to allow secondary name servers in a Grid to send notify messages to secondary name servers outside the Grid. Enabling this option increases the number of notify messages; however, it ensures that an external secondary name server receives notify messages when its master is a secondary name server in a Grid."
 ===== DNS Views ===== ===== DNS Views =====
 Multiple views on a member, fine. Looping/Forwarding between views is not fine. Possible and, in some cases, necessary, but not fine. It also means that the NIOS member probably cannot use itself as a resolver because it will often match the "wrong" view. Multiple views on a member, fine. Looping/Forwarding between views is not fine. Possible and, in some cases, necessary, but not fine. It also means that the NIOS member probably cannot use itself as a resolver because it will often match the "wrong" view.
Line 190: Line 231:
  
 If you need to increase, do so 1k at a time. If you need to increase, do so 1k at a time.
 +
 +[[https://docs.infoblox.com/space/nios90/280665882/Enabling+Recursive+Queries|Documentation page]]
 +Recursion client quota as printed in syslog
 +<code>
 +Recursion client quota: used/max/soft-limit/s-over/hard-limit/h-over/low-pri = 19005/23288/29900/0/30000/0/19005
 +
 +
 +/used /max /soft-limit /s-over /hard-limit /h-over /low-pri 
 +/21415 /24100 /29900 /0 /30000 /0 /21415</code>
 +
 +
 +
 +
  
 [[https://community.infoblox.com/t5/trending-kb-articles/support-central-kb-118-what-does-quot-no-more-recursive-clients/ba-p/6321|KB Article]] - If you want to increase the number of outstanding recursive queries on the recursive name server, confirm that you have adequate memory available for that number of outstanding recursive queries and for other services that are configured on the same server. Every recursive query can take about 20 kilobytes. [[https://community.infoblox.com/t5/trending-kb-articles/support-central-kb-118-what-does-quot-no-more-recursive-clients/ba-p/6321|KB Article]] - If you want to increase the number of outstanding recursive queries on the recursive name server, confirm that you have adequate memory available for that number of outstanding recursive queries and for other services that are configured on the same server. Every recursive query can take about 20 kilobytes.
infoblox_nios/dns.1752878856.txt.gz · Last modified: by bstafford