dnsmasq ਇੱਕ ਨਿੱਜੀ DNS ਜਵਾਬ ਡਿੱਗ ਰਿਹਾ ਹੈ: ਕੀ ਕਾਰਨ rebinding ਸੁਰੱਖਿਆ ਹੈ?

ਕੰਪਨੀ ਦਾ DNS ਸਰਵਰ ਉਮੀਦ ਕੀਤਾ ਨਿੱਜੀ ਪਤਾ ਵਾਪਸ ਕਰਦਾ ਹੈ, ਅਤੇ ਫਿਰ ਵੀ ਸਥਾਨਕ ਫਾਰਵਰਡਿੰਗ ਰਿਜ਼ੋਲਵਰ ਰਾਹੀਂ ਕੁਐਰੀ ਫੇਲ੍ਹ ਹੁੰਦੀ ਹੈ। ਜਵਾਬ ਮੌਜੂਦ ਹੈ, ਜੋ ਉੱਪਰਲੇ ਜ਼ੋਨ ਅਤੇ ਰਿਕਾਰਡ ਨੂੰ ਹੀ ਬਾਹਰ ਕਰ ਦਿੰਦਾ ਹੈ। ਬਚਦਾ ਹੈ ਉਹ ਕਦਮ ਜਿੱਥੇ ਰਿਜ਼ੋਲਵਰ ਫੈਸਲਾ ਕਰਦਾ ਹੈ ਕਿ ਇਹ ਜਵਾਬ ਕਲਾਇੰਟ ਨੂੰ ਵਾਪਸ ਦੇਣਾ ਹੈ ਜਾਂ ਨਹੀਂ। ਜੇ ਉਹ ਰਿਜ਼ੋਲਵਰ dnsmasq ਹੈ, ਤਾਂ ਇਨਕਾਰ ਸੰਭਵ ਤੌਰ ਤੇ ਪਹਿਲਾਂ ਹੀ ਲੌਗ ਵਿੱਚ ਹੈ।

ਜਵਾਬ ਪ੍ਰਾਪਤ ਕਰਨਾ ਅਤੇ ਉਸਨੂੰ ਵਾਪਸ ਦੇਣ ਦੀ ਚੋਣ ਕਰਨਾ ਦੋ ਵੱਖਰੇ ਕਦਮ ਹਨ।

ਦੋਵਾਂ ਰਿਜ਼ੋਲਵਰਾਂ ਉੱਤੇ ਉਹੀ ਨਾਮ ਤੁਲਨਾ ਕਰੋ

ਲਿਖੋ ਕਿ ਐਪ ਅਸਲ ਵਿੱਚ ਕਿਹੜਾ ਰਿਜ਼ੋਲਵਰ ਵਰਤਦੀ ਹੈ ਅਤੇ ਕਿਹੜਾ ਸਟੀਕ ਹੋਸਟਨਾਮ ਪੁੱਛਦੀ ਹੈ। ਫਿਰ ਉੱਪਰਲੇ ਨਤੀਜੇ ਦੀ ਤੁਲਨਾ ਉਸੇ ਨਾਮ ਲਈ ਫਾਰਵਰਡਿੰਗ ਰਿਜ਼ੋਲਵਰ ਦੀ ਘਟਨਾ ਨਾਲ ਕਰੋ। ਉੱਪਰੋਂ ਜਵਾਬ ਨਾ ਆਉਣਾ, ਕੈਸ਼ ਵਿੱਚ ਰੱਖਿਆ ਨਕਾਰਾਤਮਕ ਜਵਾਬ ਅਤੇ ਲੌਗ ਵਿੱਚ ਦਰਜ ਇਨਕਾਰ ਤਿੰਨ ਵੱਖਰੀਆਂ ਸੋਧਾਂ ਮੰਗਦੇ ਹਨ।

ਸਿੱਧੀ ਜਾਂਚ ਕੁਐਰੀ ਵਿੱਚ ਦਿਸਦਾ ਪਤਾ ਇਹ ਸਾਬਤ ਨਹੀਂ ਕਰਦਾ ਕਿ ਐਪ ਨੇ ਉਹ ਆਪਣੇ ਆਮ ਰਾਹ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤਾ। ਦੋਵੇਂ ਕੁਐਰੀਆਂ ਵੱਖਰੇ ਰਿਜ਼ੋਲਵਰਾਂ ਤੋਂ ਜਾਂ ਇੱਕੋ ਰਿਜ਼ੋਲਵਰ ਤੋਂ ਵੱਖਰੀਆਂ ਨੀਤੀਆਂ ਹੇਠ ਨਿਕਲ ਸਕਦੀਆਂ ਹਨ। ਸਿਧਾਂਤ ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਦੋਵੇਂ ਨਤੀਜੇ ਲਿਖੋ, ਕਿਉਂਕਿ ਇਸੇ ਕਦਮ ਉੱਤੇ ਇੱਕ ਦੀ ਥਾਂ ਦੂਜਾ ਰੱਖਿਆ ਜਾਂਦਾ ਹੈ। ਤੁਲਨਾ ਹੀ ਪੂਰਾ ਨਿਦਾਨ ਹੈ।

