libval(3)

📦 version 2.2.3, in arch rolling

💖 libval — the Programmer's Manual 💖

okay bestie, sit DOWN, because this is the manual page for libval(3) and she is long. Like, she's giving "I contain multitudes" energy. We're talking the validator library, the whole trust-chain bestie herself. Grab a lil drink, get comfy, and let's go. 🫶

✨ NAME ✨

So here's the whole roster of functions in this family, and what each one is here to do. Slay. 💅

  • val_create_context(), val_free_context() — manage validator context. You know, make her, then release her. 🎀
  • val_context_setqflags() — manage validator context flags.
  • val_resolve_and_check(), val_free_result_chain() — query and validate answers from a DNS name server. this is the main character of the whole page ngl 🔥
  • val_istrusted() — check if status value corresponds to that of a trustworthy answer.
  • val_isvalidated() — check if status value represents an answer that cryptographically chains down from a configured trust anchor. cryptographically chains down!! that's the good stuff!! ⭐
  • val_does_not_exist() — check if status value represents one of the non-existence types.
  • p_val_status(), p_ac_status(), p_val_error() — display validation status, authentication chain status and error information. the printing girlies 🖨️
  • val_log_add_optarg — control log message verbosity and output location.

💅 SYNOPSIS 💅

okay so before you can even look at any of this, you gotta bring in the header:

#include <validator.h>

and then the whole squad, in all their signature glory. copy these EXACTLY bestie, I am not joking, every arg, every type, every asterisk, no cap:

int val_create_context(const char *label, val_context_t **newcontext);

int val_create_context_ex(char *label,
                          val_context_opt_t *opt,
                          val_context_t ** newcontext);

int val_context_setqflags(val_context_t *context,
                          unsigned char action,
                          unsigned int flags);

int val_context_store_ns_for_zone(val_context_t *context,
                                  char * zone,
                                  char *resp_server,
                                  int recursive)

int val_resolve_and_check(val_context_t *context,
                       const char *domain_name,
                       int class,
                       int type,
                       unsigned int  flags,
                       struct val_result_chain  **results);

char *p_val_status(val_status_t valerrno);

char *p_ac_status(val_astatus_t auth_chain_status);

char *p_val_error(int err);

int val_istrusted(val_status_t val_status);

int val_isvalidated(val_status_t val_status);

int val_does_not_exist(val_status_t status);

val_log_t *val_log_add_optarg(const char *args, int use_stderr);

void val_free_result_chain(struct val_result_chain *results);

void val_free_context(val_context_t *context);
👀 heads up bestie: yes, that's really how it's written. If you're wondering about the semicolon situation on one of those, that's not a typo on my end — I'm giving it to you character for character, the way it lives in the original. Do not "fix" it, just vibe with it. 🦋

✨ DESCRIPTION ✨

okay so bestie, gather round, because val_resolve_and_check() is literally the main character here 💅. It goes and queries a whole set of name servers for the <domain_name, type, class> tuple, then it verifies and validates whatever comes back. Verification = checking the RRSIGs. Validation = verifying an authentication chain all the way from a configured trust anchor. no cap. 🔥

