What is 1 Byte DNS?
It is a DNS server that allows users to easily create and manage DNS zones through a convenient web interface. The server supports all major record types, load balancing, and address health monitoring.
How Does It Work?
Register, create a zone, point your domain's NS servers to ours at your registrar, and manage records through the web panel. All changes are applied instantly.
Location
The service is located in Russia. All servers are hosted within the Russian Federation, ensuring low latency for users in Russia and CIS countries.
Ownership Verification
When multiple users create zones with the same domain name, our system automatically verifies ownership by checking public DNS records. The zone that controls the authoritative NS servers becomes active. This ensures fair access and prevents conflicts.
Mobile-First Interface
The interface adapts to your screen size — it works well on phones, tablets, and desktop computers.
Zone Transfer: AXFR & IXFR
The DNS server supports both full zone transfer (AXFR, RFC 5936) and incremental transfer (IXFR, RFC 1995). With IXFR, secondary servers receive only the changes between serials in RFC-compliant delta format: each granule contains the older SOA, deleted records (TTL=0), newer SOA, and added records (TTL>0). Serial arithmetic follows RFC 1982 (unsigned 32-bit wrap-around). Transfers are restricted by ACL — only whitelisted IP addresses can request a transfer. When IXFR history is unavailable, the server falls back to AXFR.
Why Us?
- Fast DNS responses with low latency.
- High server availability and fault tolerance.
- Completely free with no hidden fees.
- Full control over your DNS records.
Why Is This Hard?
Building a correct DNS server means implementing dozens of RFC specifications down to the bit. Each requirement below is a real constraint from the DNS protocol that our server must satisfy.
The order of transmission is resolved to the octet level. Whenever an octet represents a numeric quantity, the left most bit is the high order or most significant bit.— RFC 1035 §2.3.2 — Bit-level transmission order
An entire domain name or a list of labels is replaced with a pointer to a prior occurrence of the same name. The pointer takes the form of a two-octet sequence: 11|OFFSET.— RFC 1035 §4.1.4 — Name compression pointers
A name server must employ multiple concurrent activities. It is simply not acceptable for a name server to block the service of UDP requests while it waits for TCP data.— RFC 1035 §6.1.1 — Concurrency requirement
It is very important that when a zone is refreshed, queries should not use old and new data simultaneously.— RFC 1035 §6.1.2 — Atomic zone replacement
The MINIMUM value in the SOA should be used to set a floor on the TTL of data distributed from a zone. This floor function should be done when the data is copied into a response.— RFC 1035 §6.2 — TTL floor enforcement
When a response is so long that truncation is required, the truncation should start at the end of the response and work forward in the datagram.— RFC 1035 §6.2 — Backward truncation
There must not be any other RRs associated with a nickname of the same class.— RFC 1033 — CNAME exclusivity
When data enters the domain system, its original case should be preserved whenever possible. All comparisons are done in a case-insensitive manner.— RFC 1035 §2.3.3 — Case preservation
An IXFR server should keep record of the newest version of the zone and the differences between that copy and several older versions.— RFC 1995 §4 — Incremental transfer history
When a zone has been updated, it should be saved in stable storage before the new version is used. Otherwise, if the server crashes, data which is no longer available may have been distributed.— RFC 1995 §2 — Persistence before transfer
Because accuracy is essential, TCP or some other reliable protocol must be used for AXFR requests.— RFC 5936 §4 — AXFR over TCP only
The AXFR protocol treats the zone contents as an unordered collection of RRs. Clients MUST accept any ordering and grouping of the non-SOA RRs.— RFC 5936 §2.2 — Unordered zone transfer
Name compression in an AXFR message SHOULD be performed in a case-preserving manner. Although "a" equals "A" for matching, for AXFR compression "a" is not equal to "A".— RFC 5936 §3.4 — Case-preserving compression
Negative caching in resolvers is no longer optional. If a resolver caches anything it must also cache negative answers.— RFC 2308 §8 — Mandatory negative caching
There are a large number of resolvers currently in existence that fail to correctly detect and process all forms of NXDOMAIN response.— RFC 2308 §2.1.1 — NXDOMAIN compatibility
Compute the sum of the weights, and with each RR associate the running sum. Then choose a uniform random number between 0 and the sum, and select the RR whose running sum is first which is greater than or equal to the random number.— RFC 2782 — SRV weighted selection
There MUST be one or more address records for this name, the name MUST NOT be an alias.— RFC 2782 — SRV target not an alias
Wildcard RRs can be thought of as instructions for synthesizing RRs. When the appropriate conditions are met, the name server creates RRs with an owner name equal to the query name.— RFC 4592 §1.2 — Wildcard synthesis