VPN ਦਾ DNS ਗਲਤ? ਇੱਕ ਅਧਿਕਾਰਤ ਸਰਵਰ ਪੁਰਾਣਾ ਹੋ ਸਕਦਾ ਹੈ

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

ਲੱਛਣ ਰਿਜ਼ੋਲਵਰ ਨਾਲ ਬਦਲਦਾ ਹੈ

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

ਇਸੇ ਲਈ ਇੱਕੋ ਨਾਮ ਇੱਕ ਦਫ਼ਤਰ ਵਿੱਚ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ ਅਤੇ ਹੋਟਲ ਤੋਂ ਫੇਲ੍ਹ ਹੋ ਸਕਦਾ ਹੈ, ਅਤੇ ਇਸੇ ਲਈ ਸਥਾਨਕ ਕੈਸ਼ ਸਾਫ਼ ਕਰਨਾ ਸਿਰਫ਼ ਕਦੇ-ਕਦੇ ਮਦਦ ਕਰਦਾ ਹੈ। ਕੈਸ਼ ਸਾਫ਼ ਕਰਨ ਨਾਲ ਸਵਾਲ ਫਿਰ ਉਸੇ ਅਧਿਕਾਰ ਵੱਲ ਜਾਂਦਾ ਹੈ।

ਫ਼ਰਕ ਪਾਉਣ ਵਾਲੀ ਪਰਖ ਹਰ ਪ੍ਰਕਾਸ਼ਿਤ ਸਰਵਰ ਨੂੰ ਸਿੱਧੀ ਕਵੈਰੀ ਹੈ।

ਹਰ ਅਧਿਕਾਰ ਨੂੰ ਸਿੱਧਾ ਪੁੱਛੋ

ਯਾਦ ਰੱਖੀ ਸੂਚੀ ਤੋਂ ਨਹੀਂ, ਡੈਲੀਗੇਸ਼ਨ ਤੋਂ ਸ਼ੁਰੂ ਕਰੋ। ਮੂਲ ਨੂੰ NS ਸੈੱਟ ਪੁੱਛੋ, ਫਿਰ ਉਸ ਸੈੱਟ ਦੇ ਹਰ ਨਾਮ ਨੂੰ ਤੁਹਾਨੂੰ ਲੋੜੀਂਦਾ ਰਿਕਾਰਡ ਪੁੱਛੋ। ਇੱਕੋ ਨਾਮ ਲਈ ਵੱਖ-ਵੱਖ ਅਧਿਕਾਰਾਂ 'ਤੇ ਦੋ ਕਵੈਰੀਆਂ ਤੁਰੰਤ ਦੱਸਦੀਆਂ ਹਨ ਕਿ ਜ਼ੋਨ ਸੁਸੰਗਤ ਹੈ ਜਾਂ ਨਹੀਂ।

dig +short NS example.com
dig @ns1.dns.example app.example.com A
dig @ns2.dns.example app.example.com A

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

ਉਹ ਕਵੈਰੀਆਂ ਸਿਰਫ਼ ਤੁਹਾਡੇ ਡੈਸਕ ਤੋਂ ਨਹੀਂ, ਫੇਲ੍ਹ ਹੋਣ ਵਾਲੇ ਨੈੱਟਵਰਕ ਤੋਂ ਚਲਾਓ।

ਇੱਛਤ ਦ੍ਰਿਸ਼ਾਂ ਨੂੰ ਟੁੱਟੇ ਦ੍ਰਿਸ਼ਾਂ ਤੋਂ ਵੱਖ ਕਰੋ

ਕੁਝ ਡੋਮੇਨ ਖੇਤਰ ਜਾਂ ਰਿਜ਼ੋਲਵਰ ਸਮੂਹ ਅਨੁਸਾਰ ਜਾਣਬੁੱਝ ਕੇ ਵੱਖਰਾ ਜਵਾਬ ਦਿੰਦੇ ਹਨ, ਅਤੇ ਵੰਡਿਆ ਖਿਤਿਜ ਸੈੱਟਅੱਪ ਉੱਦਮ ਨੈੱਟਵਰਕਾਂ ਵਿੱਚ ਆਮ ਹੈ।