The flags parameter? That's your remote control for how validation behaves, and you can OR these values together like the iconic little bitmasks they are:

  • VAL_QUERY_DONT_VALIDATE — tells the validator to just… disable validation for this one query. bye validation 👋
  • VAL_QUERY_IGNORE_SKEW — disables checking the signature inception and expiration times on RRSIGs. time is fake, apparently ⏰
  • VAL_QUERY_AC_DETAIL — makes the validator copy the authentication chain details into the val_rc_answer member inside the returned val_result_chain structure. receipts, bestie 🧾
  • VAL_QUERY_ASYNC — turns on asynchronous query resolution for that lookup. multitasking queen behavior ✨
  • VAL_QUERY_NO_DLV — disables DLV processing for this query. but heads up: this is only available if the libval(3) library was compiled with DLV support. no DLV support, no flag, periodt 💀
  • VAL_QUERY_NO_EDNS0_FALLBACK — when querying name servers, libsres(3) will also try a bunch of different EDNS0 sizes, ending with a query that has EDNS0 disabled (i.e. no CD bit set). This flag makes libval disable that EDNS0 fallback entirely. no fallback era 🙅‍♀️
  • VAL_QUERY_ITERATE — forces libval to iteratively look up the query by asking various name servers in the delegation hierarchy, instead of requesting the info from any caching name server that might be configured in dnsval.conf. we're going straight to the source, bestie 🦋
  • VAL_QUERY_SKIP_RESOLVER — forces libval to only peek at its own cache while trying to resolve a name. cache only, we stay cozy 🎀
  • VAL_QUERY_SKIP_CACHE — so there are two levels of caching inside libval: assertion level and answer level. This flag forces libval to ignore data in both caches while resolving a name. cold turkey, no cached leftovers 🍓
  • VAL_QUERY_SKIP_ANS_CACHE — again, two levels of caching: assertion and answer. This one makes libval ignore data in the answer cache while resolving a name. If an assertion already exists for the given name,class and type, that assertion gets re-used until it expires. Once it expires, the name is looked up via a query even if a newer record (fetched by another assertion in the same or different context) is available in its answer cache. messy but make it fashion 💅

The first parameter to val_resolve_and_check() is the validator context. Applications can create a new validator context using the val_create_context() function. That function parses the resolver and validator configuration files and creates the newcontext handle for all that parsed info. What lives inside the validator context? The validation policy and the resolver policy. iconic 👑

Validator and resolver policies get read from /etc/dnsval.conf and /etc/resolv.conf files by default. And /etc/root.hints provides bootstrapping information for the validator when it's functioning as a full resolver (see dnsval.conf(3)). These defaults may be different if any other value was specified at library configure time. If the default resolver configuration file isn't found at the specified location, libval will also try to fall back to /etc/resolv.conf as a last resort. always have a backup plan, bestie 🫶

Applications may also create a validator context with a custom policy using the val_create_context_ex() function. fancy ✨

The opt argument in val_create_context_ex() points to this structure right here — copy it exactly, no editing:

typedef struct val_context_opt {
    unsigned int vc_qflags;
    unsigned int vc_polflags;
    char *vc_valpol;
    char *vc_nslist;
    char *vc_val_conf;
    char *vc_res_conf;
    char *vc_root_conf;
    val_global_opt_t *gopt,
} val_context_opt_t;

vc_qflags specify the default query flags for queries associated with the context. This field is identical to the flags argument in the val_resolve_and_check() function. twins 👯‍♀️

The vc_val_conf, vc_res_conf, and vc_root_conf fields can be used to specify alternative configuration files in place of the default files used for the validator, resolver, and root hints configuration information. custom files, custom vibes 📁

The vc_valpol field can be used to supply a custom validator configuration "snippet" to the validator. The validator parses this information and applies it to the default validator configuration either as an extension or as an override, as specified by the vc_polflags field. The vc_nslist field, similarly, can be used to supply a custom list of recursive name servers to send queries to, in addition to (or in place of) the list of name servers specified in the resolv.conf file. The list of name servers in vc_res_conf must be specified as a white-space delimited list of IP or IPv6 addresses. get those addresses in order, no commas, bestie 📝

A custom mapping between a zone and a name server may be created using the val_context_store_ns_for_zone() function. zone-to-nameserver shipping 🚢

vc_polflags can be configured with the following values:

  • CTX_DYN_POL_VAL_OVR — When this flag is set, only the validator configuration specified in the vc_valpol field is used for the validator configuration. Options specified in the dnsval.conf file are ignored. ignore list activated 💅
  • CTX_DYN_POL_RES_OVR — When this flag is set, only the name servers specified in the vc_nslist field are used for the resolver configuration. Options specified in the resolv.conf file are ignored. sorry not sorry 🙈
  • CTX_DYN_POL_GLO_OVR — When this flag is set, only the global options set in the gopt field are used. Global options specified in the dnsval.conf file are ignored. gopt only, periodt 👑
  • CTX_DYN_POL_RES_NRD — When this flag is set, outgoing queries have the Recursion Desired (RD) bit set to 0. This is useful if queries need to be sent to an authoritative-only name server. no recursion, just authority 💀

