ਘੱਟ DNS ਲੇਟੈਂਸੀ ਤੇਜ਼ ਇੰਟਰਨੈਟ ਬ੍ਰਾਊਜ਼ਿੰਗ ਦੀ ਕੁੰਜੀ ਹੈ। ਇਸ ਨੂੰ ਘੱਟ ਤੋਂ ਘੱਟ ਕਰਨ ਲਈ, DNS ਸਰਵਰਾਂ ਨੂੰ ਧਿਆਨ ਨਾਲ ਚੁਣਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ ਅਤੇ ਅਗਿਆਤ ਰੀਲੇਅ. ਪਰ ਪਹਿਲਾ ਕਦਮ ਬੇਕਾਰ ਸਵਾਲਾਂ ਤੋਂ ਛੁਟਕਾਰਾ ਪਾਉਣਾ ਹੈ.

ਇਹੀ ਕਾਰਨ ਹੈ ਕਿ DNS ਨੂੰ ਅਸਲ ਵਿੱਚ ਇੱਕ ਉੱਚ ਕੈਸ਼ਯੋਗ ਪ੍ਰੋਟੋਕੋਲ ਵਜੋਂ ਤਿਆਰ ਕੀਤਾ ਗਿਆ ਸੀ। ਜ਼ੋਨ ਪ੍ਰਸ਼ਾਸਕ ਵਿਅਕਤੀਗਤ ਐਂਟਰੀਆਂ ਲਈ ਲਾਈਵ ਟਾਈਮ (TTL) ਨਿਰਧਾਰਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਰੈਜ਼ੋਲਵਰ ਬੇਲੋੜੀ ਆਵਾਜਾਈ ਤੋਂ ਬਚਣ ਲਈ ਐਂਟਰੀਆਂ ਨੂੰ ਮੈਮੋਰੀ ਵਿੱਚ ਸਟੋਰ ਕਰਦੇ ਸਮੇਂ ਇਸ ਜਾਣਕਾਰੀ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ।

ਕੀ ਕੈਸ਼ਿੰਗ ਪ੍ਰਭਾਵਸ਼ਾਲੀ ਹੈ? ਕੁਝ ਸਾਲ ਪਹਿਲਾਂ, ਮੇਰੀ ਛੋਟੀ ਖੋਜ ਨੇ ਦਿਖਾਇਆ ਕਿ ਇਹ ਸੰਪੂਰਨ ਨਹੀਂ ਸੀ। ਚਲੋ ਮੌਜੂਦਾ ਸਥਿਤੀ 'ਤੇ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ।

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

ਨਤੀਜਾ ਡਾਟਾ ਸੈੱਟ ਵਿੱਚ 1 ਰਿਕਾਰਡ (ਨਾਮ, qtype, TTL, ਟਾਈਮਸਟੈਂਪ) ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇੱਥੇ ਸਮੁੱਚੀ TTL ਵੰਡ ਹੈ (X-ਧੁਰਾ ਸਕਿੰਟਾਂ ਵਿੱਚ TTL ਹੈ):

86 (ਜ਼ਿਆਦਾਤਰ SOA ਰਿਕਾਰਡਾਂ ਲਈ) 'ਤੇ ਇੱਕ ਮਾਮੂਲੀ ਬੰਪ ਤੋਂ ਇਲਾਵਾ, ਇਹ ਬਿਲਕੁਲ ਸਪੱਸ਼ਟ ਹੈ ਕਿ TTLs ਘੱਟ ਸੀਮਾ ਵਿੱਚ ਹਨ। ਆਓ ਇੱਕ ਡੂੰਘੀ ਵਿਚਾਰ ਕਰੀਏ:

ਠੀਕ ਹੈ, 1 ਘੰਟੇ ਤੋਂ ਵੱਧ TTL ਅੰਕੜਿਆਂ ਦੇ ਤੌਰ 'ਤੇ ਮਹੱਤਵਪੂਰਨ ਨਹੀਂ ਹਨ। ਫਿਰ ਆਉ ਰੇਂਜ 0-3600 'ਤੇ ਧਿਆਨ ਦੇਈਏ:

ਜ਼ਿਆਦਾਤਰ TTL 0 ਤੋਂ 15 ਮਿੰਟ ਤੱਕ ਹੁੰਦੇ ਹਨ:

ਜ਼ਿਆਦਾਤਰ 0 ਤੋਂ 5 ਮਿੰਟ ਤੱਕ ਹਨ:

ਇਹ ਬਹੁਤ ਵਧੀਆ ਨਹੀਂ ਹੈ।

ਸੰਚਤ ਵੰਡ ਸਮੱਸਿਆ ਨੂੰ ਹੋਰ ਵੀ ਸਪੱਸ਼ਟ ਕਰਦੀ ਹੈ:

ਅੱਧੇ DNS ਜਵਾਬਾਂ ਵਿੱਚ 1 ਮਿੰਟ ਜਾਂ ਘੱਟ ਦਾ TTL ਹੁੰਦਾ ਹੈ, ਅਤੇ ਤਿੰਨ-ਚੌਥਾਈ ਵਿੱਚ 5 ਮਿੰਟ ਜਾਂ ਘੱਟ ਦਾ TTL ਹੁੰਦਾ ਹੈ।

ਪਰ ਉਡੀਕ ਕਰੋ, ਇਹ ਅਸਲ ਵਿੱਚ ਬਦਤਰ ਹੈ. ਆਖ਼ਰਕਾਰ, ਇਹ ਅਧਿਕਾਰਤ ਸਰਵਰਾਂ ਤੋਂ ਟੀ.ਟੀ.ਐਲ. ਹਾਲਾਂਕਿ, ਕਲਾਇੰਟ ਰੈਜ਼ੋਲਵਰ (ਜਿਵੇਂ ਕਿ ਰਾਊਟਰ, ਲੋਕਲ ਕੈਚ) ਅੱਪਸਟ੍ਰੀਮ ਰੈਜ਼ੋਲਵਰਾਂ ਤੋਂ ਇੱਕ TTL ਪ੍ਰਾਪਤ ਕਰਦੇ ਹਨ, ਅਤੇ ਇਹ ਹਰ ਸਕਿੰਟ ਘਟਦਾ ਹੈ।

ਇਸ ਲਈ ਕਲਾਇੰਟ ਅਸਲ ਵਿੱਚ ਇੱਕ ਨਵੀਂ ਬੇਨਤੀ ਭੇਜਣ ਤੋਂ ਪਹਿਲਾਂ, ਔਸਤਨ, ਅੱਧੇ ਮੂਲ TTL ਲਈ ਹਰੇਕ ਐਂਟਰੀ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦਾ ਹੈ।

ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਇਹ ਬਹੁਤ ਘੱਟ TTL ਸਿਰਫ ਅਸਧਾਰਨ ਬੇਨਤੀਆਂ 'ਤੇ ਲਾਗੂ ਹੁੰਦੇ ਹਨ ਅਤੇ ਪ੍ਰਸਿੱਧ ਵੈੱਬਸਾਈਟਾਂ ਅਤੇ APIs 'ਤੇ ਨਹੀਂ? ਆਓ ਇੱਕ ਨਜ਼ਰ ਮਾਰੀਏ:

X ਧੁਰਾ TTL ਹੈ, Y ਧੁਰਾ ਪੁੱਛਗਿੱਛ ਪ੍ਰਸਿੱਧੀ ਹੈ।

ਬਦਕਿਸਮਤੀ ਨਾਲ, ਸਭ ਤੋਂ ਵੱਧ ਪ੍ਰਸਿੱਧ ਸਵਾਲ ਵੀ ਕੈਸ਼ ਕਰਨ ਲਈ ਸਭ ਤੋਂ ਮਾੜੇ ਹਨ।

ਆਓ ਜ਼ੂਮ ਇਨ ਕਰੀਏ:

ਫੈਸਲਾ: ਇਹ ਅਸਲ ਵਿੱਚ ਬੁਰਾ ਹੈ. ਇਹ ਪਹਿਲਾਂ ਹੀ ਖਰਾਬ ਸੀ, ਪਰ ਇਹ ਹੋਰ ਵੀ ਖਰਾਬ ਹੋ ਗਿਆ. DNS ਕੈਚਿੰਗ ਲਗਭਗ ਬੇਕਾਰ ਹੋ ਗਈ ਹੈ। ਜਿਵੇਂ ਕਿ ਘੱਟ ਲੋਕ ਆਪਣੇ ISP ਦੇ DNS ਰੈਜ਼ੋਲਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ (ਚੰਗੇ ਕਾਰਨਾਂ ਕਰਕੇ), ਲੇਟੈਂਸੀ ਵਿੱਚ ਵਾਧਾ ਵਧੇਰੇ ਧਿਆਨ ਦੇਣ ਯੋਗ ਹੋ ਜਾਂਦਾ ਹੈ।

DNS ਕੈਚਿੰਗ ਸਿਰਫ਼ ਉਸ ਸਮੱਗਰੀ ਲਈ ਉਪਯੋਗੀ ਬਣ ਗਈ ਹੈ ਜਿਸਨੂੰ ਕੋਈ ਵੀ ਨਹੀਂ ਦੇਖਦਾ।

ਕਿਰਪਾ ਕਰਕੇ ਇਹ ਵੀ ਨੋਟ ਕਰੋ ਕਿ ਸੌਫਟਵੇਅਰ ਹੋ ਸਕਦਾ ਹੈ ਵੱਖਰੇ ਤੌਰ 'ਤੇ ਘੱਟ TTL ਦੀ ਵਿਆਖਿਆ ਕਰੋ।

ਅਜਿਹਾ ਕਿਉਂ ਹੈ

DNS ਰਿਕਾਰਡ ਇੰਨੇ ਘੱਟ TTL 'ਤੇ ਕਿਉਂ ਸੈੱਟ ਕੀਤੇ ਗਏ ਹਨ?

• ਪੁਰਾਤਨ ਲੋਡ ਬੈਲੇਂਸਰਾਂ ਨੂੰ ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਦੇ ਨਾਲ ਛੱਡ ਦਿੱਤਾ ਗਿਆ ਸੀ।
• ਅਜਿਹੀਆਂ ਮਿੱਥਾਂ ਹਨ ਕਿ DNS ਲੋਡ ਸੰਤੁਲਨ TTL 'ਤੇ ਨਿਰਭਰ ਕਰਦਾ ਹੈ (ਇਹ ਸੱਚ ਨਹੀਂ ਹੈ - ਨੈੱਟਸਕੇਪ ਨੈਵੀਗੇਟਰ ਦੇ ਦਿਨਾਂ ਤੋਂ, ਗਾਹਕਾਂ ਨੇ RRs ਦੇ ਇੱਕ ਸਮੂਹ ਤੋਂ ਇੱਕ ਬੇਤਰਤੀਬ IP ਪਤਾ ਚੁਣਿਆ ਹੈ ਅਤੇ ਜੇਕਰ ਉਹ ਕਨੈਕਟ ਨਹੀਂ ਕਰ ਸਕਦੇ ਤਾਂ ਪਾਰਦਰਸ਼ੀ ਤੌਰ 'ਤੇ ਇੱਕ ਹੋਰ ਕੋਸ਼ਿਸ਼ ਕੀਤੀ ਹੈ)
• ਪ੍ਰਸ਼ਾਸਕ ਤਬਦੀਲੀਆਂ ਨੂੰ ਤੁਰੰਤ ਲਾਗੂ ਕਰਨਾ ਚਾਹੁੰਦੇ ਹਨ, ਇਸਲਈ ਯੋਜਨਾ ਬਣਾਉਣਾ ਆਸਾਨ ਹੈ।
• ਇੱਕ DNS ਸਰਵਰ ਜਾਂ ਲੋਡ ਬੈਲੈਂਸਰ ਦਾ ਪ੍ਰਸ਼ਾਸਕ ਆਪਣੇ ਕੰਮ ਨੂੰ ਉਪਭੋਗਤਾ ਦੁਆਰਾ ਬੇਨਤੀ ਕੀਤੀ ਗਈ ਕੌਂਫਿਗਰੇਸ਼ਨ ਨੂੰ ਕੁਸ਼ਲਤਾ ਨਾਲ ਤੈਨਾਤ ਕਰਨ ਦੇ ਰੂਪ ਵਿੱਚ ਵੇਖਦਾ ਹੈ, ਅਤੇ ਸਾਈਟਾਂ ਅਤੇ ਸੇਵਾਵਾਂ ਨੂੰ ਤੇਜ਼ ਨਹੀਂ ਕਰਦਾ।
• ਘੱਟ TTL ਤੁਹਾਨੂੰ ਮਨ ਦੀ ਸ਼ਾਂਤੀ ਦਿੰਦੇ ਹਨ।
• ਲੋਕ ਸ਼ੁਰੂ ਵਿੱਚ ਟੈਸਟਿੰਗ ਲਈ ਘੱਟ TTL ਸੈੱਟ ਕਰਦੇ ਹਨ ਅਤੇ ਫਿਰ ਉਹਨਾਂ ਨੂੰ ਬਦਲਣਾ ਭੁੱਲ ਜਾਂਦੇ ਹਨ।

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

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