ਸਵਾਲ ਇਹ ਹੈ ਕਿ ਫ਼ਰਕ ਦਸਤਾਵੇਜ਼ੀ ਅਤੇ ਸਥਿਰ ਹੈ ਜਾਂ ਨਹੀਂ। ਗੈਰ-ਇੱਛਤ ਦ੍ਰਿਸ਼ ਵੱਖਰਾ ਦਿਸਦਾ ਹੈ: ਇੱਕ ਅਧਿਕਾਰ ਕੋਲ ਐਸਾ ਰਿਕਾਰਡ ਹੈ ਜੋ ਬਾਕੀਆਂ ਨੂੰ ਕਦੇ ਨਹੀਂ ਮਿਲਿਆ, ਜਾਂ ਉਸ ਕੋਲ ਉਹ ਨਹੀਂ ਜੋ ਸਾਰੇ ਸਾਂਝਾ ਕਰਦੇ ਹਨ। RFC 2182 ਦੀ ਚੋਣ ਅਤੇ ਤੈਨਾਤੀ ਗਾਈਡ ਅਧਿਕਾਰਤ ਉਪਲਬਧਤਾ ਨੂੰ ਸਾਂਝੀ ਜ਼ਿੰਮੇਵਾਰੀ ਮੰਨਦੀ ਹੈ, ਅਤੇ ਇੱਥੇ ਇਹੀ ਸਹੀ ਢਾਂਚਾ ਹੈ। ਰੀਡੰਡੈਂਸੀ ਸਿਰਫ਼ ਤਦ ਹੁੰਦੀ ਹੈ ਜਦੋਂ ਹਰ ਪ੍ਰਕਾਸ਼ਿਤ ਸਰਵਰ ਇੱਛਤ ਡੇਟਾ ਦਾ ਜਵਾਬ ਦੇ ਸਕਦਾ ਹੈ, ਸਿਰਫ਼ ਪੋਰਟ 53 'ਤੇ ਕਨੈਕਸ਼ਨ ਸਵੀਕਾਰ ਕਰਨਾ ਨਹੀਂ।

SERVFAIL ਜਵਾਬ ਦੇਣ ਵਾਲਾ ਸਰਵਰ ਆਤਮਵਿਸ਼ਵਾਸ ਨਾਲ ਗਲਤ ਜਵਾਬ ਦੇਣ ਵਾਲੇ ਨਾਲੋਂ ਵਧੇਰੇ ਆਸਾਨੀ ਨਾਲ ਨਿਦਾਨ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਤਬਦੀਲੀ ਉਹ ਖੋਲ੍ਹਦੀ ਹੈ ਜੋ ਕੈਸ਼ ਨੇ ਲੁਕਾਇਆ ਸੀ

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

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

ਲੈਪਟਾਪ 'ਤੇ ਰਿਜ਼ੋਲਵਰ ਬਦਲਣ ਨਾਲ ਸਿਰਫ਼ ਉਹ ਲੈਪਟਾਪ ਹੀ ਠੀਕ ਹੁੰਦਾ ਹੈ, ਹੋਰ ਕੁਝ ਨਹੀਂ।

ਜ਼ੋਨ ਠੀਕ ਕਰੋ, ਰਿਜ਼ੋਲਵਰ ਨਹੀਂ

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

ਫਿਰ ਦੋਵੇਂ ਨੈੱਟਵਰਕਾਂ ਤੋਂ ਸਿੱਧੀਆਂ ਕਵੈਰੀਆਂ ਦੁਬਾਰਾ ਚਲਾਓ ਅਤੇ ਤੁਸੀਂ ਬਦਲੇ ਰਿਕਾਰਡ ਦਾ TTL ਖ਼ਤਮ ਹੋਣ ਤੱਕ ਉਡੀਕ ਕਰੋ।

ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਜਵਾਬ ਹਰ ਅਧਿਕਾਰ ਤੋਂ ਸਥਿਰ ਹੈ, ਅਤੇ ਇੱਛਤ ਦ੍ਰਿਸ਼ ਜ਼ੋਨ ਦਸਤਾਵੇਜ਼ ਵਿੱਚ ਲਿਖੋ ਤਾਂ ਜੋ ਅਗਲਾ ਫ਼ਰਕ ਆਸਾਨੀ ਨਾਲ ਵਰਗੀਕ੍ਰਿਤ ਹੋ ਸਕੇ।