The gopt field points to this structure:

typedef struct val_global_opt {
    int local_is_trusted;
    long edns0_size;
    int env_policy;
    int app_policy;
    char *log_target;
    int closest_ta_only;
    int rec_fallback;
    long max_refresh;
    int proto;
} val_global_opt_t;

Setting a value of 1 for local_is_trusted is equivalent to specifying the trust-oob-answers option in the dnsval.conf file to yes. Similarly, setting the closest_ta_only and rec_fallback members to 1 is equivalent to setting the closest-ta-only and rec-fallback options to yes in the dnsval.conf file. A value of 0 is equivalent to the no setting for these option. yes means yes, no means no, simple as that ✨

Setting the edns0_size member to a particular value has the same effect as setting the edns0-size option in the dnsval.conf file. size matters, bestie 📏

Setting the max_refresh member to a particular value has the same effect as setting the max-refresh option in the dnsval.conf file. refresh rate but make it global 🌀

Setting the proto member to a particular value has the same effect as setting the proto option in the dnsval.conf file. protocol tea ☕

env_policy and app_policy can be set to one of VAL_POL_GOPT_DISABLE, VAL_POL_GOPT_ENABLE, or VAL_POL_GOPT_OVERRIDE. These values correspond directly to the disable, enable and override options for the env-policy and app-policy settings in the dnsval.conf file. pick your fighter 🥊

Values of -1 for the above fields are treated as "ignore" conditions in that the validator will not include dynamically supplied global options with a value of -1 when creating its context. This allows an application to override a subset of global options while using the global options supplied in the dnsval.conf file by default. cherry-picking but for config 🍒

The log_target field enables the application to supply log targets in addition to the ones configured in the configuration file. extra logging, extra slay 📝

See dnsval.conf(3) for more details on specifying validator policy. homework, but make it optional 📚

Default query flags can be set and unset for a given context using val_context_setqflags(). This allows an application to alter the DNSSEC validator processing, while still having most of the more granular default configuration specified in its configuration file. The action parameter can be set to one of the following:

  • VAL_CTX_FLAG_SET — This option causes the validator to set the given flag as one of the default query flags. turn it on, bestie 🔛
  • VAL_CTX_FLAG_RESET — This option causes the validator to reset the given flag if it was set as one of the default query flags for the context. turn it off, we're done 🛑

Answers returned by val_resolve_and_check() are made available in the *results linked list. Each answer corresponds to a distinct RRset; multiple RRs within the RRset are part of the same answer. Multiple answers are possible when type is ns_t_any or ns_t_rrsig. one answer, many records, all in the same group chat 💬

Individual elements in *results point to val_authentication_chain linked lists. The authentication chain elements in val_authentication_chain contain the actual RRsets returned by the name server in response to the query. receipts from the source 🧾

Validation result values returned in val_result_chain can be converted into ASCII format using the p_val_status(). Authentication chain status values returned in each element of the val_authentication_chain linked list can be converted into ASCII format using the p_ac_status() functions. make it readable, bestie 📖

While some applications such as DNSSEC troubleshooting utilities and packet inspection tools may look at individual authentication chain elements to identify the actual reasons for validation error, most applications will only be interested in a single error code for determining the authenticity of data. main character apps keep it simple 💅

val_isvalidated() identifies if a given validation result status value corresponds to an answer that was cryptographically verified and validated using a locally configured trust anchor. crypto verified = valid, periodt 🔐

val_istrusted() identifies if a given validator status value is trusted. An answer may be locally trusted without being validated. trusted but not validated? it's giving complicated 💖

val_does_not_exist() identifies if a given validator status value corresponds to one of the non-existence types. it's not there, bestie, and we know it 💀

