Ubuntu Manpages

NAMN

dnsmasq [OPTION]...

dnsmasq är en lättviktig DNS-, TFTP-, PXE-, routerannonserings- och DHCP-server. Den är avsedd att tillhandahålla kopplade DNS- och DHCP-tjänster till ett LAN.

Dnsmasq accepterar DNS-förfrågningar och svarar antingen på dem från en liten, lokal cache eller vidarebefordrar dem till en riktig, rekursiv DNS-server. Den laddar in innehållet i /etc/hosts så att lokala värdnamn som inte finns i den globala DNS kan lösas och svarar också på DNS-förfrågningar för DHCP-konfigurerade värdar. Den kan också fungera som auktoritativ DNS-server för en eller flera domäner, vilket gör att lokala namn kan visas i den globala DNS. Den kan konfigureras för att utföra DNSSEC-validering

DHCP-servern dnsmasq stöder statiska adress tilldelningar och flera nätverk. Den skickar automatiskt en rimlig standarduppsättning DHCP-alternativ och kan konfigureras för att skicka valfri uppsättning DHCP-alternativ, inklusive leverantörskapselade alternativ. Den inkluderar en säker, skrivskyddad TFTP-server för att möjliggöra nät-/PXE-start av DHCP-värdar och stöder även BOOTP. PXE-stödet är fullt utrustat och inkluderar ett proxyläge som tillhandahåller PXE-information till klienter medan DHCP-adressallokering utförs av en annan server.

DHCPv6-servern i dnsmasq tillhandahåller samma uppsättning funktioner som DHCPv4-servern och inkluderar dessutom routerannonser och en smidig funktion som möjliggör namngivning för klienter som använder DHCPv4 och stateless autoconfiguration endast för IPv6-konfiguration. Det finns stöd för adressallokering (både DHCPv6 och RA) från subnät som delegeras dynamiskt via DHCPv6-prefixdelegering.

Dnsmasq är kodat med små inbyggda system i åtanke. Det syftar till att uppnå minsta möjliga minnesavtryck som är kompatibelt med de funktioner som stöds, och gör det möjligt att utelämna onödiga funktioner från den kompilerade binären.

Observera att i allmänhet är saknade parametrar tillåtna och stänger av funktioner, till exempel inaktiverar ”--pid-file” skrivning av en PID-fil. På BSD, om inte GNU getopt-biblioteket är länkat, fungerar inte den långa formen av alternativen på kommandoraden; den känns fortfarande igen i konfigurationsfilen.

Läs och syntaxkontrollera konfigurationsfiler. Avsluta med kod 0 om allt är OK, eller en kod som inte är noll i annat fall. Starta inte dnsmasq.
Visa alla kommandoradsalternativ. --help dhcp visar kända DHCPv4-konfigurationsalternativ, och --help dhcp6 visar DHCPv6-alternativ.
Läs inte värdnamnen i /etc/hosts.
Ytterligare värdfiler. Läs den angivna filen samt /etc/hosts. Om --no-hosts anges, läs endast den angivna filen. Detta alternativ kan upprepas för mer än en ytterligare värdfil. Om en katalog anges, läs alla filer i den katalogen i alfabetisk ordning.
Läs alla värdfiler som finns i katalogen. Nya eller ändrade filer läses automatiskt och modifierade och raderade filer har borttagna poster som raderas automatiskt.
Lägg till domänen till enkla namn (utan punkt) i /etc/hosts på samma sätt som för DHCP-härledda namn. Observera att detta inte gäller domännamn i cnames, PTR-poster, TXT-poster etc.
När dnsmasq svarar med information från /etc/hosts eller konfigurationen eller DHCP-leasingfilen ställer den som standard in fältet time-to-live till noll, vilket innebär att den som begär informationen inte själv ska cacha informationen. Detta är det rätta att göra i nästan alla situationer. Med detta alternativ kan en time-to-live (i sekunder) anges för dessa svar. Detta minskar belastningen på servern, men innebär att klienterna under vissa omständigheter använder inaktuella data.
Samma som --local-ttl, men påverkar endast svar med information från DHCP-leasingavtal. Om båda anges gäller --dhcp-ttl för DHCP-information och --local-ttl för övrig information. Om detta sätts till noll elimineras effekten av --local-ttl för DHCP.
Negativa svar från uppströms servrar innehåller normalt information om livslängd i SOA-poster som dnsmasq använder för caching. Om svaren från uppströms servrar utelämnar denna information, cachelagrar dnsmasq inte svaret. Detta alternativ ger ett standardvärde för livslängd (i sekunder) som dnsmasq använder för att cachelagra negativa svar även i avsaknad av en SOA-post.
Ställ in ett maximalt TTL-värde som kommer att delas ut till klienter. Det angivna maximala TTL-värdet kommer att ges till klienter istället för det verkliga TTL-värdet om det är lägre. Det verkliga TTL-värdet behålls dock i cachen för att undvika att uppströms DNS-servrarna översvämmas.
Ställ in ett maximalt TTL-värde för poster i cachen.
Förläng korta TTL-värden till den tid som anges när de cachelagras. Observera att det i allmänhet är en dålig idé att artificiellt förlänga TTL-värden. Gör det inte om du inte har en god anledning och förstår vad du gör.

Dnsmasq begränsar värdet för detta alternativ till en timme, om det inte kompileras om.

Ställ in TTL-värdet som returneras i svar från den auktoritära servern.
Under normala omständigheter förlitar sig dnsmasq på DNS-klienter för att göra omförsök; det genererar inte timeouts själv. Om du ställer in detta alternativ instrueras dnsmasq att generera sina egna omförsök med start efter en fördröjning som standard är 1000 ms. Om den andra parametern anges styr detta hur länge omförsöken ska fortsätta annars är standardvärdet 10000 ms. Försöken upprepas med exponentiell backoff. Användning av detta alternativ ökar minnesanvändningen och nätverksbandbredden. Om inget annat konfigurerats aktiveras detta alternativ med standardparametrarna när --dnssec är inställt.
Gå inte in i bakgrunden vid start, men kör annars som vanligt. Detta är avsett att användas när dnsmasq körs under daemontools eller launchd.
Felsökningsläge: förgrena inte till bakgrunden, skriv inte en pid-fil, ändra inte användar-id, generera en komplett cache-dump vid mottagande av SIGUSR1, logga till stderr samt syslog, inte förgrena nya processer för att hantera TCP-förfrågningar. Observera att detta alternativ endast är avsett för felsökning.
För att stoppa dnsmasq från att köras som daemon i produktion, använd --keep-in-foreground.
Logga resultaten av DNS-frågor som hanteras av dnsmasq. Aktivera en fullständig cache-dump vid mottagande av SIGUSR1. Om argumentet ”extra” anges, dvs. --log-queries=extra,
innehåller loggen extra information i början av varje rad. Denna består av ett serienummer som kopplar samman loggraderna som är associerade med en enskild förfrågan och IP-adressen för den som gör förfrågan. Om argumentet ”proto” anges, visar detta allt som ”extra” gör och även det nätverksprotokoll som används för att kommunicera förfrågningarna. Loggning av endast förfrågningar till den auktoritära servern kan konfigureras med --log-queries=auth
-8, --log-facility=<facility>
Ställ in den funktion som dnsmasq ska skicka syslog-poster till, detta är som standard DAEMON och LOCAL0 när felsökningsläget är aktiverat. Om den angivna funktionen innehåller minst ett ’/’-tecken, tolkas det som ett filnamn och dnsmasq loggar till den angivna filen istället för syslog. Om funktionen är ’-’ loggar dnsmasq till stderr. (Fel vid läsning av konfigurationen kommer fortfarande att skickas till syslog, men all utdata från en lyckad start och all utdata under körning kommer att skickas exklusivt till filen.) Vid loggning till en fil stänger dnsmasq och öppnar om filen när den tar emot SIGUSR2. Detta gör det möjligt att rotera loggfilen utan att stoppa dnsmasq.
Aktivera extra loggning avsedd för felsökning snarare än information.
Aktivera asynkron loggning och ställ valfritt in gränsen för antalet rader som kommer att köas av dnsmasq när skrivningen till syslog är långsam.

Dnsmasq kan logga asynkront: detta gör att det kan fortsätta fungera utan att blockeras av syslog, och gör att syslog kan använda dnsmasq för DNS-frågor utan risk för deadlock. Om kön med logglinjer blir full kommer dnsmasq att logga överflödet och antalet förlorade meddelanden. Standardlängden på kön är 5, ett rimligt värde är 5-25, och en maximal gräns på 100 är inställd.

Ange en alternativ sökväg för dnsmasq att spara sitt process-id i. Normalt är det /var/run/dnsmasq.pid.
Ange det användar-id som dnsmasq kommer att byta till efter start. Dnsmasq måste normalt startas som root, men det kommer att släppa root-privilegierna efter start genom att byta id till en annan användare. Normalt är denna användare ”nobody”, men det kan åsidosättas med denna switch.
Ange den grupp som dnsmasq ska köras som. Standard är ”dip”, om tillgängligt, för att underlätta åtkomst till /etc/ppp/resolv.conf som normalt inte är läsbar för alla.
Skriv ut versionsnumret.
Lyssna på <port> istället för standard-DNS-porten (53). Om du ställer in detta till noll inaktiveras DNS-funktionen helt, och endast DHCP och/eller TFTP finns kvar.
Ange det största EDNS.0 UDP-paketet som stöds av DNS forwarder. Standardvärdet är 1232, vilket är den rekommenderade storleken efter DNS flag day 2020. Öka endast om du vet vad du gör.
Skicka utgående DNS-förfrågningar från och lyssna efter svar på den specifika UDP-porten <query_port> istället för att använda slumpmässiga portar. OBSERVERA att användning av detta alternativ gör dnsmasq mindre säkert mot DNS spoofing-attacker, men det kan vara snabbare och använda mindre resurser. Om du ställer in detta alternativ på noll använder dnsmasq en enda port som tilldelats det av operativsystemet: detta var standardbeteendet i versioner före 2.43.
Som standard använder dnsmasq en enda slumpmässig port för alla försök/omförsök när en förfrågan skickas via slumpmässiga portar till flera uppströms servrar eller när en förfrågan försöks igen. Detta alternativ gör det möjligt att använda ett större antal portar, vilket kan öka robustheten i vissa nätverkskonfigurationer. Observera att om du ökar detta till mer än två eller tre kan det få konsekvenser för säkerheten och resurserna och bör endast göras med förståelse för dessa.
Använd inte portar som är mindre än den som anges som källa för utgående DNS -frågor. Dnsmasq väljer slumpmässiga portar som källa för utgående frågor: när detta alternativ anges kommer de portar som används alltid att vara större än den angivna. Användbart för system bakom brandväggar. Om det inte anges är standardvärdet 1024.
Använd portar som är lägre än den angivna som källa för utgående DNS-frågor. Dnsmasq väljer slumpmässiga portar som källa för utgående frågor: när detta alternativ anges kommer de portar som används alltid att vara lägre än den angivna. Användbart för system bakom brandväggar.
Lyssna endast på angivna gränssnitt. Dnsmasq lägger automatiskt till loopback-gränssnittet (lokalt) till listan över gränssnitt som ska användas när alternativet --interface används. Om inga --interface eller --listen-address alternativ anges lyssnar dnsmasq på alla tillgängliga gränssnitt utom de som anges i --except-interface alternativ. På Linux, när I Linux, när --bind-interfaces eller --bind-dynamic är aktiva, kontrolleras IP-aliasgränssnittsetiketter (t.ex. ”eth1:0”) istället för gränssnittsnamn. I det degenererade fallet när ett gränssnitt har en adress blir resultatet detsamma, men när ett gränssnitt har flera adresser möjliggör det kontroll över vilka av dessa adresser som accepteras. Samma effekt kan uppnås i standardläget genom att använda --listen-address. Ett enkelt jokertecken, bestående av ett efterföljande ’*’, kan användas i --interface och --except-interface alternativen.
Lyssna inte på det angivna gränssnittet. Observera att ordningen på --listen-address --interface och --except-interface inte spelar någon roll och att --except-interface alltid har företräde framför de andra. Kommentarerna om gränssnittsetiketter för --listen-address gäller även här.
Aktivera DNS-auktoritativt läge för frågor som anländer till ett gränssnitt eller en adress. Observera att gränssnittet eller adressen inte behöver nämnas i --interface eller --listen-address konfigurationen, eftersom --auth-server kommer att åsidosätta dessa och tillhandahålla en annan DNS-tjänst på det angivna gränssnittet. <domänen> är ”klisterposten” . Den bör i den globala DNS-tjänsten omvandlas till en A- och/eller AAAA-post som pekar på den adress som dnsmasq lyssnar på. När ett gränssnitt anges kan det kvalificeras med ”/4” eller ”/6” för att endast ange IPv4- eller IPv6- adresser som är associerade med gränssnittet. Eftersom alla definierade auktoritativa zoner också är tillgängliga som en del av den normala rekursiva DNS-tjänsten som tillhandahålls av dnsmasq, kan det vara meningsfullt att ha en --auth-server-deklaration utan gränssnitt eller adress, utan att bara ange den primära externa namnservraren.
Utan parameter eller med nätparametern begränsar tjänsten till anslutna nätverk. Acceptera endast DNS-förfrågningar från värdar vars adress finns i ett lokalt subnät, dvs. ett subnät för vilket det finns ett gränssnitt på servern. Med parametern host lyssnar den endast på lo-gränssnittet och accepterar endast förfrågningar från localhost. Detta alternativ har endast effekt om det inte finns några --interface-, --except-interface-, --listen-address eller --auth-server. Det är avsett att ställas in som standard vid installation, för att tillåta okonfigurerade installationer att vara användbara men också säkra från att användas för DNS-förstärkningsattacker.
-2, --no-dhcp-interface=<gränssnittsnamn>
Tillhandahåll inte DHCP, TFTP eller routerannonsering på det angivna gränssnittet, men tillhandahåll DNS-tjänst.
Inaktivera endast IPv4 DHCP på det angivna gränssnittet.
Inaktivera IPv6 DHCP och routerannonsering på det angivna gränssnittet.
Lyssna på angivna IP-adresser. Både --interface och --listen-address kan anges, i vilket fall både gränssnitt och adresser används. Observera att om inget --interface anges, men --listen-address anges, kommer dnsmasq inte automatiskt att lyssna på loopback-gränssnittet.
För att uppnå detta måste dess IP-adress, 127.0.0.1, uttryckligen anges som ett --listen-address alternativ.
På system som stöder det binder dnsmasq vildkortsadressen, även när den endast lyssnar på vissa gränssnitt. Den kasserar då förfrågningar som den inte ska svara på. Detta har fördelen att fungera även när gränssnitt kommer och går och byter adress. Detta alternativ tvingar dnsmasq att verkligen binda endast de gränssnitt som det lyssnar på. Det enda tillfället då detta är användbart är när man kör en annan namnservrar (eller en annan instans av dnsmasq) på samma maskin. Att ställa in detta alternativ möjliggör också flera instanser av dnsmasq som tillhandahåller DHCP-tjänst att köras på samma maskin.
Aktivera ett nätverksläge som är en hybrid mellan --bind-interfaces och standardläget. Dnsmasq binder adressen för enskilda gränssnitt, vilket tillåter flera dnsmasq-instanser, men om nya gränssnitt eller adresser dyker upp lyssnar den automatiskt på dessa (med förbehåll för eventuell åtkomstkontrollkonfiguration). Detta gör att dynamiskt skapade gränssnitt fungerar på samma sätt som standard. Implementering av detta alternativ kräver icke-standardiserade nätverks-API:er och är endast tillgängligt under Linux. På andra plattformar faller det tillbaka till --bind-interfaces-läget.
Returnera svar på DNS-frågor från /etc/hosts och --interface-name och --dynamic-host som beror på det gränssnitt över vilket frågan mottogs.
Om ett namn har mer än en adress associerad med sig, och minst en av dessa adresser finns på samma subnät som gränssnittet till vilket frågan skickades, returnera då endast adressen (es) på det subnätet och returnera alla tillgängliga adresser i annat fall. Detta gör det möjligt för en server att ha flera adresser i /etc/hosts som motsvarar vart och ett av dess gränssnitt, och värdar får rätt adress baserat på vilket nätverk de är anslutna till. För närvarande är denna funktion begränsad till IPv4.
Falska privata omvända sökningar. Alla omvända sökningar för privata IP-intervall (dvs. 192.168.x.x, etc) som inte finns i /etc/hosts eller DHCP-leasingfilen besvaras med ”no such domain” istället för att vidarebefordras uppströms. Den uppsättning prefix som påverkas är listan som anges i RFC6303, för IPv4 och IPv6. Om du aktiverar detta ändras också DNSSEC-valideringen för omvända sökningar i de privata intervallen så att en icke-säker DS-post accepteras som bevis på att intervallet inte är signerat. Detta kringgår beteendet hos de offentliga DNS-tjänsterna som inte verkar returnera validerade bevis på icke-existens för DS-poster i dessa domäner.
Ändra IPv4-adresser som returneras från uppströmsnamnservrar; old-ip ersätts med new-ip. Om den valfria masken anges kommer alla adresser som matchar den maskerade old-ip att skrivas om. Så, till exempel --alias=1.2.3.0, 6.7.8.0,255.255.255.0 kommer att mappa 1.2.3.56 till 6.7.8.56 och 1.2.3.67 till 6.7.8.67. Detta är vad Cisco PIX-routrar kallar ”DNS doctoring”. Om den gamla IP-adressen anges som intervall, skrivs endast adresser inom intervallet om, istället för hela subnätet
Så --alias=192.168.0.10-192.168.0.40,10.0.0.0,255.255.255.0 mappar 192.168.0.10->192.168.0.40 till 10.0.0.10->10.0.0.40
Omvandlar svar som innehåller den angivna adressen eller subnätet till svar av typen ”No such domain”. IPv4 och IPv6 stöds. Detta är avsett att motverka ett bedrägligt drag som Verisign i september 2003 när de började returnera adressen till en reklamwebbsida som svar på förfrågningar om oregistrerade namn, istället för det korrekta NXDOMAIN-svaret. Detta alternativ säger åt dnsmasq att förfalska det korrekta svaret när det ser detta beteende. I september 2003 var IP-adressen som returnerades av Verisign 64.94.110.11
Ignorera svar på A- eller AAAA-frågor som innehåller den angivna adressen eller subnätet. Inget fel genereras, dnsmasq fortsätter helt enkelt att lyssna efter ett annat svar. Detta är användbart för att motverka blockeringsstrategier som bygger på att snabbt leverera ett förfalskat svar på en DNS-förfrågan för en viss domän, innan det korrekta svaret hinner komma fram.
Senare versioner av Windows gör periodiska DNS-förfrågningar som inte får meningsfulla svar från den offentliga DNS och kan orsaka problem genom att utlösa dial-on-demand-länkar. Denna flagga aktiverar ett alternativ för att filtrera sådana förfrågningar. De förfrågningar som blockeras är för poster av typen ANY där det begärda namnet har understreck, för att fånga LDAP-förfrågningar, och för all-poster av typen SOA och SRV.
Ta bort A-poster från svaren. Inga IPv4-adresser kommer att returneras.
Ta bort AAAA-poster från svaren. Inga IPv6-adresser kommer att returneras.
Ta bort poster av den eller de angivna typerna från svaren. Den annars meningslösa --filter-rr=ANY har en speciell betydelse: den filtrerar svar på förfrågningar av typen ANY. Allt annat än A-, AAAA-, MX- och CNAME-poster tas bort. Eftersom ANY-förfrågningar med förfalskade källadresser kan användas i DNS-förstärkningsattacker (svar på ANY-frågor kan vara stora) avväpnar detta sådana attacker, samtidigt som det fortfarande stöder den enda återstående möjliga användningen av ANY-frågor. Se RFC 8482 para 4.3 för detaljer.
Som standard cachar dnsmasq A-, AAAA-, CNAME- och SRV-DNS-posttyper. Detta alternativ lägger till andra posttyper till cachen. RR-typen kan anges som ett namn, t.ex. TXT eller MX, eller som ett decimaltal. Ett enda --cache-rr-alternativ kan ta en kommaseparerad lista med RR-typer och mer än ett --cache -rr-alternativ tillåts. Använd --cache-rr=ANY för att aktivera caching för alla RR-typer.
Läs IP-adresserna för uppströmsnamnserverna från <fil> istället för /etc/resolv.conf. För formatet på denna fil, se resolv.conf(5).