CDN ਸੇਵਾਵਾਂ ਅਤੇ ਲੋਡ ਬੈਲੰਸਰ ਘੱਟ TTLs ਲਈ ਮੁੱਖ ਤੌਰ 'ਤੇ ਜ਼ਿੰਮੇਵਾਰ ਹਨ, ਖਾਸ ਤੌਰ 'ਤੇ ਜਦੋਂ ਉਹ CNAMEs ਨੂੰ ਘੱਟ TTL ਅਤੇ ਰਿਕਾਰਡਾਂ ਨੂੰ ਬਰਾਬਰ ਘੱਟ (ਪਰ ਸੁਤੰਤਰ) TTL ਦੇ ਨਾਲ ਜੋੜਦੇ ਹਨ:

$ drill raw.githubusercontent.com
raw.githubusercontent.com.	9	IN	CNAME	github.map.fastly.net.
github.map.fastly.net.	20	IN	A	151.101.128.133
github.map.fastly.net.	20	IN	A	151.101.192.133
github.map.fastly.net.	20	IN	A	151.101.0.133
github.map.fastly.net.	20	IN	A	151.101.64.133

ਜਦੋਂ ਵੀ CNAME ਜਾਂ A ਰਿਕਾਰਡਾਂ ਵਿੱਚੋਂ ਕਿਸੇ ਦੀ ਮਿਆਦ ਪੁੱਗ ਜਾਂਦੀ ਹੈ, ਇੱਕ ਨਵੀਂ ਬੇਨਤੀ ਜ਼ਰੂਰ ਭੇਜੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਦੋਵਾਂ ਕੋਲ ਇੱਕ 30 ਸਕਿੰਟ TTL ਹੈ, ਪਰ ਇਹ ਇੱਕੋ ਜਿਹਾ ਨਹੀਂ ਹੈ। ਅਸਲ ਔਸਤ TTL 15 ਸਕਿੰਟ ਹੋਵੇਗਾ।

ਪਰ ਉਡੀਕ ਕਰੋ! ਇਹ ਹੋਰ ਵੀ ਭੈੜਾ ਹੈ। ਕੁਝ ਰਿਜ਼ੋਲਵਰ ਇਸ ਸਥਿਤੀ ਵਿੱਚ ਦੋ ਸੰਬੰਧਿਤ ਘੱਟ TTL ਦੇ ਨਾਲ ਬਹੁਤ ਬੁਰਾ ਵਿਵਹਾਰ ਕਰਦੇ ਹਨ:

$ drill raw.githubusercontent.com @4.2.2.2 raw.githubusercontent.com. 1 CNAME ਵਿੱਚ github.map.fastly.net. github.map.fastly.net. 1 IN A 151.101.16.133

Level3 ਰੈਜ਼ੋਲਵਰ ਸ਼ਾਇਦ BIND 'ਤੇ ਚੱਲਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਇਹ ਬੇਨਤੀ ਭੇਜਣਾ ਜਾਰੀ ਰੱਖਦੇ ਹੋ, ਤਾਂ 1 ਦਾ TTL ਹਮੇਸ਼ਾ ਵਾਪਸ ਕੀਤਾ ਜਾਵੇਗਾ। ਜ਼ਰੂਰੀ ਤੌਰ 'ਤੇ, raw.githubusercontent.com ਕਦੇ ਵੀ ਕੈਸ਼ ਨਹੀਂ ਕੀਤਾ ਜਾਂਦਾ।