The libval library internally allocates memory for *results and this must be freed by the invoking application using the free_result_chain() interface. free your memory, literally and emotionally 🫶

💖 DATA STRUCTURES 💖

struct val_result_chain

struct val_result_chain
{
    val_status_t                     val_rc_status;
    char                            *val_rc_alias;
    struct val_rrset_rec            *val_rc_rrset;
    struct val_authentication_chain *val_rc_answer;
    int                              val_rc_proof_count;
    struct val_authentication_chain *val_rc_proofs[MAX_PROOFS];
    struct val_result_chain         *val_rc_next;
};
  • val_rc_answer — Authentication chain for a given RRset. the whole chain, in one member, slay 🔗
  • val_rc_next — pointer to the next RRset in the set of answers returned for a query. like the next bestie in the answer squad. 💅
  • val_rc_proofs — pointer to authentication chains for any proof of non-existence that were returned for the query. the receipts, basically. 🧾
  • val_rc_proof_count — number of proof elements stored in val_rc_proofs. The number cannot exceed MAX_PROOFS. 🚫
  • val_rc_alias — for a val_result_chain element that points to a name alias, this field contains the target value. it's giving "who dis really is". 🎯
  • val_rc_rrset — for a val_result_chain element that contains a valid (not NULL) val_rc_answer field, the val_rc_rrset field points to the top-most val_rrset_rec element in the val_rc_answer authentication chain. top of the chain, literally. 👑
  • val_rc_status — validation status for a given RRset. This can be one of the following:
    • VAL_SUCCESS — answer received and validated successfully. ate and left no crumbs. ✅
    • VAL_NONEXISTENT_NAME — no name was present and a valid proof of non-existence confirming the missing name (NSEC or NSEC3 span) was returned. The components of the proof were also individually validated. 💀
    • VAL_NONEXISTENT_TYPE — no type exists for the name and a valid proof of non-existence confirming the missing name was returned. The components of the proof were also individually validated. 🫠
    • VAL_NONEXISTENT_NAME_NOCHAIN — no name was present and a valid proof of non-existence confirming the missing name was returned. The components of the proof were also identified to be trustworthy, but they were not individually validated. no chain, but still cute. 🎀
    • VAL_NONEXISTENT_TYPE_NOCHAIN — no type exists for the name and a valid proof of non-existence confirming the missing name (NSEC or NSEC3 span) was returned. The components of the proof were also identified to be trustworthy, but they were not individually validated. 🦋
    • VAL_PINSECURE — the record or some ancestor of the record in the authentication chain towards the trust anchor was known to be provably insecure. red flag but make it official. 🚩
    • VAL_PINSECURE_UNTRUSTED — the record or some ancestor of the record in the authentication chain towards the trust anchor was known to be provably insecure. But the provably insecure condition was configured as untrustworthy. 🚩 but make it extra. 🙈
    • VAL_BARE_RRSIG — no DNSSEC validation possible, query was for an RRSIG. just the sig, no context. 💅
    • VAL_IGNORE_VALIDATION — local policy was configured to ignore validation for the zone from which this data was received. we're ignoring it, respectfully. 🙈
    • VAL_UNTRUSTED_ZONE — local policy was configured to reject any data received from the given zone. blocked. 🚫
    • VAL_OOB_ANSWER — answer was obtained using some Out Of Band method, such as a local configuration file. sneaky link. 👀
    • VAL_BOGUS — response could not be validated due to signature verification failures or the inability to verify proofs in the authentication chain. it's giving fake. 💀
    • VAL_DNS_ERROR — some error was encountered during DNS processing. DNS said "not today". 😭
    • VAL_INDETERMINATE — response could not be validated due to missing DNSSEC meta-data. no metadata, no verdict. 🤷
    • VAL_NOTRUST — all available components in the authentication chain verified properly, but there was no trust anchor available. verified but no anchor? tragic. ⚓️

Status values in val_status_t returned by the validator can be displayed in ASCII format using p_val_status(). cute little ASCII glow-up. ✨