ਲੱਛਣ ਨਹੀਂ, ਇਨਕਾਰ ਪੜ੍ਹੋ

dnsmasq ਦਾ stop-dns-rebind ਵਿਕਲਪ ਉੱਪਰੋਂ ਆਉਣ ਵਾਲੇ ਅਤੇ ਸ਼ਰਤਾਂ ਪੂਰੀਆਂ ਕਰਨ ਵਾਲੇ ਨਿੱਜੀ ਪਤੇ ਵਾਲੇ ਜਵਾਬ ਰੱਦ ਕਰਦਾ ਹੈ ਅਤੇ ਇੰਝ ਕਰਦਿਆਂ ਉਹਨਾਂ ਨੂੰ ਲੌਗ ਵਿੱਚ ਦਰਜ ਕਰਦਾ ਹੈ। ਇਹ ਸੁਰੱਖਿਆ ਇੱਕ ਚੰਗੇ ਕਾਰਨ ਲਈ ਹੈ: ਅਚਾਨਕ ਨਿੱਜੀ ਪਤੇ ਵੱਲ ਮੁੜਨ ਵਾਲਾ ਜਨਤਕ ਨਾਮ ਹੀ ਕਲਾਸਿਕ rebinding ਹਮਲਾ ਹੈ। ਪਰ ਇਹ ਜਾਣ ਬੁੱਝ ਕੇ ਨਿੱਜੀ ਸੇਵਾ ਨਾਲ ਵੀ ਟਕਰਾਉਂਦੀ ਹੈ, ਅਤੇ ਇਹੀ ਤੁਹਾਡਾ ਮਾਮਲਾ ਹੈ।

ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਲੌਗ ਵਿੱਚ ਇਨਕਾਰ ਲੱਭੋ, ਕਿਉਂਕਿ ਸੁਨੇਹਾ ਮਕੈਨਿਜ਼ਮ ਦਾ ਨਾਮ ਲੈਂਦਾ ਹੈ।

ਜੇ ਨਾ ਇਨਕਾਰ ਹੈ ਅਤੇ ਨਾ ਉੱਪਰੋਂ ਜਵਾਬ, ਤਾਂ rebinding ਸੁਰੱਖਿਆ ਤੁਹਾਡੀ ਸਮੱਸਿਆ ਨਹੀਂ, ਅਤੇ ਇਸਨੂੰ ਬੰਦ ਕਰਨਾ ਅਜਿਹਾ ਬਦਲਾਅ ਹੋਵੇਗਾ ਜੋ ਕੁਝ ਵੀ ਠੀਕ ਨਹੀਂ ਕਰਦਾ ਅਤੇ ਖ਼ਤਰਾ ਵਧਾਉਂਦਾ ਹੈ। ਇਹ ਮੂਲ ਖਰਾਬੀ ਤੋਂ ਵੀ ਬੁਰਾ ਹੈ, ਕਿਉਂਕਿ ਇਹ ਇੱਕ ਕੰਟਰੋਲ ਹਟਾ ਦਿੰਦਾ ਹੈ ਅਤੇ ਨੁਕਸ ਛੱਡ ਦਿੰਦਾ ਹੈ। ਪਹਿਲਾਂ ਠੋਸ ਲੌਗ ਲਾਈਨ ਦੀ ਪੁਸ਼ਟੀ ਕਰੋ। ਫਿਰ ਫੈਸਲਾ ਕਰੋ।

ਛੋਟ ਨੂੰ ਇੱਕੋ ਡੋਮੇਨ ਤੱਕ ਸੀਮਿਤ ਕਰੋ

ਤਸਦੀਕਸ਼ੁਦਾ ਡੋਮੇਨ ਲਈ dnsmasq ਦਾ ਦਸਤਾਵੇਜ਼ ਵਿਸ਼ਵਵਿਆਪੀ ਸਵਿੱਚ ਦੀ ਥਾਂ ਡੋਮੇਨ ਸੀਮਿਤ ਛੋਟ ਦਿੰਦਾ ਹੈ।

rebind-domain-ok=corp.example

ਉੱਪਰ ਦਿੱਤਾ ਡੋਮੇਨ ਕੇਵਲ ਉਦਾਹਰਨ ਹੈ। ਉਹ ਪ੍ਰਬੰਧਕੀ ਡੋਮੇਨ ਵਰਤੋ ਜੋ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਚਲਾਉਂਦੇ ਹੋ, ਅਤੇ ਵਿਕਲਪ ਲਾਗੂ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਉਸਦਾ ਮਿਲਾਨ ਦਾਇਰਾ ਸਮਝੋ, ਕਿਉਂਕਿ ਪਿਛੇਤਰ ਨਿਯਮ ਪਰਖੇ ਗਏ ਇੱਕ ਹੋਸਟ ਤੋਂ ਵੱਧ ਕਵਰ ਕਰਦਾ ਹੈ। ਰਾਊਟਰ ਦਾ ਕਨਫਿਗਰੇਸ਼ਨ ਜਨਰੇਟਰ ਉਹੀ ਸੈਟਿੰਗ ਕੱਚੀ ਹਦਾਇਤ ਦੀ ਥਾਂ ਆਪਣੇ ਕੰਟਰੋਲ ਰਾਹੀਂ ਦਿਖਾ ਸਕਦਾ ਹੈ। ਦੋਵੇਂ ਰਾਹ ਠੀਕ ਹਨ ਜੇ ਨਤੀਜਾ ਦਾਇਰਾ ਉਹੀ ਹੋਵੇ ਜੋ ਤੁਹਾਡਾ ਇਰਾਦਾ ਸੀ।

