# AI coding agents द्वारा DNS changes: reviews को सुरक्षित बनाएं

AI coding agents द्वारा किए जाने वाले DNS changes को सामान्य infrastructure edits से अधिक सख्त रूप चाहिए। Agent को कभी भी «update DNS» को एक ही approval के रूप में पेश नहीं करना चाहिए। उसे creation, edit या deletion को अलग-अलग action के रूप में दिखाना चाहिए, जिनके लिए अलग evidence, अलग reviewer questions और failure handling के अलग तरीके हों।

यह अलगाव तब तक bureaucratic लग सकता है, जब तक agent किसी mail record को replace न कर दे, incompatible data के साथ CNAME न जोड़ दे, या migration के दौरान आखिरी address record न हटा दे। DNS में छोटे text changes अक्सर harmless दिखते हैं। उनका असर resolvers, clients, delegated zones, certificate checks, mail delivery और service discovery तक फैल सकता है। Blast radius का आकलन करने से पहले reviewer को exact verb दिखना चाहिए।

## DNS record verbs अलग-अलग तरह का जोखिम बताते हैं

DNS record बनाना zone में एक नया assertion जोड़ता है। Reviewer को पूछना चाहिए कि name का owner कौन है, target सही है या नहीं, नया data मौजूदा data से conflict तो नहीं करता, और domain validation या traffic capture के लिए कोई इसका गलत इस्तेमाल तो नहीं कर सकता।

किसी record को edit करने से मौजूदा assertion बदलता है। इस action में पुरानी और नई value साथ-साथ दिखनी चाहिए। एक address से दूसरे address पर बदलाव application traffic को दूसरी जगह भेज सकता है। TXT record में बदलाव sender authentication, ownership verification या किसी external service द्वारा इस्तेमाल की जाने वाली configuration बदल सकता है। पुरानी state reviewer को यह समझने देती है कि यह जानबूझकर किया गया replacement है या agent stale information पर काम कर रहा है।

किसी record को delete करना यह मानता है कि अब उसका न होना सही है। इसका failure range सबसे बड़ा होता है, क्योंकि सुरक्षित परिणाम अक्सर DNS के बाहर की किसी चीज पर निर्भर करता है। शायद नए endpoint को traffic पाने में समय चाहिए। शायद कोई दूसरी टीम अभी भी verification TXT record इस्तेमाल कर रही हो। शायद record किसी failover arrangement का हिस्सा हो, जिसे agent repository से समझ न सके।

इन operations को एक generic write मानने से approval blindness पैदा होती है। Reviewer देखता है कि हर card पर एक ही बात लिखी है, approve करता जाता है और बहुत देर से समझता है कि किसी card ने पूरा RRset हटा दिया। Control ऐसा होना चाहिए कि यह खतरनाक अंतर छिप ही न सके।

DNS terminology में भी सावधानी चाहिए। DNS owner name में एक RRset हो सकता है, यानी एक ही name और type वाले records का समूह। कई provider APIs एक single «record» object दिखाती हैं, लेकिन उनका update behavior पूरे RRset को replace कर सकता है। अगर agent दो A values में से एक हटाना चाहता है और provider पूरा set replace करता है, तो दोनों values गलती से हट सकती हैं। Action का अर्थ तय करने से पहले provider का वास्तविक object model समझें।

## हर request में एक irreversible verb अनिवार्य करें

DNS action में केवल एक verb होना चाहिए: `create`, `edit` या `delete`। Approval boundary पर `apply`, `sync` या `upsert` नाम वाले अस्पष्ट method स्वीकार न करें। ये नाम programmer के लिए सुविधाजनक और operator के लिए महंगे होते हैं।

Request में यह भी स्पष्ट होना चाहिए कि वह एक provider record object को address करती है या पूरे RRset को। अगर API किसी individual member को सुरक्षित रूप से edit नहीं कर सकती, तो action में लिखा होना चाहिए कि पूरा RRset replace किया जाएगा और रखी जाने वाली हर value की सूची दी जानी चाहिए। इस बात पर चुप्पी ही किसी मामूली address change को outage में बदलती है।

ऐसा request shape इस्तेमाल करें जो intent सुरक्षित रखे और executor को drift अस्वीकार करने के लिए पर्याप्त state दे:

```json
{
  "action": "edit",
  "zone": "example.net",
  "owner": "api.example.net.",
  "type": "A",
  "expected_rrset": {
    "ttl": 300,
    "values": ["198.51.100.24"]
  },
  "proposed_rrset": {
    "ttl": 300,
    "values": ["198.51.100.81"]
  },
  "reason": "Move the API endpoint after the service owner confirmed health checks",
  "verification": [
    "authoritative lookup returns 198.51.100.81",
    "HTTPS health check succeeds at the new endpoint"
  ]
}
```

Create action के लिए `expected_rrset` में यह बताया जाना चाहिए कि RRset मौजूद नहीं है, या provider के model में इसकी जरूरत हो तो कोई अनुमत मौजूदा state लिखी जानी चाहिए। Deletion के लिए `proposed_rrset` में स्पष्ट रूप से बताया जाना चाहिए कि वह मौजूद नहीं होगा। Absence को empty string के रूप में encode न करें और field को omit न करें। अस्पष्ट payload से अस्पष्ट logs बनते हैं।

Executor को write करने से ठीक पहले current zone state पढ़नी चाहिए। उसे उस observation की तुलना `expected_rrset` से करनी चाहिए और किसी भी mismatch पर रुक जाना चाहिए। यह compare-and-swap discipline है, भले ही DNS provider compare-and-swap endpoint न देता हो।

RFC 2136, Dynamic Updates in the Domain Name System, इस विचार को protocol में सीधे रखता है। इसका prerequisite section client को यह बताने देता है कि server द्वारा update स्वीकार करने से पहले कौन से RRsets मौजूद होने चाहिए या नहीं होने चाहिए। अधिकांश hosted DNS APIs RFC 2136 wire messages नहीं दिखातीं, लेकिन operational lesson वही रहता है: बिना verify की गई पिछली read पर आधारित write सुरक्षित नहीं है।

Agent read को retry कर सकता है। Failed write के बाद expected state को दिख रही state में बदलकर retry नहीं करना चाहिए। Mismatch का अर्थ है कि किसी दूसरे actor ने DNS बदला है, agent की plan पुरानी हो गई है, या provider ने data को planner की अपेक्षा से अलग normalize किया है। इस स्थिति को human reviewer तक पहुंचाएं।

## Creation के लिए ownership और conflict evidence जरूरी है

नया record approve करने से पहले यह प्रमाण चाहिए कि name intended service का है। Repository path, ticket reference या natural language request ownership का संकेत दे सकते हैं, लेकिन इनमें से कोई भी यह साबित नहीं करता कि नया public name इस्तेमाल के लिए उपलब्ध है।

Creation प्रस्तावित करने से पहले agent को सभी record types में exact owner name देखना चाहिए। यह CNAME records के लिए खास तौर पर जरूरी है। RFC 1034 कहता है कि किसी node पर CNAME RR मौजूद हो तो वहां कोई अन्य data नहीं होना चाहिए। केवल मौजूदा CNAME खोजने वाला planner ऐसे name पर CNAME प्रस्तावित कर सकता है, जहां address, mail या TXT data पहले से मौजूद हो। Provider write को reject कर सकता है, या इससे भी खराब स्थिति में provider-specific rule के तहत data replace कर सकता है।

Creation review में ये चार बातें plain language में दिखनी चाहिए:

- Fully qualified owner name, zone, record type, value और TTL।
- उसी owner name पर मौजूद current records, उन types समेत जिन्हें agent modify नहीं करेगा।
- Name का अनुरोध किसने किया और कौन सी service इसका इस्तेमाल करेगी।
- Record type के अनुसार उचित target check।

Target checks data पर निर्भर करते हैं। A या AAAA record के लिए agent जांच सकता है कि address expected deployment inventory का हिस्सा है या नहीं, अगर ऐसी inventory मौजूद हो। CNAME के लिए उसे target resolve करना चाहिए और यह सुनिश्चित करना चाहिए कि target name पूरा है। MX record के लिए mail owner से mail host name और priority की पुष्टि करनी चाहिए। External verifier द्वारा इस्तेमाल किए जाने वाले TXT record में ठीक वही supplied value रखनी चाहिए, whitespace को «साफ» करने या अनुमान से quoting बदलने की कोशिश नहीं करनी चाहिए।

