Udviklere → DNS som kode
Hold din zone i én YAML- eller JSON-fil ved siden af din kode. Gennemgå DNS-ændringer i pull requests, se præcis hvad der vil ændre sig, før det sker, og anvend det i ét trin.
$ nameocean dns export example.com > dns.yaml $ $EDITOR dns.yaml $ nameocean dns plan -f dns.yaml + CNAME blog example.netlify.app ~ A @ 203.0.113.10 ttl 1h → 5m - A old 203.0.113.9 example.com: 1 to add, 1 to change, 1 to delete, 6 unchanged. $ nameocean dns apply -f dns.yaml Apply these changes? [y/N] y Applied: 1 added, 1 changed, 1 deleted. example.com is at serial 214.
# yaml-language-server: $schema=https://nameocean.net/schemas/dns-zone.json
zone: example.com
records:
- name: "@"
type: A
value: 203.0.113.10
ttl: 5m
- name: www
type: CNAME
value: "@"
- name: "@"
type: MX
value: mail.example.com
priority: 10
- name: "@"
type: TXT
value: "v=spf1 mx -all"
- name: _sip._tcp
type: SRV
value: sip.example.com
priority: 10
weight: 5
port: 5060
- name: old
type: REDIRECT
value: https://example.com/new
name er @ for selve zonen eller et navn relativt til den (www, _dmarc); et fuldt kvalificeret navn med afsluttende punktum virker også.ttl er 5m, 15m, 30m, 1h eller 1d; uden den får en post filens ttl eller 1h. MX tager priority (standard 10), SRV priority, weight og port, REDIRECT save_path (standard true).Filen er hele zonen: en post, der findes i zonen, men ikke i filen, bliver slettet. Angiv --keep-unlisted (prune=false i API'et) for kun at tilføje og ændre.
A-, AAAA-, MX- og TXT-poster matches på navn og værdi (og prioritet for MX), da ét navn kan have flere af dem. CNAME-, SRV-, PTR- og REDIRECT-poster matches på navn. En anden ttl eller en anden SRV-prioritet, -vægt eller -port betragtes som en ændring; alt andet er en tilføjelse eller en sletning.
Apply kører i én transaktion: først sletninger, så ændringer, så nye poster, så en CNAME kan erstatte en A-post i samme fil. Hvis én post afvises, ændres intet. Hvis nogen ændrer zonen mellem plan og apply, afvises apply, og De skal lave en ny plan.
Poster, som NameOcean selv administrerer – adressen bag en HTTP-omdirigering og ACME-udfordringerne til SSL – bliver aldrig eksporteret, planlagt eller slettet.
Opret en API-nøgle med dns:write (eller kun dns:read til et job, der kun planlægger), og gem den som secret'en NAMEOCEAN_API_KEY.
name: dns
on:
pull_request: {paths: [dns.yaml]}
push: {branches: [main], paths: [dns.yaml]}
jobs:
dns:
runs-on: ubuntu-latest
env:
NAMEOCEAN_API_KEY: ${{ secrets.NAMEOCEAN_API_KEY }}
steps:
- uses: actions/checkout@v4
- run: curl -fsSL https://nameocean.net/install.sh | sh
- run: nameocean dns plan -f dns.yaml
- if: github.event_name == 'push'
run: nameocean dns apply -f dns.yaml --yes
dns plan --detailed-exitcode afslutter med 2, når der er ændringer – til jobs, der kun skal rapportere afvigelser.
| GET /dns/{zone}/export?output=yaml | Zonen som fil (JSON uden output=yaml); headeren X-Zone-Serial er dens serienummer |
| POST /dns/{zone}/plan | Hvad apply ville gøre; ændrer intet og kræver kun dns:read |
| POST /dns/{zone}/apply?serial=N | Få zonen til at matche filen; 409 zone_changed, hvis den ikke længere har planens serienummer |
$ curl -X POST https://nameocean.net/api/v1/dns/example.com/plan \ -H "Authorization: Bearer $NAMEOCEAN_API_KEY" \ -H "Content-Type: application/yaml" --data-binary @dns.yaml
Send YAML med Content-Type: application/yaml eller det samme dokument som JSON. En fil, som serveren ikke kan acceptere, besvares med 400 invalid_zone_file og en errors-liste, der angiver hver post og hvert felt. Det hele står i API-referencen.
Via MCP kan en assistent eksportere en zone, planlægge en ændring af mange records på én gang med plan_dns_zone og, efter at have vist dig planen, anvende den med apply_dns_zone.