ਇੱਥੇ ਇੱਕ ਬਹੁਤ ਮਸ਼ਹੂਰ ਡੋਮੇਨ ਨਾਲ ਅਜਿਹੀ ਸਥਿਤੀ ਦੀ ਇੱਕ ਹੋਰ ਉਦਾਹਰਣ ਹੈ:

$ drill detectportal.firefox.com @1.1.1.1
detectportal.firefox.com.	25	IN	CNAME	detectportal.prod.mozaws.net.
detectportal.prod.mozaws.net.	26	IN	CNAME	detectportal.firefox.com-v2.edgesuite.net.
detectportal.firefox.com-v2.edgesuite.net.	10668	IN	CNAME	a1089.dscd.akamai.net.
a1089.dscd.akamai.net.	10	IN	A	104.123.50.106
a1089.dscd.akamai.net.	10	IN	A	104.123.50.88

ਘੱਟੋ-ਘੱਟ ਤਿੰਨ CNAME ਰਿਕਾਰਡ। ਏ. ਇੱਕ ਕੋਲ ਇੱਕ ਵਧੀਆ TTL ਹੈ, ਪਰ ਇਹ ਪੂਰੀ ਤਰ੍ਹਾਂ ਬੇਕਾਰ ਹੈ। ਹੋਰ CNAMEs ਵਿੱਚ 60 ਸਕਿੰਟਾਂ ਦਾ ਇੱਕ ਸ਼ੁਰੂਆਤੀ TTL ਹੁੰਦਾ ਹੈ, ਪਰ ਡੋਮੇਨਾਂ ਲਈ akamai.net ਅਧਿਕਤਮ TTL 20 ਸਕਿੰਟ ਹੈ ਅਤੇ ਇਹਨਾਂ ਵਿੱਚੋਂ ਕੋਈ ਵੀ ਪੜਾਅ ਵਿੱਚ ਨਹੀਂ ਹੈ।

ਉਹਨਾਂ ਡੋਮੇਨਾਂ ਬਾਰੇ ਕੀ ਜੋ ਐਪਲ ਡਿਵਾਈਸਾਂ ਨੂੰ ਲਗਾਤਾਰ ਪੋਲ ਕਰਦੇ ਹਨ?

$ drill 1-courier.push.apple.com @4.2.2.2
1-courier.push.apple.com.	1253	IN	CNAME	1.courier-push-apple.com.akadns.net.
1.courier-push-apple.com.akadns.net.	1	IN	CNAME	gb-courier-4.push-apple.com.akadns.net.
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.84
gb-courier-4.push-apple.com.akadns.net.	1	IN	A	17.57.146.85

Firefox ਅਤੇ TTL ਵਰਗੀ ਸਮੱਸਿਆ Level1 ਰੈਜ਼ੋਲਵਰ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਜ਼ਿਆਦਾਤਰ 3 ਸਕਿੰਟ 'ਤੇ ਅਟਕ ਜਾਂਦੀ ਹੈ।

ਡ੍ਰੌਪਬਾਕਸ?

$ drill client.dropbox.com @8.8.8.8 client.dropbox.com. 7 CNAME client.dropbox-dns.com ਵਿੱਚ। client.dropbox-dns.com. 59 IN A 162.125.67.3 $ drill client.dropbox.com @4.2.2.2 client.dropbox.com. 1 CNAME client.dropbox-dns.com ਵਿੱਚ। client.dropbox-dns.com. 1 IN A 162.125.64.3

ਰਿਕਾਰਡਿੰਗ 'ਤੇ safebrowsing.googleapis.com TTL ਮੁੱਲ 60 ਸਕਿੰਟ ਹੈ, ਜਿਵੇਂ ਕਿ Facebook ਡੋਮੇਨ। ਅਤੇ, ਦੁਬਾਰਾ, ਗਾਹਕ ਦੇ ਦ੍ਰਿਸ਼ਟੀਕੋਣ ਤੋਂ, ਇਹ ਮੁੱਲ ਅੱਧੇ ਹਨ.

ਘੱਟੋ-ਘੱਟ TTL ਸੈੱਟ ਕਰਨ ਬਾਰੇ ਕਿਵੇਂ?

