scutil --dns macOS నిజంగా సంప్రదించే రిజాల్వర్ కాన్ఫిగరేషన్ను ముద్రిస్తుంది, మీరు సెట్టింగ్స్ ప్యానెల్లో టైప్ చేసిన ఒకే DNS సర్వర్ కాదు. అవుట్పుట్ చాలామంది ఊహించిన దానికంటే పొడవుగా ఉంటుంది, ఎందుకంటే సిస్టమ్ డిఫాల్ట్ మార్గం, స్కోప్ చేసిన ఇంటర్ఫేస్లు మరియు డొమైన్-నిర్దిష్ట ఫార్వార్డింగ్ కోసం వేర్వేరు రిజాల్వర్ బ్లాక్లను ఉంచుతుంది. అవుట్పుట్ ఎగువన ఉన్న బ్లాక్ ప్రశ్నకు సమాధానమిచ్చే బ్లాక్ అయి ఉండాలని లేదు. ఒక ప్రైవేట్ పేరు కార్యాలయంలో రిజాల్వ్ అయి VPN పైకి వచ్చిన క్షణంలో విఫలమైతే, అసమానత జతచేయు నియమాల్లో మరియు మార్గాల్లో ఉంది, సర్వర్ చిరునామాలో కాదు. మొదట క్రమాన్ని చదవండి, తర్వాత నిజమైన శోధనతో సమాధానాన్ని నిరూపించండి.

చిరునామాలకు ముందు బ్లాక్ క్రమాన్ని చదవండి

ప్రతి నమోదు resolver #N తో ప్రారంభమై nameserver[0], కొన్నిసార్లు if_index, flags పంక్తి, reach మరియు బ్లాక్ సాధారణ డిఫాల్ట్ కాకపోతే domain మరియు search domain జాబితాను చూపుతుంది. డొమైన్ లేని 1వ రిజాల్వర్ పబ్లిక్ పేర్లను నిర్వహించే డిఫాల్ట్. దాని ఫ్లాగ్లలో Scoped కలిగి ఉన్న ఏదైనా if_index పేరు పెట్టే ఇంటర్ఫేస్కు కట్టుబడి ఉంటుంది, మరియు Supplemental గా గుర్తించినది దాని కింద జాబితా చేసిన డొమైన్లకు మాత్రమే వర్తిస్తుంది.

ఎంపిక అనేది ప్రత్యయ జత. intranet.corp.example వంటి పేరు కోసం, domain నమోదు అత్యంత పొడవైన జత అయ్యే రిజాల్వర్ను macOS ఇష్టపడుతుంది, కాబట్టి domain : corp.example ఉన్న బ్లాక్ అవుట్పుట్లో చాలా క్రింద ఉన్నా డిఫాల్ట్ను ఓడిస్తుంది. ఒకే పొడవు డొమైన్ల మధ్య సమానత్వాన్ని order తీరుస్తుంది. మొదటి చూపుకు దీనికంటే ఎక్కువ అరుదుగా అవసరం: ఒక బ్లాక్ను మొదటి నుండి చివరి వరకు చదవాలంటే మొత్తం అవుట్పుట్, బ్లాక్ క్రమాన్ని తెలుసుకోవడానికి ప్రారంభ పంక్తులు, మరియు ఫీల్డ్ పంక్తుల పక్కన బ్లాక్ శీర్షికలను ముద్రించే వడపోత చుట్టు. స్కోప్ చేసిన బ్లాక్లు తమ శీర్షిక కింద కనిపించి పైన ఉన్న జాబితా కొనసాగింపుగా చదవబడతాయి, కాబట్టి అవుట్పుట్ను ఉల్లేఖించినప్పుడు శీర్షికను కంటికి ఎదురుగా ఉంచుకోండి.

scutil --dns
scutil --dns | sed -n '1,45p'
scutil --dns | grep -nE '^resolver #|^DNS configuration'
scutil --dns | grep -nE 'resolver #[0-9]+|if_index|domain|flags|nameserver'

if_index ను టన్నెల్ ఇంటర్ఫేస్తో జతచేయండి

సూచిక దాని వెనుక ఉన్న ఇంటర్ఫేస్కు పేరు పెట్టగలిగితే మాత్రమే ఉపయోగకరం. scutil --nwi సిస్టమ్ ఉంచుకున్న నెట్వర్క్ సమాచారాన్ని జాబితా చేస్తుంది, ప్రాథమిక ఇంటర్ఫేస్ మరియు చేరువను కలిపి, అయితే ifconfig -l మీకు పేర్లను ఇస్తుంది, ఇక్కడ utun0 నుండి utun9 వరకు క్లయింట్ సాధారణంగా సృష్టించే టన్నెల్ అభ్యర్థులు. Apple తన సొంత పరిశీలన ఉదాహరణగా scutil --dns ను అమలు మార్గదర్శినిలో ఉపయోగిస్తుంది, మరియు Network Extension ఎంచుకున్న డొమైన్లను ఎంచుకున్న రిజాల్వర్లకు ఎలా మళ్లించగలదో పత్రీకరిస్తుంది; ఆ స్కోప్ చేసిన బ్లాక్లు బయటపెట్టే యంత్రాంగం అదే.

