Lines Matching refs:records
186 records by sending DNS-like UDP query and response packets over IP
193 responders may have records with that name, rrtype, and rrclass, and
196 A "unique" resource record set is one where all the records with
206 answers containing identical rdata for these records or the
210 record sets, not to individual resource records, but it is sometimes
211 convenient to talk of "shared resource records" and "unique resource
212 records". When used this way, the terms should be understood to mean
321 names, (i.e. the names of DNS address records), but other DNS record
328 records mapping names to IP addresses) is probably desirable in the
331 maintain multiple DNS address records with the same name, possibly
335 allows hosts to verify and maintain unique names for resource records
337 multiple resource records with a single shared name where that
339 records, not just address records (host names). In summary: It is
535 A Multicast DNS Responder that is offering records that are intended
537 Querier so that it can first verify the uniqueness of those records
656 plan to re-query for records after at least 50% of the record
667 NOT perform this cache maintenance for records for which it has no
778 records in the local cache, and those record(s) were received with
838 superfluous for the Querier to include such records in the known
840 records in the known answer list whose remaining TTL is less than
845 A Multicast DNS Querier MUST NOT cache resource records observed in
851 records may have come from other hosts that are no longer on the
861 as many Known Answer records as will fit. It MUST then set the TC
864 questions, and as many more Known Answer records as will fit. If
865 there are still too many records remaining to fit in the packet, it
867 records have been sent.
907 Answer Section of that query does not contain any records which this
910 clients on the network are querying for the same resource records,
944 records for which that Responder is explicitly authoritative. These
948 warranted. A Multicast DNS Responder MUST NOT place records from its
994 question in the query packet, and for all of those answer records it
1008 Responding immediately without delay is appropriate for records like
1011 is *not* appropriate for things like looking up PTR records used for
1142 Section, and the records answering those question(s) in the Answer
1149 address records for all of its active interfaces. Creating and
1167 The first startup step is that for all those resource records that a
1169 MUST send a Multicast DNS Query asking for those resource records, to
1174 types of records with that name. This allows a single question to be
1183 for all of its resource records instead of needing a separate packet
1185 of its "A" record and all its SRV records [DNS-SD] in the same query
1225 for unique records, it SHOULD generate its response to defend that
1244 and MUST choose new names for some or all of its resource records
1264 when creating the reverse address mapping PTR records, the host can
1266 same PTR records, since that would imply that the two hosts were
1289 records with the rdata that it would be proposing to use, should its
1294 When a host is probing for a group of related records with the same
1297 type T_ANY (255) is used, which will elicit answers for all records
1299 cases, the Authority Section must contain *all* the records and
1308 another host also probing for a single record. The two records are
1325 In the case of resource records containing rdata that is subject to
1343 lexicographically later) or one of the resource records runs out
1366 When a host is probing for a set of records with the same name, or a
1367 packet is received containing multiple tie-breaker records answering
1368 a given probe question in the Question Section, the host's records
1369 and the tie-breaker records from the packet are each sorted into
1373 The records are sorted using the same lexicographical order as
1383 When comparing the records, if the first records match perfectly,
1384 then the second records are compared, and so on. If either list of
1385 records runs out of records before any difference is found, then the
1386 list with records remaining is deemed to have won the tie-break. If
1387 both lists run out of records at the same time without any difference
1389 identical sets of records, as is sometimes done for fault tolerance,
1401 Section, all of its resource records (both shared records, and unique
1402 records that have completed the probing step). If there are too many
1403 resource records to fit in a single packet, multiple packets should
1406 In the case of shared records (e.g. the PTR records used by DNS
1407 Service Discovery [DNS-SD]), the records are simply placed as-is
1410 In the case of records that have been verified to be unique in the
1467 At any time, if the rdata of any of a host's Multicast DNS records
1470 addresses change, it MUST re-announce those address records.
1472 In the case of shared records, a host MUST send a "goodbye"
1475 before announcing the new rdata. In the case of unique records,
1477 flush bit on the newly announced records will cause old rdata
1480 A host may update the contents of any of its records at any time,
1481 though a host SHOULD NOT update records more frequently than ten
1494 is context sensitive, except that resource records with identical
1579 The examples in this section focus on address records (i.e. host
1580 names), but the same considerations apply to all resource records
1588 resource records with a host name as the resource record's name
1592 The recommended TTL value for other Multicast DNS resource records
1597 of the way to expiry. If the TTL on those records is 75 minutes,
1602 DNS resource records follow the recommendation and have a TTL of 75
1615 resource records, but different rdata, then:
1635 resource records, and identical rdata, then:
1669 incorrectly sends goodbye packets for its records, it gives the other
1671 "rescue" the records before they expire and are deleted.
1692 previous records with the same name, rrtype and rrclass, all old
1693 records with that name, type and class that were received more than
1703 may have heard more than a second ago regarding records of this
1706 To accommodate the case where the set of records from one host
1708 packet, only cache records that are more than one second old are
1711 of the RRSet. When receiving records with the "cache flush" bit set,
1712 all records older than one second are marked to be deleted one second
1714 any records not represented within that packet burst will then be
1724 it MUST NOT set the cache flush bit on any of those records.
1726 The reason for waiting one second before deleting stale records from
1730 records to be flushed from peer caches. The one-second delay gives
1733 address records so that both sets remain valid and live in peer
1748 The "cache flush" bit is only set in records in the Answer Section of
1750 MUST NOT be set in any resource records in a response packet sent in
1753 The "cache flush" bit MUST NOT be set in any resource records in the
1785 flush all cache records received on a particular interface when that
1787 remaining TTL on all those records to a few seconds so that if the
1788 cable is not reconnected quickly, those records will expire from the
1904 use of NS records. There are no NS records anywhere in Multicast DNS
2010 A host may choose to use the same name for all of its address records
2048 When the host announces its host name (i.e. its address records) on
2049 its wireless interface, those announcement records are sent with the
2052 Ethernet address records from their caches. The mDNS protocol has a
2053 safeguard to protect against this situation: when records are
2054 received with the cache-flush bit set, other records are not deleted
2056 second. When the host sees its own wireless address records arrive on
2059 Ethernet address records, to reinstate those records in peer caches
2063 when those Ethernet announcement records arrive back on the wireless
2065 wireless records, and this process would continue forever,
2068 not apply to records received very recently, within the last second.
2069 This means that when the host sees its own Ethernet address records
2071 knows there's no need to re-announce its wireless address records
2167 of its relevant resource records to zero, to delete them from
2168 neighboring caches. The relevant resource records include address
2169 records and SRV records, and other resource records as may apply to a
2171 active records, plus the names, rrtypes and rrclasses of the deleted
2172 records, to the Sleep Proxy Service(s), along with a copy of the
2176 device's active records (e.g. a DNS-SD PTR record), it answers on
2179 records, it deduces that some client on the network needs to make an
2182 its deleted resource records, and re-announces them to the network.
2193 than one goodbye packet is to ensure deletion of the resource records
2194 from all peer caches. If resource records were to inadvertently
2196 packets for those records when attempting to access the sleeping
2198 the device's SRV and/or address records, and the necessary wake-up
2221 use of DNS is to store host address records, many have assumed that
2302 generated CNAME records. For example, if a responder has an address
2305 responder may issue a response containing two resource records:
2404 that normal TTL aging is performed on these cached resource records.
2455 Known Answer records may be following shortly. A responder MAY choose
2457 records, before deciding whether to respond. If the TC bit is clear,
2538 same packet, or in consecutive packets if there are too many records
2638 * uses gratuitous responses to announce new records to the peer group
2762 * When a host has a large number of records with different names, the
2864 Answer Sections means that Multicast DNS can only carry DNS records