ਨਾਮ, ਬੇਨਤੀ ਦੀ ਕਿਸਮ, TTL, ਅਤੇ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਟਾਈਮਸਟੈਂਪ ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ, ਮੈਂ ਇੱਕ ਕੈਸ਼ਿੰਗ ਰੈਜ਼ੋਲਵਰ ਵਿੱਚੋਂ ਲੰਘਣ ਵਾਲੀਆਂ 1,5 ਮਿਲੀਅਨ ਬੇਨਤੀਆਂ ਦੀ ਨਕਲ ਕਰਨ ਲਈ ਇੱਕ ਸਕ੍ਰਿਪਟ ਲਿਖੀ ਹੈ ਤਾਂ ਜੋ ਇੱਕ ਮਿਆਦ ਪੁੱਗ ਚੁੱਕੀ ਕੈਸ਼ ਐਂਟਰੀ ਦੇ ਕਾਰਨ ਭੇਜੀਆਂ ਗਈਆਂ ਬੇਲੋੜੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਮਾਤਰਾ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਇਆ ਜਾ ਸਕੇ।

ਮੌਜੂਦਾ ਰਿਕਾਰਡ ਦੀ ਮਿਆਦ ਪੁੱਗਣ ਤੋਂ ਬਾਅਦ 47,4% ਬੇਨਤੀਆਂ ਕੀਤੀਆਂ ਗਈਆਂ ਸਨ। ਇਹ ਗੈਰ-ਵਾਜਬ ਤੌਰ 'ਤੇ ਉੱਚਾ ਹੈ।

ਜੇਕਰ ਘੱਟੋ-ਘੱਟ TTL ਸੈੱਟ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਤਾਂ ਕੈਸ਼ਿੰਗ 'ਤੇ ਕੀ ਪ੍ਰਭਾਵ ਪਵੇਗਾ?

X ਧੁਰਾ ਨਿਊਨਤਮ TTL ਮੁੱਲ ਹੈ। ਇਸ ਮੁੱਲ ਤੋਂ ਉੱਪਰ ਸਰੋਤ TTL ਵਾਲੇ ਰਿਕਾਰਡ ਪ੍ਰਭਾਵਿਤ ਨਹੀਂ ਹੁੰਦੇ ਹਨ।

Y ਧੁਰਾ ਇੱਕ ਕਲਾਇੰਟ ਦੀਆਂ ਬੇਨਤੀਆਂ ਦਾ ਪ੍ਰਤੀਸ਼ਤ ਹੈ ਜਿਸਦੀ ਪਹਿਲਾਂ ਹੀ ਇੱਕ ਕੈਸ਼ ਐਂਟਰੀ ਹੈ, ਪਰ ਇਹ ਮਿਆਦ ਪੁੱਗ ਗਈ ਹੈ ਅਤੇ ਇੱਕ ਨਵੀਂ ਬੇਨਤੀ ਕਰ ਰਹੀ ਹੈ।

"ਵਾਧੂ" ਬੇਨਤੀਆਂ ਦਾ ਹਿੱਸਾ 47% ਤੋਂ ਘਟਾ ਕੇ 36% ਤੱਕ ਘੱਟ ਤੋਂ ਘੱਟ TTL ਨੂੰ 5 ਮਿੰਟ ਤੱਕ ਸੈਟ ਕਰ ਦਿੱਤਾ ਜਾਂਦਾ ਹੈ। ਘੱਟੋ-ਘੱਟ TTL ਨੂੰ 15 ਮਿੰਟਾਂ 'ਤੇ ਸੈੱਟ ਕਰਨ ਨਾਲ, ਇਹਨਾਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ 29% ਤੱਕ ਘੱਟ ਜਾਂਦੀ ਹੈ। 1 ਘੰਟੇ ਦਾ ਘੱਟੋ-ਘੱਟ TTL ਉਹਨਾਂ ਨੂੰ 17% ਤੱਕ ਘਟਾ ਦਿੰਦਾ ਹੈ। ਮਹੱਤਵਪੂਰਨ ਅੰਤਰ!

