ವೇಗದ ಇಂಟರ್ನೆಟ್ ಬ್ರೌಸಿಂಗ್‌ಗೆ ಕಡಿಮೆ DNS ಲೇಟೆನ್ಸಿ ಪ್ರಮುಖವಾಗಿದೆ. ಅದನ್ನು ಕಡಿಮೆ ಮಾಡಲು, ಡಿಎನ್ಎಸ್ ಸರ್ವರ್ಗಳನ್ನು ಎಚ್ಚರಿಕೆಯಿಂದ ಆಯ್ಕೆ ಮಾಡುವುದು ಮುಖ್ಯ ಮತ್ತು . ಆದರೆ ಮೊದಲ ಹಂತವೆಂದರೆ ಅನುಪಯುಕ್ತ ಪ್ರಶ್ನೆಗಳನ್ನು ತೊಡೆದುಹಾಕುವುದು.
ಇದಕ್ಕಾಗಿಯೇ DNS ಅನ್ನು ಮೂಲತಃ ಹೆಚ್ಚು ಕ್ಯಾಶೆಬಲ್ ಪ್ರೋಟೋಕಾಲ್ ಆಗಿ ವಿನ್ಯಾಸಗೊಳಿಸಲಾಗಿದೆ. ವಲಯ ನಿರ್ವಾಹಕರು ವೈಯಕ್ತಿಕ ನಮೂದುಗಳಿಗಾಗಿ ಲೈವ್ (TTL) ಸಮಯವನ್ನು ಹೊಂದಿಸುತ್ತಾರೆ ಮತ್ತು ಅನಗತ್ಯ ದಟ್ಟಣೆಯನ್ನು ತಪ್ಪಿಸಲು ನಮೂದುಗಳನ್ನು ಮೆಮೊರಿಯಲ್ಲಿ ಸಂಗ್ರಹಿಸುವಾಗ ಪರಿಹರಿಸುವವರು ಈ ಮಾಹಿತಿಯನ್ನು ಬಳಸುತ್ತಾರೆ.
ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವುದು ಪರಿಣಾಮಕಾರಿಯೇ? ಒಂದೆರಡು ವರ್ಷಗಳ ಹಿಂದೆ, ನನ್ನ ಚಿಕ್ಕ ಸಂಶೋಧನೆಯು ಅದು ಪರಿಪೂರ್ಣವಲ್ಲ ಎಂದು ತೋರಿಸಿದೆ. ಸದ್ಯದ ಪರಿಸ್ಥಿತಿಯನ್ನು ನೋಡೋಣ.
ಮಾಹಿತಿಯನ್ನು ಸಂಗ್ರಹಿಸಲು ನಾನು ಪ್ಯಾಚ್ ಮಾಡಿದೆ ಪ್ರತಿಕ್ರಿಯೆಗಾಗಿ TTL ಮೌಲ್ಯವನ್ನು ಉಳಿಸಲು. ಪ್ರತಿ ಒಳಬರುವ ವಿನಂತಿಗೆ ಅದರ ದಾಖಲೆಗಳ ಕನಿಷ್ಠ TTL ಎಂದು ಇದನ್ನು ವ್ಯಾಖ್ಯಾನಿಸಲಾಗಿದೆ. ಇದು ನೈಜ ಸಂಚಾರದ TTL ವಿತರಣೆಯ ಉತ್ತಮ ಅವಲೋಕನವನ್ನು ನೀಡುತ್ತದೆ ಮತ್ತು ವೈಯಕ್ತಿಕ ವಿನಂತಿಗಳ ಜನಪ್ರಿಯತೆಯನ್ನು ಸಹ ಗಣನೆಗೆ ತೆಗೆದುಕೊಳ್ಳುತ್ತದೆ. ಸರ್ವರ್‌ನ ಪ್ಯಾಚ್ ಮಾಡಿದ ಆವೃತ್ತಿಯು ಹಲವಾರು ಗಂಟೆಗಳ ಕಾಲ ಕೆಲಸ ಮಾಡಿದೆ.
ಪರಿಣಾಮವಾಗಿ ಡೇಟಾ ಸೆಟ್ 1 ದಾಖಲೆಗಳನ್ನು ಒಳಗೊಂಡಿದೆ (ಹೆಸರು, ಕ್ಯೂಟೈಪ್, ಟಿಟಿಎಲ್, ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್). ಒಟ್ಟಾರೆ TTL ವಿತರಣೆ ಇಲ್ಲಿದೆ (ಎಕ್ಸ್-ಅಕ್ಷವು ಸೆಕೆಂಡುಗಳಲ್ಲಿ TTL ಆಗಿದೆ):
86 (ಹೆಚ್ಚಾಗಿ SOA ರೆಕಾರ್ಡ್‌ಗಳಿಗೆ) ಒಂದು ಚಿಕ್ಕ ಬಂಪ್ ಅನ್ನು ಹೊರತುಪಡಿಸಿ, TTL ಗಳು ಕಡಿಮೆ ಶ್ರೇಣಿಯಲ್ಲಿವೆ ಎಂಬುದು ಬಹಳ ಸ್ಪಷ್ಟವಾಗಿದೆ. ಹತ್ತಿರದಿಂದ ನೋಡೋಣ:
ಸರಿ, 1 ಗಂಟೆಗಿಂತ ಹೆಚ್ಚಿನ TTL ಗಳು ಸಂಖ್ಯಾಶಾಸ್ತ್ರೀಯವಾಗಿ ಮಹತ್ವದ್ದಾಗಿಲ್ಲ. ನಂತರ 0−3600 ಶ್ರೇಣಿಯ ಮೇಲೆ ಕೇಂದ್ರೀಕರಿಸೋಣ:
ಹೆಚ್ಚಿನ TTL ಗಳು 0 ರಿಂದ 15 ನಿಮಿಷಗಳವರೆಗೆ:
ಬಹುಪಾಲು 0 ರಿಂದ 5 ನಿಮಿಷಗಳವರೆಗೆ:
ಇದು ತುಂಬಾ ಒಳ್ಳೆಯದಲ್ಲ.
ಸಂಚಿತ ವಿತರಣೆಯು ಸಮಸ್ಯೆಯನ್ನು ಇನ್ನಷ್ಟು ಸ್ಪಷ್ಟಗೊಳಿಸುತ್ತದೆ:
ಅರ್ಧದಷ್ಟು DNS ಪ್ರತಿಕ್ರಿಯೆಗಳು 1 ನಿಮಿಷ ಅಥವಾ ಅದಕ್ಕಿಂತ ಕಡಿಮೆ TTL ಅನ್ನು ಹೊಂದಿವೆ, ಮತ್ತು ಮುಕ್ಕಾಲು ಭಾಗವು 5 ನಿಮಿಷಗಳ ಅಥವಾ ಅದಕ್ಕಿಂತ ಕಡಿಮೆ TTL ಅನ್ನು ಹೊಂದಿರುತ್ತದೆ.
ಆದರೆ ನಿರೀಕ್ಷಿಸಿ, ಇದು ನಿಜವಾಗಿಯೂ ಕೆಟ್ಟದಾಗಿದೆ. ಎಲ್ಲಾ ನಂತರ, ಇದು ಅಧಿಕೃತ ಸರ್ವರ್‌ಗಳಿಂದ TTL ಆಗಿದೆ. ಆದಾಗ್ಯೂ, ಕ್ಲೈಂಟ್ ಪರಿಹಾರಕಗಳು (ಉದಾ. ರೂಟರ್‌ಗಳು, ಸ್ಥಳೀಯ ಕ್ಯಾಶ್‌ಗಳು) ಅಪ್‌ಸ್ಟ್ರೀಮ್ ಪರಿಹಾರಕಗಳಿಂದ TTL ಅನ್ನು ಸ್ವೀಕರಿಸುತ್ತವೆ ಮತ್ತು ಇದು ಪ್ರತಿ ಸೆಕೆಂಡಿಗೆ ಕಡಿಮೆಯಾಗುತ್ತದೆ.
ಆದ್ದರಿಂದ ಕ್ಲೈಂಟ್ ಹೊಸ ವಿನಂತಿಯನ್ನು ಕಳುಹಿಸುವ ಮೊದಲು ಪ್ರತಿ ನಮೂದನ್ನು ಸರಾಸರಿ ಅರ್ಧದಷ್ಟು ಮೂಲ TTL ಗೆ ಬಳಸಬಹುದು.
ಬಹುಶಃ ಈ ಕಡಿಮೆ ಟಿಟಿಎಲ್‌ಗಳು ಅಸಾಮಾನ್ಯ ವಿನಂತಿಗಳಿಗೆ ಮಾತ್ರ ಅನ್ವಯಿಸುತ್ತವೆಯೇ ಹೊರತು ಜನಪ್ರಿಯ ವೆಬ್‌ಸೈಟ್‌ಗಳು ಮತ್ತು API ಗಳಲ್ಲವೇ? ನೋಡೋಣ:
X ಅಕ್ಷವು TTL ಮತ್ತು Y ಅಕ್ಷವು ಪ್ರಶ್ನೆ ಜನಪ್ರಿಯತೆಯಾಗಿದೆ.
ದುರದೃಷ್ಟವಶಾತ್, ಅತ್ಯಂತ ಜನಪ್ರಿಯ ಪ್ರಶ್ನೆಗಳು ಸಂಗ್ರಹಕ್ಕೆ ಕೆಟ್ಟದ್ದಾಗಿವೆ.
ಝೂಮ್ ಇನ್ ಮಾಡೋಣ:
ತೀರ್ಪು: ಇದು ನಿಜವಾಗಿಯೂ ಕೆಟ್ಟದು. ಇದು ಈಗಾಗಲೇ ಕೆಟ್ಟದಾಗಿತ್ತು, ಆದರೆ ಅದು ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ. DNS ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯು ವಾಸ್ತವಿಕವಾಗಿ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ. ಕಡಿಮೆ ಜನರು ತಮ್ಮ ISP ಯ DNS ಪರಿಹಾರಕವನ್ನು ಬಳಸುವುದರಿಂದ (ಉತ್ತಮ ಕಾರಣಗಳಿಗಾಗಿ), ಸುಪ್ತತೆಯ ಹೆಚ್ಚಳವು ಹೆಚ್ಚು ಗಮನಾರ್ಹವಾಗುತ್ತದೆ.
ಯಾರೂ ಭೇಟಿ ನೀಡದ ವಿಷಯಕ್ಕೆ ಮಾತ್ರ DNS ಕ್ಯಾಶಿಂಗ್ ಉಪಯುಕ್ತವಾಗಿದೆ.
ಸಾಫ್ಟ್‌ವೇರ್ ಇರಬಹುದು ಎಂಬುದನ್ನು ದಯವಿಟ್ಟು ಗಮನಿಸಿ ಕಡಿಮೆ TTL ಗಳನ್ನು ಅರ್ಥೈಸಿಕೊಳ್ಳಿ.
ಅದು ಯಾಕೆ?
DNS ದಾಖಲೆಗಳನ್ನು ಏಕೆ ಕಡಿಮೆ TTL ಗೆ ಹೊಂದಿಸಲಾಗಿದೆ?
- ಲೆಗಸಿ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳನ್ನು ಡೀಫಾಲ್ಟ್ ಸೆಟ್ಟಿಂಗ್‌ಗಳೊಂದಿಗೆ ಬಿಡಲಾಗಿದೆ.
- DNS ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸಿಂಗ್ TTL ಮೇಲೆ ಅವಲಂಬಿತವಾಗಿದೆ ಎಂಬ ಪುರಾಣಗಳಿವೆ (ಇದು ನಿಜವಲ್ಲ - ನೆಟ್‌ಸ್ಕೇಪ್ ನ್ಯಾವಿಗೇಟರ್‌ನ ದಿನಗಳಿಂದಲೂ, ಕ್ಲೈಂಟ್‌ಗಳು RR ಗಳ ಗುಂಪಿನಿಂದ ಯಾದೃಚ್ಛಿಕ IP ವಿಳಾಸವನ್ನು ಆರಿಸಿಕೊಂಡಿದ್ದಾರೆ ಮತ್ತು ಅವರು ಸಂಪರ್ಕಿಸಲು ಸಾಧ್ಯವಾಗದಿದ್ದರೆ ಪಾರದರ್ಶಕವಾಗಿ ಇನ್ನೊಂದನ್ನು ಪ್ರಯತ್ನಿಸಿದ್ದಾರೆ)
- ನಿರ್ವಾಹಕರು ತಕ್ಷಣವೇ ಬದಲಾವಣೆಗಳನ್ನು ಅನ್ವಯಿಸಲು ಬಯಸುತ್ತಾರೆ, ಆದ್ದರಿಂದ ಯೋಜಿಸಲು ಸುಲಭವಾಗಿದೆ.
- DNS ಸರ್ವರ್ ಅಥವಾ ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ನ ನಿರ್ವಾಹಕರು ತಮ್ಮ ಕಾರ್ಯವನ್ನು ಬಳಕೆದಾರರು ವಿನಂತಿಸುವ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಪರಿಣಾಮಕಾರಿಯಾಗಿ ನಿಯೋಜಿಸುವುದನ್ನು ನೋಡುತ್ತಾರೆ ಮತ್ತು ಸೈಟ್‌ಗಳು ಮತ್ತು ಸೇವೆಗಳನ್ನು ವೇಗಗೊಳಿಸುವುದಿಲ್ಲ.
- ಕಡಿಮೆ ಟಿಟಿಎಲ್‌ಗಳು ನಿಮಗೆ ಮನಸ್ಸಿನ ಶಾಂತಿಯನ್ನು ನೀಡುತ್ತವೆ.
- ಜನರು ಆರಂಭದಲ್ಲಿ ಕಡಿಮೆ ಟಿಟಿಎಲ್‌ಗಳನ್ನು ಪರೀಕ್ಷೆಗಾಗಿ ಹೊಂದಿಸುತ್ತಾರೆ ಮತ್ತು ನಂತರ ಅವುಗಳನ್ನು ಬದಲಾಯಿಸಲು ಮರೆತುಬಿಡುತ್ತಾರೆ.
"ಫೇಲ್ಓವರ್" ಅನ್ನು ನಾನು ಪಟ್ಟಿಯಲ್ಲಿ ಸೇರಿಸಲಿಲ್ಲ ಏಕೆಂದರೆ ಅದು ಕಡಿಮೆ ಮತ್ತು ಕಡಿಮೆ ಪ್ರಸ್ತುತವಾಗುತ್ತಿದೆ. ಬೇರೆಲ್ಲವೂ ಮುರಿದುಹೋದಾಗ ದೋಷ ಪುಟವನ್ನು ಪ್ರದರ್ಶಿಸಲು ನೀವು ಬಳಕೆದಾರರನ್ನು ಮತ್ತೊಂದು ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಮರುನಿರ್ದೇಶಿಸಬೇಕಾದರೆ, 1 ನಿಮಿಷಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ವಿಳಂಬವು ಬಹುಶಃ ಸ್ವೀಕಾರಾರ್ಹವಾಗಿರುತ್ತದೆ.
ಹೆಚ್ಚುವರಿಯಾಗಿ, ಒಂದು-ನಿಮಿಷದ TTL ಎಂದರೆ ಅಧಿಕೃತ DNS ಸರ್ವರ್ಗಳನ್ನು 1 ನಿಮಿಷಕ್ಕಿಂತ ಹೆಚ್ಚು ಕಾಲ ನಿರ್ಬಂಧಿಸಿದರೆ, ಬೇರೆ ಯಾರೂ ಅವಲಂಬಿತ ಸೇವೆಗಳನ್ನು ಪ್ರವೇಶಿಸಲು ಸಾಧ್ಯವಾಗುವುದಿಲ್ಲ. ಮತ್ತು ಕಾರಣವು ಕಾನ್ಫಿಗರೇಶನ್ ದೋಷ ಅಥವಾ ಹ್ಯಾಕ್ ಆಗಿದ್ದರೆ ಪುನರುಕ್ತಿ ಸಹಾಯ ಮಾಡುವುದಿಲ್ಲ. ಮತ್ತೊಂದೆಡೆ, ಸಮಂಜಸವಾದ ಟಿಟಿಎಲ್‌ಗಳೊಂದಿಗೆ, ಅನೇಕ ಕ್ಲೈಂಟ್‌ಗಳು ಹಿಂದಿನ ಕಾನ್ಫಿಗರೇಶನ್ ಅನ್ನು ಬಳಸುವುದನ್ನು ಮುಂದುವರಿಸುತ್ತಾರೆ ಮತ್ತು ಏನನ್ನೂ ಗಮನಿಸುವುದಿಲ್ಲ.
CDN ಸೇವೆಗಳು ಮತ್ತು ಲೋಡ್ ಬ್ಯಾಲೆನ್ಸರ್‌ಗಳು ಕಡಿಮೆ TTL ಗಳಿಗೆ ಹೆಚ್ಚಾಗಿ ದೂಷಿಸುತ್ತವೆ, ವಿಶೇಷವಾಗಿ ಅವರು CNAME ಗಳನ್ನು ಕಡಿಮೆ 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 ಸೆಕೆಂಡುಗಳಾಗಿರುತ್ತದೆ.
ಆದರೆ ನಿಲ್ಲು! ಇದು ಇನ್ನೂ ಕೆಟ್ಟದಾಗಿದೆ. ಕೆಲವು ಪರಿಹಾರಕಾರರು ಈ ಪರಿಸ್ಥಿತಿಯಲ್ಲಿ ಎರಡು ಸಂಬಂಧಿತ ಕಡಿಮೆ ಟಿಟಿಎಲ್‌ಗಳೊಂದಿಗೆ ತುಂಬಾ ಕೆಟ್ಟದಾಗಿ ವರ್ತಿಸುತ್ತಾರೆ:
$ ಡ್ರಿಲ್ 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 ಅನ್ನು ಹೊಂದಿದ್ದಾರೆ, ಆದರೆ ಇದು ಸಂಪೂರ್ಣವಾಗಿ ನಿಷ್ಪ್ರಯೋಜಕವಾಗಿದೆ. ಇತರ CNAME ಗಳು 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
Level1 ಪರಿಹಾರಕವನ್ನು ಬಳಸುವಾಗ Firefox ಮತ್ತು TTL ನಂತಹ ಅದೇ ಸಮಸ್ಯೆಯು 3 ಸೆಕೆಂಡ್‌ನಲ್ಲಿ ಅಂಟಿಕೊಂಡಿರುತ್ತದೆ.
ಡ್ರಾಪ್ಬಾಕ್ಸ್?
$ ಡ್ರಿಲ್ client.dropbox.com @8.8.8.8 client.dropbox.com. 7 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 59 ರಲ್ಲಿ ಎ 162.125.67.3 $ ಡ್ರಿಲ್ client.dropbox.com @4.2.2.2 client.dropbox.com. 1 IN CNAME client.dropbox-dns.com. client.dropbox-dns.com. 1 ರಲ್ಲಿ ಎ 162.125.64.3
ರೆಕಾರ್ಡಿಂಗ್ ನಲ್ಲಿ safebrowsing.googleapis.com TTL ಮೌಲ್ಯವು Facebook ಡೊಮೇನ್‌ಗಳಂತೆ 60 ಸೆಕೆಂಡುಗಳು. ಮತ್ತು, ಮತ್ತೊಮ್ಮೆ, ಕ್ಲೈಂಟ್ನ ದೃಷ್ಟಿಕೋನದಿಂದ, ಈ ಮೌಲ್ಯಗಳನ್ನು ಅರ್ಧಮಟ್ಟಕ್ಕಿಳಿಸಲಾಯಿತು.
ಕನಿಷ್ಠ TTL ಅನ್ನು ಹೊಂದಿಸುವುದು ಹೇಗೆ?
ಹೆಸರು, ವಿನಂತಿಯ ಪ್ರಕಾರ, TTL, ಮತ್ತು ಆರಂಭದಲ್ಲಿ ಸಂಗ್ರಹಿಸಲಾದ ಟೈಮ್‌ಸ್ಟ್ಯಾಂಪ್ ಅನ್ನು ಬಳಸಿಕೊಂಡು, ಅವಧಿ ಮೀರಿದ ಸಂಗ್ರಹ ಪ್ರವೇಶದಿಂದಾಗಿ ಕಳುಹಿಸಲಾದ ಅನಗತ್ಯ ವಿನಂತಿಗಳ ಪರಿಮಾಣವನ್ನು ಅಂದಾಜು ಮಾಡಲು ಕ್ಯಾಶಿಂಗ್ ರೆಸಲ್ವರ್ ಮೂಲಕ ಹಾದುಹೋಗುವ 1,5 ಮಿಲಿಯನ್ ವಿನಂತಿಗಳನ್ನು ಅನುಕರಿಸಲು ನಾನು ಸ್ಕ್ರಿಪ್ಟ್ ಅನ್ನು ಬರೆದಿದ್ದೇನೆ.
ಅಸ್ತಿತ್ವದಲ್ಲಿರುವ ದಾಖಲೆಯ ಅವಧಿ ಮುಗಿದ ನಂತರ 47,4% ವಿನಂತಿಗಳನ್ನು ಮಾಡಲಾಗಿದೆ. ಇದು ಅಸಮಂಜಸವಾಗಿ ಹೆಚ್ಚಾಗಿದೆ.
ಕನಿಷ್ಠ TTL ಅನ್ನು ಹೊಂದಿಸಿದರೆ ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವಿಕೆಯ ಮೇಲೆ ಏನು ಪರಿಣಾಮ ಬೀರುತ್ತದೆ?
X ಅಕ್ಷವು ಕನಿಷ್ಠ TTL ಮೌಲ್ಯವಾಗಿದೆ. ಈ ಮೌಲ್ಯಕ್ಕಿಂತ ಹೆಚ್ಚಿನ ಮೂಲ TTL ಗಳೊಂದಿಗಿನ ದಾಖಲೆಗಳು ಪರಿಣಾಮ ಬೀರುವುದಿಲ್ಲ.
Y ಅಕ್ಷವು ಈಗಾಗಲೇ ಕ್ಯಾಶ್ ಮಾಡಿದ ನಮೂದನ್ನು ಹೊಂದಿರುವ ಕ್ಲೈಂಟ್‌ನಿಂದ ವಿನಂತಿಗಳ ಶೇಕಡಾವಾರು ಆಗಿದೆ, ಆದರೆ ಅದು ಅವಧಿ ಮೀರಿದೆ ಮತ್ತು ಹೊಸ ವಿನಂತಿಯನ್ನು ಮಾಡುತ್ತಿದೆ.
ಕನಿಷ್ಠ TTL ಅನ್ನು 47 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸುವ ಮೂಲಕ "ಹೆಚ್ಚುವರಿ" ವಿನಂತಿಗಳ ಪಾಲನ್ನು 36% ರಿಂದ 5% ಕ್ಕೆ ಕಡಿಮೆ ಮಾಡಲಾಗಿದೆ. ಕನಿಷ್ಠ TTL ಅನ್ನು 15 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸುವ ಮೂಲಕ, ಈ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯು 29% ಕ್ಕೆ ಇಳಿಯುತ್ತದೆ. ಕನಿಷ್ಠ 1 ಗಂಟೆಯ TTL ಅವುಗಳನ್ನು 17% ಗೆ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ. ಗಮನಾರ್ಹ ವ್ಯತ್ಯಾಸ!
ಸರ್ವರ್ ಬದಿಯಲ್ಲಿ ಏನನ್ನೂ ಬದಲಾಯಿಸದಿರುವುದು ಹೇಗೆ, ಬದಲಿಗೆ ಕ್ಲೈಂಟ್ DNS ಕ್ಯಾಶ್‌ಗಳಲ್ಲಿ (ರೂಟರ್‌ಗಳು, ಸ್ಥಳೀಯ ಪರಿಹಾರಕಗಳು) ಕನಿಷ್ಠ TTL ಅನ್ನು ಹೊಂದಿಸುವುದು ಹೇಗೆ?
ಅಗತ್ಯವಿರುವ ವಿನಂತಿಗಳ ಸಂಖ್ಯೆಯು ಕನಿಷ್ಠ 47 ನಿಮಿಷಗಳ ಟಿಟಿಎಲ್‌ನೊಂದಿಗೆ 34% ರಿಂದ 5% ಕ್ಕೆ, ಕನಿಷ್ಠ 25 ನಿಮಿಷಗಳಲ್ಲಿ 15% ಕ್ಕೆ ಮತ್ತು ಕನಿಷ್ಠ 13 ಗಂಟೆಯೊಂದಿಗೆ 1% ಕ್ಕೆ ಇಳಿಯುತ್ತದೆ. ಬಹುಶಃ 40 ನಿಮಿಷಗಳು ಸೂಕ್ತವಾಗಿರುತ್ತದೆ.
ಈ ಸಣ್ಣ ಬದಲಾವಣೆಯ ಪರಿಣಾಮವು ಅಗಾಧವಾಗಿದೆ.
ಪರಿಣಾಮಗಳೇನು?
ಸಹಜವಾಗಿ, ಸೇವೆಯನ್ನು ಹೊಸ ಕ್ಲೌಡ್ ಪ್ರೊವೈಡರ್, ಹೊಸ ಸರ್ವರ್, ಹೊಸ ನೆಟ್‌ವರ್ಕ್‌ಗೆ ಸರಿಸಬಹುದು, ಕ್ಲೈಂಟ್‌ಗಳು ಇತ್ತೀಚಿನ DNS ದಾಖಲೆಗಳನ್ನು ಬಳಸಬೇಕಾಗುತ್ತದೆ. ಮತ್ತು ಸಾಕಷ್ಟು ಸಣ್ಣ ಟಿಟಿಎಲ್ ಅಂತಹ ಪರಿವರ್ತನೆಯನ್ನು ಸರಾಗವಾಗಿ ಮತ್ತು ಅಗ್ರಾಹ್ಯವಾಗಿ ಮಾಡಲು ಸಹಾಯ ಮಾಡುತ್ತದೆ. ಆದರೆ ಹೊಸ ಮೂಲಸೌಕರ್ಯಕ್ಕೆ ಪರಿವರ್ತನೆಯೊಂದಿಗೆ, ಗ್ರಾಹಕರು 1 ನಿಮಿಷ, 5 ನಿಮಿಷಗಳು ಅಥವಾ 15 ನಿಮಿಷಗಳಲ್ಲಿ ಹೊಸ DNS ದಾಖಲೆಗಳಿಗೆ ವಲಸೆ ಹೋಗುತ್ತಾರೆ ಎಂದು ಯಾರೂ ನಿರೀಕ್ಷಿಸುವುದಿಲ್ಲ. ಕನಿಷ್ಠ TTL ಅನ್ನು 40 ನಿಮಿಷಗಳ ಬದಲಿಗೆ 5 ನಿಮಿಷಗಳಿಗೆ ಹೊಂದಿಸುವುದರಿಂದ ಬಳಕೆದಾರರು ಸೇವೆಯನ್ನು ಪ್ರವೇಶಿಸುವುದನ್ನು ತಡೆಯುವುದಿಲ್ಲ.
ಆದಾಗ್ಯೂ, ಇದು ಸುಪ್ತತೆಯನ್ನು ಗಮನಾರ್ಹವಾಗಿ ಕಡಿಮೆ ಮಾಡುತ್ತದೆ ಮತ್ತು ಅನಗತ್ಯ ವಿನಂತಿಗಳನ್ನು ತಪ್ಪಿಸುವ ಮೂಲಕ ಗೌಪ್ಯತೆ ಮತ್ತು ವಿಶ್ವಾಸಾರ್ಹತೆಯನ್ನು ಸುಧಾರಿಸುತ್ತದೆ.
ಸಹಜವಾಗಿ, TTL ಅನ್ನು ಕಟ್ಟುನಿಟ್ಟಾಗಿ ಅನುಸರಿಸಬೇಕು ಎಂದು RFC ಗಳು ಹೇಳುತ್ತವೆ. ಆದರೆ ವಾಸ್ತವವೆಂದರೆ DNS ವ್ಯವಸ್ಥೆಯು ತುಂಬಾ ಅಸಮರ್ಥವಾಗಿದೆ.
ನೀವು ಅಧಿಕೃತ DNS ಸರ್ವರ್‌ಗಳೊಂದಿಗೆ ಕೆಲಸ ಮಾಡುತ್ತಿದ್ದರೆ, ದಯವಿಟ್ಟು ನಿಮ್ಮ TTL ಗಳನ್ನು ಪರಿಶೀಲಿಸಿ. ನಿಮಗೆ ನಿಜವಾಗಿಯೂ ಇಂತಹ ಹಾಸ್ಯಾಸ್ಪದ ಕಡಿಮೆ ಮೌಲ್ಯಗಳು ಬೇಕೇ?
ಸಹಜವಾಗಿ, DNS ದಾಖಲೆಗಳಿಗಾಗಿ ಸಣ್ಣ TTL ಗಳನ್ನು ಹೊಂದಿಸಲು ಉತ್ತಮ ಕಾರಣಗಳಿವೆ. ಆದರೆ ವಾಸ್ತವಿಕವಾಗಿ ಬದಲಾಗದೆ ಉಳಿದಿರುವ 75% DNS ಟ್ರಾಫಿಕ್‌ಗೆ ಅಲ್ಲ.
ಮತ್ತು ಕೆಲವು ಕಾರಣಗಳಿಗಾಗಿ ನೀವು ನಿಜವಾಗಿಯೂ DNS ಗಾಗಿ ಕಡಿಮೆ TTL ಗಳನ್ನು ಬಳಸಬೇಕಾದರೆ, ಅದೇ ಸಮಯದಲ್ಲಿ ನಿಮ್ಮ ಸೈಟ್ ಕ್ಯಾಶಿಂಗ್ ಅನ್ನು ಸಕ್ರಿಯಗೊಳಿಸಿಲ್ಲ ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಿ. ಅದೇ ಕಾರಣಗಳಿಗಾಗಿ.
ನೀವು ಸ್ಥಳೀಯ DNS ಸಂಗ್ರಹವನ್ನು ಚಾಲನೆ ಮಾಡುತ್ತಿದ್ದರೆ, ಉದಾಹರಣೆಗೆ ಇದು ಕನಿಷ್ಟ TTL ಗಳನ್ನು ಹೊಂದಿಸಲು ನಿಮಗೆ ಅನುಮತಿಸುತ್ತದೆ, ಈ ಕಾರ್ಯವನ್ನು ಬಳಸಿ. ಇದು ಚೆನ್ನಾಗಿದೆ. ಕೆಟ್ಟದ್ದೇನೂ ಆಗುವುದಿಲ್ಲ. ಕನಿಷ್ಠ TTL ಅನ್ನು ಸರಿಸುಮಾರು 40 ನಿಮಿಷಗಳು (2400 ಸೆಕೆಂಡುಗಳು) ಮತ್ತು 1 ಗಂಟೆಗೆ ಹೊಂದಿಸಿ. ಸಾಕಷ್ಟು ಸಮಂಜಸವಾದ ಶ್ರೇಣಿ.
ಮೂಲ: www.habr.com