किसी familiar domain के नीचे होने के कारण agent को यह निष्कर्ष नहीं निकालने दें कि नया subdomain harmless है। `login`, `auth`, `mta`, `vpn` और `admin` के परिणाम साफ दिखते हैं, लेकिन दूसरे नाम भी महत्वपूर्ण हो सकते हैं। Public DNS name किसी के उस पर निर्भर होते ही एक interface बन जाता है।

Creation release deployment से भी अलग है, क्योंकि rollback का अर्थ हमेशा deletion नहीं होता। अगर नया record किसी verification flow को support करता है, तो flow पूरा होने के बाद उसे delete करने से renewal या future validation टूट सकती है। Proposal में लिखा होना चाहिए कि record temporary है या नहीं, expiry का निर्णय कौन करेगा और क्या requester बाद में removal स्वीकार करता है। अगर इस जवाब का कोई owner नहीं है, तो अपनी ओर से expiration date न बनाएं।

## Edit में बताएं कि कौन सी state replace होगी

Edit तभी सुरक्षित है जब proposal exact state बताए जिसे वह replace करेगा। «App को नए host पर भेजें» intent है, executable DNS action नहीं।

हर edit request में पिछला RRset अनिवार्य करें, उन values समेत जिन्हें agent रखना चाहता है। दो addresses वाले A RRset पर विचार करें:

```text
Current:  app.example.net. 60 IN A 198.51.100.10
          app.example.net. 60 IN A 198.51.100.11
Proposed: app.example.net. 60 IN A 198.51.100.11
          app.example.net. 60 IN A 198.51.100.12
```

यह controlled rotation है। Reviewer देख सकता है कि action एक serving address को रखते हुए दूसरे को replace कर रहा है। अगर provider RRsets को unit के रूप में replace करता है, तो केवल `198.51.100.12` भेजना edit के रूप में छिपा deletion और creation होगा।

TTL changes भी उसी review card में शामिल होने चाहिए। Teams अक्सर migration से पहले TTL कम करती हैं और migration के बाद बढ़ाती हैं। दोनों changes के परिणाम होते हैं। कम TTL से resolver query frequency बढ़ती है और configuration mistakes जल्दी सामने आ सकती हैं। अधिक TTL गलत edit के बाद traffic को गलत endpoint पर ज्यादा देर रख सकता है। Generic record update के भीतर किसी भी बदलाव को छिपने न दें।

Agent को data edits और formatting differences में भी अंतर करना चाहिए। Providers owner names को canonicalize कर सकते हैं, trailing dot जोड़ सकते हैं, TXT strings को split कर सकते हैं या values का order बदल सकते हैं। Raw API text की तुलना करने वाला planner अनावश्यक approval cards या false conflicts पैदा करेगा। तुलना से पहले representation normalize करें, लेकिन reviewer के लिए जरूरी semantic data सुरक्षित रखें।

केवल इसलिए edit approve न करें कि agent को source control में matching string मिल गई है। Source control में desired state हो सकती है, जो emergency DNS change के बाद relevant न रही हो। Write की शर्त authoritative current state ही रहती है। Repositories intent समझाती हैं, DNS बताता है कि clients को वास्तव में क्या मिल सकता है।

## Deletion के लिए absence का कारण चाहिए

Deletion को यह बताना चाहिए कि record अभी क्यों गायब हो सकता है, केवल यह नहीं कि agent को वह पसंद क्यों नहीं आया। पुराने records तब तक redundant लगते हैं, जब तक कोई यह न दिखा दे कि वे legacy callback, email system, certificate validator या delegated service को support कर रहे हैं।

सुरक्षित तरीका traffic movement और cleanup को अलग रखता है। पहले replacement data add या edit करें। फिर intended authoritative answer और dependent service verify करें। Owner द्वारा नए behavior को स्वीकार करने के बाद ही agent से पुराने data की deletion request कराएं। Provider इसे edit के साथ combine कर सकता हो, तब भी removal request अलग रखें।

Deletion request में ये facts होने चाहिए:

- हटाए जाने वाले exact RRset या provider record object।
- वह service या team जिसने पुष्टि की है कि अब data पर निर्भरता नहीं है।
- Replacement action, अगर कोई है, और उसका verification result।
- Removal के बाद planned verification।
- क्या removal पूरे RRset को बदलता है, इस पर स्पष्ट statement।

