Le partage de l'internet distribue une mauvaise adresse de serveur DNS

En article votre référence était en effet correcte pour la date de publication et c'est ainsi que cela fonctionne avant Mavericks. Sous Mountain Lion, 'named' est lancé lorsque le partage Internet est actif avec /etc/com.apple.named.proxy.conf comme fichier de configuration. Tout ceci est observable sous Mountain Lion - je l'ai vérifié.

Cependant, la résolution des noms de domaine n'est pas seulement basée sur le DNS sous OS X comme c'est le cas dans d'autres OSen, mais plutôt sur les Directory Services -- qui permettent des recherches DNS à partir de flat-files, NIS, NetInfo, LDAP, ZeroConfig/Bonjour ... et DNS -- et c'est mDNSResponder qui est utilisé pour la résolution de ces tournures de noms. (D'après sa page de manuel mDNSResponder is also the system-wide Unicast DNS Resolver . C'est ce qui fait (ou devrait faire) la résolution DNS pour vos clients Internet partagés sous Mavericks. (Il est étrange qu'ils aient démarré named sous Mt Lion plutôt que d'utiliser mDNSResponder à l'époque).

Lorsque le partage d'Internet est activé, soit named (pré-Mavericks), soit mDNSResponder (Mavericks) est le "serveur DNS" qui doit effectuer la résolution de noms pour le partage d'Internet, et cela fait correctement de 192.168.2.1 le serveur DNS pour les clients NAPT du partage d'Internet. La réponse directe et simple à vos questions est donc qu'il ne distribue pas la "mauvaise adresse de serveur DNS".

Cette démonstration a fonctionné pour moi lorsque j'ai configuré le partage Internet pour partager ma connexion WiFi via Ethernet. Les clients desservis par Internet Sharing qui envoyaient des requêtes DNS à 192.168.2.1 recevaient correctement ces requêtes à partir d'un navigateur et, lorsqu'ils émettaient un dig @192.168.2.1 apple.com J'ai observé cela en action avec tcpdump pour vérifier. Tout fonctionne comme on peut s'y attendre.

Je constate que dans cette configuration, je peux également, à partir du Mac d'hébergement telnet 192.168.2.1 53 et se connecter à mDNSResponder. Je constate également que l'ordre de service des réseaux configurés est défini de telle sorte que le WiFi a la priorité sur l'Ethernet.

Cependant, en procédant à l'inverse, en partageant la connexion Ethernet via le WiFi, j'ai d'abord rencontré le même problème que vous. J'ai vu la requête DNS UDP envoyée mais aucune réponse, comme vous l'avez observé. Le ping est passé par 8.8.8.8 et la résolution contre 8.8.8.8 à l'aide de dig a également fonctionné correctement. J'étais prêt à écrire qu'il s'agissait d'un bogue, mais j'ai eu l'occasion de redémarrer mon MacBook Pro et j'ai réessayé, en m'assurant cette fois que l'Ethernet avait la priorité sur le WiFi dans l'ordre de service du panneau de préférences du réseau. Cette fois-ci, cela a "juste fonctionné" et je n'ai pas été en mesure de recréer le problème. Le problème a été résolu en redémarrant et en vérifiant l'ordre de service.

En outre, j'ai vérifié que je pouvais le faire :

• Numéro un dig @192.168.2.1 apple.com d'un client (assigné à 192.168.2.3) de l'Internet Sharing et recevoir une réponse positive. J'ai également observé la requête et la réponse UDP à l'aide de tcpdump :

01:01:05.620240 IP 192.168.2.3.58817 > 192.168.2.1.domain: 34923+ A? apple.com. (27) 01:01:06.051566 IP 192.168.2.1.domain > 192.168.2.3.58817: 34923 3/0/0 A 17.149.160.49, A 17.172.224.47, A 17.178.96.59 (75)

• À partir de l'hébergement, Mac a pu telnet 192.168.2.1 53 et recevoir une connexion.

Le partage de l'internet a toujours été un peu fragile. J'ai souvent observé des comportements étranges et j'ai constaté qu'il était préférable de redémarrer avant d'essayer d'exécuter le partage d'Internet ou au moins de "rendre [le] service inactif" dans les préférences réseau pour les interfaces en question, puis de les réactiver. (En outre, l'ordre de service (qui contrôle les passerelles par défaut) peut également avoir un impact (comme on peut s'y attendre). Vous pouvez également vous assurer que vous utilisez l'emplacement "automatique" fourni par Apple (ou un fac-similé raisonnable). N'oubliez pas non plus, lorsque vous déboguez, que chaque interface réseau peut avoir sa propre passerelle et son serveur DNS préféré à utiliser depuis Leopard environ.

Je suggérerais donc trois choses : (1) un redémarrage et une confirmation de l'ordre de priorité de votre service réseau et/ou (2) une installation propre de Mavericks pour voir si cela résout vos problèmes, ainsi que (3) vérifier que vous pouvez faire fonctionner le partage d'Internet où l'Ethernet est partagé sur le WiFi et vice-versa. Si vous ne parvenez pas à faire fonctionner (3), vous devez chercher quelque chose de spécifiquement mal configuré sur votre Mac et, là encore, cela suggère une installation propre.

Si vous pouvez faire fonctionner Ethernet -> WiFi et WiFi -> Ethernet, cela suggère quelque chose avec le dongle USB -- et peut-être qu'un ajustement de l'ordre de service pour qu'il ait une plus grande priorité est nécessaire.

Assurez-vous également que vous n'avez pas de règles de pare-feu ou que vous n'exécutez pas Little Snitch ou quoi que ce soit qui puisse interférer.

Le partage d'Internet semble également disposer d'options de débogage si vous émettez des

$ /usr/libexec/InternetSharing --help

Ceux-ci, ainsi que le fichier journal, et le fichier journal de mDNSResponder, peuvent également être utiles si vous rencontrez toujours des problèmes.

Mais comme la réponse à la question : Il ne s'agit pas d'une mauvaise adresse de serveur DNS dans DHCP, car 192.168.2.1 est le "bon" serveur DNS pour le partage Internet, selon la manière dont il est conçu pour fonctionner. Et mDNSResponder est ce qui devrait gérer le DNS sur l'hôte qui exécute le partage d'Internet sous Mavericks. Non `named est nécessaire.

Le problème semble se situer à l'endroit où vous avez restreint votre recherche ; bien qu'il ne s'agisse pas d'un cas où les clients reçoivent une mauvaise adresse de serveur DNS, mais plutôt d'un cas où les clients ne peuvent pas utiliser 192.168.2.1 comme serveur DNS. La façon dont vous avez configuré les serveurs DNS sur le système qui effectue le partage d'Internet n'est pas claire, mais le problème se situe probablement dans ce domaine. Ainsi, le dchp_domain_name_server Adresse IP en bootpd.plist est correcte (du moins normalement).

Je vous recommande de procéder à quelques vérifications simples :

Ouvrez Préférences Système > Partage puis vérifiez les points suivants :

1. Partagez votre connexion à partir de : Wi-Fi
2. Pour les ordinateurs utilisant : Wi-Fi, Ethernet

Si vous vérifiez la présence d'Ethernet, vous obtiendrez peut-être un dialogue :

Si vous activez ce port, votre fournisseur d'accès à Internet pourrait mettre fin à votre service pour éviter que vous ne perturbiez son réseau.

Dans certains cas (si vous utilisez un modem câble, par exemple), vous pouvez involontairement affecter les paramètres du réseau de votre fournisseur d'accès et violer les les termes de votre contrat de service.

Je ne sais pas exactement ce que cela signifie (bien que je me sente violé par mon fournisseur d'accès).

Préférences système > Paramètres réseau > Ethernet/Wi-Fi :

1. Configurer IPv4 - Utiliser DHCP
2. Ensuite, sous Advanced...
3. Configurer IPv6 - Automatiquement

Onglet DNS > Serveurs DNS :

(Normally this would be set to your Router IP from the previous TCP/IP Tab:
Router: ... (3G USB Dongle IP Address)

/etc/bootpd.list

1. Arrêter le partage d'Internet.
2. Ouvrir /tmp/bootpd.plist
3. Localisez cette clé :

<key>reply_threshold_seconds</key> <integer>4</integer>

1. Modifier la valeur 4 en 0
2. Démarrer le partage d'Internet.

*Comme vous le savez, l'arrêt du partage d'Internet efface les paramètres. Une solution possible serait de créer une tâche cron ou un agent de lancement qui conserverait toujours vos paramètres. Il existe également un certain nombre d'options pour bootpd qui peuvent être exécutées via Terminal et que vous ne connaissez peut-être pas.

Autres notes :

• Vérifiez que le(s) dispositif(s) ou ordinateur(s) situé(s) à 192.168.2.2, etc. ne bloque(nt) pas 192.168.2.1.
• Il est possible que si le pare-feu interne d'OS X est activé, OS X transmette et reçoive des requêtes provenant d'Internet vers des appareils/ordinateurs utilisant le partage d'Internet, mais ne leur transmette pas les réponses (DNS).
• Configurer les appareils/ordinateurs pour qu'ils utilisent une IP statique et un ou plusieurs serveurs DNS autres que 192.168.2.1 (mais ce n'est peut-être pas la solution optimale, comme vous l'avez dit). De plus, dans certaines circonstances, la configuration d'IP statiques peut ne pas fonctionner (le DHCP est généralement recommandé pour le partage de l'internet et la configuration par défaut).
• Certains Dongles/Routeurs USB 3G disposent d'un réglage AP Isolation qui doit être désactivé pour le partage d'Internet.

Je sais que vous n'êtes pas un n00b et que vous avez probablement déjà vérifié beaucoup de ces choses, mais il pourrait s'agir d'une chose mineure que vous avez peut-être oubliée en cours de route. De plus, si aucune de ces choses simples ne semble résoudre le problème, il y a des commandes plus spécifiques que je peux fournir en attendant le résultat.

Cette ligne dans votre tcpdump est la réponse :

15:23:33.181528 IP 192.168.2.1 > 192.168.2.2: ICMP 192.168.2.1 udp port domain unreachable, length 36

Cela signifie que votre Firewall ou un autre logiciel jouant le même rôle ou votre configuration manuelle de /etc/pf.conf a empêché votre requête DNS d'atteindre votre MBP.

Désactivez les fonctions de filtrage une à une pour déterminer celle qui bloque. Une fois trouvée, configurez-la correctement.