rebinding ਪਛਾਣ ਤੋਂ ਛੋਟ ਠੀਕ ਇੱਕ ਕੰਮ ਕਰਦੀ ਹੈ: ਉਸ ਡੋਮੇਨ ਦੇ ਜਵਾਬ ਲੰਘਣ ਦਿੰਦੀ ਹੈ।

ਇਹ split-DNS ਫਾਰਵਰਡਰ ਕਨਫਿਗਰ ਨਹੀਂ ਕਰਦਾ, ਨਾ ਦੁਰਲਭ ਉੱਪਰਲੇ ਸਰੋਤ ਨੂੰ ਪਹੁੰਚਯੋਗ ਬਣਾਉਂਦਾ ਹੈ ਅਤੇ ਨਾ ਵਾਪਸ ਕੀਤੇ ਪਤੇ ਤੱਕ ਕੋਈ ਰਾਹ ਬਣਾਉਂਦਾ ਹੈ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਹਰ ਇੱਕ ਆਪਣੇ ਵੱਖਰੇ ਖਰਾਬੀ ਚਿੰਨ੍ਹ ਵਾਲੀ ਮੰਗ ਹੈ, ਅਤੇ ਹਰ ਇੱਕ ਕਲਾਇੰਟ ਵਿੱਚ ਵੱਖਰੇ ਢੰਗ ਨਾਲ ਫੇਲ੍ਹ ਹੁੰਦਾ ਹੈ।

ਸੀਮਾ ਹਟਾਏ ਬਿਨਾਂ ਤਸਦੀਕ ਕਰੋ

ਹੋਸਟਨਾਮ ਨੂੰ ਦੁਬਾਰਾ ਫਾਰਵਰਡਿੰਗ ਰਾਹ ਰਾਹੀਂ ਪੁੱਛੋ, ਫਿਰ ਸੇਵਾ ਨਾਲ ਉਸਦੀਆਂ ਆਮ ਪਛਾਣ ਜਾਂਚਾਂ ਨਾਲ ਜੁੜੋ। DNS ਛੋਟ ਅਣਕਿਆਸੇ ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਸਵੀਕਾਰ ਕਰਨ ਦਾ ਕਾਰਨ ਨਹੀਂ, ਅਤੇ ਦੋਵੇਂ ਖਰਾਬੀਆਂ ਆਸਾਨੀ ਨਾਲ ਉਲਝ ਜਾਂਦੀਆਂ ਹਨ ਜਦੋਂ ਦੋਵੇਂ ਬ੍ਰਾਊਜ਼ਰ ਗਲਤੀ ਵਜੋਂ ਦਿਸਦੀਆਂ ਹਨ। ਨਾਮ ਅਤੇ ਸੇਵਾ ਵੱਖਰੇ ਪਰਖੋ। ਇਹਨਾਂ ਵਿੱਚੋਂ ਸਿਰਫ਼ ਇੱਕ ਹੀ ਕਦੇ DNS ਸਮੱਸਿਆ ਸੀ।

ਛੋਟ ਦਾ ਕਾਰਨ ਕਨਫਿਗਰੇਸ਼ਨ ਦੇ ਕੋਲ, ਤਾਰੀਖ ਅਤੇ ਜ਼ਿੰਮੇਵਾਰ ਵਿਅਕਤੀ ਸਮੇਤ ਰੱਖੋ।

ਜਦੋਂ ਨਿੱਜੀ ਸੇਵਾ ਹਿੱਲੇ ਜਾਂ ਡੋਮੇਨ ਬਦਲੇ ਤਾਂ ਦੁਬਾਰਾ ਜਾਂਚੋ। ਸੁਰੱਖਿਆ ਨੂੰ ਵਿਸ਼ਵਵਿਆਪੀ ਤੌਰ ਤੇ ਬੰਦ ਕਰਨਾ ਅਸੰਬੰਧਿਤ ਜਵਾਬਾਂ ਦਾ ਵਿਵਹਾਰ ਬਦਲ ਦੇਵੇਗਾ ਅਤੇ ਜੇ rebinding ਕਦੇ ਕਾਰਨ ਨਹੀਂ ਸੀ ਤਾਂ ਰਾਹ ਜਾਂ ਸੇਵਾ ਦੀ ਖਰਾਬੀ ਫਿਰ ਵੀ ਆਪਣੀ ਥਾਂ ਰਹੇਗੀ।