ప్రశ్నను తీర్చే పరిశీలన రిజాల్వర్ టన్నెల్ ఏర్పాటు చేసిన మార్గంలో ఉందా అనేది:

scutil --nwi
ifconfig utun4
route -n get 10.20.0.53
netstat -rn | grep -m5 utun

route -n get రిజాల్వర్ నమోదుకు జతకాని గేట్వే మరియు ఇంటర్ఫేస్ను తిరిగి ఇస్తే, చిరునామా పూర్తిగా సరైనదైనా చేరుకోలేకపోవచ్చు. కార్పొరేట్ సబ్నెట్లను మాత్రమే తీసుకువెళ్లే విభజిత టన్నెల్ వాటి బయట ఉన్న DNS సర్వర్ వైపు ప్రశ్నలను పడవేస్తుంది, మరియు వైఫల్యం సమయం ముగిసినట్లు కనిపిస్తుంది, అందుకే కాన్ఫిగరేషన్ అవుట్పుట్ ఇప్పటికీ శుభ్రంగా కనిపిస్తుంది.

సిస్టమ్ రిజాల్వర్ను అడగండి, తర్వాత సర్వర్ను

మూడు సాధనాలు మూడు వేర్వేరు ప్రశ్నలకు సమాధానమిస్తాయి, వాటిని కలపడం ఈ రంగంలో చాలా తప్పు నిర్ణయాలను సృష్టిస్తుంది. dscacheutil -q host -a name సాధారణ యాప్లు ఉపయోగించే అదే సిస్టమ్ రిజాల్వర్ గుండా వెళుతుంది, కాబట్టి స్కోప్ చేసిన మరియు అదనపు బ్లాక్లు వర్తిస్తాయి. సర్వర్ ఆర్గ్యుమెంట్ లేని dig /etc/resolv.conf చదువుతుంది, ఇది macOSలో స్కోప్ చేసిన రిజల్యూషన్కు సత్యపు మూలం కాదు, మరియు ఇది డొమైన్ నియమాలను పూర్తిగా దాటవేస్తుంది. dig @address సరిగ్గా ఒక సర్వర్ను చేరుకుంటుంది మరియు ఎంపిక గురించి ఏమీ చెప్పదు.

dscacheutil -q host -a name intranet.corp.example
dig intranet.corp.example
dig @10.20.0.53 intranet.corp.example
nslookup intranet.corp.example

మొదటి ఆదేశం సమాధానమిచ్చి రెండవది NXDOMAIN తిరిగి ఇస్తే, మీరు వెతికిన విభజన దొరికింది మరియు ఏదీ పగలలేదు. మొదటిది సమయం ముగిస్తుండగా dig @10.20.0.53 సమాధానమిస్తే, రిజాల్వర్ పనిచేస్తుంది కానీ టన్నెల్ ఎంచుకున్న మార్గంలో చేరుకోలేము, కాబట్టి తదుపరి అడుగు DNS సెట్టింగ్లను మార్చడం కాదు, route -n get. ప్రైవేట్ పేర్లను టికెట్ లేదా భాగస్వామ్య నోట్కు అతికించే ఏదైనా నుండి దూరంగా ఉంచండి.

అవుట్పుట్ మీకు చూపలేనిది

రిజాల్వర్ జాబితా పైన లేదా పక్కన అనేక పొరలు కూర్చుంటాయి, మరియు ప్రతిదీ అవుట్పుట్ ఎప్పుడూ ప్రస్తావించని చోటికి ప్రశ్న పంపగలదు. సురక్షిత DNS ఆన్ చేసిన బ్రౌజర్ తన సొంత గుప్తీకృత ఛానెల్ ద్వారా రిజాల్వ్ చేయగలదు, కాబట్టి dscacheutil సమయం ముగిస్తుండగా పేజీ లోడ్ కావడం విరోధం కాదు. భద్రతా సాఫ్ట్వేర్ ఇన్స్టాల్ చేసిన DNS ప్రాక్సీ Network Extension ప్రదాతగా పనిచేసి ప్రశ్నలను తానే ఫార్వార్డ్ చేస్తుంది, మరియు scutil --dns ఏమి కాన్ఫిగర్ చేయబడిందో చూపుతుంది, ప్రాక్సీ చివరగా ఉపయోగించిన ఎగువ చిరునామాను కాదు. శోధన డొమైన్లు మూడవ మడతను జోడిస్తాయి: అర్హత లేని పేరుకు జాబితా చేసిన ప్రతి ప్రత్యయం క్రమంగా జోడించబడుతుంది, కాబట్టి సమాధానమిచ్చిన బ్లాక్ మీరు ఎప్పుడూ అనుమానించని ఒకటి కావచ్చు.

