1.1.1.1 ను ఎవరు నిర్వహిస్తున్నారు? నమ్మకముంచే ముందు DNS చిరునామాను తనిఖీ చేయడం
VPN తో ఉపయోగించే DNS చిరునామాను ఆ VPN నిర్వహించాలని లేదు. రిజాల్వర్‌ను గుర్తించి, తర్వాత మార్గాన్ని మరియు ప్రైవేట్ పేర్ల విధానాన్ని విడివిడిగా తనిఖీ చేయండి.
మీరు 1.1.1.1 ను VPN యొక్క DNS ఫీల్డ్‌లో అతికించారు, పేజీ లోడ్ అయింది, ట్యుటోరియల్ ఇప్పుడు ధృవీకరించబడినట్లు కనిపిస్తోంది. ఆ పరిశీలన అనిపించే దానికంటే సన్నగా ఉంది: అప్లికేషన్ భిన్నంగా ప్రవర్తించింది, మరియు మార్పు ఇంకా ప్రశ్నకు ఎవరు సమాధానం ఇచ్చారు లేదా పాత ఏర్పాటు ఎందుకు విఫలమైంది అనే దాని గురించి ఏమీ చెప్పడం లేదు. కాపీ చేసిన ట్యుటోరియల్ తెలిసిన పబ్లిక్ చిరునామాను “VPN యొక్క DNS” అని పిలుస్తుంది, అది యాజమాన్యం గురించిన వాదన, చేరుకోగలగడం గురించి కాదు. చిరునామా ఏమి సూచిస్తుందో తనిఖీ చేయడానికి ఐదు నిమిషాలు పడుతుంది మరియు తప్పు కారణంతో చేసే శాశ్వత మార్పును నిరోధిస్తుంది.
పనిచేసే సెట్టింగ్ గుర్తింపు కాదు
సెట్టింగ్ ఫీల్డ్‌లోని చిరునామా ఒక ముగింపు బిందువు, మరియు ముగింపు బిందువుకు ఒక ఆపరేటర్ ఉంటారు. ఈ రెండు వాస్తవాలు వేర్వేరు, మరియు రెండవది ప్రజలు దాటవేసేది. ఎక్కువగా కాపీ చేయబడే జతకు సమాధానం పబ్లిక్: Cloudflare 1.1.1.1 మరియు 1.0.0.1 లను తన రిజాల్వర్ చిరునామాలుగా ప్రచురిస్తుంది మరియు వాటిని తన అధికారిక చిరునామా సూచనలో జాబితా చేస్తుంది. అందుకే ఆపరేటర్ పేరు చిరునామా పక్కన ఉంటుంది, వేరే ట్యుటోరియల్‌లో కాదు.
టన్నెల్ పనిచేస్తున్నప్పుడు ఆ జతను నమోదు చేయడం VPN కంపెనీని దాని ఆపరేటర్‌గా చేయదు, ట్రాఫిక్‌ను అనామకంగా కూడా చేయదు. ప్రశ్న మీ మెషీన్ నుండి చిరునామా పరిధిని ప్రచురించే కంపెనీ వైపు వెళుతుంది, ఆ కంపెనీ గౌరవనీయంగా ఉండవచ్చు, అయినా ట్యుటోరియల్ సూచించిన పక్షం కాకపోవచ్చు. సూచనలలోని లేబుల్ మరియు వాస్తవ ఆపరేటర్ రెండు వేర్వేరు వాదనలు. రెండూ మధ్యలో ఉన్న నెట్‌వర్క్ మార్గాన్ని ఎవరు నిర్వహిస్తున్నారో చెప్పవు.
చిరునామా జత లేదా ఎన్‌క్రిప్ట్ చేసిన ముగింపు బిందువును ధృవీకరించడానికి రిజాల్వర్ యొక్క స్వంత ప్రచురిత సూచనను ఉపయోగించండి. మరొక సరఫరాదారు సిఫారసు చట్టబద్ధంగా ఉండవచ్చు, “సిఫారసు చేయబడింది”, “ద్వారా చేరుకోబడింది” మరియు “నిర్వహించబడుతోంది” ఇప్పటికీ మూడు వేర్వేరు సంబంధాలను వివరిస్తాయి.
రికార్డుకు అవసరమైన మూడు విషయాలను పోల్చండి
సమీక్షకు సిద్ధమైన రికార్డు మూడు ప్రశ్నలను వేరు చేస్తుంది: ప్రశ్నను ఎవరు స్వీకరించాలి, మార్పిడి సాధారణమా లేదా ఎన్‌క్రిప్ట్ చేయబడిందా, మరియు ఏ మార్గం దానిని మోయాలి. సరఫరాదారు పేరు రెండవ లేదా మూడవ దాన్ని నింపలేదు, దేశ లేబుల్ వాటిలో ఏదీ నింపలేదు. మార్పుకు ముందు మూడు నమోదులను రాసి, తర్వాత వాటిని పోల్చండి. ఆ నమోదులు పరస్పరం మార్చుకోగలిగినవి కావు, వాటిని ఒకటిగా పరిగణించడమే ఊహ డాక్యుమెంటేషన్ అయ్యే మార్గం.
పోలికే పనిచేసే సెట్టింగ్‌ను నమోదు చేసిన నిర్ణయంగా మారుస్తుంది. అది లేకుండా తదుపరి వ్యక్తికి ఎటువంటి కారణం జోడించని చిరునామా వారసత్వంగా వస్తుంది. క్రింది పట్టికలోని మూడవ నిలువు వరుసను మొదట చదవండి, ఎందుకంటే అక్కడే చాలా ఆత్మవిశ్వాస వ్యాఖ్యానాలు నిజంగా ఆగుతాయి.
| Entry | What it records | What it cannot tell you |
|---|---|---|
| Recipient | Which resolver should answer | Who operates the path to it |
| Transport | Plain DNS or an encrypted variant | Whether names stay private |
| Path | Which interface carries the query | Which upstream answers last |
పట్టిక ఉద్దేశపూర్వకంగా చిన్నది. దాని అంశం ఏమిటంటే ప్రతి నమోదు వేరే ప్రశ్నకు సమాధానం ఇస్తుంది, మరియు ఏ ఒక్క ఫీల్డ్ మూడింటినీ నింపదు.
స్థానిక ఫార్వర్డర్ అసలు మూలాన్ని దాచిపెడుతుంది
తన రౌటర్‌ను DNS గా ఉపయోగించడానికి సెట్ చేయబడిన పరికరం ఫార్వర్డర్ వైపు చూపుతోంది. ఆ చిరునామా ప్రశ్న యొక్క తదుపరి స్వీకర్తను గుర్తిస్తుంది, చివరికి సమాధానం ఇచ్చే రిజాల్వర్‌ను కాదు. స్థానిక స్టబ్ రిజాల్వర్ అదే అదనపు దశను జోడిస్తుంది, ప్రతి స్థితి అవుట్‌పుట్‌లో అది కనిపిస్తుంది కాబట్టి అసలు వస్తువుతో గందరగోళపరచుకోవడం సులభం.
స్టబ్ అదే అవుట్‌పుట్ జాబితా చేసే మూలాలకు పంపుతుంది, సాధారణంగా మరింత క్రిందకు. ఆపరేటర్ గురించి ఏదైనా నిర్ణయించే ముందు మొత్తం గొలుసును చదవండి, ఎందుకంటే మొదటి పంక్తి పూర్తి సమాధానం కాదు. లేకపోతే మీరు స్వాగతాన్ని కంపెనీ అని పిలుస్తున్నారు.
resolvectl status | grep -A4 'Current DNS Server'
dig +short CH TXT whoami.cloudflare @1.1.1.1
dig example.com | grep -E '^;; SERVER'రెండవ ఆదేశం రిజాల్వర్ యొక్క ప్రతిధ్వని పేరును ఉపయోగిస్తుంది, ఆపరేటర్ ఒకటి ప్రచురించే చోట, అది చూసే మూల చిరునామాను నివేదించడానికి. మూడవది సమాధానం ఇచ్చిన సర్వర్‌ను పేర్కొంటుంది, అది తరచుగా మీరు కాన్ఫిగర్ చేసిన చిరునామా కాదు. ఆపరేటర్‌ను రాసే ముందు మూడు అవుట్‌పుట్‌లను పోల్చండి.
ఎన్‌క్రిప్ట్ చేసిన DNS ఏది కనిపిస్తుందో మారుస్తుంది, ఎవరు చూస్తారో కాదు
DNS over HTTPS మరియు DNS over TLS క్లయింట్ మరియు రిజాల్వర్ మధ్య మార్పిడిని రక్షిస్తాయి. రిజాల్వర్ ఇప్పటికీ అడిగిన ప్రతి పేరును చదువుతుంది, ఎందుకంటే సమాధానం ఇవ్వడమే పని. మారేది ఎవరు మార్పిడిని గమనించగలరో: స్థానిక నెట్‌వర్క్ ఒక ముగింపు బిందువుకు కనెక్షన్‌ను చూస్తుంది, సాధారణ పాఠ్య ప్రశ్నల ప్రవాహాన్ని కాదు.
మారనిది విశ్వాస సంబంధం, అది ఇప్పటికీ ఆ ముగింపు బిందువును నిర్వహించే సంస్థ వైపు చూపుతుంది. స్వంత సురక్షిత DNS సెట్టింగ్ ఉన్న బ్రౌజర్ ఆపరేటింగ్ సిస్టమ్ రిజాల్వర్‌ను పూర్తిగా దాటవేయగలదు. వాటిని రెండుసార్లు వర్తించిన ఒక సెట్టింగ్‌గా కాక, ఏకీభవించకపోయే రెండు కాన్ఫిగరేషన్‌లుగా పరిగణించండి.
ప్రైవేట్ పేర్లకు మళ్లీ తమ స్వంత నిర్ణయం అవసరం. పని టన్నెల్ ఎంచుకున్న డొమైన్‌లను సంస్థాగత రిజాల్వర్‌లకు మళ్లించగలదు, దానిని పబ్లిక్ సేవతో భర్తీ చేయడం అంతర్గత శోధనలను విచ్ఛిన్నం చేయవచ్చు లేదా అంతర్గత పేర్లను తప్పు పక్షానికి వెల్లడించవచ్చు. మొత్తం అడాప్టర్ సెట్టింగ్‌లను భర్తీ చేయడానికి ముందు డొమైన్ విధానాన్ని తనిఖీ చేయండి.
పరిశీలనను సన్నగా ఉంచండి
పోల్చేటప్పుడు పాత కాన్ఫిగరేషన్‌ను భద్రపరచి, ఒకసారి ఒక సెట్టింగ్ మార్చండి. అప్లికేషన్, ఆపరేషన్, రిజాల్వర్ విధానం, మరియు తిరిగి కనెక్ట్ అయిన తర్వాత పబ్లిక్ మరియు అనుమతించిన ప్రైవేట్ పేర్లు ఇప్పటికీ పరిష్కరించబడుతున్నాయా అని నమోదు చేయండి. రెండు మార్పులతో ఉన్న పోలిక ఏదీ నిరూపించదు. ఫలితాన్ని తదుపరి వ్యక్తి కనుగొనే చోట, సెట్టింగ్ పక్కనే రాయండి.
resolvectl query intranet.corp.example
resolvectl domain
dig +short @1.1.1.1 example.comఅప్లికేషన్ పనిచేయడం ప్రారంభిస్తే, సాక్ష్యాలు అనుమతించినంత చిన్నగా వాదనను ఉంచండి. ఆ మార్పు ఒక పరీక్షకు సహాయపడింది, మునుపటి రిజాల్వర్ దురుద్దేశంతో పనిచేసిందా, టన్నెల్ విరిగిపోయిందా, లేదా మరొక పరికరానికి అదే భర్తీ అవసరమా అనే దాని గురించి ఏమీ చెప్పదు. శాశ్వత ఫలితం దాని ఆపరేటర్ మరియు ఉద్దేశ్యాన్ని మీరు వివరించగలిగే కాన్ఫిగరేషన్.