mirror of https://github.com/ipxe/ipxe.git
2acdc92994
We currently define the active DNS server as a global variable. All queries will start by attempting to contact the active DNS server, and the active DNS server will be changed only if we fail to get a response. This effectively treats the DNS server list as expressing a weak preference ordering: we will try servers in order, but once we have found a working server we will stick with that server for as long as it continues to respond to queries. Some sites are misconfigured to hand out DNS servers that do not have a consistent worldview. For example: the site may hand out two DNS server addresses, the first being an internal DNS server (which is able to resolve names in private DNS domains) and the second being a public DNS server such as 8.8.8.8 (which will correctly return NXDOMAIN for any private DNS domains). This type of configuration is fundamentally broken and should never be used, since any DNS resolver performing a query for a name within a private DNS domain may obtain a spurious NXDOMAIN response for a valid private DNS name. Work around these broken configurations by treating the DNS server list as expressing a strong preference ordering, and always starting DNS queries from the first server in the list (rather than maintaining a global concept of the active server). This will have the debatable benefit of converting permanent spurious NXDOMAIN errors into transient spurious NXDOMAIN errors, which can at least be worked around at a higher level (e.g. by retrying a download in a loop within an iPXE script). The cost of always starting DNS queries from the first server in the list is a slight delay introduced when the first server is genuinely unavailable. This should be negligible in practice since DNS queries are relatively infrequent and the failover expiry time is short. Treating the DNS server list as a preference ordering is permitted by the language of RFC 2132, which defines DHCP option 6 as a list in which "[DNS] servers SHOULD be listed in order of preference". No specification defines a precise algorithm for how this preference order should be applied in practice: this new approach seems as good as any. Requested-by: Andreas Hammarskjöld <junior@2PintSoftware.com> Signed-off-by: Michael Brown <mcb30@ipxe.org> |
||
|---|---|---|
| .. | ||
| 80211 | ||
| infiniband | ||
| oncrpc | ||
| tcp | ||
| udp | ||
| aoe.c | ||
| arp.c | ||
| dhcpopts.c | ||
| dhcppkt.c | ||
| eap.c | ||
| eapol.c | ||
| eth_slow.c | ||
| ethernet.c | ||
| fakedhcp.c | ||
| fc.c | ||
| fcels.c | ||
| fcns.c | ||
| fcoe.c | ||
| fcp.c | ||
| fragment.c | ||
| icmp.c | ||
| icmpv4.c | ||
| icmpv6.c | ||
| infiniband.c | ||
| iobpad.c | ||
| ipv4.c | ||
| ipv6.c | ||
| ndp.c | ||
| neighbour.c | ||
| netdev_settings.c | ||
| netdevice.c | ||
| nullnet.c | ||
| pccrc.c | ||
| pccrd.c | ||
| peerblk.c | ||
| peerdisc.c | ||
| peerdist.c | ||
| peermux.c | ||
| ping.c | ||
| rarp.c | ||
| retry.c | ||
| rndis.c | ||
| socket.c | ||
| stp.c | ||
| tcp.c | ||
| tcpip.c | ||
| tls.c | ||
| udp.c | ||
| validator.c | ||
| vlan.c | ||