పాత సమాధానాలను బయటపెట్టడం అత్యంత చవకైనది మరియు ఎక్కువగా దాటవేయబడేది:

sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
scutil --dns | head -20

ఫ్లష్ తర్వాత అవుట్పుట్ మారితే, స్థితి కాష్లో ఉంది మరియు మునుపటి అవుట్పుట్ ఇప్పుడు లేని టన్నెల్ను వివరించింది. మారకపోతే, కాన్ఫిగరేషన్ ఉన్నట్లే ఉంది, మరియు ప్రశ్న మార్గాలు మరియు యాప్ విధానం వైపు కదులుతుంది.

ముందు మరియు తర్వాత కోసం చిన్న మార్గదర్శిని

విధానం అనుమతించిన చోట మాత్రమే బేస్లైన్ తీసుకోండి, మరియు ఫైళ్లను ఏదైనా సింక్ చేసిన ఫోల్డర్ బయట ఉంచండి. కింది క్రమం నేను క్లయింట్ యంత్రాలపై నడిపేది: బేస్లైన్ తీసుకోండి, కనెక్ట్ అవ్వండి, మళ్లీ తీసుకోండి, తర్వాత పోల్చి వెతకండి.

scutil --dns > ~/dns-before.txt
# connect the VPN, then:
scutil --dns > ~/dns-after.txt
diff -u ~/dns-before.txt ~/dns-after.txt
dscacheutil -q host -a name intranet.corp.example

భేదాన్ని పంక్తుల వారీగా కాదు, బ్లాక్ల వారీగా చదవండి. టన్నెల్ ఇంటర్ఫేస్ సూచిక మరియు ప్రైవేట్ ప్రత్యయం కోసం domain నమోదును మోసే కొత్త స్కోప్ చేసిన రిజాల్వర్ ఆశించిన ఆకారం. పబ్లిక్ చిరునామా వైపు చూపే కొత్త డిఫాల్ట్ రిజాల్వర్ క్లయింట్ ప్రొఫైల్ యజమాని ముందు ఉంచదగిన కనుగొనడం. తర్వాత నిజంగా విఫలమైన యాప్ లోపల శోధనను పునరావృతం చేయండి, షెల్లో మాత్రమే కాదు, మరియు ఫలితం పక్కన route -n get ఇంటర్ఫేస్ను నమోదు చేయండి.

మార్పును రద్దు చేయడానికి డిస్కనెక్ట్ చేసి బేస్లైన్ తీసుకోవడాన్ని పునరావృతం చేయండి. స్కోప్ చేసిన బ్లాక్ పోతే, క్లయింట్ తన వెనుక స్వచ్ఛం చేసింది. బ్లాక్ ఇప్పుడు లేని ఇంటర్ఫేస్కు వ్యతిరేకంగా ఇంకా జాబితా అయి ఉంటే, స్థితి పాతది, మరియు ఎవరైనా ప్రొఫైల్ను తాకడానికి ముందు ఫ్లష్ మరియు పునఃకనెక్షనే అత్యంత మృదువైన సరిదిద్దుడు.

ఈ క్రమంలో నాలుగు పరిశీలనలు: ఏదైనా రిజాల్వర్ బ్లాక్ పేరు యొక్క అత్యంత పొడవైన ప్రత్యయంతో జత అవుతుందా; ఆ బ్లాక్ టన్నెల్ ఏర్పాటు చేసిన ఇంటర్ఫేస్కు కట్టుబడి ఉందా; దాని పేరు సర్వర్కు ఉన్న మార్గం టన్నెల్ను ఉపయోగిస్తుందా; మరియు dig కాదు, సిస్టమ్ రిజాల్వర్ సమాధానాన్ని తిరిగి ఇస్తుందా. మొదటి విఫల పరిశీలన DNS విధానం, టన్నెల్ మార్గాలు లేదా యాప్ను మార్చాలా అని చెబుతుంది. నాలుగూ పాస్ అయి పేరు ఇంకా విఫలమైతే, సమస్య DNS పైన ఉంది, మరియు తర్వాత పరిశీలించవలసినది దాని ముందు పోర్ట్ 53కు సమాధానమిచ్చేది.

సంబంధిత వ్యాసాలు