ਸਰਵਰ ਸਾਈਡ 'ਤੇ ਕੁਝ ਵੀ ਨਾ ਬਦਲਣ ਬਾਰੇ, ਪਰ ਇਸ ਦੀ ਬਜਾਏ ਕਲਾਇੰਟ DNS ਕੈਚਾਂ (ਰਾਊਟਰਾਂ, ਸਥਾਨਕ ਰੈਜ਼ੋਲਵਰ) ਵਿੱਚ ਘੱਟੋ-ਘੱਟ TTL ਸੈੱਟ ਕਰਨ ਬਾਰੇ ਕਿਵੇਂ?

ਘੱਟੋ-ਘੱਟ 47 ਮਿੰਟ ਦੇ TTL ਨਾਲ ਲੋੜੀਂਦੀਆਂ ਬੇਨਤੀਆਂ ਦੀ ਗਿਣਤੀ 34% ਤੋਂ ਘਟ ਕੇ 5%, ਘੱਟੋ-ਘੱਟ 25 ਮਿੰਟਾਂ ਦੇ ਨਾਲ 15%, ਅਤੇ ਘੱਟੋ-ਘੱਟ 13 ਘੰਟੇ ਦੇ ਨਾਲ 1% ਹੋ ਜਾਂਦੀ ਹੈ। ਸ਼ਾਇਦ 40 ਮਿੰਟ ਅਨੁਕੂਲ ਹਨ.

ਇਸ ਛੋਟੀ ਜਿਹੀ ਤਬਦੀਲੀ ਦਾ ਪ੍ਰਭਾਵ ਬਹੁਤ ਜ਼ਿਆਦਾ ਹੈ।

ਇਸ ਦੇ ਨਤੀਜੇ ਕੀ ਹਨ?

ਬੇਸ਼ੱਕ, ਸੇਵਾ ਨੂੰ ਇੱਕ ਨਵੇਂ ਕਲਾਉਡ ਪ੍ਰਦਾਤਾ, ਨਵੇਂ ਸਰਵਰ, ਨਵੇਂ ਨੈਟਵਰਕ ਵਿੱਚ ਭੇਜਿਆ ਜਾ ਸਕਦਾ ਹੈ, ਜਿਸ ਲਈ ਗਾਹਕਾਂ ਨੂੰ ਨਵੀਨਤਮ DNS ਰਿਕਾਰਡਾਂ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਅਤੇ ਇੱਕ ਕਾਫ਼ੀ ਛੋਟਾ TTL ਅਜਿਹੇ ਪਰਿਵਰਤਨ ਨੂੰ ਸੁਚਾਰੂ ਅਤੇ ਅਪ੍ਰਤੱਖ ਰੂਪ ਵਿੱਚ ਕਰਨ ਵਿੱਚ ਮਦਦ ਕਰਦਾ ਹੈ। ਪਰ ਨਵੇਂ ਬੁਨਿਆਦੀ ਢਾਂਚੇ ਵਿੱਚ ਤਬਦੀਲੀ ਦੇ ਨਾਲ, ਕੋਈ ਵੀ ਗਾਹਕਾਂ ਨੂੰ 1 ਮਿੰਟ, 5 ਮਿੰਟ ਜਾਂ 15 ਮਿੰਟ ਦੇ ਅੰਦਰ ਨਵੇਂ DNS ਰਿਕਾਰਡਾਂ ਵਿੱਚ ਮਾਈਗਰੇਟ ਕਰਨ ਦੀ ਉਮੀਦ ਨਹੀਂ ਕਰਦਾ ਹੈ। ਘੱਟੋ-ਘੱਟ TTL ਨੂੰ 40 ਮਿੰਟ ਦੀ ਬਜਾਏ 5 ਮਿੰਟ ਕਰਨ ਨਾਲ ਉਪਭੋਗਤਾਵਾਂ ਨੂੰ ਸੇਵਾ ਤੱਕ ਪਹੁੰਚ ਕਰਨ ਤੋਂ ਰੋਕਿਆ ਨਹੀਂ ਜਾਵੇਗਾ।

