Unit Instance

HTTP 200 OK
Allow: GET, PUT, PATCH, DELETE, HEAD, OPTIONS
Content-Type: application/json
Vary: Accept

{
    "translation": "https://weblate.info.ucl.ac.be/api/translations/cnp3-ebook/protocolsdns/en/?format=api",
    "source": [
        "The `AA` bit is set when the server that sent the response has `authority` for the domain name found in the question section. In the original DNS deployments, two types of servers were considered : `authoritative` servers and `non-authoritative` servers. The `authoritative` servers are managed by the system administrators responsible for a given domain. They always store the most recent information about a domain. `Non-authoritative` servers are servers or resolvers that store DNS information about external domains without being managed by the owners of a domain. They may thus provide answers that are out of date. From a security point of view, the `authoritative` bit is not an absolute indication about the validity of an answer. Securing the Domain Name System is a complex problem that was only addressed satisfactorily recently by the utilization of cryptographic signatures in the DNSSEC extensions to DNS described in :rfc:`4033`."
    ],
    "previous_source": "",
    "target": [
        "The `AA` bit is set when the server that sent the response has `authority` for the domain name found in the question section. In the original DNS deployments, two types of servers were considered : `authoritative` servers and `non-authoritative` servers. The `authoritative` servers are managed by the system administrators responsible for a given domain. They always store the most recent information about a domain. `Non-authoritative` servers are servers or resolvers that store DNS information about external domains without being managed by the owners of a domain. They may thus provide answers that are out of date. From a security point of view, the `authoritative` bit is not an absolute indication about the validity of an answer. Securing the Domain Name System is a complex problem that was only addressed satisfactorily recently by the utilization of cryptographic signatures in the DNSSEC extensions to DNS described in :rfc:`4033`."
    ],
    "id_hash": -1242861462525954664,
    "content_hash": -1242861462525954664,
    "location": "../../protocols/dns.rst:35",
    "context": "",
    "note": "",
    "flags": "",
    "state": 100,
    "fuzzy": false,
    "translated": true,
    "approved": false,
    "position": 9,
    "has_suggestion": false,
    "has_comment": false,
    "has_failing_check": false,
    "num_words": 146,
    "source_unit": "https://weblate.info.ucl.ac.be/api/units/37554/?format=api",
    "priority": 100,
    "id": 37554,
    "web_url": "https://weblate.info.ucl.ac.be/translate/cnp3-ebook/protocolsdns/en/?checksum=6ec07815b51e3598",
    "url": "https://weblate.info.ucl.ac.be/api/units/37554/?format=api",
    "explanation": "",
    "extra_flags": "",
    "pending": false,
    "timestamp": "2022-09-17T01:14:28.959376+02:00"
}