De enda raderna som är relevanta för dnsmasq är namnservrarna. Dnsmasq kan inställas att söka igenom mer än en resolv.conf-fil, det första filnamnet som anges ersätter standardinställningen, efterföljande filer läggs till i listan. Detta är endast tillåtet vid sökning; filen med den senaste ändringstiden används.

Läs inte /etc/resolv.conf. Hämta endast uppströms servrar från kommandoraden eller dnsmasq-konfigurationsfilen.
-1, --enable-dbus[=<service-name>]
Tillåt att dnsmasq-konfigurationen uppdateras via DBus-metodanrop. Den konfiguration som kan ändras är uppströms DNS-servrar (och motsvarande domäner) och cache-rensning. Kräver att dnsmasq har byggts med DBus-stöd. Om tjänstenamnet anges tillhandahåller dnsmasq tjänsten med det namnet, istället för standardnamnet som är uk.org.thekelleys.dnsmasq
Aktivera dnsmasq UBus-gränssnitt. Det skickar meddelanden via UBus om DHCPACK- och DHCPRELEASE-händelser. Dessutom erbjuder det mätvärden och möjliggör konfiguration av Linux-anslutningsspårmärkesbaserad filtrering. När DNS-frågefiltrering baserad på Linux-anslutningsspårmärken är aktiverad genereras UBus-meddelanden för varje löst eller filtrerat DNS-fråge. Kräver att dnsmasq har byggts med UBus-stöd. Om tjänsten namn anges, tillhandahåller dnsmasq tjänsten vid det namnområdet, istället för standardvärdet som är dnsmasq
Som standard skickar dnsmasq förfrågningar till alla uppströms servrar som den känner till och försöker prioritera servrar som är kända för att vara uppe. Om du ställer in denna flagga tvingas dnsmasq att prova varje förfrågan med varje server strikt i den ordning de visas i /etc/resolv.conf
Som standard, när dnsmasq har mer än en uppströms server tillgänglig, skickar den frågor till endast en server. Om du ställer in denna flagga tvingas dnsmasq att skicka alla frågor till alla tillgängliga servrar. Svaret från den server som svarar först returneras till den ursprungliga frågeställaren.
Aktivera kod för att upptäcka DNS-vidarebefordringsloopar, dvs. situationer där en förfrågan som skickas till en av uppströms-servrarna så småningom returneras som en ny förfrågan till dnsmasq-instansen. Processen fungerar genom att generera TXT-förfrågningar av formen <hex>.test och skicka dem till varje uppströms server. Hex är ett UID som kodar instansen av dnsmasq som skickar frågan och den uppströms server som den skickades till. Om frågan returneras till den server som skickade den, inaktiveras den uppströms server genom vilken den skickades och denna händelse loggas. Varje gång uppsättningen uppströms servrar ändras, körs testet igen på alla, inklusive de som tidigare inaktiverats.
Avvisa (och logga) adresser från uppströmsnamnservrar som finns i de privata intervallen. Detta blockerar en attack där en webbläsare bakom en brandvägg används för att undersöka maskiner i det lokala nätverket. För IPv6 täcker det privata intervallet IPv4-mappade adresser i privat utrymme plus alla länklokala (LL) och webbplatslokala (ULA) adresser.
Undanta 127.0.0.0/8 och ::1 från ombindningskontroller. Detta adressintervall returneras av realtids-black hole-servrar, så att blockera det kan inaktivera dessa tjänster.
Detektera och blockera inte dns-rebind vid förfrågningar till dessa domäner. Argumentet kan vara antingen en enda domän eller flera domäner omgivna av ’/’, som i syntaxen --server, t.ex. --rebind-domain-ok=/domain1/domain2/domain3/
Sök inte efter ändringar i /etc/resolv.conf.
När /etc/resolv.conf läses om eller uppströms servrarna ställs in via DBus, rensa DNS-cachen. Detta är användbart när nya namnservrar kan ha annan data än den som finns i cachen.
Säger åt dnsmasq att aldrig vidarebefordra A- eller AAAA-förfrågningar för vanliga namn, utan punkter eller domändelar, till uppströms namnservrar. Om namnet inte är känt från /etc/hosts eller DHCP returneras ett ”not found”-svar.
Ange uppströms servrar direkt. Att ställa in denna flagga undertrycker inte läsningen av /etc/resolv.conf, använd --no-resolv för att göra det. Om en eller flera valfria domäner anges, används den servern endast för dessa domäner och de frågas endast med hjälp av den angivna servern. Detta är avsett för privata namnservrar: om du har en namnservrar på ditt nätverk som hanterar namn av formen xxx.internal.thekelleys.org.uk på 192.168.1.1 och anger flaggan --server=/internal.thekelleys.org.uk/192.168.1.1 kommer alla förfrågningar för interna maskiner att skickas till den namnservraren, allt annat går till servrarna i /etc/resolv.conf. En tom domänspecifikation, // har den speciella betydelsen ”endast okvalificerade namn”, dvs. namn utan några punkter i sig. En icke-standardport kan anges som del av IP-adressen med hjälp av tecknet #. Mer än en --server-flagga är tillåten, med upprepade domän- eller ipaddr-delar efter behov.

Mer specifika domäner har företräde framför mindre specifika domäner, så: --server=/google.com/1.2.3.4 --server=/www.google.com/2.3.4.5 kommer att skicka förfrågningar för google.com och gmail.google.com till 1.2.3.4, men www.google.com kommer att skickas till 2.3.4.5

