Lines Matching refs:resolver

24 resolver. A validating resolver performs validation for each remote
73 through that resolver. For the end user, the issue may manifest itself
125 validating resolver yourself.
329 resolver:
425 that process now and see what your validating resolver is doing in more
429 1.  The validating resolver queries the ``isc.org`` name servers for the
438 3.  The validating resolver queries for the DNSKEY for ``isc.org``.
443 5.  The validating resolver queries the parent (``.org``) for the DS
450 7.  The validating resolver queries for the DNSKEY for ``.org``.
455 9.  The validating resolver queries the parent (root) for the DS record
461 11. The validating resolver queries for the DNSKEY for root.
466 After step #12, the validating resolver takes the DNSKEY received and
473 validating resolver can verify the answer received. That is what we
502 When the validating resolver queries for the resource record, it
504 validating resolver knows the hash function used (it is listed in the digital
507 hash value X. The validating resolver can also obtain the public key
537 When a validating resolver queries for the A record ``ftp.isc.org``, it
541 hash value X. The resolver also fetches the appropriate DNSKEY record to
555 7:18:51 PM (20200401191851). The validating resolver's current
571 A trust anchor is a key that is placed into a validating resolver, so
573 known or trusted public key (the trust anchor). A validating resolver
591 and where each validating resolver only needs to have one trust anchor - that
593 validating resolver must only have one trust anchor. In fact, in the
595 resolver to have more than one trust anchor.
607 1. The validating resolver queried ``fbi.gov`` name server for the A
612 3. The validating resolver queried the FBI's name server for its DNSKEY.
616 5. The validating resolver queried a ``.gov`` name server for the DS
622 7. The validating resolver queried the ``.gov`` name server for its DNSKEY.
628 we saw earlier. Once the validating resolver receives the DNSKEY file in
633 In fact, whenever the validating resolver receives a DNSKEY, it checks
642 Since the resolver is validating, we must have at least one key (trust
794 you can use to verify resolver behavior regarding EDNS support:
836 resolver, and your validating resolver may need to re-ask the question