CDN ਵੱਲੋਂ ਆਪਣੇ ਪਤੇ ਬਦਲਣ 'ਤੇ VPN ਡੋਮੇਨ ਨਿਯਮ ਟੁੱਟਦਾ ਹੈ

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

ਇੱਕ ਖੋਜ ਇਨਵੈਂਟਰੀ ਕਿਉਂ ਨਹੀਂ

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

ਦੂਜੀ ਖਾਲੀ ਥਾਂ ਹੈ। ਇੱਕ ਦਿਸਦਾ ਹੋਸਟਨਾਮ ਪੂਰੀ ਐਪਲੀਕੇਸ਼ਨ ਨੂੰ ਘੱਟ ਹੀ ਢਕਦਾ ਹੈ, ਕਿਉਂਕਿ ਲੌਗਇਨ, ਮੀਡੀਆ ਅਤੇ API ਟ੍ਰੈਫਿਕ ਅਕਸਰ ਵੱਖਰੇ ਨਾਮ ਵਰਤਦੇ ਹਨ। ਐਡਰੈਸ ਬਾਰ ਦੇ ਹੋਸਟਨਾਮ ਤੋਂ ਬਣਿਆ ਨਿਯਮ ਪੇਜ ਨੂੰ ਢਕ ਸਕਦਾ ਹੈ ਅਤੇ ਵੀਡੀਓ ਖੁੰਝਾ ਸਕਦਾ ਹੈ, ਜਿਸਨੂੰ ਰਾਊਟਿੰਗ ਗਲਤੀ ਨਹੀਂ ਬਲਕਿ ਅੰਸ਼ਕ ਅਸਫਲਤਾ ਵਜੋਂ ਪੜ੍ਹਿਆ ਜਾਂਦਾ ਹੈ।

ਤੀਜੀ ਖਾਲੀ ਥਾਂ ਪਤਾ-ਪਰਿਵਾਰ ਹੈ। ਸਿਰਫ਼ v4 ਲਈ ਨਿਯਮ AAAA ਰਿਕਾਰਡ ਬਾਰੇ ਕੁਝ ਨਹੀਂ ਕਹਿੰਦਾ, ਜੋ ਕਲਾਇੰਟ ਪਸੰਦ ਕਰ ਸਕਦਾ ਹੈ।

ਡੋਮੇਨ ਨਿਯਮ ਜਾਂ ਰੇਂਜ ਤੈਅ ਕਰਨ ਵਾਲੀਆਂ ਤਿੰਨ ਸ਼ਰਤਾਂ

ਪਹਿਲਾਂ, ਕੀ ਸੇਵਾ ਸਥਿਰ ਪ੍ਰੀਫਿਕਸ ਦਾ ਸਮੂਹ ਪ੍ਰਕਾਸ਼ਿਤ ਕਰਦੀ ਹੈ ਜੋ ਤੁਸੀਂ ਰੱਖ ਅਤੇ ਦਸਤਾਵੇਜ਼ ਕਰ ਸਕਦੇ ਹੋ? ਜੇ ਕਰਦੀ ਹੈ, ਸਪਸ਼ਟ ਰੇਂਜਾਂ ਇਮਾਨਦਾਰ ਅਤੇ ਸਸਤੀਆਂ ਹਨ। ਜੇ ਨਹੀਂ ਕਰਦੀ, ਡੋਮੇਨ ਨਿਯਮ ਹੀ ਇੱਕੋ-ਇੱਕ ਤਰੀਕਾ ਹੈ ਜੋ ਸੇਵਾ ਦਾ ਪਿੱਛਾ ਕਰ ਸਕਦਾ ਹੈ।

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

ਇਨ੍ਹਾਂ ਤਿੰਨਾਂ ਦਾ ਜਵਾਬ ਦਿਓ ਅਤੇ ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਸਪਸ਼ਟ ਹੁੰਦੀ ਹੈ। ਅੰਦਾਜ਼ਾ ਲਾਉਣ ਨਾਲ ਅਜਿਹਾ ਨਿਯਮ ਬਣਦਾ ਹੈ ਜੋ ਟੈਸਟ ਵਿੱਚ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਉਤਪਾਦਨ ਵਿੱਚ ਅਸਫਲ ਹੁੰਦਾ ਹੈ।

ਸੈਸ਼ਨ ਜਾਂਚੋ, ਪੇਜ ਨਹੀਂ

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

ਪੇਜ ਕੀ ਦਿਖਾਉਂਦਾ ਹੈ ਦੀ ਬਜਾਏ ਸੈਸ਼ਨ ਅਸਲ ਵਿੱਚ ਕਿਸ ਨਾਲ ਸੰਪਰਕ ਕਰਦਾ ਹੈ, ਇਸ ਦੀ ਸੂਚੀ ਬਣਾਓ:

dig +short example.com A
dig +short example.com AAAA
curl -sI https://example.com | head -5

ਤੁਲਨਾ ਦੌਰਾਨ ਰਿਜ਼ੌਲਵਰ ਦਿਸਦਾ ਰੱਖੋ, ਕਿਉਂਕਿ ਇੱਕ ਰਿਜ਼ੌਲਵਰ ਤੋਂ ਕੰਮ ਕਰਨ ਵਾਲਾ ਅਤੇ ਦੂਜੇ ਤੋਂ ਅਸਫਲ ਹੋਣ ਵਾਲਾ ਨਿਯਮ ਤੁਹਾਨੂੰ CDN ਦੇ ਜਵਾਬ ਬਾਰੇ ਦੱਸਦਾ ਹੈ, ਟਨਲ ਬਾਰੇ ਨਹੀਂ। ਛੋਟਾ TTL ਇਹ ਵੀ ਦਰਸਾਉਂਦਾ ਹੈ ਕਿ ਤੁਹਾਡੇ ਦਰਜ ਕੀਤੇ ਜਵਾਬ ਦੀ ਮਿਆਦ ਹੈ।

ਹਰ ਵਿਧੀ ਅਸਲ ਵਿੱਚ ਕੀ ਢਕਦੀ ਹੈ

ਦੋਵੇਂ ਵਿਧੀਆਂ ਸੈਟਿੰਗਾਂ ਪੇਜ 'ਤੇ ਬਦਲਣਯੋਗ ਦਿਸਦੀਆਂ ਹਨ ਅਤੇ ਅੰਦਰੋਂ ਵੱਖਰਾ ਵਿਵਹਾਰ ਕਰਦੀਆਂ ਹਨ।

ਕਰਨਲ ਪਤਾ-ਰਾਹ ਪ੍ਰੀਫਿਕਸ ਮਿਲਾਉਂਦਾ ਹੈ। ਇਸਨੂੰ ਪਤਾ ਨਹੀਂ ਕਿ ਹੋਸਟਨਾਮ ਕੀ ਹੈ, ਇਸ ਲਈ ਇਹ ਪਤੇ ਬਦਲਣ ਵਾਲੀ ਸੇਵਾ ਦਾ ਪਿੱਛਾ ਨਹੀਂ ਕਰ ਸਕਦਾ। ਡੋਮੇਨ ਨਿਯਮ ਨਾਮ ਹੱਲ ਕਰਦਾ ਹੈ ਅਤੇ ਨਤੀਜਾ ਰਾਊਟ ਕਰਦਾ ਹੈ; ਇਹ ਸੇਵਾ ਦਾ ਪਿੱਛਾ ਕਰਦਾ ਹੈ ਪਰ ਰਿਜ਼ੌਲਵਰ, ਰਿਫ੍ਰੈਸ਼ ਵਿਵਹਾਰ ਅਤੇ ਸਬਡੋਮੇਨ ਪ੍ਰਤੀ ਕਲਾਇੰਟ ਦੀ ਸੰਭਾਲ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ ਨਾਮਾਂ ਦਾ ਪਿੱਛਾ ਕਰਨ ਵਾਲਾ ਨਿਯਮ ਕਲਾਇੰਟ ਵੱਲੋਂ ਅਸਲ ਵਿੱਚ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਰਿਜ਼ੌਲਵਰ ਨਾਲ ਜਾਂਚਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ।

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

ਸੇਵਾ ਬਦਲਣ ਤੋਂ ਬਾਅਦ ਦੁਬਾਰਾ ਜਾਂਚੋ

ਕਲਾਇੰਟ ਅੱਪਡੇਟ ਜਾਂ ਸੇਵਾ ਬਦਲਾਅ ਤੋਂ ਬਾਅਦ ਉਹੀ ਸੈਸ਼ਨ ਟੈਸਟ ਦੁਬਾਰਾ ਚਲਾਓ। ਪਹਿਲਾਂ ਕੰਮ ਕਰਨ ਵਾਲੀ ਪਤਾ-ਸੂਚੀ ਉਸ ਸਮੇਂ ਦਾ ਸਬੂਤ ਹੈ, ਸੇਵਾ ਦੇ ਢਾਂਚੇ ਦੀ ਸਥਾਈ ਇਨਵੈਂਟਰੀ ਨਹੀਂ।

ਕਿਹੜੀ ਵਿਧੀ ਕਿਹੜਾ ਹੋਸਟਨਾਮ ਢਕਦੀ ਹੈ, ਅਤੇ ਆਖਰੀ ਜਾਂਚ ਦੀ ਤਾਰੀਖ ਲਿਖੋ।

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