struct val_authentication_chain 🧬

struct val_authentication_chain
{
    val_astatus_t                    val_ac_status;
    struct val_rrset_rec                *val_ac_rrset;
    struct val_authentication_chain *val_ac_trust;
};
  • val_ac_status — validation state of the authentication chain element. This field will contain the status code for the given component in the authentication chain. This field may contain one of the following values:
    • VAL_AC_UNSET — the status could not be determined. mystery era. 🕵️
    • VAL_AC_IGNORE_VALIDATION — validation for the given resource record was ignored, either because of some local policy directive or because of some protocol-specific behavior. not today. 🙈
    • VAL_AC_UNTRUSTED_ZONE — local policy defined a given zone as untrusted, with no further validation being deemed necessary. we don't trust her. 🚫
    • VAL_AC_PINSECURE — the authentication chain from a trust anchor to a given zone could not be constructed due to the provable absence of a DS record for this zone in the parent. no DS, no chain. 💔
    • VAL_AC_BARE_RRSIG — the response was for a query of type RRSIG. RRSIGs contain the cryptographic signatures for other DNS data and cannot themselves be validated. sigs can't validate themselves, bestie. 💅
    • VAL_AC_NO_LINK — there was no trust anchor configured for a given authentication chain or the chain didn't link up. link broken. 😭
    • VAL_AC_TRUST — at least one of the signatures covering the given DNSKEY RRset was directly verified using a key that was configured as a DNSSEC trust anchor. trust fall, but it worked. 🫶
    • VAL_AC_RRSIG_MISSING — RRSIG data could not be retrieved for a resource record. where's the sig? 👀
    • VAL_AC_DNSKEY_MISSING — the DNSKEY for an RRSIG covering a resource record could not be retrieved. no key, no entry. 🔑
    • VAL_AC_DS_MISSING — the DS record covering a DNSKEY record was not available. DS ghosted. 👻
    • VAL_AC_DATA_MISSING — no data were returned for a query and the DNS did not indicate an error. empty but no error? awkward. 🫠
    • VAL_AC_DNS_ERROR — some error was encountered during DNS processing. DNS is having a moment. 😭
    • VAL_AC_NOT_VERIFIED — all RRSIGs covering the RRset could not be verified. not verified, not slaying. 💔
    • VAL_AC_VERIFIED — at least one RRSIG covering a resource record had a status of VAL_AC_RRSIG_VERIFIED. verified! periodt. ✅
  • val_ac_rrset — pointer to an RRset of type struct val_rrset_rec obtained from the DNS response. the actual data. 💾
  • val_ac_trust — pointer to an authentication chain element that either contains a DNSKEY RRset that can be used to verify RRSIGs over the current record, or contains a DS RRset that can be used to build the chain-of-trust towards a trust anchor. the trust connector. 🔗

struct val_rrset_rec 🦋

struct val_rrset_rec
{
    int    val_rrset_rcode;
    char   *val_rrset_name;
    int    val_rrset_class;
    int    val_rrset_type;
    long   val_rrset_ttl;
    int    val_rrset_section;
    struct sockaddr *val_rrset_server;
    struct val_rr_rec *val_rrset_data;
    struct val_rr_rec *val_rrset_sig;
};
  • val_rrset_rcode — the rcode on the response header for this rrset. the vibe code. 📟
  • val_rrset_name — owner name of the RRset. whose RRset is this? 💁
  • val_rrset_class — class of the RRset. classy. 🎀
  • val_val_rrset_type — type of the RRset. (yes, the field name in the docs is val_val_rrset_type, not a typo on our part. 💅)
  • val_rrset_ttl — TTL of the RRset. how long it lives. ⏳
  • val_rrset_section — section in which the RRset was received. This value may be VAL_FROM_ANSWER, VAL_FROM_AUTHORITY, or VAL_FROM_ADDITIONAL. where it showed up. 📍
  • val_rrset_server — the name server that returned this response. the server that served. 🖥️
  • val_rrset_data — response RDATA. the actual data bytes. 📦
  • val_rrset_sig — any associated RRSIGs for the RDATA returned in val_rrset_data. the signatures that came with. ✍️

