કંપનીનો DNS સર્વર અપેક્ષિત ખાનગી સરનામું પરત કરે છે, તો પણ સ્થાનિક ફોરવર્ડિંગ રિઝોલ્વર દ્વારા ક્વેરી નિષ્ફળ જાય છે. જવાબ અસ્તિત્વમાં છે, જે ઉપરના ઝોન અને રેકોર્ડને બાદ કરે છે. બાકી રહે છે તે પગલું જ્યાં રિઝોલ્વર નક્કી કરે છે કે આ જવાબ ક્લાયન્ટને પરત આપવો કે નહીં. જો તે રિઝોલ્વર dnsmasq હોય, તો અસ્વીકાર સંભવતઃ પહેલેથી લૉગમાં છે.

જવાબ મેળવવો અને તેને પરત આપવાની પસંદગી કરવી એ બે અલગ પગલાં છે.

બંને રિઝોલ્વર પર એ જ નામની સરખામણી કરો

નોંધો કે ઍપ ખરેખર કયો રિઝોલ્વર વાપરે છે અને કયું ચોક્કસ હોસ્ટનામ પૂછે છે. પછી ઉપરના પરિણામની સરખામણી તે જ નામ માટે ફોરવર્ડિંગ રિઝોલ્વરની ઘટના સાથે કરો. ઉપરથી જવાબ ન મળવો, કૅશમાં રાખેલ નકારાત્મક જવાબ અને લૉગમાં નોંધાયેલ અસ્વીકાર ત્રણ અલગ સુધારા માંગે છે.

સીધી નિદાનાત્મક ક્વેરીમાં દેખાતું સરનામું સાબિત કરતું નથી કે ઍપને તે તેના સામાન્ય માર્ગે મળ્યું. બંને ક્વેરી અલગ રિઝોલ્વરથી કે એક જ રિઝોલ્વરથી અલગ નીતિઓ હેઠળ નીકળી શકે છે. સિદ્ધાંત ઘડતા પહેલા બંને પરિણામ લખી લો, કારણ કે આ જ પગલે એકની જગ્યાએ બીજું મૂકવામાં આવે છે. સરખામણી એ જ આખું નિદાન છે.

લક્ષણ નહીં, અસ્વીકાર વાંચો

dnsmasq નો stop-dns-rebind વિકલ્પ ઉપરથી આવતા અને શરતો પૂરી કરતા ખાનગી સરનામાવાળા જવાબો નકારે છે અને એમ કરતી વખતે તેમને લૉગમાં નોંધે છે. આ સુરક્ષા એક સારા કારણ માટે છે: અચાનક ખાનગી સરનામા તરફ જતું જાહેર નામ એ જ ક્લાસિક rebinding હુમલો છે. પરંતુ તે જાણી જોઈને ખાનગી સેવા સાથે પણ અથડાય છે, અને એ જ તમારો કિસ્સો છે.

કંઈપણ બદલતા પહેલા લૉગમાં અસ્વીકાર શોધો, કારણ કે સંદેશો પ્રક્રિયાનું નામ આપે છે.

જો ન અસ્વીકાર હોય ન ઉપરથી જવાબ, તો rebinding સુરક્ષા તમારી સમસ્યા નથી, અને તેને બંધ કરવો એ એવો ફેરફાર થશે જે કંઈ સુધારતો નથી અને જોખમ વધારે છે. આ મૂળ ખામીથી પણ ખરાબ છે, કારણ કે તે એક નિયંત્રણ દૂર કરે છે અને ખામી છોડી દે છે. પહેલા ચોક્કસ લૉગ લાઇનની ખાતરી કરો. પછી નિર્ણય લો.

અપવાદને એક જ ડોમેન સુધી મર્યાદિત કરો

ચકાસાયેલ ડોમેન માટે dnsmasq નું માર્ગદર્શિકા વૈશ્વિક સ્વિચને બદલે ડોમેન-મર્યાદિત અપવાદ આપે છે.

rebind-domain-ok=corp.example

ઉપરનું ડોમેન ફક્ત ઉદાહરણ છે. તમે ખરેખર ચલાવો છો તે વહીવટી ડોમેન વાપરો, અને વિકલ્પ લાગુ કરતા પહેલા તેની મેળ ખાવાની હદ સમજો, કારણ કે પ્રત્યય નિયમ પરીક્ષણ કરેલ એક હોસ્ટ કરતાં વધુ આવરી લે છે. રાઉટરનું રૂપરેખાંકન જનરેટર એ જ સેટિંગ કાચી સૂચનાને બદલે પોતાના નિયંત્રણ દ્વારા બતાવી શકે છે. બંને માર્ગ ઠીક છે જો પરિણામી હદ ઇચ્છિત હોય.

rebinding ઓળખમાંથી અપવાદ બરાબર એક કામ કરે છે: તે ડોમેનના જવાબો પસાર થવા દે છે.

તે split-DNS ફોરવર્ડર રૂપરેખાંકિત કરતું નથી, ન દુર્ગમ ઉપરના સ્રોતને સુલભ બનાવે છે અને ન પરત આપેલા સરનામા સુધી માર્ગ બનાવે છે. આમાંની દરેક અલગ જરૂરિયાત છે જેની પોતાની નિષ્ફળતાની છાપ છે, અને દરેક ક્લાયન્ટમાં જુદી રીતે નિષ્ફળ જાય છે.

સીમા દૂર કર્યા વિના ચકાસો

હોસ્ટનામ ફરી ફોરવર્ડિંગ માર્ગે પૂછો, પછી સેવા સાથે તેની સામાન્ય ઓળખ ચકાસણીઓ સાથે જોડાઓ. DNS અપવાદ અણધાર્યું પ્રમાણપત્ર સ્વીકારવાનું કારણ નથી, અને બંને ખામી સહેલાઈથી ભેળસેળ થાય છે જ્યારે બંને બ્રાઉઝર ભૂલ તરીકે દેખાય. નામ અને સેવા અલગ અલગ ચકાસો. આમાંથી ફક્ત એક જ ક્યારેય DNS સમસ્યા હતી.

અપવાદનું કારણ રૂપરેખાંકનની બાજુમાં, તારીખ અને જવાબદાર વ્યક્તિ સાથે રાખો.

ખાનગી સેવા ખસે કે ડોમેન બદલાય ત્યારે તેને ફરી ચકાસો. સુરક્ષા વૈશ્વિક રીતે બંધ કરવાથી અસંબંધિત જવાબોની ગોઠવણી બદલાશે અને rebinding કદી કારણ ન હોય તો પણ માર્ગ કે સેવાની ખામી યથાવત્ રહેશે.

સંબંધિત લેખો