కనెక్ట్ అయిన తర్వాత సెట్టింగ్స్ పేజీని తెరవండి, మూడు DNS చిరునామాలు జాబితా చేయబడతాయి; ఆడిట్ ప్రశ్న మీ చివరి క్వెరీని ఏది నిర్వహించింది అనేది. కేవలం సంఖ్య ఏమీ సమాధానం ఇవ్వదు, ఎందుకంటే క్లయింట్ పుష్, భౌతిక ఇంటర్ఫేస్ మరియు ప్రతి డొమైన్ విధానం అన్నీ ఒకే వీక్షణలో రాస్తాయి. ఈ నమోదులకు వేర్వేరు పరిధులు ఉన్నాయి, ఎవరు సమాధానం ఇస్తారో స్థానం కాదు, పరిధి నిర్ణయిస్తుంది. మూలాలను వేరు చేయడంతో ప్రారంభించి, ఆపై మీకు ముఖ్యమైన పేరు ఉన్న మూలాన్ని పరీక్షించండి.

జాబితా మీ ప్రొఫైల్ కంటే పొడవుగా ఎందుకు ఉంది

VPN క్లయింట్ టన్నెల్ లింక్ కోసం రిజాల్వర్ చిరునామాలను నెట్టుతుంది, మరియు ఆపరేటింగ్ సిస్టమ్ వాటిని భౌతిక ఇంటర్ఫేస్ ఇప్పటికే కలిగి ఉన్న దాని పక్కన ఉంచుతుంది. రౌటర్, కార్పొరేట్ DHCP లీజ్, రెండవ VPN మరియు ప్రతి డొమైన్ విధానం ఒక్కొక్కటి తమ సొంత నమోదును జోడిస్తాయి. అందువల్ల పేజీలోని మూడు చిరునామాలు ఒక పనికి మూడు అభ్యర్థులు కాదు, మూడు పరిధులను సూచించవచ్చు. సంఖ్యను లీక్‌కు రుజువుగా చదవడం ఈ ఆడిట్‌లో మొదటి తప్పు.

ఒక ఇంటర్ఫేస్ లోపల క్లయింట్ తన సర్వర్లను క్రమంగా ప్రయత్నిస్తుంది, కాబట్టి క్రమబద్ధ జాబితా అర్థహీనం కాదు. క్యూ కానిది మిళిత వీక్షణ, ఇక్కడ ప్రొఫైల్, భౌతిక లింక్ మరియు ప్రతి డొమైన్ నియమాల నమోదులు ఒకే ర్యాంకింగ్ లేకుండా పక్కపక్కనే నిలుస్తాయి. ఆ భేదం మీరు ఏమి పరీక్షిస్తారో నిర్ణయిస్తుంది: క్రమం ఒక పరిధిలో ప్రవర్తనను వివరిస్తుంది, పరిధి మిగతావన్నీ వివరిస్తుంది.

ఎన్‌క్రిప్ట్ చేసిన DNS అనువర్తనం లోపలి నుండి చిత్రాన్ని బద్దలు కొడుతుంది. తన సొంత DNS-over-HTTPS రిజాల్వర్ ఉన్న బ్రౌజర్ లేదా చాట్ క్లయింట్ క్వెరీలను ఆపరేటింగ్ సిస్టమ్ జాబితాను పూర్తిగా దాటి పంపుతుంది, కాబట్టి సెట్టింగ్స్ పేజీ చిరునామాలు యాప్ ఎప్పుడూ సృష్టించని ట్రాఫిక్‌ను వివరిస్తాయి. పేరు తప్పుగా వచ్చినందుకు ప్రొఫైల్‌ను నిందించడానికి ముందు యాప్ సొంత రిజాల్వర్ సెట్టింగ్‌ను తనిఖీ చేయండి.

మూడు తనిఖీలలో ప్రతి ఒక్కటి ఏమి చెబుతుంది

ప్రతి మూలం తన గుర్తును వేరే ప్రదేశంలో వదిలిస్తుంది, ఏ ఒక్క ఆదేశం అన్నీ చూపదు. సెట్టింగ్స్ పేజీ పక్కన ఉంచడానికి తగిన మ్యాపింగ్ ఇది:

Entry sourceWhere it is visibleWhat it proves
Tunnel profileLink-scoped DNS on the tunnel deviceWhich servers the VPN asked you to use, not which one answered
Per-domain policySuffix list or routing domainsWhich names are steered to a particular resolver
Physical linkDNS on the LAN interfaceWhether a second scope still exists outside the tunnel
Application resolverApp settings, absent from the OS listWhether the system list was consulted at all

systemd-resolved ఉపయోగించే సిస్టమ్‌లో resolvectl status అధికారం కలిగినది, ఎందుకంటే ఇది రూటింగ్ డొమైన్లతో పాటు ప్రతి లింక్‌కు DNS ను నివేదిస్తుంది. macOS scutil --dns ద్వారా సమాధానం ఇస్తుంది, ఇది పరిధి ఉన్న రిజాల్వర్లను ప్రయత్నించే క్రమంలో జాబితా చేస్తుంది. Windows రెండు సగాలుగా విభజిస్తుంది: ప్రతి ఇంటర్ఫేస్ సర్వర్లకు Get-DnsClientServerAddress మరియు సఫిక్స్ నియమాలకు Get-DnsClientNrptPolicy. వాస్తవంగా ఉపయోగించే రిజాల్వర్‌కు చెందిన ఆదేశాన్ని అమలు చేయండి, ఎందుకంటే కంటైనర్ రన్‌టైమ్ మరియు డెస్క్‌టాప్ రిజాల్వర్ ఉన్న మెషీన్‌లో ఒకటి కంటే ఎక్కువ ఇన్‌స్టాల్ చేయబడి ఉండవచ్చు.