Apex records पर अतिरिक्त संदेह रखें। Provider के अनुसार zone apex behavior बदलता है, खासकर तब जब provider ऐसे aliases या synthetic records देता हो जो CNAME जैसा behavior करते हैं। Agent को reviewer की स्पष्ट मंजूरी के बिना desired CNAME को provider-specific apex feature में नहीं बदलना चाहिए। DNS का परिचित शब्द अपने आप परिचित behavior की गारंटी नहीं देता।

Removal के बाद restoration को negative caching जटिल बनाती है। RFC 2308 बताता है कि resolvers negative answers, जिनमें NXDOMAIN और no data responses शामिल हैं, को कैसे cache कर सकते हैं। Record delete करके फिर restore करने पर कुछ clients को negative cache expire होने तक पहले की absence दिखाई दे सकती है। इसका अर्थ यह नहीं कि deletion मना है। इसका अर्थ है कि rollback planning में वह समय शामिल होना चाहिए जब authoritative DNS ठीक हो चुका हो, लेकिन users को अभी भी cached failure मिल रहा हो।

अगर provider individual value हटाने से मना करता है, तो delete action को चुपचाप अपना scope नहीं बढ़ाना चाहिए। Executor को बताना चाहिए कि provider को whole RRset replacement चाहिए और नया, स्पष्ट action मांगना चाहिए। यह अतिरिक्त approval उस स्थिति से सस्ता है जिसमें यह समझाना पड़े कि supposedly unused address record क्यों गायब हो गया।

## Review cards में zone diff से अधिक context दें

Raw diff reviewers को data देता है, लेकिन परिणाम अक्सर छिपा देता है। Review card की शुरुआत उस छोटे वाक्य से होनी चाहिए जो operation और expected behavior बताता हो: «`verify.example.net` के obsolete TXT verification record को delete करें; requester ने पुष्टि की है कि external verification पूरी हो चुकी है।» फिर exact records दिखाएं।

इन fields को किसी अलग view में खोले बिना दिखाई देना चाहिए: action verb, zone, owner name, type, old state, proposed state, TTL, requester, agent process identity, reason और verification plan। अगर write पूरे RRset को प्रभावित कर सकती है, तो यह बात पहली line में लिखें।

सीधी भाषा इस्तेमाल करें। «दोनों A values replace करें» की जगह «reconcile record set» न लिखें। «इस MX record को remove करें» की जगह «apply desired configuration» न लिखें। जब system abstraction की जगह operational verbs इस्तेमाल करता है, तो reviewers जल्दी निर्णय ले पाते हैं।

एक उपयोगी card reviewer को action reject करने का कारण भी देता है। CNAME creation के लिए उस owner name पर conflicting data दिखाएं। Edit के लिए बताएं कि current state expected state से अलग है या नहीं। Delete के लिए दिखाएं कि agent के पास service owner की confirmation नहीं है। Approval interface को uncertainty सामने लानी चाहिए, उसे execution log में नहीं छिपाना चाहिए।

Reviewers को manual policy engine न बनाएं और उन्हें बड़ा free text exception box न दें। अगर agent सामान्य shape से बाहर का action मांगता है, तो उससे missing evidence के साथ नया action तैयार करवाएं। जिस reviewer को chat transcript से DNS semantics फिर से समझनी पड़े, वह आखिरकार गलती approve कर देगा।

### एक worked review example

मान लें कि agent को `api.example.net` को replacement address पर ले जाना है। खराब card कहता है: «API के लिए DNS update करें।» Reviewer के पास यह पहचानने का कोई तरीका नहीं है कि provider दो members वाले RRset को replace करेगा।

Review योग्य edit कहता है: «`api.example.net` के A RRset में `198.51.100.24` को `198.51.100.81` से replace करें; `198.51.100.25` को रखें; TTL 300 ही रखें।» इसके बाद current और proposed full RRsets दिखाए जाते हैं, service owner का नाम दिया जाता है और बताया जाता है कि write के बाद agent authoritative nameserver को query करेगा तथा approved health check चलाएगा।

अगर reviewer overlap के बिना cutover चाहता है, तो उसे इस card को reject करके वह intent स्पष्ट रूप से मांगना चाहिए। Agent को यह तय नहीं करना चाहिए कि overlap जरूरी नहीं है, केवल इसलिए कि उसकी deployment files में नया address मौजूद है।

