|
|
| (3 intermediate revisions by 2 users not shown) |
| Line 1: |
Line 1: |
| | | Content moved to M204int page of same name, but history preserved here. |
| The following features are new or changed in <var class="product">[[Janus TCP/IP Base]]</var>.
| |
|
| |
| ==DNS Retries==
| |
| Prior to <var class="product">[[Sirius Mods]]</var> Version 7.8,
| |
| the [[JANUS NAMESERVER]] command had no facility to call for a retry of
| |
| a DNS UDP packet for which no response is received.
| |
| This meant that if <var class="product>Janus</var> does a DNS lookup just when the target nameserver
| |
| is down for an instant, or if the UDP packet gets lost on the network (IP
| |
| networks don't have to guarantee delivery of IP packets), the DNS lookup
| |
| could fail.
| |
|
| |
| The version 7.8 "DNS Retries" feature is
| |
| a RETRIES parameter for the JANUS NAMESERVER command.
| |
| Setting RETRIES to a positive integer value, say 2, instructs <var class="product>Janus</var>
| |
| to retry as many as two times if no response was received to a DNS lookup.
| |
| Setting RETRIES to 0, its default, means no retries are attempted.
| |
|
| |
| On a swamped network, it is probably better to
| |
| set a JANUS NAMESERVER TIMEOUT value of, say, 3 and a RETRIES setting of 2, rather than to set TIMEOUT to
| |
| 10 with RETRIES 0. This is so because:
| |
| *If a packet gets dropped, there is no benefit to waiting 10 seconds instead of 3.
| |
| *It is very unlikely that it would take a nameserver 3 seconds to respond to a received request (including packet turnaround time).
| |
|
| |
| It probably does not make sense to set RETRIES
| |
| to a value greater than 2: if packets are being dropped so frequently
| |
| that three consecutive DNS requests are dropped, you have problems much more serious than the failed lookups.
| |
|
| |
| | |
| {{Template:Content index: V7.8 Release Notes}}
| |