మీ జోన్‌కు సమాధానం ఇవ్వలేని బ్యాకప్ రిజాల్వర్

రెండవ నమోదు సాధారణంగా లభ్యత కోసం ఉంటుంది, లభ్యత బ్యాకప్‌కు పేర్లు తెలిస్తే మాత్రమే పని చేస్తుంది. పబ్లిక్ రిజాల్వర్‌ను అంతర్గత హోస్ట్ పేరు అడగండి, అది NXDOMAIN ను తిరిగి ఇస్తుంది, లేదా మీకు ఎటువంటి సంబంధం లేని శోధన డొమైన్ నుండి వైల్డ్‌కార్డ్ సమాధానం ఇస్తుంది. ఎవరూ తనిఖీ చేయని ఫెయిల్‌ఓవర్ అప్పుడు అవసరమైన క్షణంలోనే అంతరాయాన్ని కలిగిస్తుంది.

Split DNS దాన్ని నిరోధించడానికే ఉంది: కంపెనీ సఫిక్స్‌లు జోన్‌ను కలిగి ఉన్న రిజాల్వర్‌కు వెళ్తాయి, పబ్లిక్ పేర్లు డిఫాల్ట్ మార్గంలో ఉంటాయి. డిజైన్ బలంగా ఉంది, అది సఫిక్స్ జాబితా పూర్తిగా ఉండటంపై ఆధారపడుతుంది. Microsoft Windows లో దీన్ని నడిపించే ప్రతి సఫిక్స్ రిజాల్వర్ విధానాన్ని డాక్యుమెంట్ చేస్తుంది, అదే ఆలోచన systemd-resolved లో రూటింగ్ డొమైన్లుగా మరియు macOS లో పరిధి ఉన్న రిజాల్వర్లుగా కనిపిస్తుంది.

బ్యాకప్ సమాధానం ఇవ్వగల జోన్‌లను విధానంలో ఉన్న సఫిక్స్‌లతో పోల్చండి. ఆ పోలిక వినియోగదారు టన్నెల్ మార్పు తర్వాత ఒక అంతర్గత సైట్ పరిష్కారం కావడం ఆగిపోయిందని నివేదించడానికి ముందే ఖాళీని కనుగొంటుంది.

విధానం ద్వారా అడగండి, దాని చుట్టూ కాదు

ఆపరేటింగ్ సిస్టమ్ రిజాల్వర్ ద్వారా అడగండి, ఎందుకంటే సర్వర్‌కు నేరుగా క్వెరీ విధానాన్ని దాటవేసి ఆ సర్వర్ చెప్పేది మాత్రమే నివేదిస్తుంది. రెండు సమాధానాల మధ్య ఖాళీనే మొత్తం విషయం:

resolvectl query intranet.example.com
dig +short intranet.example.com @198.51.100.53

సిస్టమ్ క్వెరీ ప్రైవేట్ చిరునామాను తిరిగి ఇచ్చి నేరుగా క్వెరీ NXDOMAIN ఇస్తే, విధానం పని చేస్తోంది మరియు బలహీనమైన స్థానం బ్యాకప్. రెండూ ఒకే పబ్లిక్ సమాధానం ఇస్తే, పేరు మీరు ఉద్దేశించిన పరిధి వెలుపల పరిష్కరించబడుతోంది, మరియు సఫిక్స్ జాబితా చూడవలసిన ప్రదేశం. రెండు అవుట్‌పుట్‌లను ఉంచండి, ఎందుకంటే సెట్టింగ్స్ పేజీ స్క్రీన్‌షాట్ కంటే రెండు పంక్తులతో రిజాల్వర్ చర్చ త్వరగా ముగుస్తుంది.

తర్వాత వైఫల్య మార్గాన్ని సాధన చేయండి, ఎందుకంటే ఎవరూ పరీక్షించని బ్యాకప్ ఒక ఊహ. ఒక క్వెరీకి ఇష్టపడే రిజాల్వర్‌ను బ్లాక్‌హోల్‌గా చేసి ఏ చిరునామా తిరిగి వస్తుందో చూడండి:

ip route add blackhole 198.51.100.53/32
resolvectl query intranet.example.com
ip route del blackhole 198.51.100.53/32

క్వెరీ ముగిసిన వెంటనే ఆ మార్గాన్ని తొలగించండి, లేకపోతే తదుపరి వ్యక్తి ఒక రహస్యాన్ని వారసత్వంగా పొందుతాడు. ఆ సమయంలో అంతర్గత పేర్లు ఇంకా పరిష్కరించబడితే, ఉద్దేశించిన పరిధి వెలుపల ఏదో వాటికి సమాధానం ఇచ్చింది. అవి బదులుగా సమయం ముగిస్తే, బ్యాకప్ లేదు లేదా సరిగ్గా పరిమితం చేయబడింది, మరియు రిజాల్వర్ సొంత లాగ్ రెండింటిలో ఏది అని చెబుతుంది.

నిర్ణయించండి: ఉంచండి, పరిమితం చేయండి లేదా తొలగించండి

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

ఫలితాన్ని నాలుగు నిలువు వరుసలుగా నమోదు చేయండి: సఫిక్స్, రిజాల్వర్, ఇంటర్ఫేస్ మరియు యజమాని. ఆ పంక్తి ఏ స్క్రీన్‌షాట్ కంటే వేగంగా తదుపరి ఆడిట్ ప్రశ్నకు సమాధానం ఇస్తుంది, జాబితాను నిశ్శబ్దంగా పునర్వ్యవస్థీకరించే క్లయింట్ నవీకరణను కూడా తట్టుకుంటుంది.

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