Crate dns_server
source · [−]Expand description
dns-server
A threaded DNS server library.
Use Cases
- Make your API server its own DNS server. This eliminates the DNS server as a separate point of failure.
- Keep your DNS config in code, next to your server code. Include it in code reviews and integration tests.
- DNS-based domain validation for free ACME certificates. This is useful for servers that don’t listen on port 80. Servers on port 80 can use HTTP for domain validation and don’t need to use this.
Features
- Depends only on
std
forbid(unsafe_code)
- ?% test coverage
Limitations
- Brand new.
Example
use permit::Permit;
use prob_rate_limiter::ProbRateLimiter;
use dns_server::DnsRecord;
use std::net::{IpAddr, Ipv6Addr, SocketAddr, UdpSocket};
let permit = Permit::new();
let sock = UdpSocket::bind(SocketAddr::new(IpAddr::V6(Ipv6Addr::UNSPECIFIED), 0)).unwrap();
let addr = sock.local_addr().unwrap();
let response_bytes_rate_limiter = ProbRateLimiter::new(100_000);
let records = vec![
DnsRecord::new_a("aaa.example.com", "93.184.216.34").unwrap(),
DnsRecord::new_aaaa("aaa.example.com", "2606:2800:220:1:248:1893:25c8:1946").unwrap(),
DnsRecord::new_cname("bbb.example.com", "target.foo.com").unwrap(),
];
dns_server::serve_udp(
&permit,
&sock,
response_bytes_rate_limiter,
&records,
)
.unwrap();
Related Crates
Cargo Geiger Safety Report
Changelog
- v0.1.0 - Initial version
To Do
- Message compression
- Decide whether to send back error responses.
- Ergonomic constructors that take
OsStr
, for using environment variables - Custom TTLs
- NS records (and glue)
- Client
- Caching client
- Recursive resolver
Alternatives
Structs
4.1.1. Header section format
The header contains the following fields:
2.3.1. Preferred name syntax
The DNS specifications attempt to be as general as possible in the rules for constructing domain names. The idea is that the name of any existing object can be expressed as a domain name with minimal changes.
However, when assigning a domain name for an object, the prudent user will select a name which satisfies both the rules of the domain system and any existing rules for the object, whether these rules are published or implied by existing programs.
For example, when naming a mail domain, the user should satisfy both the rules of this memo and those in RFC-822. When creating a new host name, the old rules for HOSTS.TXT should be followed. This avoids problems when old software is converted to use domain names.
The following syntax will result in fewer problems with many
applications that use domain names (e.g., mail, TELNET).
<domain> ::= <subdomain> | " "
<subdomain> ::= <label> | <subdomain> "." <label>
<label> ::= <letter> [ [ <ldh-str> ] <let-dig> ]
<ldh-str> ::= <let-dig-hyp> | <let-dig-hyp> <ldh-str>
<let-dig-hyp> ::= <let-dig> | "-"
<let-dig> ::= <letter> | <digit>
<letter> ::=
any one of the 52 alphabetic charactersA
throughZ
in upper case anda
throughz
in lower case
<digit> ::=
any one of the ten digits0
through9
Note that while upper and lower case letters are allowed in domain names, no significance is attached to the case. That is, two names with the same spelling but different case are to be treated as if identical.
The labels must follow the rules for ARPANET host names. They must start with a letter, end with a letter or digit, and have as interior characters only letters, digits, and hyphen. There are also some restrictions on the length. Labels must be 63 characters or less.
For example, the following strings identify hosts in the Internet:
A.ISI.EDU XX.LCS.MIT.EDU SRI-NIC.ARPA
The question section is used to carry the “question” in most queries, i.e., the parameters that define what is being asked. The section contains QDCOUNT (usually 1) entries, each of the following format:
Enums
CLASS
fields appear in resource records. The followingCLASS
mnemonics and values are defined:
IN
1 the InternetCS
2 the CSNET class (Obsolete - used only for examples in some obsolete RFCs)CH
3 the CHAOS classHS
4 Hesiod [Dyer 87]
QCLASS
fields appear in the question section of a query.QCLASS
values are a superset ofCLASS
values; everyCLASS
is a validQCLASS
. In addition toCLASS
values, the followingQCLASSes
are defined:
*
255 any class
OPCODE
A four bit field that specifies kind of query in this message. This value is set by the originator of a query and copied into the response. The values are:
0
a standard query (QUERY
)1
an inverse query (IQUERY
)2
a server status request (STATUS
)3-15
reserved for future use
4.1.3. Resource record format
The answer, authority, and additional sections all share the same format: a variable number of resource records, where the number of records is specified in the corresponding count field in the header. Each resource record has the following format:
RCODE
Response code - this 4 bit field is set as part of responses. The values have the following interpretation:
0
No error condition1
Format error - The name server was unable to interpret the query.2
Server failure - The name server was unable to process this query due to a problem with the name server.3
Name Error - Meaningful only for responses from an authoritative name server, this code signifies that the domain name referenced in the query does not exist.4
Not Implemented - The name server does not support the requested kind of query.5
Refused - The name server refuses to perform the specified operation for policy reasons. For example, a name server may not wish to provide the information to the particular requester, or a name server may not wish to perform a particular operation (e.g., zone transfer) for particular data.6-15
Reserved for future use.
TYPE fields are used in resource records. Note that these types are a subset of QTYPEs.
Functions
Errors
Errors