ਵੈੱਬ ਐਪ ਲਈ ਕਸਟਮ ਡੋਮੇਨ ਸੈਟਅਪ — ਸਪਸ਼ਟ DNS ਰਿਕਾਰਡ ਸਟੈਪ, SSL ਜਾਰੀ ਕਰਨ, ਰੀਡਾਇਰੈਕਟਸ ਅਤੇ ਬਿਨਾਂ ਡਾਊਨਟਾਈਮ ਵਾਲੇ cutover ਲਈ ਘੱਟ-ਖਤਰਾ ਯੋਜਨਾ।
ਕਸਟਮ ਡੋਮੇਨ ਸਿਰਫ਼ ਇੱਕ ਸੋਹਣਾ URL ਨਹੀਂ ਹੈ। ਜਦੋਂ ਤੁਸੀਂ ਇੱਕ ਪਲੇਟਫਾਰਮ ਪਤੇ (ਜਿਵੇਂ Koder.ai ਦੇ ਅਧੀਨ ਇੱਕ ਅਪਲਿਕੇਸ਼ਨ) ਤੋਂ ਆਪਣੀ ਆਪਣੀ ਡੋਮੇਨ ‘ਤੇ ਜਾਣਾ ਸ਼ੁਰੂ ਕਰਦੇ ਹੋ, ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਨੈੱਟਵਰਕ ਇਸਨੂੰ ਇਕ ਵੱਖਰੇ ਸਾਈਟ ਵਜੋਂ ਵਿਆਖਿਆ ਕਰਦੇ ਹਨ। ਇਸਦਾ ਅਸਰ ਰਾਊਟਿੰਗ, ਸੁਰੱਖਿਆ, ਅਤੇ ਯੂਜ਼ਰ ਸੈਸ਼ਨ ਵਿੱਚ ਹੁੰਦਾ ਹੈ।
ਜਦੋਂ ਤੁਸੀਂ ਕਸਟਮ ਡੋਮੇਨ ‘ਤੇ ਸਵਿੱਚ ਕਰਦੇ ਹੋ ਤਾਂ ਕੁਝ ਚੀਜ਼ਾਂ ਤੁਰੰਤ ਬਦਲ ਜਾਂਦੀਆਂ ਹਨ:
www ਤੇ ਆਉਣਗੇ ਜਾਂ apex ਡੋਮੇਨ ਤੇ, ਅਤੇ HTTP ਤੋਂ HTTPS ਨਿਯਮ ਸਹੀ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ।old-platform.example ਦੀ ਲੋਗਿਨ ਕੁਕੀ ਆਪਣੇ-ਆਪ ਹੀ app.yourdomain.com ‘ਤੇ ਕੰਮ ਨਹੀਂ ਕਰੇਗੀ।ਛੋਟੀ ਡਾਊਨਟਾਈਮ ਆਮ ਤੌਰ ‘ਤੇ ਟਾਈਮਿੰਗ ਕਾਰਨ ਹੁੰਦੀ ਹੈ। DNS ਪਹਿਲਾਂ ਨਵੀਂ ਹੋਸਟ ਨੂੰ ਟ੍ਰੈਫਿਕ ਭੇਜ ਸਕਦਾ ਹੈ ਪਰ SSL ਤਿਆਰ ਨਹੀਂ ਹੁੰਦਾ, ਜਿਸ ਨਾਲ ਬ੍ਰਾਉਜ਼ਰ ਚੇਤਾਵਨੀ ਆ ਸਕਦੀ ਹੈ। ਜਾਂ ਵਿਰੋਧੀ ਘਟਨਾ: SSL ਤਿਆਰ ਹੈ ਪਰ DNS ਕੈਸ਼ ਕਾਰਨ ਬਹੁਤ ਸਾਰੇ ਯੂਜ਼ਰ ਪੁਰਾਣੇ ਸਥਾਨ ‘ਤੇ ਹੀ ਜਾ ਰਹੇ ਹਨ।
ਰੀਡਾਇਰੈਕਟਸ ਵੀ ਲੌਗਿਨ ਨੂੰ ਸੁਖਾਵਟੇ ਤਰੀਕੇ ਨਾਲ ਖਰਾਬ ਕਰ ਸਕਦੇ ਹਨ। ਜੇ ਰੀਡਾਇਰੈਕਟ ਹੋਸਟਨੇਮ ਬਦਲਦਾ ਹੈ (apex ਤੋਂ www ਜਾਂ ਉਲਟ), ਤਾਂ ਕੁਕੀ ਡ੍ਰਾਪ ਹੋ ਸਕਦੀ ਹੈ ਜੇ ਉਹ ਦੂਜੇ ਹੋਸਟ ਲਈ ਸੀਟ ਕੀਤੀ ਗਈ ਸੀ। ਆਥ ਪ੍ਰੋਵਾਈਡਰ ਫੇਲ ਹੋ ਸਕਦੇ ਹਨ ਜੇ ਉਹਨਾਂ ਦੀ callback URL ਪੁਰਾਣੀ ਡੋਮੇਨ ਤੇ ਹੀ ਹੋਵੇ।
ਏਕ ਨਿਯਮ: ਇੱਕ low-risk cutover ਵਿੱਚ overlap ਪਲਾਨ ਕੀਤਾ ਜਾਂਦਾ ਹੈ: ਪੁਰਾਣੀ URL ਚੱਲਦੀ ਰਹੇ, ਨਵੀਂ ਡੋਮੇਨ ਪੈਰੈਲੇਲ ਉੱਪਰ ਆਵੇ, ਫਿਰ ਇੱਕ ਪੂਰੇ ਤਰੀਕੇ ਨਾਲ ਟ੍ਰੈਫਿਕ ਸ਼ਿਫਟ ਕੀਤਾ ਜਾਵੇ ਅਤੇ rollback ਸਧਾਰਨ ਹੋਵੇ (DNS ਨੂੰ ਵਾਪਸ ਕਰਨਾ)।
ਕੋਈ ਵੀ ਚੀਜ਼ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਉਹਨਾਂ ਸਾਰਿਆਂ ਨਾਮਾਂ ਨੂੰ ਲਿਖੋ ਜੋ ਤੁਸੀਂ ਯੂਜ਼ਰਾਂ ਨੂੰ ਟਾਈਪ ਕਰਵਾਉਣੀ ਚਾਹੁੰਦੇ ਹੋ, ਅਤੇ ਉਹਨਾਂ ਨਾਮਾਂ ਨੂੰ ਜੋ ਚੁੱਪ-ਚਾਪ ਰੀਡਾਇਰੈਕਟ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ “ਆਧੇ-ਕਾਮ ਕਰ ਰਹੇ” ਮਾਮਲੇ ਇਸ ਕਰਕੇ ਹੁੰਦੇ ਹਨ ਕਿ ਟੀਮ ਇੱਕ ਸੱਚੇ ਹੋਸਟਨੇਮ 'ਤੇ ਇਕੱਠੀ ਸਹਿਮਤੀ ਨਹੀਂ ਬਣਾਂਦੀ।
ਬੜੀ ਚੋਣ ਨਾਲ ਸ਼ੁਰੂ ਕਰੋ: apex (example.com) ਜਾਂ www (www.example.com) ਨੂੰ ਪ੍ਰਾਇਮਰੀ ਬਣਾਉਣਾ। ਦੋਹਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਕੰਮ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਇੱਕ ਚੁਣੋ ਅਤੇ ਦੂਜੇ ਨੂੰ ਰੀਡਾਇਰੈਕਟ ਸਮਝੋ। ਇਹ ਕੁਕੀਆਂ ਲਈ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹੈ: ਜਦੋਂ ਐਪ ਇਕ ਸਥਿਰ ਹੋਸਟ 'ਤੇ ਰਹੇ ਤਾਂ ਸੈਸ਼ਨ ਆਸਾਨ ਹੁੰਦੇ ਹਨ।
ਅਗਲੇ ਕਦਮ ਵਿੱਚ ਸੋਚੋ ਕਿ ਤੁਹਾਨੂੰ ਕਿਹੜੇ ਸਬਡੋਮੇਨ ਲੋੜੀਂਦੇ ਹਨ ਅਤੇ ਕਿਹੜੇ ਬਾਅਦ ਵਿੱਚ ਬਣਾਏ ਜਾ ਸਕਦੇ ਹਨ। ਆਮ ਤੌਰ ‘ਤੇ app.example.com ਵੈੱਬ ਐਪ ਲਈ ਅਤੇ api.example.com API ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ ‘ਤੇ ਕਸਟਮ ਡੋਮੇਨ ਸੈਟ ਕਰ ਰਹੇ ਹੋ ਤਾਂ ਇਹ ਚੋਣਾਂ SSL ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ DNS ਪਾਇਂਟਿੰਗ ਨਾਲ ਸਿੱਧੇ ਜੁੜਦੀਆਂ ਹਨ।
ਕਈ ਵਾਰੀ ਡੋਮੇਨ ਰਜਿਸਟਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਪਰ DNS ਕਿਤੇ ਹੋਰ ਤੇ ਹੋਸਟ ਹੁੰਦਾ ਹੈ। ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਰਿਕਾਰਡ ਅੱਜ ਕਿੱਥੇ ਸੋਧੇ ਜਾਂਦੇ ਹਨ, ਕਿਸਦੇ ਕੋਲ ਐਕਸੈੱਸ ਹੈ, ਅਤੇ ਕੋਈ ਆਟੋਮੇਸ਼ਨ (ਕੰਪਨੀ IT, ਏਜੰਸੀ, ਜਾਂ ਮੈਨੇਜਡ DNS ਪ੍ਰੋਵਾਇਡਰ) ਤਾਂ ਨਹੀਂ ਚਲਾ ਰਹੀ। ਜੇ ਤੁਸੀਂ ਲੌਗਿਨ ਕਰਕੇ ਮੌਜੂਦਾ ਰਿਕਾਰਡ ਨਹੀਂ ਵੇਖ ਸਕਦੇ ਤਾਂ ਪਹਿਲਾਂ ਇਹ ਠੀਕ ਕਰੋ।
ਡੋਮੇਨ ਦਾ ਜੋ ਪਹਿਲਾਂ ਵਰਤੋਂ ਚੁੱਕਾਇਆ ਹੋਇਆ ਹੈ ਉਹ ਵੀ ਆਡਿਟ ਕਰੋ। ਈਮੇਲ ਸਭ ਤੋਂ ਵੱਡਾ ਫੰਦਾ ਹੈ: ਰਿਕਾਰਡ ਹਟਾ ਕੇ ਜਾਂ ਓਵਰਰਾਈਟ ਕਰ ਕੇ ਤੁਸੀਂ ਮੇਲ ਡਿਲਿਵਰੀ ਨੂੰ ਤੋੜ ਸਕਦੇ ਹੋ।
ਚਲਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਇਹ ਫੈਸਲੇ ਲਿਖੋ:
www) ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਦਿਸ਼ਾਜੇ ਮਾਰਕੀਟਿੰਗ ਪਹਿਲਾਂ ਹੀ example.com ‘ਤੇ ਈਮੇਲ ਚਲਾ ਰਹੀ ਹੈ, ਤਾਂ ਮੇਲ-ਸਬੰਧੀ ਰਿਕਾਰਡ ਨੂੰ ਬਿਨਾਂ ਛੋੜੇ ਰੱਖੋ ਅਤੇ ਸਿਰਫ਼ ਐਪ ਲਈ ਲੋੜੀਂਦੇ ਨਵੇਂ ਰਿਕਾਰਡ ਜੋੜੋ।
ਜ਼ਿਆਦਾਤਰ ਰਿਸਕ ਇੱਕ ਗਲਤ DNS ਬਦਲਾਉ ਹੈ: ਟ੍ਰੈਫਿਕ ਕਿਸੇ ਖਾਲੀ ਜਗ੍ਹਾ ਨੂੰ ਜਾ ਸਕਦਾ ਹੈ, ਈਮੇਲ ਟੁੱਟ ਸਕਦੀ ਹੈ, ਜਾਂ SSL ਵੈਰਿਫਿਕੇਸ਼ਨ ਫੇਲ ਹੋ ਸਕਦੀ ਹੈ।
A record ਇੱਕ ਨਾਮ ਨੂੰ IP ਪਤੇ ‘ਤੇ ਜੋੜਦਾ ਹੈ — ਸਿੱਧਾ “ਲੋਕਾਂ ਨੂੰ ਇਸ ਸਰਵਰ ਤੇ ਭੇਜੋ”। ਇਹ ਆਮ ਤੌਰ ‘ਤੇ apex (example.com) ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ ਜੇ ਤੁਹਾਡੇ ਪ੍ਰੋਵਾਇਡਰ ਨੇ ਇੱਕ ਫਿਕਸਡ IP ਦਿੱਤਾ ਹੈ।
CNAME record ਇੱਕ ਨਾਮ ਨੂੰ ਦੂਜੇ ਨਾਮ ਦੇ ਨਾਲ ਜੋੜਦਾ ਹੈ — “ਇਸ ਨਾਮ ਨੂੰ ਉਸ ਹੋਸਟਨੇਮ ਵਜੋਂ ਮੰਨੋ”। ਇਹ ਆਮ ਤੌਰ www.example.com ਨੂੰ ਪਲੇਟਫਾਰਮ ਹੋਸਟਨੇਮ ਵੱਲ ਪਾਇੰਟ ਕਰਨ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ।
ਕਈ DNS ਪ੍ਰੋਵਾਇਡਰ ALIAS/ANAME ਵੀ ਦਿੰਦੇ ਹਨ ਜੋ apex ਲਈ CNAME ਵਰਗਾ ਹоведਾ ਕਰਦਾ ਹੈ ਪਰ apex 'ਤੇ ਕੰਮ ਕਰਦਾ ਹੈ। ਜੇ ਤੁਹਾਡਾ ਪ੍ਰੋਵਾਇਡਰ ਇਸਨੂੰ ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ ਤਾਂ ਇਹ IPs ਨੂੰ ਹੱਥ ਨਾਲ ਬਦਲਣ ਦੀ ਲੋੜ ਘਟਾ ਦਿੰਦਾ ਹੈ।
ਸਰਲ ਮੋਡਲ:
ਤੁਸੀਂ ਅਕਸਰ TXT ਰਿਕਾਰਡ domain ownership ਚੈੱਕ ਲਈ, ਅਤੇ SSL ਸਰਟੀਫਿਕੇਟ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲਈ ਜੋੜੋਗੇ। TXT SPF ਜੇਹੜਾ ਈਮੇਲ ਨੀਤੀ ਲਈ ਵਰਤਿਆ ਜਾਂਦਾ ਹੈ। ਮੌਜੂਦਾ SPF ਨੂੰ ਗਲਤ ਤਰੀਕੇ ਨਾਲ ਡਿਲੀਟ ਜਾਂ ਰੀਪਲੇਸ ਕਰਨਾ ਮੇਲ ਨੂੰ ਤੋੜ ਸਕਦਾ ਹੈ।
TTL ਇਹ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ ਕਿ ਹੋਰ ਸਿਸਟਮ ਤੁਹਾਡੇ DNS ਜਵਾਬ ਨੂੰ ਕਿੰਨੀ ਦੇਰ ਕੈਸ਼ ਕਰਨਗੇ। Cutover ਤੋਂ ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ TTL ਘਟਾਓ (ਆਮ ਤੌਰ ਤੇ 300–600 ਸਕਿੰਟ)। ਸਭ ਕੁਝ ਸਥਿਰ ਹੋਣ ਤੋਂ ਬਾਅਦ TTL ਵਾਪਸ ਵਧਾ ਦਿਓ ਤਾਂ ਕਿ ਸਰਵਰ ਲੋਡ ਘਟੇ।
ਸੋਧ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ zone ਦਾ ਐਕਸਪੋਰਟ ਜਾਂ ਸਕ੍ਰੀਨਸ਼ਾਟ ਲੈ ਲੋ। ਹਰ ਰਿਕਾਰਡ ਜੋ ਤੁਸੀਂ ਬਦਲੋਗੇ ਉਸਦਾ ਪੁਰਾਣਾ ਅਤੇ ਨਵਾਂ ਮੁੱਲ ਲਿਖੋ ਅਤੇ TTL ਦਰਜ ਕਰੋ। ਗਲਤ ਹੋਣ ‘ਤੇ ਰੋਲਬੈਕ ਮਤਲਬ ਪਹਿਲੇ ਮੁੱਲ ਨੂੰ ਵਾਪਸ ਰੱਖਣਾ ਹੈ।
ਇਹ ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਡੋਮੇਨਾਂ ਲਈ ਜ਼ਰੂਰੀ ਹੈ ਜਿਨ੍ਹਾਂ ‘ਤੇ ਪਹਿਲਾਂ ਤੋਂ MX, DKIM ਜਾਂ ਹੋਰ TXT ਰਿਕਾਰਡ ਹਨ।
SSL (ਲੌਕ ਆਈਕਨ) ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ ਤੁਹਾਡੇ ਐਪ ਵਿਚਕਾਰ ਟ੍ਰੈਫਿਕ ਨੂੰ ਇਨਕ੍ਰਿਪਟ ਕਰਦਾ ਹੈ। ਬਹੁਤ ਸਾਰੇ ਬ੍ਰਾਉਜ਼ਰ ਅਤੇ APIs ਹੀ HTTPS ਉਮੀਦ ਕਰਦੇ ਹਨ। ਬਿਨਾਂ ਇਸ ਦੇ ਚੇਤਾਵਨੀਆਂ, ਅਵਰੋਧ ਅਤੇ ਕੁਝ ਫੀਚਰ ਕੰਮ ਨਹੀਂ ਕਰਨਗੇ।
CA ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਨ ਲਈ ਇਹ ਪੂਰਾ ਵਿਸ਼ਵਾਸ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ ਕਿ ਤੁਸੀਂ ਡੋਮੇਨ ਕੰਟਰੋਲ ਕਰਦੇ ਹੋ। ਆਮ ਤਰੀਕੇ ਹਨ HTTP ਵੈਰੀਫਿਕੇਸ਼ਨ ਅਤੇ DNS TXT ਵੈਰੀਫਿਕੇਸ਼ਨ:
Jਦੋਂ CDN ਜਾਂ ਤੁਹਾਡੀ ਐਪ ਨਵੀਂ ਡੋਮੇਨ 'ਤੇ ਸਿੱਧੇ ਪਹੁੰਚ ਨਹੀਂ ਹੁੰਦੀ, ਤਾਂ DNS validation ਅਕਸਰ ਆਸਾਨ ਰਹਿੰਦੀ ਹੈ।
ਸਰਟੀਫਿਕੇਟ ਕਿੱਥੇ ਜਾਰੀ ਹੁੰਦਾ ਹੈ ਇਹ ਤੁਹਾਡੇ ਸੈਟਅਪ 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ। ਕੁਝ ਟੀਮ ਸਰਟੀਫਿਕੇਟ ਆਪਣੇ ਹੋਸਟਿੰਗ ਸਟੈਕ 'ਤੇ ਜਾਰੀ ਕਰਦੀਆਂ ਹਨ, ਕੁਝ CDN 'ਤੇ, ਅਤੇ ਬਹੁਤ ਸਾਰੇ ਪਲੇਟਫਾਰਮ (ਜਿਵੇਂ Koder.ai) ਕਸਟਮ ਡੋਮੇਨ ਸਮਰਥਨ ਦੌਰਾਨ ਇਹ ਸੰਭਾਲ ਲੈਂਦੇ ਹਨ। ਮਹੱਤਵਪੂਰਣ Gall ਇਹ ਹੈ ਕਿ ਸਪਸ਼ਟ ਹੋਵੇ ਕੌਣ ਸਰਟੀਫਿਕੇਟ ਲਾਈਫਸਾਈਕਲ (ਜਾਰੀ/renewal) ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਰੱਖਦਾ ਹੈ।
ਸਰਟੀਫਿਕੇਟ ਤੁਰੰਤ ਮਿਲ ਨਹੀਂ ਸਕਦੇ। DNS ਪ੍ਰੋਪੇਗੇਸ਼ਨ, ਵੈਰੀਫਿਕੇਸ਼ਨ ਚੈੱਕ, ਅਤੇ ਰੇਟ ਲਿਮਿਟਸ ਕਾਰਨ ਦੇਰੀ ਹੋ ਸਕਦੀ ਹੈ। ਰੀਟ੍ਰਾਈ ਅਤੇ cutover ਨੂੰ ਆਖਰੀ ਪਲ ਤੇ ਨਾ ਰੱਖੋ।
ਅਮਲੀ ਟਾਈਮਿੰਗ ਯੋਜ਼ਨਾ:
ਸਰਟੀਫਿਕੇਟ ਨੂੰ ਹਰ ਉਸ ਹੋਸਟਨੇਮ ਨੂੰ ਕਵਰ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ ਜਿਸ 'ਤੇ ਯੂਜ਼ਰ ਆ ਸਕਦੇ ਹਨ। SAN ਲਿਸਟ (Subject Alternative Names) ਚੈੱਕ ਕਰੋ। ਜੇ ਤੁਹਾਡੀ ਐਪ ਦੋਹਾਂ example.com ਅਤੇ www.example.com 'ਤੇ ਉਪਲਬਧ ਹੋਵੇਗੀ, ਤਾਂ ਦੋਹਾਂ ਨੂੰ ਸਰਟੀਫਿਕੇਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕਰੋ।
Wildcard (*.example.com) ਕਈ ਸਬਡੋਮੇਨਾਂ ਲਈ ਮਦਦਗਾਰ ਹੋ ਸਕਦਾ ਹੈ, ਪਰ ਇਹ apex (example.com) ਨੂੰ ਕਵਰ ਨਹੀਂ ਕਰਦਾ।
ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ ਸਿਰਫ www.example.com ਲਈ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਕਰਦੇ ਹੋ, ਤਾਂ ਜੋ ਯੂਜ਼ਰ example.com ਟਾਈਪ ਕਰਨਗੇ ਉਹ ਚੇਤਾਵਨੀ ਦੇਖਣਗੇ ਜਦੋਂ ਤੱਕ ਤੁਸੀਂ ਕੋਈ ਥੰਕ ਲੇਅਰ ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਨਹੀਂ ਰੱਖਦੇ ਜਿਸਦੇ ਕੋਲ example.com ਲਈ ਵੀ ਵੈਧ ਸਰਟੀਫਿਕੇਟ ਹੋਵੇ।
ਰੀਡਾਇਰੈਕਟਸ ਸਾਦੇ ਲੱਗਦੇ ਹਨ ਪਰ ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਸਮੱਸਿਆਵਾਂ ਇੱਥੇ ਆਉਂਦੀਆਂ ਹਨ: ਲੂਪ, ਮਿਕਸਡ ਕੰਟੈਂਟ, ਅਤੇ ਯੂਜ਼ਰ ਲੌਗਆਊਟ ਹੋ ਜਾਣਾਂ ਕਿਉਂਕਿ ਉਹ ਹੋਸਟਸ ਵਿੱਚ ਬਰਫ਼ਲ ਹੋ ਰਹੇ ਹਨ।
ਇੱਕ canonical host ਚੁਣੋ ਅਤੇ ਉਸ 'ਤੇ ਟਿਕੇ ਰਹੋ: ਜਾਂ www.example.com ਜਾਂ example.com (apex)। ਦੂਜਾ ਐਨਟਰੀ-poinਟ canonical host ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰੇ ਤਾਂ ਕੁਕੀਆਂ, ਸੈਸ਼ਨ ਅਤੇ SEO ਸੰਕੇਤ ਇੱਕਸਾਰ ਰਹਿੰਦੇ ਹਨ।
ਸੁਰੱਖਿਅਤ ਡਿਫੌਲਟ:
http:// ਤੋਂ https:// ਤੱਕ 301 ਰੀਡਾਇਰੈਕਟHTTP ਤੋਂ HTTPS ਲਈ, ਐਸੇ ਨਿਯਮ ਬਣਾਓ ਜੋ ਯੂਜ਼ਰਾਂ ਨੂੰ ਵਾਪਸ ਨਹੀਂ ਭੇਜ਼ਣ। ਲੂਪ ਰੋਕਣ ਦਾ ਆਸਾਨ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਫੈਸਲਾ ਇਸ ਆਧਾਰ ਤੇ ਕੀਤਾ ਜਾਵੇ ਕਿ ਅਸਲ ਰੀਕਵੈਸਟ ਕੀ ਸੀ। ਜੇ ਤੁਹਾਡਾ ਐਪ ਪ੍ਰੋਕਸੀ ਜਾਂ CDN ਪਿੱਛੇ ਬੈਠਾ ਹੈ, ਤਾਂ ਅਗਾਂਹੇ headers (forwarded headers) ਨੂੰ ਸਹੀ ਤਰ੍ਹਾਂ ਸੰਰਚਿਤ ਕਰੋ; ਨਹੀਂ ਤਾਂ ਐਪ ਹਰ ਰਿਕਵੇਸਟ ਨੂੰ HTTP ਸਮਝ ਕੇ ਲਗਾਤਾਰ ਰੀਡਾਇਰੈਕਟ ਕਰ ਸਕਦਾ ਹੈ।
ਇੱਕ ਮੂਹਾਂ ਤਰ੍ਹਾਂ ਦੌਰਾਨ ਪੁਰਾਣੇ paths ਨੂੰ ਜ਼ਿੰਦਾ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ routes ਬਦਲ ਰਹੇ ਹੋ (ਜਿਵੇਂ /login ਤੋਂ /sign-in), ਤਾਂ ਉਹਨਾਂ ਲਈ ਖ਼ਾਸ ਰੀਡਾਇਰੈਕਟ ਜੋੜੋ। ਸਿਫ਼ਰ ਹੋਮਪੇਜ ਵੱਲ blanket ਰੀਡਾਇਰੈਕਟ ਤੇ ਭਰੋਸਾ ਨਾ ਕਰੋ—ਇਹ ਬੁੱਕਮਾਰਕ ਅਤੇ ਸਾਂਝੇ ਲਿੰਕ ਤੋੜ ਦਿੰਦਾ ਹੈ।
HSTS ਨੂੰ ਸ਼ੁਰੂ ਵਿੱਚ ਬੰਦ ਰੱਖੋ। ਜੇ ਤੁਸੀਂ ਇਹ ਜਲਦੀ ਜਲ੍ਹਾ ਦਿੰਦੇ ਹੋ ਅਤੇ ਬਾਅਦ ਵਿੱਚ HTTP ਟਰਬਲਸ਼ੂਟਿੰਗ ਜਾਂ ਵੈਰੀਫਿਕੇਸ਼ਨ ਕਰਨ ਦੀ ਲੋੜ ਪੈਂਦੀ ਹੈ, ਤਾਂ ਬ੍ਰਾਉਜ਼ਰ ਮਨਾਹੀ ਕਰ ਸਕਦੇ ਹਨ। HTTPS ਸਥਿਰ ਹੋਣ ਅਤੇ ਸਬਡੋਮੇਨ ਕਵਰੇਜ ਹੋਣ ਤੋਂ ਬਾਅਦ ਹੀ HSTS ਚਾਲੂ ਕਰੋ।
ਰੀਡਾਇਰੈਕਟਸ ਦੀ ਜਾਂਚ ਕਰਨ ਲਈ ਇੱਕ ਅਸਰਮੁਹਤ ਟੈਸਟ ਹੋਸਟਨੇਮ ਵਰਤੋ, ਕੁਝ ਡੀਪ ਲਿੰਕ ਟੈਸਟ ਕਰੋ (ਜਤਕ auth pages), ਅਤੇ ਕਮਾਂਡ-ਲਾਈਨ ਰਿਕਵੇਸਟ ਚਲਾਉ ਜੋ ਹਰ ਰੀਡਾਇਰੈਕਟ ਕਦਮ ਅਤੇ ਆਖਰੀ ਮੰਜ਼ਿਲ ਦਿਖਾਏ।
ਇੱਕ ਸੁਰੱਖਿਅਤ cutover ਵੱਧਤਰ ਟਾਈਮਿੰਗ ਦੀ ਗੱਲ ਹੈ। ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ ਨਵੀਂ ਡੋਮੇਨ ਤਿਆਰ ਅਤੇ ਟੈਸਟ ਹੋਵੇ ਜਦੋਂ ਤੱਕ ਕੋਈ ਅਸਲ ਯੂਜ਼ਰ ਉੱਤੇ ਨਹੀਂ ਆ ਰਿਹਾ, ਅਤੇ ਤੁਸੀਂ ਡੀ.ਐਨ.ਐਸ. ਬਦਲਾਅ ਨੂੰ ਤੇਜ਼ੀ ਨਾਲ ਫੈਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ ਤਾਂ ਕਿ ਘਟਨਾ ਦੌਰਾਨ ਫਸੇ ਨਾ ਰਹੋ।
ਜੋ ਰਿਕਾਰਡ ਤੁਸੀਂ ਬਦਲਣ ਵਾਲੇ ਹੋ ਉਹਨਾਂ ਦੀ TTL ਘਟਾਓ। ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ ਕਰੋ ਅਤੇ ਪੁਰਾਣੇ TTL ਵਿੰਡੋ ਦਾ ਇੰਤਜ਼ਾਰ ਕਰੋ ਤਾਂ ਕਿ caches ਨਵੇਂ ਘਟਾਅ ਨੂੰ ਜਾਣ ਲੈਣ।
ਅਗਲਾ, ਕਸਟਮ ਡੋਮੇਨ ਨੂੰ ਆਪਣੇ ਹੋਸਟ/ਪ੍ਰੋਵਾਇਡਰ ਵਿੱਚ ਜੋੜੋ ਅਤੇ ਜੋ ਵੀ ਵੈਰੀਫਿਕੇਸ਼ਨ ਲੋੜੀਂਦੀ ਹੈ ਪੂਰੀ ਕਰੋ। ਜੇ ਤੁਸੀਂ Koder.ai ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ ਪਹਿਲਾਂ ਡੋਮੇਨ ਉਥੇ ਜੋੜੋ ਤਾਂ ਕਿ ਪਲੇਟਫਾਰਮ ownership ਸਾਬਤ ਕਰਕੇ ਰਾਊਟਿੰਗ ਤਿਆਰ ਕਰ ਸਕੇ।
SSL ਜਲਦੀ ਜਾਰੀ ਕਰੋ। ਸਰਟੀਫਿਕੇਟ ਕੁਝ ਮਿੰਟ ਜਾਂ ਹੋਰ ਸਮਾਂ ਲੈ ਸਕਦੇ ਹਨ ਅਤੇ ਤੁਸੀਂ cutover ਦੌਰਾਨ ਉਸ ਦੇ ਇੰਤਜ਼ਾਰ ਵਿੱਚ ਨਹੀਂ ਫਸਣਾ ਚਾਹੁੰਦੇ।
ਡੋਮੇਨ ਨੂੰ ਪਬਲਿਕ ਕਰਨ ਤੋਂ ਪਹਿਲਾਂ ਪ੍ਰਾਈਵੇਟ ਟੈਸਟ ਕਰੋ: ਆਪਣੇ ਮਸ਼ੀਨ 'ਤੇ ਟੈਂਪਰੇਰੀ host entry ਨਾਲ ਨਵਾਂ endpoint ਖੋਲ੍ਹੋ ਅਤੇ ਪੁਸ਼ਟੀ ਕਰੋ ਕਿ ਸਾਈਟ HTTPS ਤੇ ਸਹੀ ਸਰਟੀਫਿਕੇਟ ਨਾਲ ਲੋਡ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਸਟੇਜਡ ਅੱਗੇ-ਪਿੱਛੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਵਰਤੋ ਤਾਂ ਕਿ ਜਲਦੀ ਰੋਕੇ ਜਾ ਸਕੇ ਜੇ ਕੁਝ ਗਲਤ ਲੱਗੇ:
www) ਪਹਿਲਾਂ ਹੀ।ਜੇ ਤੁਸੀਂ DNS ਪੱਧਰ 'ਤੇ canary ਨਹੀਂ ਕਰ ਸਕਦੇ, ਤਾਂ ਇੱਕ ਹੋਸਟਨੇਮ (ਜਿਵੇਂ www) ਹੀ ਪਹਿਲਾਂ ਸਵਿੱਚ ਕਰੋ ਅਤੇ apex ਨੂੰ ਬਾਅਦ ਵਿਚ ਰੱਖੋ।
ਠੰਡੇ ਦਿਮਾਗ ਨਾਲ ਲਿਖੋ ਕਿ ਤੁਸੀਂ ਕਿਸ ਨੂੰ ਵਾਪਸ ਕਰੋਗੇ (ਕਿਹੜੇ ਰਿਕਾਰਡ, ਕਿਹੜੇ ਮੁੱਲ), ਅਤੇ ਕੌਣ ਇਹ ਕਰੇਗਾ। ਰੋਲਬੈਕ ਆਮ ਤੌਰ 'ਤੇ DNS ਨੂੰ ਪਹਿਲਾਂ ਵਰਤੇ ਗਏ ਰਿਕਾਰਡਾਂ 'ਤੇ ਦੁਬਾਰਾ ਰੱਖਣਾ ਹੁੰਦਾ ਹੈ।
ਪੁਰਾਣਾ ਸੈਟਅਪ ਜਿਵੇਂ SSL ਆਦਿ ਵੀ ਸਹੀ ਰਹਿਣ ਦਾ ਯਕੀਨ ਕਰੋ ਤਾਂ ਕਿ ਯੂਜ਼ਰ ਵਾਪਸੀ ਤੌਰ 'ਤੇ ਸਹੀ ਢੰਗ ਨਾਲ fallback ਹੋ ਸਕਣ।
ਡੋਮੇਨ ਬਦਲਣਾ ਸਿਰਫ DNS ਬਦਲਣਾ ਨਹੀਂ ਹੈ। ਬਹੁਤ ਸਾਰੀਆਂ ਐਪਾਂ ਲਈ "ਲੌਗਡ ਇਨ ਹੋਣਾ" ਉਹ ਕੁਕੀ 'ਤੇ ਨਿਰਭਰ ਹੁੰਦਾ ਹੈ ਜੋ ਬ੍ਰਾਉਜ਼ਰ ਖਾਸ ਹੋਸਟਨੇਮ ਨਾਲ ਜੋੜ ਕੇ ਭੇਜਦਾ ਹੈ। ਜੇ ਤੁਸੀਂ ਇਕ ਹੋਸਟਨੇਮ ਤੋਂ ਦੂਜੇ ਤੇ ਸਵਿੱਚ ਕਰੋਗੇ ਤਾਂ ਬ੍ਰਾਉਜ਼ਰ ਪੁਰਾਣੀਆਂ ਕੁਕੀਜ਼ ਨਹੀਂ ਭੇਜੇਗਾ ਅਤੇ ਯੂਜ਼ਰ ਆਊਟ ਲੌਗ ਹੋ ਸਕਦੇ ਹਨ।
ਕੁਕੀ ਸੈਟਿੰਗ ਆਮ ਤੌਰ ਤੇ ਕਾਰਨ ਹੁੰਦੇ ਹਨ:
app.old.com ਲਈ ਸੈਟ ਕੀਤੀ ਕੁਕੀ app.new.com ਨੂੰ ਨਹੀਂ ਭੇਜੀ ਜਾਵੇਗੀ। .example.com ਲਈ ਸੈਟ ਕੀਤੀ ਕੁਕੀ app.example.com ਅਤੇ www.example.com ‘ਤੇ ਸਾਂਝੀ ਹੋ ਸਕਦੀ ਹੈ।/api), ਤਾਂ ਤੁਹਾਡੀ UI ਉਹ ਵੇਖ ਨਹੀਂ ਪਾਏਗੀ।Lax ਆਮ ਤੌਰ ਤੇ ਠੀਕ ਹੈ, ਪਰ ਕੁਝ SSO ਜਾਂ ਭੁਗਤਾਨ ਰੀਡਾਇਰੈਕਟਾਂ ਲਈ None ਅਤੇ Secure ਦੀ ਲੋੜ ਹੋ ਸਕਦੀ ਹੈ।ਰਿਸਕ ਘਟਾਉਣ ਲਈ, ਇੱਕ ਛੋਟੀ ਟ੍ਰਾਂਜ਼ੀਸ਼ਨ ਯੋਜਨਾ ਬਣਾਓ ਜਿਸ ਵਿਚ ਦੋਹਾਂ ਡੋਮੇਨਾਂ ਕੰਮ ਕਰਨ। ਪੁਰਾਣਾ ਹੋਸਟਨੇਮ ਬਤਾਇਆ ਰਹਿਣ ਦਿਓ, ਨਰਮ ਰੀਡਾਇਰੈਕਟ ਕਰੋ, ਅਤੇ ਜੇ ਸੰਭਵ ਹੋਵੇ ਤਾਂ ਸਾਂਝਾ ਸੈਸ਼ਨ ਸਟੋਰ ਵਰਤੋਂ ਤਾਂ ਕਿ ਕੋਈ ਵੀ ਯੂਜ਼ਰ ਜੋ ਕਿਸੇ ਵੀ ਹੋਸਟਨੇਮ 'ਤੇ ਪਹੁੰਚੇ ਉਹ ਪਛਾਣਿਆ ਜਾ ਸਕੇ।
ਜੇ ਤੁਸੀਂ SSO ਜਾਂ OAuth ਵਰਤਦੇ ਹੋ ਤਾਂ cutover ਤੋਂ ਪਹਿਲਾਂ settings ਅੱਪਡੇਟ ਕਰੋ: callback URLs, allowed origins, ਅਤੇ ਕਿਸੇ ਵੀ allowlist ਵਿਚ 'audience' ਜਾਂ redirect URI। ਨਹੀਂ ਤਾਂ ਲਾਗਿਨ identity provider 'ਤੇ ਸਫ਼ਲ ਹੋ ਸਕਦਾ ਹੈ ਪਰ ਤੁਹਾਡੇ ਐਪ ਵੱਲ ਵਾਪਸ ਆਉਣ ਤੇ ਅਸਫਲ ਹੋ ਸਕਦਾ ਹੈ।
ਪਹਿਲਾਂ ਉਹ ਫਲੋਅ ਟੈਸਟ ਕਰੋ ਜੋ ਆਮ ਤੌਰ 'ਤੇ ਟੁੱਟਦੇ ਹਨ: sign up (ਅਤੇ email verification), login/logout, password reset, checkout ਜਾਂ payment return, ਅਤੇ multi-tab sessions।
ਉਦਾਹਰਣ: ਜੇ ਤੁਸੀਂ www.example.com ਨੂੰ example.com ਤੱਕ redirect ਕਰਦੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਕੁਕੀਆਂ .example.com ਲਈ ਸੈਟ ਕੀਤੀਆਂ ਗਈਆਂ ਹਨ (ਜਾਂ ਇੱਕ ਹੀ ਹੋਸਟਨੇਮ ਹਮੇਸ਼ਾਂ ਵਰਤਿਆ ਜਾਵੇ)। ਨਹੀਂ ਤਾਂ ਯੂਜ਼ਰ ਹੋਸਟਨੇਮਾਂ ਵਿਚ ਬਰਫ਼ਲ ਹੋ ਕੇ ਸੈਸ਼ਨ ਗੁਆ ਸਕਦਾ ਹੈ।
ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਸਮੱਸਿਆਵਾਂ “ਰਾਜ਼ਦਾਰ ਇੰਟਰਨੈੱਟ ਮੁੱਦੇ” ਨਹੀਂ ਹੁੰਦੀਆਂ। ਇਹਨਾਂ ਵਿੱਚ DNS, ਸਰਟੀਫਿਕੇਟ, ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮਾਂ ਦੇ ਛੋਟੇ-ਛੋਟੇ ਮਿਲਾਪੀਆਂ ਹੁੰਦੀਆਂ ਹਨ ਜੋ ਅਸਲੀ ਯੂਜ਼ਰਾਂ ਦੇ ਪਹੁੰਚਣ 'ਤੇ ਹੀ ਸਾਹਮਣੇ ਆਉਂਦੀਆਂ ਹਨ।
ਇੱਕ ਆਸਾਨ ਫੰਦਾ apex ਡੋਮੇਨ (example.com) ਹੈ। ਬਹੁਤ ਸਾਰੇ DNS ਪ੍ਰੋਵਾਇਡਰ ਸੱਚੀ CNAME ਨੂੰ apex ਤੇ ਬਰਦਾਸ਼ਤ ਨਹੀਂ ਕਰਦੇ। ਜੇ ਤੁਸੀਂ ਆਨ੍ਹਾ ਨੂੰ CNAME ਵਜੋਂ ਪਾਇੰਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੋਗੇ ਉਹ ਸ਼ਾਇਦ ਚੁਪਕੇ ਠੀਕ ਨਾ ਕੰਮ ਕਰੇ, inconsistent resolve ਹੋਵੇ, ਜਾਂ ਕੁਝ ਨੈੱਟਵਰਕਾਂ ਤੇ ਟੁੱਟ ਜਾਵੇ। ਆਪਣਾ DNS ਹੋਸਟ ਜੋ ਸਹਿਯੋਗ ਦਿੰਦਾ ਹੈ (A/AAAA ਜਾਂ ALIAS/ANAME) ਵਰਤੋਂ।
ਇਕ ਹੋਰ ਆਮ ਕਾਰਨ ਡਾਊਨਟਾਈਮ ਦਾ ਹੈ: DNS ਨੂੰ ਫਲਿੱਪ ਕਰ ਦੇਣਾ ਪਹਿਲਾਂ SSL ਤਿਆਰ ਹੋਣ ਤੋਂ ਪਹਿਲਾਂ। ਯੂਜ਼ਰ ਨਵੀਂ ਜਗ੍ਹਾ ਤੇ ਜਾਂਦੇ ਹਨ, ਪਰ ਬ੍ਰਾਉਜ਼ਰ ਸਰਟੀਫਿਕੇਟ ਦੀ ਕਮੀ ਜਾਂ ਅਧੂਰਾ ਕਵਰੇਜ ਕਾਰਨ ਰੋਕ ਦਿੰਦਾ ਹੈ। ਅਮਲ ਵਿੱਚ, ਤੁਹਾਨੂੰ ਆਮ ਤੌਰ ਤੇ ਦੋਹਾਂ example.com ਅਤੇ www.example.com ਲਈ ਸਰਟੀਫਿਕੇਟ ਚਾਹੀਦਾ ਹੈ, ਭਾਵੇਂ ਤੁਸੀਂ ਇੱਕ ਨੂੰ ਦੂਜੇ ਵੱਲ redirect ਕਰਨ ਦੀ ਯੋਜਨਾ ਬਣਾਈ ਹੋਵੇ।
ਆਮ ਗਲਤੀਆਂ:
www -> apex, ਫਿਰ apex ਵਾਪਸ www), ਜਾਂ ਕਿਸੇ ਥਾਂ HTTP ਬਲਾਕ ਕਰਕੇ HTTPS ਦੂਜੇ ਥਾਂ ਫੋਰਸ ਕਰਨਾhttp:// ਹਾਰਡਕੋਡ ਕੀਤੇ ਐਸੈੱਟਸ ਛੱਡ ਦੇਣਾ, ਜਿਸ ਨਾਲ ਬ੍ਰਾਊਜ਼ਰ ਚੇਤਾਵਨੀ ਅਤੇ ਟੁੱਟੇ ਹੋਏ ਫੀਚਰ ਆ ਜਾਂਦੇ ਹਨਇੱਕ ਤੇਜ਼ sanity check: ਦੋਹਾਂ ਹੋਸਟਨੇਮ (www ਅਤੇ apex) ਨੂੰ HTTPS ਤੇ ਖੋਲ੍ਹੋ, ਲੌਗ ਇਨ ਕਰੋ, refresh ਕਰੋ, ਅਤੇ ਪੂਸ਼ਟੀ ਕਰੋ ਕਿ address bar ਕਦੇ ਵੀ ਵਾਪਸ HTTP ਤੇ ਨਹੀਂ ਆਉਂਦਾ।
ਜੇ ਤੁਸੀਂ ਇਹ Koder.ai ਵਰਗੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਕਰ ਰਹੇ ਹੋ ਤਾਂ confirm ਕਰੋ ਕਿ custom domains connected ਹਨ ਅਤੇ SSL ਜਾਰੀ ਹੋ ਚੁੱਕਾ ਹੈ ਪਹਿਲਾਂ ਹੀ, ਅਤੇ rollback ਚੋਣ ਤੇ ਤਿਆਰ ਰਹੋ ਤਾਂ ਕਿ ਕੋਈ ਗਲਤ ਰੀਕਾਰਡ ਜਾਂ redirect ਲੰਮੇ ਸਮੇਂ ਲਈ ਨਾ ਰਹਿ ਜਾਵੇ।
ਇੱਕ ਸ਼ਾਂਤ cutover ਅਕਸਰ ਤਿਆਰੀ ਦਾ ਨਤੀਜਾ ਹੁੰਦਾ ਹੈ। ਲਕਸ਼: ਯੂਜ਼ਰ ਲੌਗਿਨ ਜਾਰੀ ਰੱਖਣ, ਕੁਕੀਆਂ ਕੰਮ ਕਰਦੀਆਂ ਰਹਿਣ, ਅਤੇ ਜੇ ਕੁਝ ਗਲਤ ਹੋਵੇ ਤਾਂ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ rollback ਕਰ ਸਕੋ।
ਇਹ ਉਨ੍ਹਾਂ ਕਦਮਾਂ ਨੂੰ ਕਰੋ ਜਦੋਂ ਟ੍ਰੈਫਿਕ ਹਾਲੇ ਪੁਰਾਣੇ ਡੋਮੇਨ ਵੱਲ ਜਾ ਰਿਹਾ ਹੋਵੇ। ਇੱਕ ਦਿਨ ਦੇ ਲਈ ਸਮਾਂ ਦਿਓ ਤਾਂ ਕਿ DNS ਬਦਲਾਅ settle ਹੋ ਸਕੇ:
www, api, ਆਦਿ) ਅਤੇ SSL validation ਦਾ ਮੋਡ ਚੁਣੋ (DNS ਜਾਂ HTTP)।www -> apex (ਜਾਂ ਉਲਟ), ਅਤੇ ਇੱਕ canonical host।DNS ਫਲਿੱਪ ਕਰਦਿਆਂ ਪਹਿਲਾ ਘੰਟਾ ਇੱਕ incident drill ਵਾਂਗ ਪਰਵਾਰ ਕਰੋ। ਅਸਲ ਯੂਜ਼ਰ ਫਲੋਅਜ਼ ਦੇਖੋ, ਸਿਰਫ਼ status dashboards ਨਹੀਂ:
ਚਾਹੇ Koder.ai (ਜਾਂ ਹੋਰ ਕੋਈ ਪਲੇਟਫਾਰਮ) custom domains ਅਤੇ SSL ਤੁਸੀਂ ਸੰਭਾਲਦਾ ਹੋਵੇ, ਇਹ ਚੈਕਲਿਸਟ ਫਿਰ ਵੀ ਮਹੱਤਵਪੂਰਣ ਹੈ—ਜ਼ਿਆਦਾਤਰ ਮੁੱਦੇ DNS ਅਤੇ ਰੀਡਾਇਰੈਕਟਸ ਤੋਂ ਆਉਂਦੇ ਹਨ, ਨਾ ਕਿ ਐਪ ਕੋਡ ਤੋਂ।
ਤੁਹਾਡੀ ਐਪ ਹਣੇ myapp.koder.ai ਵਰਗੇ ਅਸਥਾਈ ਪਲੇਟਫਾਰਮ ਪਤੇ ਤੇ ਚੱਲ ਰਹੀ ਹੈ। ਇਹ ਕੰਮ ਕਰਦੀ ਹੈ ਪਰ ਤੁਸੀਂ example.com ਵਰਤਣਾ ਚਾਹੁੰਦੇ ਹੋ, www.example.com ਨੂੰ apex ਵੱਲ ਰੀਡਾਇਰੈਕਟ ਕਰਦੇ ਹੋ ਅਤੇ ਹਰ ਚੀਜ਼ HTTPS 'ਤੇ ਫੋਰਸ ਹੋਵੇ।
ਸਰਲ DNS ਯੋਜਨਾ ਰਿਸਕ ਘਟਾਉਂਦੀ ਹੈ। ਕੁਝ ਵੀ ਬਦਲਣ ਤੋਂ ਪਹਿਲਾਂ ਮੌਜੂਦਾ ਸਥਿਤੀ ਦਾ ਨੋਟ ਲਵੋ (ਜੇ ਤੁਹਾਡਾ ਪਲੇਟਫਾਰਮ snapshot ਸਹਿਯੋਗ ਕਰਦਾ ਹੈ ਤਾਂ ਉਸਦਾ ਸਕ੍ਰੀਨਸ਼ਾਟ ਲੋ) ਅਤੇ TTL ਇੱਕ ਦਿਨ ਪਹਿਲਾਂ ਛੋਟਾ ਕਰੋ।
ਨਵੇਂ ਰਿਕਾਰਡ ਜੋੜੋ ਜਦੋਂ ਕਿ ਮੌਜੂਦਾ ਪਲੇਟਫਾਰਮ URL ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰਹੇ:
example.com: A/ALIAS record ਜੋ ਤੁਹਾਡੇ ਹੋਸਟਿੰਗ ਟਾਰਗਟ ਨੂੰ ਪਾਇੰਟ ਕਰਦਾ ਹੈ ਜੋ ਪਲੇਟਫਾਰਮ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈwww.example.com: CNAME ਜੋ example.com ਨੂੰ ਪਾਇੰਟ ਕਰਦਾ ਹੈ (ਜਾਂ ਪ੍ਰੋਵਾਇਡਰ ਟਾਰਗਟ ਨੂੰ, ਪ੍ਰੋਵਾਇਡਰ ਦੇ ਅਨੁਸਾਰ)myapp.koder.ai ਨੂੰ ਜਿਵੇਂ ਦਾ ਤਿਵੇਂ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਹਾਡੇ ਕੋਲ ਹਮੇਸ਼ਾ ਇੱਕ ਜਾਣਿਆ-ਪਛਾਣਿਆ fallback ਮੌਜੂਦ ਹੋਵੇਜਦੋਂ DNS ਠੀਕ ਹੋਵੇ, ਦੋਹਾਂ ਹੋਸਟਨੇਮ (example.com ਅਤੇ www.example.com) ਲਈ SSL ਦੀ ਬੇਨਤੀ ਕਰੋ। ਯੂਜ਼ਰਾਂ ਨੂੰ ਸਵਿੱਚ ਨਾ ਕਰੋ ਜਦ ਤੱਕ ਸਰਟੀਫਿਕੇਟ ਜਾਰੀ ਅਤੇ ਐਕਟਿਵ ਨਾ ਹੋਵੇ, ਨਹੀਂ ਤਾਂ ਬ੍ਰਾਉਜ਼ਰ ਚੇਤਾਵਨੀ ਹੋ ਸਕਦੀਆਂ ਹਨ।
Cutover ਟਾਈਮਲਾਈਨ ਅਤੇ ਚੈਕਪੌਇੰਟ:
example.com ਟੈਸਟ ਕਰੋ (ਹੋਮਪੇਜ, ਸਟੈਟਿਕ ਐਸੈੱਟਸ, API calls)www -> apex)ਮੂਵ ਤੋਂ ਬਾਅਦ cookie ਵਿਵਹਾਰ ਦਾ ਮੁਲਾਂਕਣ ਕਰੋ। ਲੌਗ ਇਨ ਕਰੋ, refresh ਕਰੋ, ਅਤੇ ਚੈੱਕ ਕਰੋ ਕਿ ਤੁਸੀਂ ਦੋਹਾਂ www ਅਤੇ apex ‘ਤੇ ਲੌਗਡ ਰਹਿੰਦੇ ਹੋ। ਜੇ ਸੈਸ਼ਨ ਟੁੱਟਦੇ ਹਨ ਤਾਂ ਅਕਸਰ ਇਹ cookie domain ਜਾਂ SameSite ਸੈਟਿੰਗ ਕਾਰਨ ਹੁੰਦਾ ਹੈ ਜੋ ਪੁਰਾਣੇ ਹੋਸਟ ਨੂੰ ਮੰਨਦੀ ਰਹਿੰਦੀ ਹੈ।
Cutover ਚੱਲਾਂਦੇ ਫੇਰ, ਕੰਮ ਖਤਮ ਨਹੀਂ ਹੁੰਦਾ। ਜ਼ਿਆਦਾਤਰ ਡੋਮੇਨ ਮੂਵ ਬਾਅਦ ਫੇਲ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਕੋਈ ਨਹੀਂ ਨੋਟਿਸ ਕਰਦਾ: ਸਰਟੀਫਿਕੇਟ ਮਿਆਦ ਨੇੜੇ ਆਉਣਾ, ਜਲਦੀ ਕੀਤਾ DNS ਬਦਲਾਅ, ਜਾਂ ਰੀਡਾਇਰੈਕਟ ਵਿੱਚ ਕੀਤੀ ਛੋਟੀ-ਸੁਧਾਰ ਜੋ ਲੌਗਿਨ ਨੂੰ ਨੁਕਸਾਨ ਪਹੁੰਚਾਉਂਦੀ ਹੈ।
ਛੋਟਾ ਮੋਨੀਟਰੀੰਗ ਰੁਟੀਨ ਬਣਾਓ ਜੋ ਤੁਸੀਂ ਰੱਖ ਸਕੋ। ਤੁਹਾਨੂੰ ਕਿਸੇ ਵਿਸ਼ਾਲ ਉਪਕਰਣ ਦੀ ਲੋੜ ਨਹੀਂ, ਪਰ ਕੁਝ ਭਰੋਸੇਯੋਗ ਸੰਕੇਤ ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ: ਕੁੰਜੀ ਪੇਜ਼ਾਂ ਲਈ availability checks (home, login, ਅਤੇ ਇਕ authenticated page), ਸਰਟੀਫਿਕੇਟ expiry alerts (ਉਦਾਹਰਣ ਲਈ 30 ਦਿਨ ਅਤੇ ਫਿਰ 7 ਦਿਨ), error-rate tracking (4xx/5xx spikes), ਅਤੇ ਹੋਰ ਰੀਡਾਇਰੈਕਟ ਪੁਸ਼ਟੀ।
24 ਤੋਂ 72 ਘੰਟਿਆਂ ਲਈ ਪਿਛਲਾ ਸੈਟਅਪ ਤਿਆਰ ਰੱਖੋ ਤਾਂ ਕਿ ਤੁਸੀਂ ਤੇਜ਼ੀ ਨਾਲ ਵਾਪਸ ਆ ਸਕੋ ਜੇ ਕੋਈ ਛੁਪਿਆ ਮੁੱਦਾ ਜਿਵੇਂ payment callback ਜਾਂ OAuth provider ਅਜੇ ਵੀ ਪੁਰਾਣੇ ਡੋਮੇਨ ਨੂੰ ਪોઈਂਟ ਕਰ ਰਿਹਾ ਹੋਵੇ।
ਜਦੋਂ ਤੁਹਾਨੂੰ ਭਰੋਸਾ ਹੋ ਜਾਵੇ, TTL ਮੁੱਲ ਵਾਪਸ ਵਧਾ ਦਿਓ। ਘੱਟ TTL ਚੇੰਜ ਦੌਰਾਨ ਲਾਭਦਾਇਕ ਹੈ ਪਰ ਇਹ resolvers ਉੱਤੇ ਲੋਡ ਵਧਾਉਂਦਾ ਹੈ ਅਤੇ ਛੋਟੀ ਗਲਤੀਆਂ ਦੇ ਪ੍ਰਭਾਵ ਨੂੰ ਵਧਾ ਦਿੰਦਾ ਹੈ। ਅਕਸਰ ਤੀਮ 1 ਤੋਂ 4 ਘੰਟੇ TTL ਦੇਣਦੀ ਹੈ।
ਆਖਿਰ ਵਿੱਚ, final state ਦਸਤਾਵੇਜ਼ ਕਰੋ ਜਦੋਂ ਯਾਦ ਤਾਜ਼ਾ ਹੋ: ਕਿਹੜੇ ਰਿਕਾਰਡ ਮੌਜੂਦ ਹਨ (type, name, value, TTL), ਕਿਹੜੇ ਹੋਸਟਨੇਮ ਸਹੀ ਹਨ, ਅਤੇ ਠੀਕ ਰੀਡਾਇਰੈਕਟ ਨਿਯਮ। ਸ਼ਾਮਲ ਕਰੋ ਕਿ ਸਰਟੀਫਿਕੇਟ ਕਿੱਥੇ ਜਾਰੀ ਹੁੰਦੇ ਹਨ, ਉਹ ਕੀ ਕਵਰ ਕਰਦੇ ਹਨ (apex, www, subdomains), ਅਤੇ renewal ਦੀ ਜ਼ਿੰਮੇਵਾਰੀ ਕਿਸਦੇ ਕੋਲ ਹੈ।
ਜੇ ਤੁਸੀਂ ਪਲੇਟਫਾਰਮ 'ਤੇ build ਅਤੇ deploy ਕਰਦੇ ਹੋ ਤਾਂ ਡੋਮੇਨਾਂ ਨੂੰ ਪਹਿਲਵਾਰ ਫੀਚਰ ਵਜੋਂ ਦੇਖਣਾ ਮਦਦਗਾਰ ਹੁੰਦਾ ਹੈ ਅਤੇ rollback ਸਧਾਰਨ ਹੋਵੇ ਤਾਂ ਭਵਿੱਖੀ ਡੋਮੇਨ ਅਤੇ ਰੀਡਾਇਰੈਕਟ ਬਦਲਾਅਾਂ ਘੱਟ ਤਣਾਅ ਵਾਲੀਆਂ ਰਹਿੰਦੀਆਂ ਹਨ।
Default to one canonical hostname and redirect everything else to it.
example.com (apex) or www.example.com as the “real” one.This keeps cookies, sessions, and bookmarks consistent and prevents half-working behavior.
Lower TTL the day before you plan to switch, then wait long enough for the old TTL to age out.
Only lower TTL on the records you’re actually going to change.
For many app setups:
www.example.com or app.example.com when you’re pointing to a provider hostname.example.com.Don’t switch user traffic until HTTPS is valid on the new hostname(s).
A practical order:
This avoids browser warnings and blocked requests right at cutover.
Most email breakage happens when people delete or overwrite MX and TXT records.
Before changing anything:
Redirect chains and loops usually come from conflicting rules between your CDN/proxy and your app.
Use these safe defaults:
http:// → https://If you’re behind a proxy/CDN, make sure your app respects forwarded scheme headers; otherwise it may think every request is HTTP and keep redirecting forever.
Yes, it’s common if cookies were scoped to the old hostname.
What to check:
old-host won’t be sent to new-hostUpdate identity settings before cutover.
Typical items that must match the new domain exactly:
If these still point to the old domain, sign-in can succeed at the provider but fail when returning to your app.
A rollback is usually just restoring the previous DNS values.
Keep it simple:
If your platform supports snapshots/rollback (Koder.ai does), take one before cutover so you can quickly undo related configuration changes too.
Focus on real user paths, not just the homepage.
Test these on both the canonical host and the redirecting host:
Also verify the address bar ends on and always on , with no mixed-content warnings.
Avoid trying to force a CNAME at the apex if your DNS host doesn’t support an apex alias style record.
A quick safety step is exporting or screenshotting the current zone so you can restore it fast.
A low-risk approach is keeping the old hostname working during a transition so users can refresh sessions on the new domain.