## DNS caches timing को approval का हिस्सा बना देती हैं

Authoritative DNS और recursive DNS अलग operational questions के जवाब देते हैं। Authoritative server zone का वर्तमान published data बताता है। Recursive resolver TTL समाप्त होने तक पुराना answer लौटा सकता है। Browser, operating system, application runtime, load balancer या internal resolver एक और cache जोड़ सकते हैं।

इसलिए approval में desired verification point लिखा होना चाहिए। «Authoritative servers नया answer लौटा रहे हैं» write verify करता है। «Public resolver नया answer लौटा रहा है» कुछ propagation verify करता है। «Application नए destination पर traffic serve कर रही है» वह outcome verify करता है जिसकी users को जरूरत है। ये अलग-अलग checks हैं।

ऐसे commands इस्तेमाल करें जिनसे answer का source स्पष्ट हो। Names और address को zone के वास्तविक authoritative server के अनुसार बदलें:

```sh
dig @ns1.example.net api.example.net A +noall +answer

; expected answer shape
api.example.net. 300 IN A 198.51.100.81

dig @1.1.1.1 api.example.net A +noall +answer

; resolver answer can retain an older value with a lower remaining TTL
api.example.net. 117 IN A 198.51.100.24
```

पहली query एक authoritative server पर published state जांचती है। दूसरी query यह जांचती है कि एक recursive resolver इस समय क्या लौटा रहा है। इनमें से कोई भी यह साबित नहीं करती कि हर client switch कर चुका है। दोनों results को action log में record करें, ताकि incident responder provider write की failure और expected cache behavior में अंतर कर सके।

TTL को global consistency तक पहुंचने का countdown न मानें। Resolver answer cache करते समय TTL प्राप्त करता है, इसलिए अलग-अलग resolvers अपना countdown अलग समय पर शुरू करते हैं। कुछ clients connections या application configuration को DNS से स्वतंत्र रूप से भी cache कर सकते हैं। Migration plan को service-level verification चाहिए, केवल इस वादे की जरूरत नहीं कि कुछ seconds गुजर गए हैं।

DNS delegation changes में और अधिक सावधानी चाहिए। NS records, glue records, DS records या delegation से जुड़े दूसरे data को edit करने से child zone के बाहर की resolution प्रभावित हो सकती है। Agent को इन्हें अलग class of change मानना चाहिए और ऐसे reviewer की मंजूरी लेनी चाहिए जो parent और child relationship का owner हो। इन्हें सामान्य host record workflow में न मिलाएं।

## Broad DNS credentials गलत shortcut हैं

Agent को ऐसा provider credential देना जो हर zone edit कर सके, efficient लगता है, क्योंकि agent integration change का इंतजार किए बिना task पूरा कर सकता है। यह गलत boundary है। Prompt injection, गलत repository instruction या confused plan को उस service से कहीं अधिक authority मिल जाती है जिसे बदलने का agent से अनुरोध किया गया था।

हर execution path को केवल जरूरी zones और operations तक सीमित रखें। जहां provider अनुमति दे, वहां read access को write access से अलग रखें। Repository या service identity और उन zones के बीच mapping रखें जिनके लिए वह request कर सकती है। Provider credentials तक पहुंचने से पहले उस mapping से बाहर के zone वाले request को reject करें।

Boundary को actions सीमित करने चाहिए, केवल token छिपाना पर्याप्त नहीं है। अगर agent intermediary से arbitrary provider API requests भेजवा सकता है, तो intermediary arbitrary paths, methods, headers और request bodies स्वीकार करने पर उसके पास फिर भी broad control रहेगा। Action layer को DNS operations के लिए provider call shape अपने नियंत्रण में रखनी चाहिए और schema से बाहर के fields reject करने चाहिए।

Generic «upsert» endpoints इसी जगह समस्या पैदा करते हैं। वे agent को एक request body में creation, edit और deletion मिला देने देते हैं, अक्सर ऐसे provider defaults के साथ जिन्हें reviewer देख नहीं सकता। अलग executor methods define करें और हर method से action के लिए जरूरी evidence validate करवाएं। Deletion method को replacement state वाला payload reject करना चाहिए। Edit method को missing expected state reject करनी चाहिए।