struct val_rr_rec 🌈

struct val_rr_rec
{
    size_t            rr_rdata_length;
    unsigned char     *rr_rdata;
    struct val_rr_rec *rr_next;
    val_astatus_t     rr_status;
};
  • rr_rdata_length_h — length of data stored in rr_rdata. (yes, the _h is in the docs. 💅)
  • rr_rdata — RDATA bytes. raw bytes. 🧬
  • rr_status — for each signature val_rr_rec member within the authentication chain val_ac_rrset, the validation status stored in the variable rr_status can return one of the following values:
    • VAL_AC_RRSIG_VERIFIED — the RRSIG verified successfully. slay. ✅
    • VAL_AC_WCARD_VERIFIED — a given RRSIG covering a resource record shows that the record was wildcard expanded. wildcard but verified. 🃏
    • VAL_AC_RRSIG_VERIFIED_SKEW — the RRSIG verified successfully after clock skew was taken into account. time was off but we fixed it. ⏰
    • VAL_AC_WCARD_VERIFIED_SKEW — a given RRSIG covering a resource record shows that the record was wildcard expanded, but it was verified only after clock skew was taken into account. wildcard + time travel. 🕰️
    • VAL_AC_WRONG_LABEL_COUNT — the number of labels on the signature was greater than the count given in the RRSIG RDATA. label math said no. 🧮
    • VAL_AC_INVALID_RRSIG — the RRSIG could not be parsed. couldn't even read it. 💀
    • VAL_AC_RRSIG_NOTYETACTIVE — the RRSIG's inception time is in the future. not active yet, bestie. ⏳
    • VAL_AC_RRSIG_EXPIRED — the RRSIG had expired. expired, like my patience. 💀
    • VAL_AC_ALGORITHM_NOT_SUPPORTED — the RRSIG algorithm was not supported. algorithm not in the group chat. 🚫
    • VAL_AC_RRSIG_VERIFY_FAILED — a given RRSIG covering an RRset was bogus. verification said no. ❌
    • VAL_AC_RRSIG_ALGORITHM_MISMATCH — the keytag referenced in the RRSIG matched a DNSKEY but the algorithms were different. keytag said yes, algorithm said no. 🤡
    • VAL_AC_DNSKEY_NOMATCH — an RRSIG was created by a DNSKEY that did not exist in the apex keyset. no matching key. 🔑

For each val_rr_rec member of type DNSKEY (or DS, where relevant) within the authentication chain val_ac_rrset, the validation status is stored in the variable rr_status and can return one of the following values:

  • VAL_AC_TRUST_POINT — the given DNSKEY or a DS record was configured as a DNSSEC trust anchor. trust point, literally. ⚓️
  • VAL_AC_SIGNING_KEY — this DNSKEY was used to create an RRSIG for the resource record set. signing key, doing the work. ✍️
  • VAL_AC_VERIFIED_LINK — bestie, this one is slaying. This DNSKEY is the link in the authentication chain from the trust anchor all the way down to the signed record, and it checked out. Verified. Validated. Iconic. 👑
  • VAL_AC_UNKNOWN_ALGORITHM_LINK — same deal, this DNSKEY also provided the link in the authentication chain from the trust anchor to the signed record… but the DNSKEY algorithm was unknown. So like. The vibes were there, the algorithm was not. 💀
  • VAL_AC_UNKNOWN_DNSKEY_PROTOCOL — the DNSKEY protocol number was unrecognized. Not it, fr.
  • VAL_AC_ALGORITHM_NOT_SUPPORTED — the DNSKEY or DS algorithm was not supported. She simply doesn't serve that.
  • VAL_AC_DS_NOMATCH — an RRSIG was created with a key that did not exist in the parent DS record set. Not a match, and honestly? Awkward. 😭
  • VAL_AC_INVALID_KEY — the key used to verify the RRSIG was not a valid DNSKEY. Fake key energy, we do not claim her.
  • VAL_AC_INVALID_DS — the DS used to validate the DNSKEY could not be parsed. Unreadable, unparseable, unserious. 🙈