Matchning av domäner görs normalt på kompletta etiketter, så /google.com/ matchar google.com och www.google.com men INTE supergoogle.com. Detta kan åsidosättas med ett * endast i början av ett mönster: /*google.com/ matchar google.com och www.google.com OCH supergoogle.com. Formen utan jokertecken har prioritet, så om både /google.com/ och /*google.com/ anges kommer google.com och www.google.com att matcha /google.com/ och / *google.com/ matchar endast supergoogle.com.

Av historiska skäl är mönstret /.google.com/ likvärdigt med /google.com/. Om du vill matcha alla underdomäner till google.com men INTE google.com själv, använd /*.google.com/.

Den speciella serveradressen ’#’ betyder ”använd standardservrarna”, så --server=/google.com/1.2.3.4 --server=/www.google.com/# kommer att skicka förfrågningar för google.com och dess underdomäner till 1.2.3.4, förutom www.google.com (och dess underdomäner) som kommer att vidarebefordras som vanligt.

Det är också tillåtet att använda flaggan -S som anger en domän men ingen IP-adress. Detta talar om för dnsmasq att domänen är lokal och att den kan svara på förfrågningar från /etc/hosts eller DHCP men aldrig vidarebefordra förfrågningar på den domänen till någon uppströms server. --local är en synonym för --server för att göra konfigurationsfilerna tydligare i detta fall.

IPv6-adresser kan inkludera ett %interface scope-id, t.ex. fe80::202:a412:4512:7bbf%eth0.

Den valfria strängen efter @-tecknet talar om för dnsmasq hur källan för frågorna till denna namnservrar ska ställas in. Det kan antingen vara en ip-adress, ett gränssnittsnamn eller båda. Ip-adressen bör tillhöra den maskin på vilken dnsmasq körs, annars kommer denna serverrad att loggas och sedan ignoreras. Om ett gränssnittsnamn anges kommer förfrågningar till servern att tvingas via det gränssnittet; om en IP-adress anges kommer källadressen för förfrågningarna att ställas in till den adressen; och om båda anges kommer en kombination av IP-adress och gränssnittsnamn att användas för att styra förfrågningar till servern. Flaggan query-port ignoreras för alla servrar som har en källadress angiven, men porten kan anges direkt som del av källadressen. Att tvinga förfrågningar till ett gränssnitt är inte implementerat på alla plattformar som stöds av dnsmasq.

Uppströms servrar kan anges med ett värdnamn istället för en IP-adress. I detta fall kommer dnsmasq att försöka använda systemets resolver för att hämta IP-adressen till en server under uppstart. Om namnuppslagningen misslyckas misslyckas även starten av dnsmasq. Om systemets konfiguration är sådan att systemets resolver skickar DNS-frågor via dnsmasq-instansen som startar, kommer detta att timeout och misslyckas.

Detta är funktionellt samma sak som --server, men ger lite syntaktisk socker för att göra det enklare att ange adress-till-namn-frågor. Till exempel --rev-server=1.2.3.0/24,192.168.0.1 är exakt likvärdigt med --server=/3.2.1.in-addr.arpa/192.168.0.1 Tillåtna prefixlängder är 1-32 (IPv4) och 1-128 (IPv6). Om prefixlängden utelämnas ersätter dnsmasq antingen 32 (IPv4) eller 128 (IPv6).
Ange en IP-adress som ska returneras för alla värdar i de angivna domänerna. A- (eller AAAA-)frågor i domänerna vidarebefordras aldrig och besvaras alltid med den angivna IP-adressen, som kan vara IPv4 eller IPv6. För att ange flera adresser eller både IPv4- och IPv6-adresser för en domän, använd upprepade --address-flaggor. Observera att /etc/hosts och DHCP-leasingavtal åsidosätter detta för enskilda namn. En vanlig användning av detta är att omdirigera hela domänen doubleclick.net till någon vänlig lokal webbserver för att undvika bannerannonser. Domänspecifikationen fungerar på samma sätt som för --server, med den extra funktionen att /#/ matchar alla domäner. Således --address=/#/1.2.3.4 alltid returnera 1.2.3.4 för alla frågor som inte besvaras från /etc/hosts eller DHCP och som inte skickas till en uppströms namnservrar av ett mer specifikt --server-direktiv. När det gäller --server returnerar en eller flera domäner utan adress ett svar om att domänen inte finns, så --address=/example.com/ motsvarar --server=/example.com/ och returnerar NXDOMAIN för example.com och alla dess underdomäner. En adress som anges som ’#’ översätts till NULL-adressen 0.0.0.0 och dess IPv6-motsvarighet ::, så --address=/example.com/# returnerar NULL-adresser för example.com och dess underdomäner. Detta är delvis syntaktiskt socker för --address=/example.com/0.0.0.0 och --address=/example.com/:: men är också effektivare än att inkludera båda som separata konfigurationsrader. Observera att NULL-adresser normalt fungerar på samma sätt som localhost, så var medveten om att klienter som söker efter dessa namn sannolikt kommer att kommunicera med sig själva.

Observera att beteendet för frågor som inte matchar den angivna adresslitteralen ändrades i version 2.86. Tidigare versioner, konfigurerade med (t.ex.) --address=/example.com/1.2.3.4 och sedan frågade efter en annan RR-typ än A, skulle returnera ett NoData-svar. Från 2.86 skickas frågan uppströms. För att återställa beteendet före 2.86, använd konfigurationen --address=/example.com/1.2.3.4 --local=/example.com/

Placerar de upplösta IP-adresserna för förfrågningar för en eller flera domäner i den angivna Netfilter IP-uppsättningen. Om flera uppsättningsnamn anges placeras adresserna i var och en av dem, med förbehåll för begränsningarna i en IP-uppsättning (IPv4-adresser kan inte lagras i en IPv6-IP-uppsättning och vice versa). Domäner och underdomäner matchas på samma sätt som --address. Dessa IP-uppsättningar måste redan existera. Se ipset(8) för mer information.
Liknar alternativet --ipset, men accepterar en eller flera nftables -uppsättningar att lägga till IP-adresser i. Dessa uppsättningar måste redan existera. Se nft(8) för mer information. Familjen, tabellen och uppsättningen skickas direkt till nft. Om specifikationen börjar med 4# eller 6# läggs endast A- respektive AAAA-poster till i uppsättningen. Eftersom en nftset endast kan innehålla IPv4- eller IPv6-adresser undviks fel som loggas för adresser av fel typ.
Aktiverar filtrering av inkommande DNS-förfrågningar med associerade Linux-anslutningsspårmärken enligt individuella tillåtna listor som konfigurerats via en serie --connmark-allowlist -alternativ. Otillåtna förfrågningar vidarebefordras inte; de avvisas med felkoden REFUSED. DNS-frågor tillåts endast om de inte har en associerad Linux-anslutningsspårningsmarkering eller om de frågade domänerna matchar de konfigurerade DNS-mönstren för den associerade Linux-anslutningsspårningsmarkeringen. Om ingen tillåtelselista är konfigurerad för en Linux-anslutningsspårningsmarkering avvisas alla DNS-frågor som är associerade med den markeringen. Om en mask anges, bitvis AND-kopplas Linux-anslutningsspårningsmarkeringar med den angivna masken innan de bearbetas.
Konfigurerar de DNS-mönster som är tillåtna i DNS-förfrågningar associerade med den angivna Linux-anslutningsspårmärkningen. Om en mask anges, AND-kopplas Linux-anslutningsspårmärkningar först bitvis med den angivna masken innan de jämförs med den angivna anslutningsspårmärkningen. Mönstren följer syntaxen för DNS-namn, men tillåter dessutom att jokertecknet ”*” används upp till två gånger per etikett för att matcha 0 eller fler tecken inom den etiketten. Observera att jokertecknet aldrig matchar en punkt (t.ex. ”*.example.com” matchar ”api.example.com” men inte ”api.us.example.com”). Mönster måste vara fullständigt kvalificerade, dvs. bestå av minst två etiketter. Den sista etiketten får inte vara helt numerisk och får inte vara den ”lokala” pseudo-TLD. Ett mönster måste sluta med minst två bokstavliga (icke-jokertecken) etiketter. Istället för ett mönster kan ”*” anges för att inaktivera filtrering av tillåtelselistan för ett givet Linux-anslutningsspårmärke helt.
Returnera en MX-post med namnet <mx name> som pekar på det angivna värdnamnet (om angivet), eller den värd som anges i --mx-target-omkopplaren eller, om den omkopplaren inte anges, den värd på vilken dnsmasq körs. Standardinställningen är användbar för att dirigera e-post från system på ett LAN till en central server. Preferensvärdet är valfritt och är som standard 1 om det inte anges. Mer än en MX-post kan anges för en värd.
Ange standardmålet för MX-posten som returneras av dnsmasq. Se --mx-host. Om --mx-target anges, men inte --mx-host, returnerar dnsmasq en MX-post som innehåller MX-målet för MX-frågor på värdnamnet för den maskin där dnsmasq körs.
Returnera en MX-post som pekar på sig själv för varje lokal maskin. Lokala maskiner är de som finns i /etc/hosts eller med DHCP-leasingavtal.
Returnera en MX-post som pekar på värden som anges av --mx-target (eller den maskin där dnsmasq körs) för varje lokal maskin. Lokala maskiner är de som finns i /etc/hosts eller med DHCP -leasingavtal.
Returnera en SRV DNS-post. Se RFC2782 för mer information. Om inte angivet, är domänen som standard den som anges av --domain. Standardvärdet för måldomänen är tomt, standardvärdet för port är ett och standardvärdena för vikt och prioritet är noll. Var försiktig om du överför data från BIND zonfiler: port-, vikt- och prioritetsnumren är i en annan ordning. Mer än en SRV-post för en given tjänst/domän är tillåten, alla som matchar returneras.
Lägg till A-, AAAA- och PTR-poster till DNS. Detta lägger till ett eller flera namn till DNS med tillhörande IPv4- (A) och IPv6- (AAAA) poster. Ett namn kan förekomma i mer än en --host-record och därför tilldelas mer än en adress. Endast den första adressen skapar en PTR-post som länkar adressen till namnet. Detta är samma regel som används vid läsning av hosts-filer.

--host-record -alternativ anses läsas före värdfiler, så ett namn som visas där hindrar skapandet av PTR-poster om det också visas i värdfilen. Till skillnad från värdfiler expanderas inte namn, även när --expand-hosts är aktivt. Korta och långa namn kan visas i samma --host-record, t.ex.

--host-record=laptop,laptop.thekelleys.org,192.168.0.1,1234::100

Om time-to-live anges, åsidosätter det standardvärdet, som är noll eller värdet för --local-ttl. Värdet är ett positivt heltal och anger time-to-live i sekunder.

Lägg till A-, AAAA- och PTR-poster till DNS i samma subnät som det angivna gränssnittet. Adressen härleds från nätverksdelen av varje adress som är associerad med gränssnittet, och värddelsdelen från den angivna adressen. Till exempel --dynamic-host=example.com,0.0.0.8,eth0 kommer, när eth0 har adressen 192.168.78.x och nätmask 255.255.255.0, att ge namnet example.com en A-post för 192.168.78.8. Samma princip gäller för IPv6-adresser. Observera att om ett gränssnitt har mer än en adress kommer mer än en A- eller AAAA-post att skapas. Postaernas TTL är alltid noll, och alla ändringar av gränssnittsadresser kommer omedelbart att återspeglas i dem.
Returnera en TXT DNS-post. Värdet på TXT-posten är en uppsättning strängar, så valfritt antal kan inkluderas, avgränsade med kommatecken; använd citattecken för att infoga kommatecken i en sträng. Observera att den maximala längden på en enskild sträng är 255 tecken, längre strängar delas upp i bitar om 255 tecken.
Returnerar en PTR DNS-post.
Returnerar en NAPTR DNS-post, enligt specifikationen i RFC3403.
Returnerar en CAA DNS-post, enligt specifikationen i RFC6844.
Returnerar en CNAME-post som anger att <cname> egentligen är <target>. Det finns en betydande begränsning för målet; det måste vara en DNS-post som är känd för dnsmasq och INTE en DNS-post som kommer från en uppströms server. Cname måste vara unikt, men det är tillåtet att ha mer än ett cname som pekar på samma mål. Det är det möjligt att deklarera flera cnames till ett mål på en enda rad, så här: --cname=cname1,cname2,target

Om time-to-live anges, åsidosätter det standardvärdet, som är noll eller värdet av --local-ttl. Värdet är ett positivt heltal och anger time-to-live i sekunder.

Returnerar en godtycklig DNS-resurspost. Numret är typen av posten (som alltid är i klassen C_IN). Värdet på posten anges av hexdata, som kan ha formen 01:23:45 eller 01 23 45 eller 012345 eller en kombination av dessa.
Returnerar DNS-poster som associerar namnet med adresserna för det angivna gränssnittet. Denna flagga anger en A- eller AAAA-post för det angivna namnet på samma sätt som en /etc/hosts-rad, förutom att adressen inte är konstant utan hämtas från det angivna gränssnittet. Gränssnittet kan följas av ”/4” eller ”/6” för att ange att endast IPv4- eller IPv6-adresser för gränssnittet ska användas. Om gränssnittet är nere, inte konfigurerat eller inte existerar, returneras en tom post. Den matchande PTR-posten skapas också, vilket mappar gränssnittsadressen till namnet. Mer än ett namn kan associeras med en gränssnitts adress genom att upprepa flaggan; i så fall används den första instansen för omvänd adress-till-namn-mappning. Observera att ett namn som används i --interface-name inte får förekomma i /etc/hosts.
Skapa artificiella A/AAAA- och PTR-poster för ett adressintervall. Posterna är antingen sekventiella nummer eller adressen, med punkter (eller kolon för IPv6) ersatta med bindestreck.

Ett exempel bör göra detta tydligare. Först sekventiella nummer. --synth-domain=thekelleys.org.uk,192.168.0.50,192.168.0.70,internal-* resulterar i namnet internal-0.thekelleys.org.uk. som returnerar 192.168.0.50, internal-1.thekelleys.org.uk som returnerar 192.168.0.51 och så vidare. (notera *) Samma princip gäller för IPv6-adresser (där siffrorna kan vara mycket stora). Omvända sökningar från adress till namn fungerar som förväntat.

För det andra --synth-domain=thekelleys.org.uk,192.168.0.0/24,internal- (utan *) resulterar i en förfrågan om internal-192-168-0-56.thekelleys.org.uk som returnerar 192.168.0.56 och en omvänd förfrågan vice versa. Detsamma gäller för IPv6; representationen använder inte ::-komprimeringsfunktionen eller den speciella representationen av V4-mappade IPv6-adresser, eftersom dessa kan generera olagliga domännamn, så alla domäner har formen internal-1000-0000-0000-0000-0000-0000-0000-0008.example.com

Adressintervallet kan ha formen <startadress>,<slutadress> eller <ip-adress>/<prefixlängd> i båda formerna av alternativet. För IPv6 måste start- och slutadresserna falla inom samma /64-nätverk, eller prefixlängden måste vara större än eller lika med 64, förutom att prefixlängder kortare än 64 endast är tillåtna om icke-sekventiella namn används.

Ange platsen för en fil i pcap-format som dnsmasq använder för att dumpa kopior av nätverkspaket för felsökningsändamål. Om filen finns när dnsmasq startar raderas den inte; nya paket läggs till i slutet. Filen kan vara en namngiven pipe som Wireshark lyssnar på.
Ange vilka typer av paket som ska läggas till i dumpfilen. Argumentet ska vara OR för bitmaskerna för varje typ av paket som ska dumpas: det kan anges i hexadecimal form genom att föregå siffran med 0x på normalt sätt. Varje gång ett paket skrivs till dumpfilen loggar dnsmasq paketsekvensen och masken som representerar dess typ. De aktuella typerna är: 0x0001 - DNS-förfrågningar från klienter, 0x0002 DNS-svar till klienter, 0x0004 - DNS-förfrågningar till uppströms, 0x0008 - DNS-svar från uppströms, 0x0010 - förfrågningar som skickas uppströms för DNSSEC-validering, 0x0020 – svar på förfrågningar för DNSSEC-validering, 0x0040 – svar på klientförfrågningar som misslyckas med DNSSEC-validering, 0x0080 – svar på förfrågningar för DNSSEC-validering som misslyckas med validering, 0x1000 – DHCPv4, 0x2000 – DHCPv6, 0x4000 - Routerannonsering, 0x8000 - TFTP.
Lägg till MAC-adressen för den som gör förfrågan till DNS-förfrågningar som vidarebefordras uppströms. Detta kan användas för DNS-filtrering av uppströms servern. MAC-adressen kan endast läggas till om den som gör förfrågan befinner sig i samma subnät som dnsmasq-servern. Observera att mekanismen som används för att uppnå detta (ett EDNS0-alternativ) ännu inte är standardiserad, så detta bör betraktas som experimentellt. Observera också att exponering av MAC-adresser på detta sätt kan ha konsekvenser för säkerhet och integritet. Varningen om caching som ges för --add-subnet gäller även --add-mac. En alternativ kodning av MAC, som base64, aktiveras genom att lägga till parametern ”base64” och en läsbar kodning av hex-och-kolon aktiveras genom att lägga till ”text”.
Ta bort all MAC-adressinformation som redan finns i nedströmsfrågor innan de vidarebefordras uppströms.
Lägg till en godtycklig identifieringssträng till DNS-frågor som vidarebefordras uppströms.
Lägg till en subnätadress till DNS-frågor som vidarebefordras uppströms. Om en adress anges i flaggan kommer den att användas, annars kommer begärarens adress att användas. Mängden adress som vidarebefordras beror på prefixlängdsparametern: 32 (128 för IPv6) vidarebefordrar hela adressen, noll vidarebefordrar ingen del av den men markerar ändå begäran så att ingen uppströms namnservrar lägger till klient adressinformation heller. Standardvärdet är noll för både IPv4 och IPv6. Observera att uppströms namnservrar kan konfigureras för att returnera olika resultat baserat på denna information, men dnsmasq-cachen tar inte hänsyn till detta. Cachning är därför inaktiverad för sådana svar, såvida inte den subnätadress som läggs till är konstant.

Till exempel --add-subnet=24,96 kommer att lägga till /24- och /96-undernät för IPv4- och IPv6-förfrågare. --add-subnet=1.2.3.4/24 kommer att lägga till 1.2.3.0/24 för IPv4-förfrågare och ::/0 för IPv6-förfrågare. --add-subnet=1.2.3.4/24,1.2.3.4/24 lägger till 1.2.3.0/24 för både IPv4- och IPv6-begärare.

Ta bort alla subnätadresser som redan finns i en nedströmsfråga innan den vidarebefordras uppströms. Om --add-subnet är inställt säkerställer detta också att alla nedströmslevererade subnät ersätts av det som lagts till av dnsmasq. Annars kommer dnsmasq INTE att ersätta ett befintligt subnät i frågan.
Bäddar in begärarens IP-adress i DNS-frågor som vidarebefordras uppströms. Om enhets-id, tillgångs-id eller organisations-id anges, inkluderas informationen i de vidarebefordrade frågorna och kan eventuellt användas i filtreringspolicyer och rapportering. Ordningen på id -attributen är irrelevant, men de måste separeras med kommatecken. Deviceid är ett sexton siffrigt hexadecimalt tal, org- och asset-id är decimaltal.
Ställ in storleken på dnsmasq:s cache. Standardvärdet är 150 namn. Om cacheminnets storlek ställs in på noll inaktiveras cachningen. Obs! Ett stort cacheminne påverkar prestandan.
Inaktivera negativ cachning. Negativ cachning gör det möjligt för dnsmasq att komma ihåg svaren ”ingen sådan domän” från uppströmsnamnserver och svara på identiska frågor utan att vidarebefordra dem igen.
Dnsmasq permuterar normalt ordningen på A- eller AAAA-poster för samma namn vid på varandra följande frågor, för lastbalansering. Detta inaktiverar det beteendet, så att posterna alltid returneras i den ordning de tas emot från uppströms.
Dnsmasq kan kryptera bokstäverna i DNS-frågor som skickas uppströms som en säkerhetsfunktion. Denna teknik kan interagera dåligt med sällsynta trasiga DNS-servrar som inte bevarar bokstäverna i frågan i sitt svar. Första gången ett svar returneras som matchar frågan i alla avseenden utom bokstäverna, loggas en varning. Om detta sammanfaller med att DNS inte fungerar, är det nödvändigt att inaktivera funktionen. I version 2.91 är 0x20-kodning inaktiverad som standard och måste aktiveras med --do-0x20-encode. Standardinställningen kan komma att ändras i framtiden, så för att vara säker på dess status efter en uppgradering, ställ in --do-0x20-encode eller --no-0x20-encode i din konfiguration. --no-0x20-encode åsidosätter --do-x20-encode eller en framtida standardinställning 0x20-encode enable.
När detta är inställt kommer dnsmasq att returnera data ändå om ett DNS-namn finns i cachen men dess livslängd har gått ut. (Det försöker uppdatera data med en uppströmsfråga efter att ha returnerat den inaktuella datan.) Detta kan förbättra hastigheten och tillförlitligheten. Det sker på bekostnad av att ibland returnera föråldrade data och mindre effektiv cacheanvändning, eftersom gamla data inte kan rensas när dess TTL löper ut, så cachen blir mestadels minst nyligen använd. För att mildra problem orsakade av massivt föråldrade DNS-svar kan den maximala åldern för cachade poster anges i sekunder (standardinställningen är att inte servera något äldre än en dag). Om TTL-övertiden ställs in på noll kommer föråldrade cachade data att serveras oavsett hur länge de har gått ut.
-0, --dns-forward-max=<frågor>
Ställ in det maximala antalet samtidiga DNS-frågor. Standardvärdet är 150, vilket bör fungera bra för de flesta installationer. Den enda kända situationen där detta behöver ökas är när man använder webbserverloggfilsresolvers ,
som kan generera ett stort antal samtidiga förfrågningar. Denna parameter styr faktiskt antalet samtidiga förfrågningar per servergrupp, där en servergrupp är den uppsättning servrar som är associerade med en enda domän. Så om en domän har sin egen server via --server=/example.com/1.2.3.4 och 1.2.3.4 inte svarar, men frågor för *.example.com inte kan gå någon annanstans, kommer andra frågor inte att påverkas. I konfigurationer med många sådana servergrupper och begränsade resurser kan det vara nödvändigt att minska detta värde.
Validera DNS-svar och cachelagra DNSSEC-data. När DNS-frågor vidarebefordras begär dnsmasq de DNSSEC-poster som behövs för att validera svaren. Svaren valideras och resultatet returneras som den autentiserade databiten i DNS-paketet. Dessutom lagras DNSSEC-posterna i cachen, vilket gör valideringen av klienter mer effektiv. Observera att validering av klienter är det säkraste DNSSEC-läget, men för klienter som inte kan utföra validering är det användbart att använda AD-biten som ställs in av dnsmasq, förutsatt att nätverket mellan dnsmasq-servern och klienten är betrott. Dnsmasq måste kompileras med HAVE_DNSSEC aktiverat och DNSSEC trust anchors tillhandahållna, se --trust-anchor. Eftersom DNSSEC-valideringsprocessen använder cachen är det inte tillåtet att minska cacheminnets storlek under standardvärdet när DNSSEC är aktiverat. Namnserverna uppströms från dnsmasq måste vara DNSSEC-kompatibla, dvs. kunna returnera DNSSEC-poster med data. Om de inte är det kommer dnsmasq inte att kunna avgöra den betrodda statusen för svaren, vilket innebär att DNS-tjänsten kommer att sluta fungera helt.
Tillhandahåll DS-poster som fungerar som förtroendeankare för DNSSEC -validering. Klassen är som standard IN. Vanligtvis är detta DS-poster för nyckelsigneringsnycklar nycklar (KSK) i rotzonen, men förtroendeankare för begränsade domäner är också möjliga. Ett negativt förtroendeankare (dvs. bevis på att en DS-post inte finns) kan konfigureras genom att ange endast namnet eller endast namnet och klassen. Detta kan vara användbart för att tvinga dnsmasq att behandla zoner som delegerats med --server=/<domän>/<ip-adress> som osignerade. De aktuella rotzonens förtroendeankare kan laddas ner från https://data.iana.org/root-anchors/root-anchors.xml
Som standard kontrollerar dnsmasq att osignerade DNS-svar är legitima: detta medför möjliga extra förfrågningar även för majoriteten av DNS -zoner som för närvarande inte är signerade. Om --dnssec-check-unsigned=no förekommer i konfigurationen, antas sådana svar vara giltiga och vidarebefordras (utan att ”authentic data”-biten är inställd, förstås). Detta skyddar inte mot en angripare som förfalskar osignerade svar för signerade DNS-zoner, men det är snabbt.

Versioner av dnsmasq före 2.80 kontrollerade som standard inte osignerade svar och använde --dnssec-check-unsigned för att aktivera detta. Sådana konfigurationer kommer att fortsätta att fungera som tidigare, men de som använde standardinställningen utan kontroll måste ändras för att uttryckligen välja ingen kontroll. Den nya standardinställningen beror på att det är farligt att inaktivera kontrollen av osignerade svar. Det öppnar inte bara för möjligheten till förfalskade svar, utan gör också att allt verkar fungera även när uppströmsnamnserverna inte stöder DNSSEC, och i detta fall sker ingen DNSSEC-validering alls.

DNSSEC-signaturer är endast giltiga under angivna tidsfönster och bör avvisas utanför dessa fönster. Detta genererar ett intressant hönan-och-ägg-problem för maskiner som inte har en realtidsklocka i hårdvaran. För att dessa maskiner ska kunna bestämma rätt tid krävs vanligtvis användning av NTP och därmed DNS, men för att validera DNS krävs att rätt tid redan är känd. Om denna flagga ställs in tas tidsfönsterkontrollerna bort (men inte andra DNSSEC-valideringar) endast tills dnsmasq-processen tar emot SIGINT. Avsikten är att dnsmasq ska startas med denna flagga när plattformen fastställer att tillförlitlig tid för närvarande inte är tillgänglig. Så snart tillförlitlig tid har fastställts ska ett SIGINT skickas till dnsmasq, vilket aktiverar tidskontroll och rensar cachen för DNS-poster som inte har kontrollerats noggrant.

Tidigare versioner av dnsmasq överbelastade SIGHUP (som läser om mycket av konfigurationen) för att också aktivera tidsvalidering.

Om dnsmasq körs i felsökningsläge (--no-daemon flagga) behåller SIGINT sin vanliga funktion att avsluta dnsmasq-processen.

Aktiverar ett alternativt sätt att kontrollera giltigheten av systemtiden för DNSSEC (se --dnssec-no-timecheck). I detta fall anses systemtiden vara giltig när den blir senare än tidsstämpeln på den angivna filen. Filen skapas och dess tidsstämpel ställs in automatiskt av dnsmasq. Filen måste lagras på ett beständigt filsystem, så att den och dess mtime överförs vid omstart av systemet. Tidsstämpel-filen skapas efter att dnsmasq har släppt root, så den måste finnas på en plats som kan skrivas av den icke-privilegierade användare som dnsmasq körs som.
Kopiera DNSSEC-autentiserade databitar från uppströms servrar till nedströms klienter. Detta är ett alternativ till att låta dnsmasq validera DNSSEC, men det beror på säkerheten i nätverket mellan dnsmasq och uppströms servrarna, samt på uppströms servrarnas tillförlitlighet. Observera att det inte är tekniskt möjligt att cachelagra autentiserade databiten korrekt i alla fall inte tekniskt möjligt. Om AD-biten ska användas när detta alternativ används, bör cachen inaktiveras med --cache-size=0. I de flesta fall är det bättre att aktivera DNSSEC-validering i dnsmasq. Se --dnssec för mer information.
Åsidosätt de standardresursbegränsningar som tillämpas på DNSSEC-validering. Kryptografiska operationer är kostsamma och specialdesignade domäner kan överbelasta en DNSSEC-validerare genom att tvinga den att utföra hundratusentals sådana operationer. För att undvika detta tillämpar dnsmasq-valideringskoden begränsningar på hur mycket arbete som får läggas ner på valideringen.
Om någon av gränserna överskrids misslyckas valideringen och domänen behandlas som BOGUS. Det finns fyra gränser, i ordning (standardvärden inom parentes): antal signaturvalideringar som misslyckas per RRset (20), antal signaturvalideringar och hashberäkningar per fråga (200), antal underfrågor för att hämta DS- och DNSKEY-RRset per fråga (40) och antalet iterationer i en NSEC3-post (150). De maximala värden som uppnås under valideringen lagras och dumpas som en del av statistiken som genereras av SIGUSR1. Om du anger ett gränsvärde på 0 behålls standardvärdet, så --dnssec-limits=0,0,20 ställer in antalet underfrågor till 20 medan de andra gränserna behålls på standardvärdena.
Ställ in felsökningsläge för DNSSEC-valideringen, ställ in biten Checking Disabled på uppströmsfrågor och konvertera inte svar som inte valideras till svar med returkoden SERVFAIL. Observera att inställningen kan påverka DNS-beteendet på ett negativt sätt, det är inte en extra loggningsflagga och bör inte ställas in i produktion.
Definiera en DNS-zon för vilken dnsmasq fungerar som auktoritativ server. Lokalt definierade DNS-poster som finns i domänen kommer att betjänas. Om subnät anges måste A- och AAAA-poster finnas i ett av de angivna subnäten.

Som alternativ till att direkt ange subnät är det möjligt att ange namnet på ett gränssnitt, i vilket fall de subnät som antyds av det gränssnittets konfigurerade adresser och nätmask/prefixlängd används; detta är användbart när man använder konstruerade DHCP-intervall eftersom den faktiska adressen är dynamisk och inte känd när dnsmasq konfigureras. Gränssnittsadresserna kan begränsas till endast IPv6-adresser med <interface>/6 eller till endast IPv4 med <interface>/4. Detta är användbart när ett gränssnitt har dynamiskt bestämda globala IPv6-adresser som ska visas i zonen, men RFC1918 IPv4-adresser som inte ska visas. Gränssnittsnamn och adressliterala subnätsspecifikationer kan användas fritt i samma --auth-zone-deklaration.

Det är möjligt att utesluta vissa IP-adresser från svaren. Det kan användas för att säkerställa att svaren endast innehåller globala routbara IP-adresser (genom att utesluta loopback-, RFC1918- och ULA-adresser).

Undernätet/undernäten används också för att definiera in-addr.arpa- och ip6.arpa-domäner som används för omvända DNS-frågor. Om inget anges är prefixlängden som standard 24 för IPv4 och 64 för IPv6. För IPv4-undernät bör prefixlängden ha värdet 8, 16 eller 24 om du inte är bekant med RFC 2317 och har ordnat in-addr.arpa-delegeringen därefter. Observera att om inga undernät anges, besvaras inga omvända frågor.

Ange fält i SOA-posten som är associerad med auktoritativa zoner. Observera att detta är valfritt, alla värden är inställda på rimliga standardvärden.
Ange eventuella sekundära servrar för en zon för vilken dnsmasq är auktoritativ. Dessa servrar måste konfigureras för att hämta zondata från dnsmasq genom zonöverföring och besvara frågor för samma auktoritativa zoner som dnsmasq.
Ange adresserna till sekundära servrar som har tillåtelse att initiera zonöverföringsförfrågningar (AXFR) för zoner för vilka dnsmasq är auktoritativ. Om detta alternativ inte anges men --auth-sec-servers anges, kommer AXFR-förfrågningar att accepteras från alla sekundära servrar. Om du anger --auth-peer utan --auth-sec-servers aktiveras zonöverföring, men sekundärservern annonseras inte i NS-poster som returneras av dnsmasq.
Läs Linux-anslutningsspårmärket som är associerat med inkommande DNS -frågor och ställ in samma märkesvärde på uppströms trafik som används för att svara på dessa frågor.
Detta gör att trafik som genereras av dnsmasq kan associeras med de förfrågningar som orsakar den, vilket är användbart för bandbreddsredovisning och brandväggar. Dnsmasq måste ha conntrack-stöd kompilerat och kärnan måste ha conntrack-stöd inkluderat och konfigurerat. Detta alternativ kan inte kombineras med --query-port.

Aktivera DHCP-servern. Adresser kommer att delas ut från intervallet <start-addr> till <end-addr> och från statiskt definierade adresser som anges i --dhcp-host alternativ. Om leasingtiden anges kommer leasingavtal att ges för den tidsperioden. Leasingtiden anges i sekunder, minuter (t.ex. 45m), timmar (t.ex. 1h), dagar (2d), veckor (1w) eller ”infinite” . Om den inte anges är standardleasetiden en timme för IPv4 och en dag för IPv6. Den minsta leasetiden är två minuter. För IPv6-intervall kan leasetiden vara ”deprecated”; detta sätter den önskade livslängden som skickas i en DHCP lease eller routerannonsering till noll, vilket gör att klienter använder andra adresser, om tillgängliga, för nya anslutningar som en förberedelse för omnumrering.

Det här alternativet kan upprepas med olika adresser för att aktivera DHCP -tjänsten för mer än ett nätverk. För direktanslutna nätverk (dvs. nätverk där maskinen som kör dnsmasq har ett gränssnitt) är nätmasken valfri: dnsmasq bestämmer den utifrån gränssnittets konfiguration. För nätverk som tar emot DHCP-tjänsten via en reläagent kan dnsmasq inte bestämma nätmasken själv, så den bör anges, annars måste dnsmasq gissa utifrån klassen (A, B eller C) för nätverksadressen. Sändningsadressen är alltid valfri. Det är alltid tillåtet att ha mer än en --dhcp-range i ett enda undernät.

För IPv6 är parametrarna något annorlunda: istället för nätmask och sändningsadress finns det en valfri prefixlängd som måste vara lika med eller större än prefixlängden på det lokala gränssnittet. Om den inte anges är standardvärdet 64. Till skillnad från IPv4-fallet härleds prefixlängden inte automatiskt från gränssnittskonfigurationen. Den minsta storleken på prefixlängden är 64.

IPv6 (endast) stöder en annan typ av intervall. I detta fall innehåller startadressen och den valfria slutadressen endast nätverksdelen (dvs. ::1) och följs av konstruktör:<gränssnitt>. Detta bildar en mall som beskriver hur man skapar intervall, baserat på de adresser som tilldelats gränssnittet. Till exempel

--dhcp-range=::1,::400,constructor:eth0

kommer att söka efter adresser på eth0 och sedan skapa ett intervall från <nätverk>::1 till <nätverk>::400. Om gränssnittet tilldelas mer än ett nätverk, kommer motsvarande intervall att skapas automatiskt, och sedan föråldras och slutligen tas bort igen när adressen föråldras och sedan raderas. Gränssnittsnamnet kan ha ett slutligt ”*” jokertecken. Observera att inte vilken adress som helst på eth0 duger: den får inte vara en autokonfigurerad eller privat adress, eller vara föråldrad.

Om --dhcp-range endast används för stateless DHCP och/eller SLAAC, kan adressen helt enkelt vara ::

--dhcp-range=::,constructor:eth0

Det valfria set:<tag> ställer in en alfanumerisk etikett som markerar detta nätverk så att DHCP-alternativ kan anges per nätverk. När det istället prefixeras med ’tag:’ ändras dess betydelse från att ställa in en tagg till att matcha den. Endast en tagg kan ställas in, men mer än en tagg kan matchas.

Det valfria nyckelordet <mode> kan vara static som talar om för dnsmasq att aktivera DHCP för det angivna nätverket, men inte att dynamiskt tilldela IP-adresser: endast värdar som har statiska adresser angivna via --dhcp-host eller från /etc/ethers kommer att betjänas. Ett statiskt subnät med adress alla nollor kan användas som en ”catch-all”-adress för att möjliggöra svar på alla informationsförfrågningspaket på ett subnät som tillhandahålls med stateless DHCPv6, dvs. --dhcp-range=::,static

För IPv4 kan <mode> vara proxy,
i vilket fall dnsmasq tillhandahåller proxy-DHCP på det angivna subnätet. (Se --pxe-prompt och

--pxe-service för mer information.)

För IPv6 kan läget vara en kombination av ra-only, slaac, ra-names, ra-stateless, ra-advrouter, off-link.

ra-only talar om för dnsmasq att endast erbjuda Router Advertisement på detta subnät, och inte DHCP.

slaac ber dnsmasq att erbjuda Router Advertisement på detta subnät och att ställa in A-biten i routerannonseringen, så att klienten kommer att använda SLAAC-adresser. När detta används med ett DHCP-intervall eller en statisk DHCP-adress resulterar det i att klienten har både en DHCP-tilldelad och en SLAAC-adress

ra-stateless skickar routerannonser med O- och A-bitarna inställda och tillhandahåller en stateless DHCP-tjänst. Klienten kommer att använda en SLAAC-adress och använda DHCP för annan konfigurationsinformation.

ra-names aktiverar ett läge som ger DNS-namn till dual-stack-värdar som använder SLAAC för IPv6. Dnsmasq använder värdens IPv4-lease för att härleda namnet, nätverkssegmentet och MAC-adressen och antar att värden också kommer att ha en IPv6-adress beräknad med SLAAC-algoritmen, på samma nätverkssegment.
Adressen pingas, och om ett svar mottas läggs en AAAA-post till i DNS för denna IPv6-adress.
Observera att detta endast sker för direktanslutna nätverk (inte sådana som använder DHCP via en relä) och att det inte fungerar om en värd använder sekretessförlängningar.

ra-names kan kombineras med ra-stateless och slaac.

ra-advrouter aktiverar ett läge där routeradresser snarare än prefix inkluderas i annonserna. Detta beskrivs i RFC-3775 avsnitt 7.2 och används i mobilt IPv6. I detta läge ingår även intervallalternativet,
som beskrivs i RFC-3775 avsnitt 7.3.

off-link talar om för dnsmasq att annonsera prefixet utan att on-link-biten (även kallad L) är inställd.

Ange parametrar per värd för DHCP-servern. Detta gör att en maskin med en viss hårdvaruadress alltid tilldelas samma värdnamn, IP-adress och leasingtid. Ett värdnamn som anges på detta sätt ersätter alla som tillhandahålls av DHCP-klienten på maskinen. Det är också tillåtet att utelämna hårdvaruadressen och inkludera värdnamnet, i vilket fall IP-adressen och leasingtiderna kommer att gälla för alla maskiner som gör anspråk på det namnet. Till exempel --dhcp-host=00:20:e0:3b:13:af,wap,infinite talar om för dnsmasq att ge maskinen med hårdvaruadress 00:20:e0:3b:13:af namnet wap och en oändlig DHCP-lease.

--dhcp-host=lap,192.168.0.199 talar om för dnsmasq att alltid tilldela maskinen lap IP-adressen 192.168.0.199.

Adresser som tilldelas på detta sätt är inte begränsade till det intervall som anges av alternativet --dhcp-range, men de måste vara i samma subnät som något giltigt dhcp-intervall. För subnät som inte behöver en pool med dynamiskt tilldelade adresser använder du nyckelordet ”static” i deklarationen --dhcp-range.

Det är tillåtet att använda klientidentifierare (kallade klient DUID i IPv6-land) istället för hårdvaruadresser för att identifiera värdar genom att lägga till prefixet ’id:’. Alltså: --dhcp-host=id:01:02:03:04,.....

hänvisar till värden med klientidentifieraren 01:02:03:04. Det är också tillåtet att ange klient-ID som text, så här: --dhcp-host=id:clientidastext,.....

En enda --dhcp-host kan innehålla en IPv4-adress eller en eller flera IPv6-adresser, eller båda. IPv6-adresser måste omges av hakparenteser, så här: --dhcp-host=laptop,[1234::56] IPv6-adresser får endast innehålla värdidentifieringsdelen: --dhcp-host=laptop,[::56] I så fall fungerar de som jokertecken i konstruerade DHCP-intervall, med lämplig nätverksdel infogad. För IPv6 kan en adress innehålla en prefixlängd: --dhcp-host=laptop,[1234:50/126] vilket (i detta fall) anger fyra adresser, 1234::50 till 1234::53. Detta (och möjligheten att ange flera adresser) är användbart när en värd har ett konsekvent namn eller hårdvaru-ID, men varierande DUID:er, eftersom det gör det möjligt för dnsmasq att respektera den statiska adressallokeringen men tilldela en annan adress för varje DUID. Detta inträffar vanligtvis vid kedjebaserad nätverksstart, eftersom varje steg i kedjan i tur och ordning tilldelar en adress.

Observera att i IPv6 DHCP kanske hårdvaruadressen inte är tillgänglig, även om den normalt är det för direktanslutna klienter eller klienter som använder DHCP-reläer som stöder RFC 6939.

För DHCPv4 betyder det speciella alternativet id:* ”ignorera alla klient-id och använd endast MAC-adresser”. Detta är användbart när en klient ibland presenterar ett klient-id men inte alltid.

Om ett namn förekommer i /etc/hosts kan den associerade adressen tilldelas en DHCP-lease, men endast om ett --dhcp-host -alternativ som anger namnet också finns. Endast ett värdnamn kan anges i ett --dhcp-host -alternativ, men alias är möjliga genom att använda CNAME. (Se --cname).
Observera att /etc/hosts INTE används när DNS-serversidan av dnsmasq är inaktiverad genom att DNS-serverporten är inställd på noll.

Mer än en --dhcp-host kan associeras (med namn, hårdvaruadress eller UID) med en värd. Vilken som används (och därmed vilken adress som tilldelas av DHCP och visas i DNS) beror på det subnät där värden senast erhöll en DHCP-lease: den --dhcp-host med en adress inom subnätet används. Om mer än en adress finns inom subnätet är resultatet odefinierat. En följd av detta är att namnet som är associerat med en värd som använder --dhcp-host inte visas i DNS förrän värden erhåller en DHCP-lease.

Det speciella nyckelordet ignore talar om för dnsmasq att aldrig erbjuda en DHCP-lease till en maskin. Maskinen kan anges med hårdvaruadress, klient-ID eller värdnamn. Till exempel: --dhcp-host=00:20:e0:3b:13:af,ignore.

Detta kan vara användbart när det finns en annan DHCP-server i nätverket som ska användas av vissa maskiner.

Konstruktionen set:<tag> ställer in taggen när denna --dhcp-host-direktiv används. Detta kan användas för att selektivt skicka DHCP-alternativ endast till denna värd. Mer än en tagg kan ställas in i ett --dhcp-host-direktiv (men inte på andra ställen där set:<tag> är tillåtet). När en värd matchar något --dhcp-host-direktiv (eller ett som antyds av /etc/ethers) sätts den speciella taggen known. Detta gör det möjligt att konfigurera dnsmasq så att den ignorerar förfrågningar från okända maskiner med --dhcp-ignore=tag:!known. Om värden endast matchar ett --dhcp-host-direktiv som inte kan användas eftersom det anger en adress på ett annat subnät, sätts taggen known-othernet.

Konstruktionen tag:<tag> filtrerar vilka dhcp-host-direktiv som används. Mer än en tagg kan anges. I detta fall måste förfrågan matcha alla taggar. Taggade direktiv används före otaggade. Observera att en av <hwaddr>, <client_id> eller <hostname> fortfarande måste anges (kan vara ett jokertecken).

Ethernet-adresser (men inte klient-id) kan ha jokertecken, så till exempel --dhcp-host=00:20:e0:3b:13:*,ignore kommer att få dnsmasq att ignorera det angivna intervallet av hårdvaruadresser. Observera att ”*” måste undvikas eller anges inom citationstecken på kommandoraden, men inte i konfigurationsfilen.

Hårdvaruadresser matchar normalt alla nätverkstyper (ARP), men det är möjligt att begränsa dem till en enda ARP-typ genom att föregå dem med ARP-typen (i HEX) och ”-”. Så --dhcp-host=06-00:20:e0:3b:13:af,1.2.3.4

kommer endast att matcha en Token-Ring-hårdvaruadress, eftersom ARP-adress typen för token ring är 6.

Som ett specialfall är det i DHCPv4 möjligt att inkludera mer än en hårdvaruadress. Exempel: --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2. Detta gör det möjligt att koppla en IP-adress till flera hårdvaruadresser och ger dnsmasq tillstånd att överge en DHCP-lease till en av hårdvaruadresserna när en annan begär en lease. Observera att detta är farligt att göra: det fungerar bara tillförlitligt om endast en av hårdvaruadresserna är aktiv vid varje tillfälle och det finns inget sätt för dnsmasq att genomdriva detta. Det är till exempel användbart att tilldela en stabil IP-adress till en bärbar dator som har både trådbundna och trådlösa gränssnitt.

Läs DHCP-värdinformation från den angivna filen. Om en katalog anges, läs då alla filer i den katalogen i alfabetisk ordning. Filen innehåller information om en värd per rad. Radens format är detsamma som texten till höger om ’=’ i --dhcp-host. Fördelen med att lagra DHCP-värdinformation i den här filen är att den kan ändras utan att dnsmasq behöver startas om: filen läses om när dnsmasq tar emot SIGHUP.
Läs DHCP-optionsinformation från den angivna filen. Om en katalog anges, läs då alla filer i den katalogen i alfabetisk ordning. Fördelen med att använda detta alternativ är densamma som för --dhcp-hostsfile: --dhcp-optsfile läses om när dnsmasq tar emot SIGHUP. Observera att det är möjligt att koda informationen i en --dhcp-boot flagga som DHCP-alternativ, med hjälp av alternativnamnen bootfile-name, server-ip-address och tftp-server. Detta gör att dessa kan inkluderas i en --dhcp-optsfile.
Detta motsvarar --dhcp-hostsfile, med undantag för följande. Sökvägen MÅSTE vara en katalog, inte en enskild fil. Ändrade eller nya filer i katalogen läses automatiskt, utan att SIGHUP behöver skickas. Om en fil raderas eller ändras efter att den har lästs av dnsmasq, kommer värdpost som den innehöll att finnas kvar tills dnsmasq tar emot ett SIGHUP eller startas om; dvs. värdposten läggs endast till dynamiskt. Ordningen i vilken filerna i en katalog läses är inte definierad.
Detta motsvarar --dhcp-optsfile, med de skillnader som anges för --dhcp-hostsdir.
Läs /etc/ethers för information om värdar för DHCP-servern. Formatet för /etc/ethers är en hårdvaruadress, följd av antingen ett värdnamn eller en IP-adress med fyra punkter. När dnsmasq läser dessa rader exakt samma effekt som --dhcp-host -alternativ som innehåller samma information. /etc/ethers läses om när dnsmasq tar emot SIGHUP. IPv6-adresser läses INTE från /etc/ethers.
Skicka olika extra alternativ till DHCP-klienter. Som standard skickar dnsmasq vissa standardalternativ till DHCP-klienter, nätmasken och sändningsadressen är inställda på samma som värden som kör dnsmasq, och DNS-servern och standardrutten är inställda på adressen till den maskin som kör dnsmasq. (Motsvarande regler gäller för IPv6.) Om alternativet för domännamn har ställts in skickas det. Denna konfiguration gör det möjligt att åsidosätta dessa standardinställningar eller ange andra alternativ. Alternativet som ska skickas kan anges som ett decimaltal eller som option:<option-name>.

Alternativnumren anges i RFC2132 och efterföljande RFC:er. Den uppsättning alternativnamn som dnsmasq känner till kan hittas genom att köra dnsmasq --help dhcp. Om du till exempel vill ställa in standardroutningsalternativet till 192.168.4.4 använder du --dhcp-option=3,192.168.4.4 eller --dhcp-option=option: router,192.168.4.4 och för att ställa in tidsserveradressen till 192.168.0.4, använd --dhcp-option=42,192.168.0.4 eller --dhcp-option=option:ntp-server,192.168.0.4. Den speciella adressen 0.0.0.0 betyder ”adressen till det system som kör dnsmasq”.

Ett alternativ utan data är giltigt och innehåller bara alternativet utan data. (Det finns för närvarande bara ett alternativ med ett datafält med längden noll definierat för DHCPv4, 80:rapid commit, så denna funktion är inte särskilt användbar i praktiken). Alternativ för vilka dnsmasq normalt tillhandahåller standardvärden kan utelämnas genom att definiera alternativet utan data. Dessa är netmask, broadcast, router, DNS-server, domännamn och värdnamn. För DHCPv4 --dhcp-option = option:router resultera i att inget routeralternativ skickas, istället för standardvärdet för den värd där dnsmasq körs. För DHCPv6 gäller samma sak för alternativen DNS-server och uppdateringstid.

Tillåtna datatyper är kommaseparerade punktseparerade IPv4-adresser, []-omslutna IPv6-adresser, ett decimaltal, kolonseparerade hexadecimala siffror och en textsträng. Om de valfria taggarna anges skickas detta alternativ endast när alla taggar matchar.

Särskild bearbetning utförs på ett textargument för alternativ 119, för att överensstämma med RFC 3397. Text eller IP-adresser med fyra punkter som argument till alternativ 120 hanteras enligt RFC 3361. IP-adresser med fyra punkter som följs av en snedstreck och sedan en nätmaskstorlek kodas enligt beskrivningen i RFC 3442.

IPv6-alternativ anges med hjälp av nyckelordet option6:,
följt av alternativnumret eller alternativnamnet. IPv6-alternativets är skilt från IPv4-optionsnamnrymden. IPv6-adresser i optioner måste omges av hakparenteser, t.ex. --dhcp-option=option6:ntp-server,[1234::56].

För IPv6 betyder [::] ”den globala adressen för maskinen som kör dnsmasq”, medan [fd00::] ersätts med ULA, om den finns, och [fe80::] med den länklokala adressen.

Var försiktig: datatypens lämplighet för det skickade optionsnumret kontrolleras inte. Det är fullt möjligt att få dnsmasq att generera olagliga DHCP-paket med oförsiktig användning av denna flagga. När värdet är ett decimaltal måste dnsmasq bestämma hur stor dataposten är. Detta görs genom att undersöka optionsnumret och/eller värdet, men kan åsidosättas genom att lägga till en enda bokstavsflagga enligt följande: b = en byte, s = två byte, i = fyra byte. Detta är främst användbart med inkapslade leverantörsklassalternativ (se nedan) där dnsmasq inte kan bestämma datastorleken utifrån alternativnumret. Alternativdata som enbart består av punkter och siffror tolkas av dnsmasq som en IP-adress och infogas i ett alternativ som sådan. För att tvinga fram en bokstavlig sträng, använd citattecken. När du till exempel använder alternativ 66 för att skicka en bokstavlig IP-adress som TFTP-servernamn, måste du göra --dhcp-option=66,”1.2.3.4”.

Inkapslade leverantörsklassalternativ kan också anges (endast IPv4) med --dhcp-option: till exempel --dhcp-option=vendor:PXEClient,1,0.0.0.0 skickar det inkapslade leverantörs klassspecifika alternativet ”mftp-address=0.0.0.0” till alla klienter vars leverantörsklass matchar ”PXEClient”. Leverantörsklassmatchningen är baserad på delsträngar (se --dhcp-vendorclass för mer information) . Om ett leverantörsklassalternativ (nummer 60) skickas av dnsmasq, används det för att välja inkapslade alternativ framför de som skickas av klienten. Det är möjligt att helt utelämna leverantörsklassen; --dhcp-option=vendor:,1,0.0.0.0 i vilket fall det inkapslade alternativet alltid skickas.

Alternativ kan kapslas (endast IPv4) inom andra alternativ: till exempel --dhcp-option=encap:175, 190, ”iscsi-client0” skickar alternativ 175, inom vilket alternativ 190 finns. Om flera alternativ anges som är inkapslade med samma alternativnummer kommer de att kombineras korrekt till ett inkapslat alternativ. encap: och vendor: kan inte båda anges i samma --dhcp-option.

Den sista varianten av inkapslade alternativ är ”Vendor-Identifying Vendor Options” enligt specifikationen i RFC3925. Dessa betecknas så här: --dhcp-option=vi-encap:2, 10, ”text” Siffran i vi-encap: är IANA-företagsnumret som används för att identifiera detta alternativ. Denna form av inkapsling stöds i IPv6.

Adressen 0.0.0.0 behandlas inte särskilt i inkapslade alternativ.

Detta fungerar på exakt samma sätt som --dhcp-option förutom att alternativet alltid skickas, även om klienten inte begär det i parameterförfrågningslistan. Detta är ibland nödvändigt, till exempel när alternativ skickas till PXELinux.
En variant av --dhcp-option som definierar alternativ som endast skickas som svar till PXE-klienter. Dessutom skickas sådana alternativ som svar till PXE-klienter när dnsmasq fungerar som en PXE-proxy, till skillnad från andra alternativ. Ett typiskt användningsfall är alternativ 175, som skickas till iPXE.
(Endast IPv4) Inaktivera återanvändning av DHCP-servernamns- och filnamnsfälten som extra optionsutrymme. Om det är möjligt flyttar dnsmasq informationen om startserver och filnamn (från --dhcp-boot) från deras dedikerade fält till DHCP-alternativ. Detta frigör extra utrymme i DHCP-paketet för alternativ, men kan i sällsynta fall förvirra gamla eller trasiga klienter. Denna flagga tvingar fram ett ”enkelt och säkert” beteende för att undvika problem i sådana fall.
Aktivera RFC 4388 leasequery. Dnsmasq DHCP-servern svarar på LEASEQUERY-meddelanden från DHCP-reläer när detta alternativ anges. Om en adress eller ett subnät anges tillåts endast förfrågningar från ett relä vid den källan. Upprepa alternativet --leasequery för att ange flera tillåtna källor. För att kunna svara korrekt på lease-förfrågningar är det nödvändigt att lagra extra data i lease-databasen, och detta aktiveras också av alternativet --leasequery. De extra fälten (agent-info och vendorclass) lagras i leases-filen på ett något bakåtkompatibelt sätt. Att aktivera och sedan inaktivera leasequery orsakar inga problem; den extra informationen kommer att åldras ut ur databasen. Att aktivera leasequery i version 2.92 eller senare, lagra leases som kommer via DHCP-reläer som lägger till option-82 agent-info-data, och sedan återgå till en dnsmasq-binärfil före 2.92 kan orsaka problem med att läsa leasingfilen. Från och med version 2.92 stöds leasequery endast för DHCPv4.
Konfigurera dnsmasq för att utföra DHCP-relä. Den lokala adressen är en adress som tilldelats ett gränssnitt på värden som kör dnsmasq. Alla DHCP -förfrågningar som anländer till det gränssnittet vidarebefordras till en fjärr-DHCP -server på serveradressen. Det är möjligt att vidarebefordra från en enda lokal adress till flera fjärrservrar genom att använda flera --dhcp-relay konfigurationer med samma lokala adress och olika serveradresser.
En serveradress måste vara en IP-adress, inte ett domännamn. Om serveradressen utelämnas kommer begäran att vidarebefordras via broadcast (IPv4) eller multicast (IPv6). I detta fall måste gränssnittet anges och får inte vara ett jokertecken. Serveradressen kan ange en icke-standardport att vidarebefordra till. Om detta används bör --dhcp-proxy troligen också anges, annars kommer delar av DHCP-konversationen som inte passerar genom vidarebefordran att levereras till fel port.

Åtkomstkontroll för DHCP-klienter har samma regler som för DHCP -servern, se --interface, --except-interface, etc. Det valfria gränssnittsnamnet i --dhcp-relay-konfigurationen har en annan funktion: det styr på vilket gränssnitt DHCP-svar från servern kommer att accepteras. Detta är avsett för konfigurationer som har tre gränssnitt: ett som vidarebefordras från, ett andra som ansluter till DHCP-servern och ett tredje som är ett opålitligt nätverk, vanligtvis det bredare internet. Det undviker risken för att falska svar anländer via detta tredje gränssnitt.

Det är tillåtet att låta dnsmasq fungera som en DHCP-server på en uppsättning gränssnitt och vidarebefordra från en separat uppsättning gränssnitt. Observera att även om det är fullt möjligt att skriva konfigurationer som verkar fungera som en server och en vidarebefordran på samma gränssnitt, stöds detta inte : vidarebefordringsfunktionen har företräde.

Både DHCPv4- och DHCPv6-vidarebefordran stöds. Det är inte möjligt att vidarebefordra DHCPv4 vidare till en DHCPv6-server eller vice versa.

DHCP-reläfunktionen för IPv6 inkluderar möjligheten att snoopa prefix-delegering från vidarebefordrade DHCP-transaktioner. Se --dhcp-script för mer information.

En användbar förbättrad version av DHCPv4-relä. IPv4 DHCP använder normalt en enda adress för två funktioner; den används av DHCP-servern för att avgöra vilket nätverk som ska tilldelas en adress, och den används som adress för reläet till vilket servern skickar paket.

Denna version av DHCP-relä delar upp dessa funktioner. Den använder adressen till det server-facing relä gränssnittet eller en direkt angiven adress som den adress som servern kommunicerar med. Adressen till det klient-facing gränssnittet (det första objektet i konfigurationen) används för att bestämma klientens subnät. Den lokala adressen används också som server-ID-överskrivning så att klienten alltid skickar förfrågningar via reläet. Effekten av detta är att servern inte behöver en rutt till klientnätverket och att klienterna inte behöver en rutt till servern.

Den tredje parametern är obligatorisk. Om det är ett gränssnittsnamn kan det inte vara ett jokertecken och samma filtrering som beskrivs i --dhcp-relay; svar från servern måste komma via det angivna gränssnittet. Om den tredje parametern är en IP-adress måste det vara en adress till ett lokalt gränssnitt som är routbart från servern; i detta fall sker ingen filtrering och svarspaketen kan komma via vilken rutt som helst.

Om du konfigurerar ett nätverk där klientnätverken har begränsad routing, var försiktig med att konfigurera DHCP-servern. Dnsmasq, som DHCP-server, kommer att ställa in standardrutten till det klientinriktade relägränssnittet om det inte uttryckligen konfigureras: det är en rimlig standardinställning. Den normala standard-DNS-servern (samma adress som DHCP-servern) är inte lämplig när det inte finns någon rutt mellan de två, så detta måste konfigureras uttryckligen.

Mappa från en vendor-class-sträng till en tagg. De flesta DHCP-klienter tillhandahåller en

”leverantörsklass” som i viss mening representerar typen av värd. Detta alternativ mappar leverantörsklasser till taggar, så att DHCP-alternativ kan levereras selektivt till olika klasser av värdar. Till exempel --dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect tillåter att alternativ endast ställs in för HP-skrivare så här: --dhcp-option=tag:printers,3,192.168.4.4 Strängen för leverantörsklass är en delsträng som matchas mot den leverantörsklass som tillhandahålls av klienten, för att möjliggöra fuzzy-matchning. Prefixet set: är valfritt men tillåtet för konsistens.

Observera att endast i IPv6 har leverantörsklasser namnutrymme med ett IANA-tilldelat företagsnummer. Detta anges med nyckelordet enterprise: och specificerar att endast leverantörsklasser som matchar det angivna numret ska sökas.

Mappa från en användarklasssträng till en tagg (med delsträngsmatchning,
som leverantörsklasser). De flesta DHCP-klienter tillhandahåller en ”användarklass” som är konfigurerbar. Detta alternativ mappar användarklasser till taggar, så att DHCP-alternativ kan levereras selektivt till olika klasser av värdar. Det är till exempel möjligt att använda detta för att ställa in en annan skrivarserver för värdar i klassen ’konton’ än för värdar i klassen ”teknik”.
-4, --dhcp-mac=set:<tag>,<MAC-adress>
Mappa från en MAC-adress till en tagg. MAC-adressen kan innehålla jokertecken. Till exempel --dhcp-mac=set:3com,01:34:23:*:*:* kommer att ställa in taggen ”3com” för alla värdar vars MAC-adress matchar mönstret.
Mappa från RFC3046-reläagentalternativ till taggar. Dessa data kan tillhandahållas av DHCP-reläagenter. Circuit-id eller remote-id anges normalt som kolonavgränsad hexadecimal, men kan också vara en enkel sträng. Om en exakt matchning uppnås mellan circuit- eller agent-id och den som tillhandahålls av en reläagent, sätts taggen.

--dhcp-remoteid (men inte --dhcp-circuitid) stöds i IPv6.

(IPv4 och IPv6) Mappa från RFC3993-alternativ för abonnent-id-reläagent till taggar.
(endast IPv4) En normal DHCP-reläagent används endast för att vidarebefordra de inledande delarna av en DHCP-interaktion till DHCP-servern. När en klient har konfigurerats kommunicerar den direkt med servern. Detta är inte önskvärt om reläagenten lägger till extra information till DHCP-paketen, till exempel den som används av --dhcp-circuitid och --dhcp-remoteid. En fullständig reläimplementering kan använda RFC 5107 serverid-override -alternativet för att tvinga DHCP-servern att använda reläet som en fullständig proxy, med alla paket som passerar genom det. Denna flagga ger en alternativ metod för att göra samma sak, för reläer som inte stöder RFC 5107. Om den anges ensam manipulerar den server-id för alla interaktioner via reläer. Om en lista med IP-adresser anges påverkas endast interaktioner via reläer på dessa adresser.
Utan <värde>, ställ in <tag> om klienten skickar en DHCP option med det angivna numret eller namnet. Med <värde>, ställ in <tag> endast om klienten skickar option som matchar eller innehåller <värde>.

Värdet kan ha formen ”01:ff:*:02”, i vilket fall värdet måste matcha (förutom jokertecken) men den skickade optionen kan ha omatchade data efter slutet av värdet. Värdet kan också ha samma form som i --dhcp-option,
i vilket fall den skickade optionen behandlas som en array, och ett element måste matcha. --dhcp-match=set:efi-ia32,option:client-arch,6 ställer in taggen efi-ia32 om siffran 6 förekommer i listan över arkitekturer som skickas av klienten i alternativ 93. (Se RFC 4578 för detaljer. ) Om värdet är en sträng används delsträngsmatchning.

Den speciella formen med vi-encap:<företagsnummer> matchas mot leverantörsidentifierande leverantörsklasser för det angivna företaget. Se RFC 3925 för mer information om dessa sällsynta och intressanta varelser.

Ställ in en <tag> om det angivna <name> tillhandahålls av en DHCP-klient. Det kan finnas ett enda efterföljande jokertecken *, med en glob-betydelse. I kombination med dhcp-ignore eller dhcp-ignore-names ger detta möjlighet att ignorera vissa klienter efter namn eller förbjuda vissa värdnamn från att göras anspråk på av en klient.
Utför booleska operationer på taggar. Alla set:<tag>-taggar sätts om alla tag:<tag> redan är satta (eller avmarkeras när tag:!<tag> används). Om ingen tag:<tag> förekommer, sätts set:<tag>-taggarna villkorslöst. Valfritt antal set:- och tag:-former kan förekomma, i valfri ordning. --tag-if-raderna exekveras i ordning, så om taggen i tag:<tag> är en tagg som satts av en annan --tag-if, måste raden som sätter taggen föregå raden som testar den.

Som en utökning stöder tag:<tag>-klausuler begränsad jokerteckenmatchning, liknande matchningen i direktivet --interface. Detta gör det möjligt för exemplet --tag-if=set:ppp,tag:ppp* att ställa in taggen ’ppp’ för alla förfrågningar som tas emot på alla matchande gränssnitt (ppp0, ppp1, etc). Detta kan användas tillsammans med formatet tag:!<tag>, vilket innebär att ingen tagg som matchar jokertecknet får sättas.

När alla angivna taggar förekommer i tagguppsättningen, ignorera värden och tilldela den inte en DHCP-lease.
När alla angivna taggar förekommer i tagguppsättningen, ignorera alla värdnamn som tillhandahålls av värden. Observera att till skillnad från --dhcp-ignore är det tillåtet att inte ange några taggar, i vilket fall DHCP-klientens värdnamn alltid ignoreras och DHCP-värdar läggs till i DNS med endast --dhcp-host-konfigurationen i dnsmasq och innehållet i /etc/hosts och /etc/ethers.
(endast IPv4) Generera ett namn för DHCP-klienter som annars inte har något, med hjälp av MAC-adressen uttryckt i hexadecimal form, separerad med bindestreck. Observera att om en värd tillhandahåller ett namn, kommer det att användas i stället för detta, såvida inte --dhcp-ignore-names är inställt.
(endast IPv4) När alla angivna taggar förekommer i tagguppsättningen, använd alltid broadcast för att kommunicera med värden när den är okonfigurerad. Det är tillåtet att inte ange några taggar, i vilket fall detta är ovillkorligt. De flesta DHCP-klienter som behöver broadcast-svar sätter en flagga i sina förfrågningar så att detta sker automatiskt, men vissa äldre BOOTP-klienter gör inte det.
(endast IPv4) Ställ in BOOTP-alternativ som ska returneras av DHCP-servern. Servernamn och adress är valfria: om de inte anges lämnas namnet tomt och adressen ställs in till adressen för den maskin som kör dnsmasq. Om dnsmasq tillhandahåller en TFTP-tjänst (se --enable-tftp )
krävs endast filnamnet här för att aktivera nätverksstart. Om valfria taggar anges måste de matcha för att denna konfiguration ska skickas. Istället för en IP-adress kan TFTP-serveradressen anges som ett domännamn som söks upp i /etc/hosts. Detta namn kan associeras i /etc/hosts med flera IP-adresser, som används i round-robin. Denna funktion kan användas för att balansera tftp-belastningen mellan en uppsättning servrar.
Dnsmasq är utformat för att välja IP-adresser för DHCP-klienter med hjälp av en hash av klientens MAC-adress. Detta gör normalt att en klients adress förblir stabil på lång sikt, även om klienten ibland låter sin DHCP -lease löpa ut. I detta standardläge fördelas IP-adresser pseudorandomt över hela det tillgängliga adressintervallet. Det finns ibland omständigheter (vanligtvis serverdistribution) där det är mer praktiskt att ha IP tilldelas sekventiellt, med början från den lägsta tillgängliga adressen, och denna flagga aktiverar detta läge. Observera att i sekventiellt läge är det mycket mer sannolikt att klienter som låter en leasing löpa ut byter IP-adress; av denna anledning bör det inte användas generellt.
Dnsmasq läser alternativet ”klientidentifierare” (RFC 2131) som skickas av klienter (om tillgängligt) för att identifiera klienter. Detta gör det möjligt att tilldela samma IP-adress till en värd som använder flera gränssnitt. Använd detta alternativ för att inaktivera läsning av ”klientidentifierare”,
dvs. för att alltid identifiera en värd med hjälp av MAC-adressen.
De flesta användningar av PXE-boot-ROMS tillåter helt enkelt PXE -systemet att hämta en IP-adress och sedan ladda ner filen som anges av --dhcp-boot och köra den. PXE-systemet kan dock utföra mer komplexa funktioner när det stöds av en lämplig DHCP-server.

Detta anger ett startalternativ som kan visas i en PXE-startmeny. <CSA> är klientsystemtyp, endast tjänster av rätt typ visas i en meny. De kända typerna är x86PC, PC98, IA64_EFI, Alpha, Arc_x86, Intel_Lean_Client, IA32_EFI, x86-64_EFI, Xscale_EFI, BC_EFI, ARM32_EFI och ARM64_EFI; ett heltal kan användas för andra typer. Parametern efter menytexten kan vara ett filnamn, i vilket fall dnsmasq fungerar som en startserver och dirigerar PXE-klienten att ladda ner filen via TFTP, antingen från sig själv ( --enable-tftp måste vara inställt för att detta ska fungera) eller en annan TFTP-server om den slutliga serverns adress/namn anges. Observera att suffixet ”lager” (normalt ”.0”) tillhandahålls av PXE och inte behöver läggas till basnamnet. Alternativt kan basnamnet vara ett filnamn, komplett med suffix, i vilket fall inget lagersuffix läggs till. Om en heltalstyp av starttjänst anges istället för ett basnamn kommer PXE-klienten att söka efter en lämplig starttjänst för den typen i nätverket. Denna sökning kan göras genom sändning eller direkt till en server om dess IP-adress/namn anges.

Om ingen starttjänsttyp eller filnamn anges (eller om en starttjänsttyp på 0 anges) kommer menyposten att avbryta nätverksstartsproceduren och fortsätta starta från lokala medier. Serveradressen kan anges som ett domännamn som söks upp i /etc/hosts. Detta namn kan associeras i /etc/hosts med flera IP-adresser, som används i tur och ordning.

Om detta anges visas en prompt efter PXE-uppstarten. Om timeout anges kommer det första tillgängliga menyalternativet att köras automatiskt efter att timeout har löpt ut utan att något har matats in på tangentbordet. Om timeout är noll kommer det första tillgängliga menyalternativet att köras omedelbart. Om --pxe-prompt utelämnas kommer systemet att vänta på användarinmatning om det finns flera alternativ i menyn, men startar omedelbart om det bara finns ett. Se --pxe-service för detaljer om menyalternativ.

Dnsmasq stöder PXE ”proxy-DHCP”, i detta fall ansvarar en annan DHCP-server i nätverket för att tilldela IP-adresser, och dnsmasq tillhandahåller endast informationen som anges i --pxe-prompt och --pxe-service för att möjliggöra nätverksstart. Detta läge aktiveras med hjälp av nyckelordet proxy i --dhcp-range. Om den ”andra” DHCP-servern finns på ett fjärrnätverk är det möjligt och användbart att konfigurera dnsmasq som både en PXE proxy-DHCP-server och en DHCP-relä till den fjärranslutna DHCP-servern. Se --dhcp-relay för mer information. PXE stöds för närvarande endast över IPv4.

Enligt UEFI- och PXE-specifikationerna ska DHCP-paket mellan PXE-klienter och proxy-PXE-servrar ha PXEClient i sitt leverantörsklassfält. Dock är firmware för datorer från några leverantörer anpassad för att ha en annan identifierare i det fältet. Det här alternativet används för att betrakta sådana identifierare som giltiga för att identifiera PXE-klienter. Till exempel

--dhcp-pxe-vendor=PXEClient,HW-Client

aktiverar dnsmasq så att det också tillhandahåller proxy-PXE-tjänst till de PXE-klienter som har HW-Client som identifierare.

Begränsar dnsmasq till det angivna maximala antalet DHCP-leasingavtal. Standardvärdet är 1000. Denna begränsning är till för att förhindra DoS-attacker från värdar som skapar tusentals leasingavtal och använder mycket minne i dnsmasq-processen
Bör ställas in när dnsmasq definitivt är den enda DHCP-servern i ett nätverk. För DHCPv4 ändrar det beteendet från strikt RFC-kompatibilitet så att DHCP-förfrågningar på okända leasingavtal från okända värdar inte ignoreras. Detta gör det möjligt för nya värdar att få en leasing utan en tröttsam timeout under alla omständigheter. Det gör också det möjligt för dnsmasq att återuppbygga sin leasingdatabas utan att varje klient behöver skaffa en ny leasing om databasen går förlorad. För DHCPv6 styr det samma beteendet som DHCPv4 med saknade leasingavtal (förutom RFC-oöverensstämmelsen – DHCPv6 RFC tillåter detta beteende om det är konfigurerat). Det ställer också in prioritet i svar till 255 (det maximala) istället för 0 (minimivärdet).
Aktivera DHCPv4 Rapid Commit Option som anges i RFC 4039. När detta är aktiverat kommer dnsmasq att svara på ett DHCPDISCOVER-meddelande inklusive ett Rapid Commit -alternativ med ett DHCPACK som inkluderar ett Rapid Commit-alternativ och fullständigt bekräftad adress- och konfigurationsinformation. Bör endast aktiveras om antingen servern är den enda servern för undernätet, eller om flera servrar finns och de var och en bekräftar en bindning för alla klienter.
(endast IPv4) Ändra de portar som används för DHCP från standardinställningen. Om detta alternativ anges ensamt, utan argument, ändras de portar som används för DHCP från 67 och 68 till 1067 och 1068. Om ett enda argument anges, används det portnumret för servern och portnumret plus ett används för klienten. Slutligen möjliggör två portnummer godtycklig specificering av både server- och klientportar för DHCP.
-3, --bootp-dynamic[=<nätverks-id>[,<nätverks-id>]]
(Endast IPv4) Aktivera dynamisk tilldelning av IP-adresser till BOOTP-klienter. Använd detta med försiktighet, eftersom varje adress som tilldelas en BOOTP-klient hyrs för alltid och därför blir permanent otillgänglig för återanvändning av andra värdar. Om detta anges utan taggar, aktiveras dynamisk tilldelning villkorslöst. Med taggar, endast när alla taggar är inställda. Det kan upprepas med olika taggset.

-5, --no-ping
(endast IPv4) Som standard försöker DHCP-servern säkerställa att en adress inte används innan den tilldelas en värd. Detta görs genom att skicka en ICMP-ekoförfrågan (även kallad ”ping”) till adressen i fråga. Om den får ett svar måste adressen redan vara i bruk, och en annan försöks. Denna flagga inaktiverar denna kontroll. Använd med försiktighet.
Extra loggning för DHCP: logga alla alternativ som skickas till DHCP-klienter och de taggar som används för att bestämma dem.
Undertryck loggning av rutinmässig drift av dessa protokoll. Fel och problem loggas fortfarande. --quiet-tftp betraktar inte filer som inte hittas som ett fel. --quiet-dhcp och quiet-dhcp6 åsidosätts av --log-dhcp.
Använd den angivna filen för att lagra DHCP-leasinginformation.
(endast IPv6) Ange den permanenta UID som DHCPv6-servern kommer att använda. Detta alternativ krävs normalt inte eftersom dnsmasq skapar en DUID automatiskt när det behövs för första gången. När detta alternativ anges tillhandahåller det dnsmasq de data som krävs för att skapa en DUID-EN-typ DUID. Observera att när DUID väl har ställts in lagras den i leasingdatabasen, så för att växla mellan DUID-EN och automatiskt skapade DUID:er eller vice versa måste leasingdatabasen initialiseras om. Enterprise-id tilldelas av IANA, och uid är en sträng av hexadecimala oktetter som är unik för en viss enhet.
-6 --dhcp-script=<path>
När en ny DHCP-lease skapas, en gammal förstörs eller en TFTP-filöverföring slutförs, körs det exekverbara program som anges av detta alternativ. <path> måste vara en absolut sökväg, ingen PATH-sökning sker.

Argumenten till processen är ”add”, ’old’ eller ”del”, MAC -adressen för värden (eller DUID för IPv6) , IP-adressen och värdnamnet, om det är känt. ”add” betyder att en leasing har skapats, ’del’ betyder att den har förstörts, ”old” är en anmälan om en befintlig leasing när dnsmasq startar eller en ändring av MAC-adress eller värdnamn för en befintlig leasing (även leasinglängd eller utgångsdatum och klient-id, om --leasefile-ro är inställt och leasingens utgångsdatum om --script-on-renewal är inställt). Om MAC-adressen kommer från en annan nätverkstyp än ethernet, kommer nätverkstypen att läggas till i början, t.ex. ”06-01:23:45:67:89:ab” för token ring. Processen körs som root (förutsatt att dnsmasq ursprungligen kördes som root) även om dnsmasq är konfigurerat för att ändra UID till en icke-privilegierad användare.

Miljön ärvs från den som anropar dnsmasq, med några eller alla följande variabler tillagda

För både IPv4 och IPv6:

DNSMASQ_DOMAIN om värdens fullständiga domännamn är känt, är detta inställt på domändelen. (Observera att värdnamnet som skickas till skriptet som ett argument aldrig är fullständigt.)

Om klienten tillhandahåller ett värdnamn, DNSMASQ_SUPPLIED_HOSTNAME

Om klienten tillhandahåller användarklasser, DNSMASQ_USER_CLASS0..DNSMASQ_USER_CLASSn

Om dnsmasq kompilerades med HAVE_BROKEN_RTC, lagras längden på leasingavtalet (i sekunder) i DNSMASQ_LEASE_LENGTH, annars lagras tiden för leasingavtalets utgång i DNSMASQ_LEASE_EXPIRES. Antalet sekunder till leasingavtalets utgång lagras alltid i DNSMASQ_TIME_REMAINING.

DNSMASQ_DATA_MISSING sätts till ”1” under ”gamla” händelser för befintliga leasingavtal som genereras vid start för att indikera att data som inte lagras i den permanenta leasingdatabasen inte kommer att finnas. Detta omfattar allt utom IP-adress, värdnamn, MAC-adress, DUID, IAID och leasingavtalets längd eller utgångstid.

Om ett leasingavtal tidigare hade ett värdnamn som har tagits bort genereras en ”gammal” händelse med leasingavtalets nya status, dvs. inget namn, och det tidigare namnet anges i miljövariabeln DNSMASQ_OLD_HOSTNAME.

DNSMASQ_INTERFACE lagrar namnet på det gränssnitt som begäran kom till; detta ställs inte in för ”gamla” åtgärder när dnsmasq startas om.

DNSMASQ_RELAY_ADDRESS ställs in om klienten använde en DHCP-relä för att kontakta dnsmasq och IP-adressen för reläet är känd.

DNSMASQ_TAGS innehåller alla taggar som ställts in under DHCP-transaktionen, separerade med mellanslag.

DNSMASQ_LOG_DHCP ställs in om --log-dhcp är aktivt.

DNSMASQ_REQUESTED_OPTIONS en sträng som innehåller decimalvärdena i alternativet Parameter Request List, separerade med kommatecken, om alternativet parameter request list tillhandahålls av klienten.

DNSMASQ_MUD_URL URL:en för tillverkarens användningsbeskrivning om den tillhandahålls av klienten. (Se RFC8520 för mer information.)

Endast för IPv4:

DNSMASQ_CLIENT_ID om värden tillhandahöll ett klient-id.

DNSMASQ_CIRCUIT_ID, DNSMASQ_SUBSCRIBER_ID, DNSMASQ_REMOTE_ID om en DHCP-reläagent har lagt till något av dessa alternativ.

Om klienten tillhandahåller leverantörsklass, DNSMASQ_VENDOR_CLASS.

Endast för IPv6:

Om klienten tillhandahåller leverantörsklass, DNSMASQ_VENDOR_CLASS_ID, som innehåller IANA-företags-id för klassen, och DNSMASQ_VENDOR_CLASS0..DNSMASQ_VENDOR_CLASSn för data.

DNSMASQ_SERVER_DUID som innehåller serverns DUID: detta är detsamma för varje anrop till skriptet.

DNSMASQ_IAID som innehåller IAID för leasingavtalet. Om leasingavtalet är en tillfällig tilldelning, prefixeras detta med ’T’.

DNSMASQ_MAC innehåller klientens MAC-adress, om den är känd.

Observera att de angivna uppgifterna om värdnamn, leverantörsklass och användarklass endast anges för ”add”-åtgärder eller ”old”-åtgärder när en värd återupptar en befintlig leasing, eftersom dessa uppgifter inte finns i dnsmasq:s leasingdatabas

Alla filbeskrivare är stängda utom stdin, som är öppen för /dev/null, och stdout och stderr som fångar upp utdata för loggning av dnsmasq. (I felsökningsläge lämnas stdio-, stdout- och stderr-filerna som de ärvts från den som anropade dnsmasq).

Skriptet anropas inte samtidigt: högst en instans av skriptet körs åt gången (dnsmasq väntar på att en instans av skriptet ska avslutas innan nästa körs). Ändringar i leasingdatabasen som kräver att skriptet anropas köas i väntan på att en körande instans ska avslutas. Om denna köning tillåter att flera tillståndsändringar sker för en enda lease innan skriptet kan köras, kasseras tidigare tillstånd och det aktuella tillståndet för den leasen återspeglas när skriptet slutligen körs.

Vid start av dnsmasq kommer skriptet att anropas för alla befintliga leasingavtal när de läses från leasingfilen. Utgångna leasingavtal kommer att anropas med ”del” och andra med ’old’. När dnsmasq tar emot en HUP-signal kommer skriptet att anropas för befintliga leasingavtal med en ”old”-händelse.

Det finns ytterligare fem åtgärder som kan visas som det första argumentet till skriptet: ”init”, ”arp-add”, ”arp-del”, ”relay-snoop” och ’tftp’. Fler kan läggas till i framtiden, så skript bör skrivas så att de ignorerar okända åtgärder. ”init” beskrivs nedan i --leasefile-ro

Åtgärden ”tftp” aktiveras när en TFTP-filöverföring slutförs: argumenten är filstorleken i byte, adressen till vilken filen skickades och filens fullständiga sökväg.

Åtgärden ”relay-snoop” aktiveras när dnsmasq är konfigurerat som en DHCP relä för DHCPv6 och det vidarebefordrar en prefx-delegering till en klient. Argumenten är namnet på gränssnittet där klienten är ansluten, dess (lokal) adress på det gränssnittet och det delegerade prefixet. Denna information är tillräcklig för att installera rutter till det delegerade prefixet för en router. Se --dhcp-relay för mer information om konfigurering av DHCP-relä.

Åtgärderna ”arp-add” och ”arp-del” anropas endast om de är aktiverade med --script-arp De förses med en MAC-adress och IP-adress som argument. ”arp-add” indikerar att en ny post har kommit in i ARP- eller grannbordet, och ”arp-del” indikerar att samma post har raderats.

Ange ett skript skrivet i Lua som ska köras när leasingavtal skapas, förstörs eller ändras. För att kunna använda detta alternativ måste dnsmasq kompileras med rätt stöd. Lua-tolken initialiseras en gång när dnsmasq startar, så att globala variabler kvarstår mellan leasinghändelser.
Lua-koden måste definiera en lease -funktion och kan tillhandahålla init - och shutdown -funktioner, som anropas utan argument när dnsmasq startar och avslutas. Den kan också tillhandahålla en tftp -funktion.

Funktionen lease tar emot den information som beskrivs i --dhcp-script. Den får två argument, först åtgärden, som är en sträng som innehåller ”add”, ’old’ eller ”del”, och sedan en tabell med taggvärde par. Taggarna motsvarar mestadels de miljövariabler som beskrivs ovan, till exempel innehåller taggen ”domain” samma data som miljövariabeln DNSMASQ_DOMAIN. Det finns några extra taggar som innehåller data som anges som argument till --dhcp-script.

Dessa är mac_address, ip_address och hostname för IPv4, samt client_duid, ip_address och hostname för IPv6.

Funktionen tftp anropas på samma sätt som funktionen lease, och tabellen innehåller taggarna destination_address, file_name och file_size.

Funktionerna arp och arp-old anropas endast när de är aktiverade med --script-arp och har en tabell som innehåller taggarna mac_address och client_address.

Ange användaren som ska köra lease-change-skriptet eller Lua-skriptet. Standardvärdet är root, men kan ändras till en annan användare med hjälp av denna flagga.
Aktivera funktionerna ”arp” och ”arp-old” i --dhcp-script och --dhcp-luascript.
-9, --leasefile-ro
Undvik helt användning av leasingdatabasfilen. Filen kommer inte att skapas, läsas eller skrivas. Ändra sättet på vilket lease-change -skriptet (om ett sådant finns) anropas, så att leasingdatabasen kan underhållas i extern lagring av skriptet. Utöver de anrop som anges i --dhcp-script anropas lease-change-skriptet en gång, vid start av dnsmasq, med det enda argumentet ”init”. När det anropas på detta sätt ska skriptet skriva den sparade statusen för leasingdatabasen, i dnsmasq leasefile-format, till stdout och avslutas med utgångskod noll. Om denna option ställs in tvingas också leasechange-skriptet att anropas vid ändringar av klient-id och leasinglängd och utgångstid.
Anropa DHCP-skriptet när leasingens utgångstid ändras, till exempel när leasingen förnyas.
Behandla DHCP-förfrågningar (v4 och v6) och IPv6 Router Solicit-paket som anländer till något av <alias>-gränssnitten som om de hade anlänt till <interface>. Detta alternativ gör det möjligt för dnsmasq att tillhandahålla DHCP- och RA-tjänster över oadresserade och obryggade Ethernet-gränssnitt, t.ex. på en OpenStack-beräkningsvärd där varje sådant gränssnitt är ett TAP-gränssnitt till en VM, eller som i ”gammal stil-bryggning” på BSD-plattformar. Ett efterföljande ’*’ jokertecken kan användas i varje <alias>.

Det är tillåtet att lägga till mer än ett alias med mer än ett --bridge-interface-alternativ eftersom --bridge-interface=int1,alias1,alias2 är exakt likvärdigt med --bridge-interface=int1,alias1 --bridge-interface=int1,alias2

DHCP-servern avgör vilka DHCP-intervall som kan användas för att tilldela en adress till en DHCP-klient baserat på det nätverk från vilket DHCP-förfrågan kommer och IP-konfigurationen för serverns gränssnitt på det nätverket. Alternativet shared-network utökar de tillgängliga undernäten (och därmed DHCP-intervall) utöver de undernät som är konfigurerade på ankomstgränssnittet.

Det första argumentet är antingen namnet på ett gränssnitt eller en adress som är konfigurerad på ett lokalt gränssnitt, och det andra argumentet är en adress som definierar ett annat undernät där adresser kan tilldelas.

För att vara användbart måste det finnas ett lämpligt dhcp-intervall som tillåter adressallokering på detta undernät och detta dhcp-intervall MÅSTE inkludera nätmasken.

Användning av shared-network kräver också extra hänsyn till routning. Dnsmasq har inte den vanliga informationen som den använder för att bestämma standardrutten, så standardrutealternativet (eller annan routning) MÅSTE konfigureras manuellt. Klienten måste ha en rutt till servern: om tvåadressformen av shared-network används måste denna vara till den första angivna adressen. Om gränssnitts-,adress , måste det finnas en rutt till alla adresser som är konfigurerade på gränssnittet.

Den tvåadressform av shared-network kan också användas med en DHCP-relä: den första adressen är reläets adress och den andra anger, som tidigare, ett extra subnät från vilket adresser kan tilldelas.

Anger DNS-domäner för DHCP-servern. Domäner kan anges villkorslöst (utan IP-intervall) eller för begränsade IP-intervall. Detta har två effekter: för det första gör det att DHCP-servern returnerar domänen till alla värdar som begär den, och för det andra anger det den domän som det är tillåtet för DHCP-konfigurerade värdar att göra anspråk på. Avsikten är att begränsa värdnamn så att en opålitlig värd på LAN inte kan annonsera sitt namn via DHCP som t.ex. ”microsoft.com” och fånga upp trafik som inte är avsedd för den. Om inget domänsuffix anges kommer alla DHCP värdnamn med en domändel (dvs. med en punkt) att förbjudas och loggas. Om suffix anges är värdnamn med en domändel tillåtna, förutsatt att domändelen matchar suffixet. Dessutom, när ett suffix är inställt, läggs suffixet till som en valfri domändel för värdnamn utan en domändel mitt nätverk kan jag till exempel ställa in --domain=thekelleys.org.uk och ha en maskin vars DHCP-värdnamn är ”laptop”. IP-adressen för den maskinen är tillgänglig från dnsmasq både som ’laptop’ och ”laptop.thekelleys.org.uk”.
Om domänen anges som ”#” läses domänen från det första ”search”-direktivet i /etc/resolv.conf (eller motsvarande).

Adressintervallet kan ha formen <ip-adress>,<ip-adress> eller <ip-adress>/<nätmask> eller bara en enda <ip-adress>. Se --dhcp-fqdn som kan ändra beteendet hos dnsmasq med domäner.

Om adressintervallet anges som ip-adress/nätverksstorlek, kan en ytterligare flagga ”local” anges, vilket har effekten att --local-deklarationer läggs till för framåt- och bakåt-DNS-frågor. T.ex. --domain=thekelleys.org.uk,192.168.0.0/24,local är identiskt med --domain=thekelleys.org.uk,192.168.0.0/24 --local=/thekelleys.org.uk/ - -local=/0.168.192.in-addr.arpa/

Adressintervallet kan också anges som ett nätverksgränssnittsnamn, i vilket fall alla subnät som för närvarande är tilldelade gränssnittet används för att matcha adressen. Detta gör det möjligt att ge värdar på olika fysiska subnät olika domäner på ett sätt som uppdateras automatiskt när gränssnittsadresserna ändras.

I standardläget infogar dnsmasq de okvalificerade namnen på DHCP-klienter i DNS. Av denna anledning måste namnen vara unika, även om två klienter med samma namn finns i olika domäner. Om en andra DHCP-klient dyker upp som har samma namn som en befintlig klient, överförs namnet till den nya klienten. Om --dhcp-fqdn är inställt ändras detta beteende: det okvalificerade namnet läggs inte längre in i DNS, utan endast det kvalificerade namnet. Två DHCP-klienter med samma namn kan båda behålla namnet, förutsatt att domändelen är olika (dvs. de fullständigt kvalificerade namnen skiljer sig åt). För att säkerställa att alla namn har en domändel måste det finnas minst --domain utan en adress angiven när --dhcp-fqdn är inställt.
Normalt, när dnsmasq ger en DHCP-lease, sätter det flaggor i FQDN -alternativet för att tala om för klienten att inte försöka en DDNS-uppdatering med sitt namn och IP-adress. Detta beror på att namn-IP-paret automatiskt läggs till i dnsmasq:s DNS-vy. Denna flagga undertrycker det beteendet, vilket är användbart, till exempel för att tillåta Windows-klienter att uppdatera Active Directory-servrar. Se RFC 4702 för detaljer.

Aktivera dnsmasq:s IPv6 Router Advertisement-funktion. DHCPv6 hanterar inte komplett nätverkskonfiguration på samma sätt som DHCPv4. Router upptäckt och (möjligen) prefixupptäckt för autonom adress hanteras av ett annat protokoll. När DHCP används behövs endast en delmängd av detta, och dnsmasq kan hantera det med hjälp av befintlig DHCP-konfiguration för att tillhandahålla de flesta data. När RA är aktiverat kommer dnsmasq att annonsera ett prefix för varje --dhcp-range, med standard router som relevant länklokal adress på maskinen som kör dnsmasq. Som standard är bitarna för ”hanterad adress” inställda och biten ”använd SLAAC” återställd. Detta kan ändras för enskilda undernät med hjälp av de nyckelord för läge som beskrivs i --dhcp-range. RFC6106 DNS-parametrar ingår i annonserna. Som standard skickas den relevanta länklokala adressen för den maskin som kör dnsmasq som rekursiv DNS-server. Om de anges används DHCPv6-alternativen dns-server och domain-search för DNS-servern (RDNSS) och domänsökningslistan (DNSSL).
Ställ in icke-standardvärden för routerannonser som skickas via ett gränssnitt. Prioritetsfältet för routern kan ändras från standardvärdet medium med t.ex. --ra-param=eth0,high. Intervallet mellan routerannonser kan ställas in (i sekunder) med --ra-param=eth0,60. Livslängden för rutten kan ändras eller ställas in till noll, vilket gör att en router kan annonsera prefix men inte en rutt via sig själv. --ra-param=eth0,0,0 (Ett värde på noll för intervallet betyder standardvärdet.) Alla fyra parametrar kan ställas in samtidigt. --ra-param=eth0,mtu:1280,low,60,1200

Gränssnittsfältet kan innehålla ett jokertecken.

Parametern mtu: kan vara ett godtyckligt gränssnittsnamn, i vilket fall MTU-värdet för det gränssnittet används. Detta är användbart för (t.ex.) att annonsera MTU för ett WAN-gränssnitt på andra gränssnitt i en router.

Fördröjer sändningen av DHCPOFFER- och PROXYDHCP-svar med minst det angivna antalet sekunder. Detta kan användas som en lösning på buggar i PXE-startfirmware som inte fungerar korrekt när det tar emot ett omedelbart svar. Detta alternativ tar hänsyn till den tid som redan har gått åt till väntan (t.ex. ping-kontroll) om sådan finns.
Aktiverar TFTP-serverfunktionen. Detta är avsiktligt begränsat till det som behövs för att nätverksstarta en klient. Endast läsning är tillåten; tsize- och blksize-tilläggen stöds (tsize stöds endast i oktett -läge). Utan ett argument tillhandahålls TFTP-tjänsten till samma uppsättning gränssnitt som DHCP-tjänsten.

Om listan över gränssnitt anges, definierar den vilka gränssnitt som tar emot TFTP-tjänsten.

Sök efter filer som ska överföras med TFTP relativt den angivna katalogen. När detta är inställt avvisas TFTP-sökvägar som innehåller ”..” för att förhindra att klienter kommer utanför den angivna roten. Absoluta sökvägar (som börjar med /) är tillåtna, men de måste ligga inom tftp-roten. Om det valfria gränssnittsargumentet anges används katalogen endast för TFTP-förfrågningar via det gränssnittet.
Avbryt inte start om angivna tftp-rotkataloger är otillgängliga.
Lägg till TFTP-klientens IP- eller hårdvaruadress som en sökvägsdel i slutet av TFTP-roten. Endast giltigt om --tftp-root är inställt och katalogen finns. Standardinställningen är att lägga till IP-adressen (i standardformat med punkter). . Om till exempel --tftp-root är ”/tftp” och klient 1.2.3.4 begär filen ’myfile’ blir den effektiva sökvägen ”/tftp/1.2.3.4/myfile” om /tftp/1.2.3.4 finns eller /tftp/myfile i annat fall. När ”=mac” anges läggs MAC-adressen till istället, med små bokstäver och nollor framför siffrorna separerade med bindestreck, t.ex.: 01-02-03-04-aa-bb Observera att det endast är möjligt att lösa MAC-adresser om klienten befinner sig i det lokala nätverket eller har erhållit en DHCP-lease från oss.
Aktivera TFTP-säkerhetsläge: utan detta är alla filer som kan läsas av dnsmasq-processen enligt normala Unix-åtkomstkontrollregler tillgängliga via TFTP. När flaggan --tftp -secure anges är endast filer som ägs av användaren som kör dnsmasq-processen tillgängliga. Om dnsmasq körs som root gäller andra regler: --tftp-secure har ingen effekt, utan endast filer som har biten för allmän läsbarhet inställd är tillgängliga. Det rekommenderas inte att köra dnsmasq som root med TFTP aktiverat, och absolut inte utan att ange --tftp-root. Om du gör det kan alla filer på servern som är läsbara för alla exponeras för alla värdar på nätet.
Konvertera filnamn i TFTP-förfrågningar till små bokstäver. Detta är användbart för förfrågningar från Windows-maskiner, som har filsystem som inte skiljer på versaler och gemener och tenderar att vara mindre noggranna med versaler och gemener i filnamn. Observera att dnsmasq:s tftp-server alltid konverterar ”\” till ”/” i filnamn.
Ställ in det maximala antalet samtidiga TFTP-anslutningar som tillåts. Detta är som standard 50. När ett stort antal TFTP-anslutningar betjänas kan begränsningar för filbeskrivare per process uppstå. Dnsmasq behöver en filbeskrivare för varje samtidig TFTP-anslutning och en filbeskrivare per unik fil (plus några andra). Att betjäna samma fil samtidigt till n klienter kommer alltså att kräva cirka n + 10 filbeskrivare,
medan att betjäna olika filer samtidigt till n klienter kommer att kräva ungefär (2*n) + 10 deskriptorer. Om --tftp-port-range anges kan det påverka antalet samtidiga anslutningar.
Använd storleken som tak för MTU som stöds av det mellanliggande nätverket när TFTP-blocksize förhandlas, och åsidosätt MTU-inställningen för det lokala gränssnittet om den är större.
Stoppa TFTP-servern från att förhandla om alternativet ”blocksize” med en klient. Vissa buggiga klienter begär detta alternativ men beter sig då dåligt när det beviljas.
En TFTP-server lyssnar på en välkänd port (69) för att initiera anslutningar, men den använder också en dynamiskt tilldelad port för varje anslutning. Normalt tilldelas dessa av operativsystemet, men detta alternativ anger ett portintervall som ska användas för TFTP-överföringar. Detta kan vara användbart när TFTP måste passera en brandvägg. Intervallets start kan inte vara lägre än 1025 om inte dnsmasq körs som root. Antalet samtidiga TFTP-anslutningar begränsas av storleken på portintervallet.
Kör i ett läge där TFTP-servern ENDAST använder den välkända porten (69) för sin ände av TFTP-överföringen. Detta gör att TFTP kan fungera när det finns NAT mellan klienten och servern. Observera att detta inte är helt kompatibelt med RFC:erna som specificerar TFTP-protokollet: använd på egen risk.
Ange en konfigurationsfil. När detta alternativ används läser dnsmasq inte standardkonfigurationsfilen (normalt /etc/dnsmasq.conf). Flera filer kan anges genom att upprepa alternativet antingen på kommandoraden eller i konfigurationsfiler. Ett filnamn på ”-” gör att dnsmasq läser konfigurationen från stdin.
-7, --conf-dir=<katalog>[,<filändelse>......],
Läs alla filer i den angivna katalogen som konfigurationsfiler.
Om filändelser anges, hoppas alla filer som slutar på dessa filändelser över. Alla filer vars namn slutar på ~ eller börjar med . eller börjar och slutar med # hoppas alltid över. Om filändelsen börjar med * laddas endast filer som har den filändelsen. Så --conf-dir=/path/to/dir,*.conf laddar alla filer med suffixet .conf i /path/to/dir. Denna flagga kan anges på kommandoraden eller i en konfigurationsfil. Om du anger den på kommandoraden, se till att eskapera *-tecken. Filerna laddas i alfabetisk ordning efter filnamn.
Ett specialfall av --conf-file som skiljer sig på två sätt. För det första är endast --server och --rev-server tillåtna i den inkluderade konfigurationsfilen. För det andra läses filen om och konfigurationen där uppdateras när dnsmasq tar emot SIGHUP.
Kör <fil> och behandla det som skickas till stdout som innehållet i en konfigurationsfil. Om skriptet avslutas med en exitkod som inte är noll, behandlar dnsmasq detta som ett allvarligt fel. Skriptet kan förses med argument, separerade med mellanslag från filnamnet och varandra, till exempel --conf-dir=”/etc/dnsmasq-uncompress-ads /share/ads-domains.gz”

med /etc/dnsmasq-uncompress-ads innehållande

set -e

zcat ${1} | sed -e ”s:^:address=/:” -e ”s:$:/:”

exit 0

och /share/ads-domains.gz som innehåller en komprimerad lista över annonsserverdomäner sparar diskutrymme med stora annonsserverblocklistor.

Svara inte på klass CHAOS och typ TXT i domänbindningsfrågor.

Om detta alternativ inte är inställt är cache-statistiken också tillgänglig i DNS som svar på frågor av klass CHAOS och typ TXT i domänbindning. Domännamnen är cachesize.bind, insertions.bind, evictions.bind, misses.bind, hits.bind, auth.bind och servers.bind om de inte inaktiverats vid kompilering. Ett exempel på ett kommando för att fråga detta, med hjälp av verktyget dig,
skulle vara

dig +short chaos txt cachesize.bind

Det maximala antalet samtidiga TCP-anslutningar. Applikationen förgrenar sig för att hantera varje TCP-förfrågan. Standardvärdet är 20.

Vid start läser dnsmasq /etc/dnsmasq.conf, om den finns. (På FreeBSD är filen /usr/local/etc/dnsmasq.conf)
(men se --conf-file och --conf-dir alternativen.) Formatet för denna fil består av ett alternativ per rad, precis som de långa alternativen som beskrivs i avsnittet ALTERNATIV, men utan inledande ”--”. Rader som börjar med # är kommentarer och ignoreras. För alternativ som endast kan anges en gång åsidosätter konfigurationsfilen kommandoraden. Citat är tillåtna i en konfigurationsfil: mellan "-citat tas den speciella betydelsen av ,:. och # bort och följande escape-tecken är tillåtna: \  \" \t \e \b \r och \n. De senare motsvarar tabb, escape, backspace, retur och ny rad.

När den tar emot ett SIGHUP, dnsmasq rensar sin cache och laddar sedan om /etc/hosts och /etc/ethers och alla filer som anges av --dhcp-hostsfile, --dhcp-hostsdir, --dhcp-optsfile, --dhcp-optsdir, --addn-hosts eller --hostsdir. Skriptet för ändring av DHCP-leasing kallas för alla befintliga DHCP-leasingavtal. Om --no-poll är inställt läser SIGHUP också om /etc/resolv.conf. SIGHUP läser INTE om konfigurationsfilen.

När det tar emot ett SIGUSR1, dnsmasq skriver statistik till systemloggen. Den skriver cacheminnets storlek, antalet namn som har behövt tas bort från cacheminnet innan de löpt ut för att göra plats för nya namn och det totala antalet namn som har lagts in i cacheminnet. Antalet cache-träffar och missar samt antalet auktoritativa frågor som besvarats anges också. För varje uppströms server anges antalet skickade frågor och antalet som resulterade i ett fel. Det ger också information om antalet förgreningar för TCP-anslutningar. I --no-daemon -läge eller när fullständig loggning är aktiverad (--log-queries) görs en fullständig dumpning av innehållet i cachen.

När den tar emot SIGUSR2 och loggar direkt till en fil (se --log-facility ) dnsmasq stänger och öppnar loggfilen igen. Observera att under denna operation kommer dnsmasq inte att köras som root. När den först skapar loggfilen ändrar dnsmasq ägarskapet för filen till den icke-root-användare som den kommer att köras som. Logrotate bör konfigureras för att skapa en ny loggfil med ägarskapet som matchar det befintliga innan SIGUSR2 skickas. Om TCP DNS-förfrågningar pågår kommer den gamla loggfilen att förbli öppen i barnprocesser som hanterar TCP-förfrågningar och kan fortsätta att skrivas. Det finns en gräns på 150 sekunder, efter vilken alla befintliga TCP -processer ha löpt ut: av denna anledning är det inte klokt att konfigurera loggfilskomprimering för loggfiler som just har roterats. Med logrotate är de nödvändiga alternativen create och delaycompress.

Dnsmasq är en DNS-frågevidarebefordrare: den kan inte rekursivt svara på godtyckliga frågor som börjar från rotservrarna, men vidarebefordrar sådana frågor till en fullständigt rekursiv uppströms DNS-server som vanligtvis tillhandahålls av en internetleverantör. Som standard läser dnsmasq /etc/resolv.conf för att upptäcka IP-adresserna för de uppströmsnamnsservrar som den ska använda, eftersom informationen vanligtvis lagras där. Om inte --no-poll används, dnsmasq kontrollerar ändringstidpunkten för /etc/resolv.conf (eller motsvarande om --resolv-file används) och läser den igen om den ändras. Detta gör det möjligt att ställa in DNS-servrarna dynamiskt med PPP eller DHCP, eftersom båda protokollen tillhandahåller informationen. Avsaknaden av /etc/resolv.conf är inte ett fel eftersom den kanske inte har skapats innan en PPP-anslutning finns. Dnsmasq fortsätter helt enkelt att kontrollera om /etc/resolv.conf skapas vid någon tidpunkt. Dnsmasq kan instrueras att analysera mer än en resolv.conf -fil. Detta är användbart på en bärbar dator, där både PPP och DHCP kan användas: dnsmasq kan ställas in för att avfråga både /etc/ppp/resolv.conf och /etc/dhcpc/resolv.conf och kommer att använda innehållet i den som ändrats senast, vilket ger automatisk växling mellan DNS-servrar.

Uppströms servrar kan också anges på kommandoraden eller i konfigurationsfilen. Dessa serverspecifikationer tar valfritt ett domännamn som talar om för dnsmasq att endast använda den servern för att hitta namn i den specifika domänen.

För att konfigurera dnsmasq så att den fungerar som cache för den värd där den körs, lägg till ”nameserver 127.0.0.1” i /etc/resolv.conf för att tvinga lokala processer att skicka förfrågningar till dnsmasq. Ange sedan antingen uppströmservrarna direkt till dnsmasq med hjälp av --server -alternativen eller lägg in deras adresser i en annan fil, till exempel /etc/resolv.dnsmasq och kör dnsmasq med --resolv-file /etc/resolv.dnsmasq -alternativet. Den andra tekniken möjliggör dynamisk uppdatering av serveradresserna med PPP eller DHCP.

Adresser i /etc/hosts kommer att ”skugga” olika adresser för samma namn i uppströms-DNS, så ”mycompany.com 1.2.3.4” i /etc/hosts säkerställer att frågor om ”mycompany.com” alltid returnerar 1.2.3.4 även om frågor i uppströms DNS annars skulle returnera en annan adress. Det finns ett undantag från detta: om uppströms DNS innehåller ett CNAME som pekar på ett skuggat namn, kommer sökning av CNAME via dnsmasq att resultera i den oskuggade adressen som är associerad med målet för CNAME. För att komma runt detta, lägg till CNAME till /etc/hosts så att CNAME också skuggas.

Taggsystemet fungerar enligt följande: dnsmasq taggar varje DHCP-förfrågan med taggar från tillämpliga konfigurationsrader som innehåller set:<tag>, dvs.

set:<tag> från --dhcp-range som används för att tilldela adressen;

set:<tag> från alla matchande --dhcp-host (plus taggen known eller known-othernet).

BOOTP-förfrågningar taggas med bootp. Varje förfrågan taggas också med namnet på det gränssnitt som förfrågan anlände till.

Varje konfigurationsrad som innehåller en eller flera tag:<tag>-konstruktioner gäller när alla dess taggar finns i begäran. Det vill säga:

Konfigurationstagg:A gäller för en begäran som är märkt med A.

Konfigurationstagg:B gäller för en begäran som är märkt med B.

Konfigurationstagg:A+B gäller inte för en begäran som är märkt med A.

Konfigurationstagg:A+B gäller inte för en begäran som är märkt med B.

Konfigurationstaggarna:A+B, tagg:A, tagg:B gäller för en begäran som är märkt med A+B.

set:<tag>-konstruktioner i --dhcp-range- och --dhcp-host-taggförfrågningar.

Använd tag:<tag>s i --dhcp-options för att matcha set:<tag> och tillämpa konfigurationer.

En --dhcp-option med tag:<tag> föredras framför en otaggad --dhcp-option, förutsatt att all dess taggar matchar någonstans i uppsättningen som samlats ovan.

Taggprefixet ’!’ betyder ’inte’. --dhcp-option=tag:!purple,3,1.2.3.4 skickar alternativet när begäran inte är taggad med purple. (Skalets metatecken ’!’ måste undvikas på kommandoraden men inte i en konfigurationsfil).

När man väljer --dhcp-options är en --dhcp-range-tagg underordnad andra taggar, för att göra det enkelt att åsidosätta alternativ för enskilda värdar, så:

--dhcp-range=set:interface1,......

--dhcp-host=set:myhost,.....

--dhcp-option=tag:interface1,option:nis-domain,”domain1”

--dhcp-option=tag:myhost,option:nis-domain,”domain2”

ställer in NIS-domänen till domain1 för värdar i intervallet, men till domain2 för en viss värd som kan eller inte kan falla inom intervallet.

Observera att för --dhcp-range är både tag:<tag> och

set:<tag> möjliga, för att både välja intervallet som används baserat på (t.ex.) --dhcp-host och för att påverka de alternativ som skickas, baserat på det valda intervallet.

Taggsystemet har utvecklats från ett tidigare, mer begränsat system. För bakåtkompatibilitet kan ”net:” användas istället för ”tag:” och ”set:” kan uteslutas. (Förutom i --dhcp-host, där ”net:” kan användas istället för ”set:”. ) Av samma anledning kan ’#’ användas istället för ’!’ för att ange NOT.

DHCP-servern i dnsmasq fungerar också som en BOOTP-server, förutsatt att MAC-adressen och IP-adressen för klienterna anges, antingen med hjälp av --dhcp-host konfigurationer eller i /etc/ethers,
och ett --dhcp-range finns för att aktivera DHCP-servern på ett visst nätverk. (Inställningen --bootp-dynamic eliminerar behovet av statiska adressmappningar.) Parametern filnamn i en BOOTP-begäran används som en tagg, liksom taggen bootp, vilket möjliggör viss kontroll över de alternativ som returneras till olika klasser av värdar.

Att konfigurera dnsmasq för att fungera som en auktoritativ DNS-server är komplicerat eftersom det innebär konfiguration av externa DNS-servrar för att tillhandahålla delegering. Vi kommer att gå igenom tre scenarier med ökande komplexitet. Förutsättningar för alla dessa scenarier är en globalt tillgänglig IP-adress, en A- eller AAAA-post som pekar på den adressen och en extern DNS-server som kan delegera zonen i fråga. I den första delen av denna förklaring kallar vi A- (eller AAAA-)posten för den globalt tillgängliga adressen server.example.com och zonen för vilken dnsmasq är auktoritativ vår.zone.com.

Den enklaste konfigurationen består av två rader i dnsmasq-konfigurationen, ungefär så här

--auth-server=server.example.com,eth0
--auth-zone=our.zone.com,1.2.3.0/24

och två poster i den externa DNS

server.example.com A 192.0.43.10
our.zone.com NS server.example.com

eth0 är det externa nätverksgränssnittet som dnsmasq lyssnar på och har (globalt tillgänglig) adress 192.0.43.10.

Observera att den externa IP-adressen mycket väl kan vara dynamisk (dvs. tilldelad av en ISP via DHCP eller PPP). Om så är fallet måste A-posten länkas till denna dynamiska tilldelning av ett av de vanliga dynamiska DNS-systemen.

En mer komplex, men praktiskt användbar konfiguration har adress posten för den globalt tillgängliga IP-adressen som finns i den auktoritativa zonen som dnsmasq betjänar, vanligtvis i roten. Nu har vi

--auth-server=our.zone.com,eth0
--auth-zone=our.zone.com,1.2.3.0/24

our.zone.com A 1.2.3.4
our.zone.com NS our.zone.com

A-posten för our.zone.com har nu blivit en limpost, den löser hönan-och-ägget-problemet med att hitta IP-adressen till namnservern för our.zone.com när A-posten finns inom den zonen.
Observera att detta är den enda funktionen för denna post: eftersom dnsmasq nu är auktoritativ från our.zone.com måste den också tillhandahålla denna post. Om den externa adressen är statisk kan detta göras med en /etc/hosts -post eller --host-record.

--auth-server=our.zone.com,eth0
--host-record=our.zone.com,1.2.3.4
--auth-zone=our.zone.com,1.2.3.0/24

Om den externa adressen är dynamisk måste adressen som är associerad med our.zone.com härledas från adressen för det relevanta gränssnittet. Detta görs med hjälp av --interface-name Något i stil med:

--auth-server=our.zone.com,eth0
--interface-name=our.zone.com,eth0
--auth-zone=our.zone.com,1.2.3.0/24,eth0

(Argumentet ”eth0” i --auth-zone lägger till det subnät som innehåller eth0:s dynamiska adress till zonen, så att --interface-name returnerar adressen i externa frågor.)

Vår slutliga konfiguration bygger på ovanstående, men lägger också till en sekundär DNS-server. Detta är en annan DNS-server som lär sig DNS-data för zonen genom att göra zonöverföringar och fungerar som en backup om den primära servern blir otillgänglig. Konfigurationen av den sekundära servern ligger utanför ramen för denna man-sida, men den extra konfigurationen av dnsmasq är enkel:

--auth-sec-servers=secondary.myisp.com

och

our.zone.com NS secondary.myisp.com

Genom att lägga till auth-sec-servers aktiveras zonöverföring i dnsmasq, så att sekundärservern kan samla in DNS-data. Om du vill begränsa dessa data till vissa värdar kan du använda

--auth-peer=<IP-adress för sekundärservern>

Dnsmasq fungerar som en auktoritativ server för in-addr.arpa- och ip6.arpa-domäner som är associerade med de subnät som anges i --auth-zone -deklarationer, så omvända (adress till namn) uppslagningar kan enkelt konfigureras med en lämplig NS-post, till exempel i detta exempel, där vi tillåter 1.2.3.0/24-adresser.

3.2.1.in-addr.arpa NS our.zone.com

Observera att omvända zoner (in-addr.arpa och ip6.arpa) för närvarande inte är tillgängliga i zonöverföringar, så det är ingen mening med att ordna sekundära servrar för omvända sökningar.

När dnsmasq är konfigurerat för att fungera som en auktoritativ server används följande data för att fylla den auktoritativa zonen.

--mx-host, --srv-host, --dns-rr, --txt-record, --naptr-record, --caa-record, så länge postnamnen finns i den auktoritativa domänen.

--synth-domain så länge domänen finns i den auktoritativa zonen och, för omvända (PTR) frågor, adressen finns i relevant subnät.

--cname så länge postnamnet finns i den auktoritativa domänen. Om målet för CNAME är okvalificerat, kvalificeras det med det auktoritativa zonnamnet. CNAME som används på detta sätt (endast) kan vara jokertecken, som i

--cname=*.example.com,default.example.com

IPv4- och IPv6-adresser från /etc/hosts (och --addn-hosts)
och --host-record och --interface-name och ---dynamic-host förutsatt att adressen faller inom ett av de subnät som anges i --auth-zone.

Adresser för DHCP-leasingavtal, förutsatt att adressen faller inom ett av de undernät som anges i --auth-zone. (Om konstruerade DHCP-intervall används, som beror på den adress som dynamiskt tilldelas ett gränssnitt, bör formen --auth-zone som definierar undernät efter ett gränssnitts dynamiska adress användas för att säkerställa att detta villkor uppfylls.)

I standardläget, där en DHCP-lease har ett okvalificerat namn och eventuellt ett kvalificerat namn som konstruerats med --domain,
konstrueras namnet i den auktoritativa zonen från det okvalificerade namnet och zonens domän. Detta kan vara samma som det som anges av --domain Om --dhcp-fqdn är inställt, används de fullständigt kvalificerade namnen som är associerade med DHCP-leasingavtalen och måste matcha zonens domän.

0 - Dnsmasq har framgångsrikt förgrenats till bakgrunden eller avslutats normalt om bakgrundskörning inte är aktiverad.

1 - Ett problem med konfigurationen upptäcktes.

2 - Ett problem med nätverksåtkomst uppstod (adress i bruk, försök att använda privilegierade portar utan tillstånd).

3 - Ett problem uppstod med en filsystemoperation (saknad fil/katalog, behörigheter).

4 - Fel vid minnesallokering.

5 - Annat diverse problem.

11 eller högre - en returkod som inte är noll mottogs från lease-script-processen ”init”-anrop eller en --conf-script -fil. Avslutningskoden från dnsmasq är -skriptets avslutningskod med 10 tillagt.

Standardvärdena för resursbegränsningar i dnsmasq är i allmänhet konservativa och lämpliga för inbäddade routertypsenheter med långsamma processorer och begränsat minne. På mer kapabel hårdvara är det möjligt att öka begränsningarna och hantera många fler klienter. Följande gäller för dnsmasq-2.37: tidigare versioner skalade inte lika bra.

Dnsmasq kan hantera DNS och DHCP för minst tusen klienter. DHCP-leasingtiderna bör inte vara för korta (mindre än en timme). Värdet för --dns-forward-max kan ökas: börja med ett värde som motsvarar antalet klienter och öka det om DNS verkar långsamt. Observera att DNS prestanda också beror på prestandan hos uppströms namnservrar. Storleken på DNS-cachen kan ökas: den hårda gränsen är 10000 namn och standardvärdet (150) är mycket lågt. Om du skickar SIGUSR1 till dnsmasq loggar den information som är användbar för att justera cacheminnets storlek. Se avsnittet NOTES för mer information.

Den inbyggda TFTP-servern kan hantera många samtidiga filöverföringar : den absoluta gränsen är relaterad till antalet filhanterare som tillåts för en process och förmågan hos systemanropet select() att hantera ett stort antal filhanterare. Om gränsen är för hög med

--tftp-max kommer den att skalas ned och den faktiska gränsen loggas vid start. Observera att fler överföringar är möjliga när samma fil skickas än när varje överföring skickar en annan fil.

Det är möjligt att använda dnsmasq för att blockera webbannonsering genom att använda en lista över kända bannerannonsservrar, som alla löser till 127.0.0.1 eller 0.0.0.0, i /etc/hosts eller en ytterligare hosts-fil. Listan kan vara mycket lång, dnsmasq har testats framgångsrikt med en miljon namn. En fil av den storleken kräver en 1 GHz-processor och cirka 60 MB RAM.

Dnsmasq kan kompileras för att stödja internationalisering. För att göra detta bör målen ”all-i18n” och ”install-i18n” användas istället för standardmålen ’all’ och ”install”. När internationalisering är kompilerad kommer dnsmasq att producera loggmeddelanden på det lokala språket och stödja internationaliserade domännamn (IDN). Domän namn i /etc/hosts, /etc/ethers och /etc/dnsmasq.conf som innehåller icke-ASCII-tecken kommer att översättas till DNS-intern punycode -representation. Observera att dnsmasq bestämmer både språket för meddelanden och den antagna teckensatsen för konfigurationsfiler från miljövariabeln LANG. Detta bör ställas in till systemets standardvärde av det skript som ansvarar för att starta dnsmasq. När du redigerar konfigurationsfilerna, var noga med att göra det med endast systemets standardlokalisering och inte en användarspecifik, eftersom dnsmasq inte har något direkt sätt att bestämma vilken teckenuppsättning som används och måste anta att det är systemets standard.

/etc/dnsmasq.conf

/usr/local/etc/dnsmasq.conf

/etc/resolv.conf /var/run/dnsmasq/resolv.conf /etc/ppp/resolv.conf /etc/dhcpc/resolv.conf

/etc/hosts

/etc/ethers

/var/lib/misc/dnsmasq.leases

/var/db/dnsmasq.leases

/var/run/dnsmasq.pid

hosts(5), resolver(5)

Denna manual sida är skriven av Simon Kelley <simon@thekelleys.org.uk>.