ਹਾਲਾਂਕਿ, ਇਹ ਲੇਟੈਂਸੀ ਨੂੰ ਮਹੱਤਵਪੂਰਣ ਰੂਪ ਵਿੱਚ ਘਟਾਏਗਾ ਅਤੇ ਬੇਲੋੜੀਆਂ ਬੇਨਤੀਆਂ ਤੋਂ ਬਚ ਕੇ ਗੋਪਨੀਯਤਾ ਅਤੇ ਭਰੋਸੇਯੋਗਤਾ ਵਿੱਚ ਸੁਧਾਰ ਕਰੇਗਾ।

ਬੇਸ਼ੱਕ, RFCs ਦਾ ਕਹਿਣਾ ਹੈ ਕਿ TTL ਦੀ ਸਖਤੀ ਨਾਲ ਪਾਲਣਾ ਕੀਤੀ ਜਾਣੀ ਚਾਹੀਦੀ ਹੈ। ਪਰ ਅਸਲੀਅਤ ਇਹ ਹੈ ਕਿ DNS ਸਿਸਟਮ ਬਹੁਤ ਅਕੁਸ਼ਲ ਹੋ ਗਿਆ ਹੈ.

ਜੇਕਰ ਤੁਸੀਂ ਅਧਿਕਾਰਤ DNS ਸਰਵਰਾਂ ਨਾਲ ਕੰਮ ਕਰ ਰਹੇ ਹੋ, ਤਾਂ ਕਿਰਪਾ ਕਰਕੇ ਆਪਣੇ TTLs ਦੀ ਜਾਂਚ ਕਰੋ। ਕੀ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਅਜਿਹੇ ਹਾਸੋਹੀਣੇ ਘੱਟ ਮੁੱਲਾਂ ਦੀ ਲੋੜ ਹੈ?

ਬੇਸ਼ੱਕ, DNS ਰਿਕਾਰਡਾਂ ਲਈ ਛੋਟੇ TTL ਸੈੱਟ ਕਰਨ ਦੇ ਚੰਗੇ ਕਾਰਨ ਹਨ। ਪਰ DNS ਟ੍ਰੈਫਿਕ ਦੇ 75% ਲਈ ਨਹੀਂ ਜੋ ਅਸਲ ਵਿੱਚ ਬਦਲਿਆ ਨਹੀਂ ਰਹਿੰਦਾ ਹੈ।

ਅਤੇ ਜੇਕਰ ਕਿਸੇ ਕਾਰਨ ਕਰਕੇ ਤੁਹਾਨੂੰ ਅਸਲ ਵਿੱਚ DNS ਲਈ ਘੱਟ TTLs ਦੀ ਵਰਤੋਂ ਕਰਨ ਦੀ ਲੋੜ ਹੈ, ਉਸੇ ਸਮੇਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਤੁਹਾਡੀ ਸਾਈਟ ਵਿੱਚ ਕੈਚਿੰਗ ਸਮਰਥਿਤ ਨਹੀਂ ਹੈ। ਇਸੇ ਕਾਰਨਾਂ ਕਰਕੇ.

ਜੇਕਰ ਤੁਹਾਡੇ ਕੋਲ ਇੱਕ ਸਥਾਨਕ DNS ਕੈਸ਼ ਚੱਲ ਰਿਹਾ ਹੈ, ਜਿਵੇਂ ਕਿ dnscrypt-ਪ੍ਰੌਕਸੀਜੋ ਤੁਹਾਨੂੰ ਘੱਟੋ-ਘੱਟ TTL ਸੈੱਟ ਕਰਨ ਦੀ ਇਜਾਜ਼ਤ ਦਿੰਦਾ ਹੈ, ਇਸ ਫੰਕਸ਼ਨ ਦੀ ਵਰਤੋਂ ਕਰੋ। ਇਹ ਠੀਕ ਹੈ। ਕੁਝ ਵੀ ਮਾੜਾ ਨਹੀਂ ਹੋਵੇਗਾ। ਘੱਟੋ-ਘੱਟ TTL ਨੂੰ ਲਗਭਗ 40 ਮਿੰਟ (2400 ਸਕਿੰਟ) ਅਤੇ 1 ਘੰਟੇ 'ਤੇ ਸੈੱਟ ਕਰੋ। ਕਾਫ਼ੀ ਵਾਜਬ ਸੀਮਾ ਹੈ।

ਸਰੋਤ: www.habr.com