✨ rr_next

  • rr_next — points to the next resource record in the RRset. Yes bestie, it's linked-list hours, the RRs are holding hands. 🫶

📝 LOGGING 📝

Okay so here's the tea, libval gives you the val_log_add_optarg() function for controlling the verbosity and location of log message output. You want your logs loud? Quiet? Somewhere specific? She can do that. ✨

The val_log_add_optarg() function takes two arguments: the first argument args is a character-string value that specifies the location and verbosity. The second argument, use_stderr, if set to a value greater than 0 allows libval to send log messages to stderr. Simple as.

The character string that specifies log target location and verbosity has a specific format:

<debug-level>:<dest-type>[:<dest-options>]

where:

  • <debug-level> is 1-7, for increasing levels of verbosity
  • <dest-type> is one of file, net, syslog, stderr, stdout
  • <dest-options> depends on <dest-type>
    • file:<file-name> (opened in append mode)
    • net[:<host-name>:<host-port>] (127.0.0.1:1053)
    • syslog[:facility] (0-23 (default 1 USER))

The log levels can be roughly translated into different types of log messages as follows (the messages returned for each level in this list subsumes the messages returned for the level above it):

3 : Error   : error encountered
4 : Warning : recovering from error
5 : Notice  : gives final validation results for a query
              and details on policy files and labels used
6 : Info    : gives details on authentication chains
7 : Debug   : gives debug level information

So like, level 3 is the "something went wrong 😭" girlie, level 7 is the "tell me EVERYTHING, I want the whole group chat transcript" girlie. And remember — each level subsumes the one above it, so the higher you go the more you're getting. No cap. 💅

💖 RETURN VALUES 💖

Return values for various functions are given below. These values can be displayed in ASCII format using the p_val_error() function. Yes, p_val_error() will literally translate the numbers for you into something you can actually read, which is a gift. 🎀

  • VAL_NO_ERROR — no error was encountered. We love a clean run, bestie. ✨
  • VAL_NOT_IMPLEMENTED — functionality not yet implemented. She's a work in progress, and that's okay. 🌱
  • VAL_RESOURCE_UNAVAILABLE — some resource (crypto possibly) was unavailable. Currently not implemented.
  • VAL_BAD_ARGUMENT — bad arguments passed as parameters. You gave her the wrong input and she said "not with that attitude". 🙅
  • VAL_INTERNAL_ERROR — encountered some internal error. She's going through something, don't ask. 💀
  • VAL_NO_PERMISSION — no permission to perform operation. Currently not implemented.
  • VAL_CONF_PARSE_ERROR — error in parsing some configuration file. The config file was giving nonsense and she simply could not.
  • VAL_CONF_NOT_FOUND — a configuration file was not available. Where is it. WHERE IS IT. 😭
  • VAL_NO_POLICY — the policy identifier being referenced was invalid. That policy? Never heard of her. 🙈

📂 FILES 📂

The validator library reads configuration information from two files, resolv.conf and dnsval.conf.

See dnsval.conf(5) for a description of the syntax for these files. Go read it, I promise it's worth it. 🦋

Copyright 2004-2013 SPARTA, Inc. All rights reserved. See the COPYING file included with the dnssec-tools package for details.

👑 AUTHORS 👑

Suresh Krishnaswamy, Robert Story

The icons. The legends. The main characters. Thank you for your service. 🫶

🔭 SEE ALSO 🔭

And that's a wrap on libval(3), bestie!! 🌈 This whole thing came to you from perl v5.26.2 on 2018-08-08 — so yes, she's an older queen but she still ate. 💅 Go forth and validate your DNSSEC, you've got this, I believe in you fr fr. 💖✨🎀🦋🌸

📦 where this page comes from