DNS credentials को agent process से बाहर रखें। Sallyport इस्तेमाल करने वाली teams के लिए app HTTP call कर सकती है, जबकि credentials उसके encrypted vault में रहते हैं और agent को credential के बजाय result मिलता है। इससे credential exposure की समस्या हल होती है, लेकिन इससे यह तय नहीं होता कि proposed DNS action उचित है या नहीं। वह काम action schema और approval evidence को करना है।

## Stale plan गलत live record delete कर सकती है

एक सामान्य failure तब शुरू होता है जब agent लंबे coding task की शुरुआत में DNS पढ़ता है। उसे `cdn.example.net` पर एक CNAME target दिखता है और deployment के बाद उसे replace करने की plan बनती है। Agent के काम करते समय on-call engineer incident के दौरान traffic divert करने के लिए target बदल देता है।

Agent बाद में पुरानी replacement request भेजता है। अगर उसका provider call generic update या unconditional delete-then-create sequence इस्तेमाल करता है, तो on-call change overwrite हो जाती है। Agent ने कुछ घंटे पहले जो state देखी थी, उसके हिसाब से request सही लग सकती है। Live zone के हिसाब से वह गलत है।

Write से पहले fresh reads इस failure को रोकती हैं। Executor RRset पढ़ता है, उसे action की `expected_rrset` से compare करता है और on-call target अलग होने पर write से मना कर देता है। Refusal में दोनों values log होनी चाहिए और reviewer को बताया जाना चाहिए कि किसी दूसरे actor ने record बदला है। Executor को merge की कोशिश नहीं करनी चाहिए।

DNS data merge करने के लिए service knowledge चाहिए। दो address values deliberate capacity, temporary overlap, geographic split या emergency route दिखा सकती हैं। Agent केवल इसलिए सुरक्षित रूप से यह अनुमान नहीं लगा सकता कि deployment file में उसे एक ही address क्यों दिख रहा है।

यही नियम partial failure के बाद भी लागू होता है। अगर provider timeout report करता है, तो executor retry से पहले authoritative provider state पढ़े। Client को response न मिला हो, फिर भी write सफल हो सकती है। Blind retries कुछ APIs पर duplicate values और दूसरी APIs पर unwanted replacement behavior पैदा कर सकती हैं।

## Logs में वही सुरक्षित रहे जिसे reviewer ने approve किया था

DNS audit record में provider activity event का इतना लिखना पर्याप्त नहीं कि कोई record बदला। Proposed action, execution से पहले observed state, approval decision, request करने वाला process, provider response और verification results store करें। इतना data रखें कि यह फिर से बनाया जा सके कि executor ने approved request का पालन किया था या नहीं।

Tamper-evident log एक उपयोगी गुण जोड़ता है: incident की जांच करने वाला व्यक्ति यह परख सकता है कि बाद में history बदली गई थी या नहीं। यह तब महत्वपूर्ण है जब DNS answers caches से expire हो चुके हों और लोग memory या screenshots पर निर्भर होने लगें। Evidence मूल agent conversation के बिना भी समझ में आना चाहिए।

Run record को call record से अलग रखें। Run record बताता है कि किस agent process को कब authority मिली और वह authority कब खत्म हुई। Call record बताता है कि उसने कौन सा exact DNS action मांगा, किसी ने उसे approve किया या नहीं और परिणाम क्या रहा। Run को तुरंत revoke करने से बाद की calls रुकनी चाहिए, लेकिन provider द्वारा स्वीकार की जा चुकी DNS write वापस नहीं हो सकती। Audit trail को यह boundary स्पष्ट रखनी चाहिए।

Approval card और execution record दोनों में action IDs इस्तेमाल करें। Operator को खराब result दिखने पर अलग-अलग agent output की stream में खोजने के बजाय exact approved deletion या edit मिल जाना चाहिए। ID को request, state comparison, provider response और verification commands से जोड़ना चाहिए।

पहला practical change छोटा है: approval boundary पर generic DNS writes पर रोक लगाएं। हर request को create, edit या delete में बदलना अनिवार्य करें, edits और deletions के लिए पूरा expected RRset मांगें और execution से पहले drift reject करें। यह एक constraint agent के proposed DNS work को इतना स्पष्ट बना देता है कि इंसान महत्वपूर्ण गलतियां पकड़ सके।