DNSMASQ(8) System Manager's Manual DNSMASQ(8)

dnsmasq - سرور سبک‌وزن برای DHCP و حافظه نهان DNS

dnsmasq [OPTION]...

dnsmasq یک سرور سبک‌وزن برای DNS، TFTP، PXE، اعلان مسیریاب (router advertisement) و DHCP است. این برنامه با هدف ارائه خدمات هماهنگ و یکپارچه DNS و DHCP به یک شبکه محلی (LAN) طراحی شده است.

برنامه Dnsmasq پرس‌وجوهای DNS را می‌پذیرد و یا از طریق یک حافظه نهان محلی و کوچک به آن‌ها پاسخ می‌دهد یا آن‌ها را به یک سرور DNS بازگشتی واقعی هدایت می‌کند. این برنامه محتویات فایل /etc/hosts را بارگذاری می‌کند تا نام‌های میزبان محلی که در DNS سراسری وجود ندارند قابل حل‌وفصل باشند و همچنین به پرس‌وجوهای DNS برای میزبان‌های پیکربندی‌شده با DHCP پاسخ می‌دهد. همچنین می‌تواند به عنوان سرور DNS معتبر (authoritative) برای یک یا چند دامنه عمل کند و اجازه دهد نام‌های محلی در DNS سراسری ظاهر شوند. علاوه بر این می‌تواند برای اعتبارسنجی DNSSEC نیز پیکربندی شود.

سرور DHCP در dnsmasq از انتساب آدرس‌های ایستا و چندین شبکه پشتیبانی می‌کند. این برنامه به طور خودکار مجموعه‌ای منطقی از گزینه‌های پیش‌فرض DHCP را ارسال می‌کند و می‌تواند برای ارسال هر مجموعه دلخواهی از گزینه‌های DHCP، از جمله گزینه‌های بسته‌بندی‌شده مختص سازنده (vendor-encapsulated)، پیکربندی شود. این برنامه شامل یک سرور TFTP امن و فقط‌خواندنی است که بوت تحت شبکه/PXE را برای میزبان‌های DHCP امکان‌پذیر می‌سازد و همچنین از BOOTP پشتیبانی می‌کند. پشتیبانی از PXE کامل است و شامل حالت پراکسی نیز می‌شود که اطلاعات PXE را در اختیار کلاینت‌ها قرار می‌دهد، در حالی که تخصیص آدرس DHCP توسط سرور دیگری انجام می‌شود.

سرور DHCPv6 در dnsmasq همان مجموعه قابلیت‌های سرور DHCPv4 را ارائه می‌دهد و علاوه بر آن، شامل اعلان‌های مسیریاب و قابلیتی کاربردی است که امکان نام‌گذاری کلاینت‌هایی را که از DHCPv4 و خودپیکربندی بدون‌وضعیت (stateless autoconfiguration) صرفاً برای پیکربندی IPv6 استفاده می‌کنند، فراهم می‌سازد. همچنین از تخصیص آدرس (هم DHCPv6 و هم RA) از زیرشبکه‌هایی که به صورت پویا از طریق واگذاری پیشوند DHCPv6 تفویض شده‌اند، پشتیبانی می‌کند.

برنامه Dnsmasq با در نظر گرفتن سامانه‌های تعبیه‌شده (embedded) کوچک کدنویسی شده است. هدف آن اشغال کمترین میزان ممکن حافظه متناسب با قابلیت‌های پشتیبانی‌شده است و اجازه می‌دهد تا عملکردهای غیرضروری از باینری کامپایل‌شده حذف شوند.

توجه داشته باشید که به طور کلی ذکر نکردن پارامترها مجاز بوده و باعث غیرفعال شدن عملکردها می‌شود؛ به عنوان مثال --pid-file نوشتن فایل PID را غیرفعال می‌کند. در سیستم‌های BSD، مگر در صورتی که کتابخانه GNU getopt پیوند (link) داده شده باشد، شکل طولانی گزینه‌ها در خط فرمان کار نمی‌کند؛ با این حال همچنان در فایل پیکربندی شناسایی می‌شود.

خواندن و بررسی نحو (syntax) فایل(های) پیکربندی. در صورت صحیح بودن همه موارد با کد 0 خارج می‌شود، و در غیر این صورت با یک کد غیرصفر خروج می‌کند. برنامه dnsmasq را راه‌اندازی نمی‌کند.
نمایش تمام گزینه‌های خط فرمان. --help dhcp گزینه‌های پیکربندی شناخته‌شده DHCPv4 را نمایش می‌دهد، و --help dhcp6 گزینه‌های DHCPv6 را نمایش خواهد داد.
نام‌های میزبان موجود در /etc/hosts را نمی‌خواند.
فایل میزبان‌های اضافی. فایل مشخص‌شده را همراه با /etc/hosts می‌خواند. اگر --no-hosts داده شده باشد، فقط فایل مشخص‌شده را می‌خواند. این گزینه را می‌توان برای بیش از یک فایل میزبان اضافی تکرار کرد. اگر یک دایرکتوری مشخص شود، تمام فایل‌های موجود در آن دایرکتوری به ترتیب حروف الفبا خوانده می‌شوند.
تمام فایل‌های میزبان موجود در دایرکتوری را می‌خواند. فایل‌های جدید یا تغییریافته به طور خودکار خوانده می‌شوند و رکوردهای فایل‌های تغییریافته و حذف‌شده به صورت خودکار پاک می‌شوند.
افزودن دامنه به نام‌های ساده (بدون نقطه) در /etc/hosts به همان روشی که برای نام‌های حاصل از DHCP انجام می‌شود. توجه داشته باشید که این موضوع برای نام‌های دامنه در cnameها، رکوردهای PTR، رکوردهای TXT و غیره اعمال نمی‌شود.
هنگام پاسخ با اطلاعات برگرفته از /etc/hosts، پیکربندی یا فایل اجاره‌های DHCP، برنامه dnsmasq به طور پیش‌فرض فیلد طول عمر (time-to-live یا TTL) را روی صفر تنظیم می‌کند؛ بدین معنا که درخواست‌کننده نباید خودش این اطلاعات را در حافظه نهان ذخیره کند. این کار تقریباً در تمامی شرایط رفتار درستی است. این گزینه اجازه می‌دهد یک مقدار طول عمر (به ثانیه) برای این پاسخ‌ها تعیین شود. این کار بار روی سرور را کاهش می‌دهد، اما در برخی شرایط ممکن است کلاینت‌ها از داده‌های قدیمی استفاده کنند.
مشابه --local-ttl، اما فقط بر پاسخ‌های حاوی اطلاعات حاصل از اجاره‌های DHCP تأثیر می‌گذارد. اگر هر دو مشخص شوند، --dhcp-ttl برای اطلاعات DHCP و --local-ttl برای سایر موارد اعمال می‌شود. تنظیم این مقدار روی صفر، اثر --local-ttl را برای DHCP خنثی می‌کند.
پاسخ‌های منفی از سرورهای بالادستی معمولاً حاوی اطلاعات طول عمر در رکوردهای SOA هستند که dnsmasq از آن‌ها برای ذخیره در حافظه نهان استفاده می‌کند. اگر پاسخ‌های سرورهای بالادستی فاقد این اطلاعات باشند، dnsmasq پاسخ را کَش نمی‌کند. این گزینه یک مقدار پیش‌فرض برای طول عمر (به ثانیه) مشخص می‌کند که dnsmasq برای ذخیره پاسخ‌های منفی حتی در غیاب رکورد SOA از آن بهره می‌برد.
تنظیم حداکثر مقدار TTL که به کلاینت‌ها تحویل داده می‌شود. اگر حداکثر TTL مشخص‌شده کمتر باشد، به جای مقدار واقعی TTL به کلاینت‌ها تحویل داده خواهد شد. با این حال مقدار واقعی TTL در حافظه نهان نگهداری می‌شود تا از ارسال سیل‌آسای درخواست‌ها به سرورهای DNS بالادستی جلوگیری شود.
تنظیم حداکثر مقدار TTL برای مدخل‌های موجود در حافظه نهان.
تمدید مقادیر کوتاه TTL به زمان مشخص‌شده هنگام ذخیره آن‌ها در حافظه نهان. توجه داشته باشید که تمدید ساختگی مقادیر TTL عموماً ایده بدی است؛ این کار را انجام ندهید مگر آنکه دلیل خوبی داشته باشید و بدانید چه می‌کنید. برنامه Dnsmasq مقدار این گزینه را به یک ساعت محدود می‌کند، مگر اینکه مجدداً کامپایل شود.
تنظیم مقدار TTL بازگردانده‌شده در پاسخ‌های سرور معتبر.
در شرایط عادی، dnsmasq برای انجام تلاش‌های مجدد به کلاینت‌های DNS اتکا می‌کند؛ خود برنامه زمان‌بندی وقفه ایجاد نمی‌کند. تنظیم این گزینه به dnsmasq دستور می‌دهد تلاش‌های مجدد اختصاصی خود را پس از یک تأخیر که پیش‌فرض آن 1000 میلی‌ثانیه است آغاز کند. اگر پارامتر دوم ارائه شود، مدت زمان ادامه تلاش‌های مجدد را کنترل می‌کند، در غیر این صورت پیش‌فرض آن 10000 میلی‌ثانیه است. تلاش‌های مجدد با روش پس‌نشینی نمایی تکرار می‌شوند. استفاده از این گزینه مصرف حافظه و پهنای باند شبکه را افزایش می‌دهد. در صورت عدم پیکربندی دیگر، این گزینه هنگام تنظیم --dnssec با پارامترهای پیش‌فرض فعال می‌شود.
در هنگام راه‌اندازی به پس‌زمینه نرود اما در سایر موارد به صورت عادی اجرا شود. این گزینه برای مواقعی در نظر گرفته شده که dnsmasq تحت نظارت daemontools یا launchd اجرا می‌شود.
حالت عیب‌یابی: به پس‌زمینه چنگال نزند، فایل pid ننویسد، شناسه کاربر را تغییر ندهد، با دریافت سیگنال SIGUSR1 یک نسخه تخلیه کامل از حافظه نهان تولید کند، لاگ‌ها را به stderr و همچنین syslog بفرستد، و برای رسیدگی به پرس‌وجوهای TCP فرآیندهای جدید منشعب نکند. توجه داشته باشید که این گزینه فقط برای عیب‌یابی کاربرد دارد؛ برای جلوگیری از رفتن dnsmasq به پس‌زمینه در محیط عملیاتی، از گزینه --keep-in-foreground استفاده کنید.
ثبت گزارش نتایج پرس‌وجوهای DNS رسیدگی‌شده توسط dnsmasq. فعال‌سازی تخلیه کامل حافظه نهان با دریافت SIGUSR1. اگر آرگومان "extra" ارائه شود، یعنی --log-queries=extra آن‌گاه لاگ حاوی اطلاعات اضافی در ابتدای هر خط خواهد بود. این اطلاعات شامل یک شماره سریال است که خطوط لاگ مربوط به یک پرس‌وجوی مشخص را به هم پیوند می‌دهد، همراه با آدرس IP درخواست‌کننده. اگر آرگومان "proto" ارائه شود، تمام اطلاعات "extra" و همچنین پروتکل شبکه مورد استفاده برای تبادل پرس‌وجوها را نشان می‌دهد. ثبت گزارش تنها برای پرس‌وجوهای ارسالی به سرور معتبر را می‌توان با --log-queries=auth و ثبت لاگ فقط برای پاسخ‌های ناموفق (Error، NXDOMAIN یا NODATA) را می‌توان با --log-queries=only_failed پیکربندی کرد.
-8, --log-facility=<facility>
تنظیم تسهیلات (facility) که dnsmasq مدخل‌های syslog را به آن ارسال می‌کند؛ این مقدار به صورت پیش‌فرض DAEMON است و هنگامی که حالت عیب‌یابی فعال باشد روی LOCAL0 تنظیم می‌شود. اگر بخش تسهیلات حاوی حداقل یک نویسه '/' باشد، به عنوان نام فایل در نظر گرفته می‌شود و dnsmasq به جای syslog در فایل مشخص‌شده لاگ می‌اندازد. اگر مقدار تسهیلات '-' باشد، dnsmasq در stderr لاگ می‌نویسد. (خطاها هنگام خواندن پیکربندی همچنان به syslog ارسال می‌شوند، اما تمام خروجی‌های حاصل از راه‌اندازی موفق و تمام خروجی‌های زمان اجرا منحصراً در فایل ثبت خواهند شد.) هنگام لاگ‌اندازی در فایل، dnsmasq با دریافت SIGUSR2 فایل را بسته و مجدداً باز می‌کند. این ویژگی امکان چرخش فایل لاگ را بدون متوقف کردن dnsmasq فراهم می‌سازد.
فعال‌سازی لاگ‌های اضافی با هدف عیب‌یابی به جای اطلاع‌رسانی صرف.
فعال‌سازی ثبت لاگ تخصیص و آزادسازی حافظه، جهت عیب‌یابی.
فعال‌سازی لاگ‌اندازی ناهمگام و تعیین حد اختیاری برای تعداد خطوطی که در صورت کند بودن نوشتن در syslog، توسط dnsmasq در صف قرار می‌گیرند. برنامه Dnsmasq می‌تواند به صورت ناهمگام لاگ بیاندازد: این امر به آن اجازه می‌دهد بدون مسدود شدن توسط syslog به کار خود ادامه دهد و به syslog اجازه می‌دهد بدون خطر بن‌بست از dnsmasq برای پرس‌وجوهای DNS استفاده کند. اگر صف خطوط لاگ پر شود، dnsmasq سرریز شدن صف و تعداد پیام‌های از دست رفته را ثبت می‌کند. طول پیش‌فرض صف 5 است، یک مقدار معقول بین 5 تا 25 خواهد بود، و حداکثر سقف مجاز 100 تعیین شده است.
مشخص کردن مسیر جایگزین برای dnsmasq جهت ثبت شناسه فرآیند (process-id) خود در آن. معمولاً /var/run/dnsmasq.pid است.
تعیین شناسه کاربری (userid) که dnsmasq پس از راه‌اندازی به آن تغییر خواهد یافت. برنامه Dnsmasq معمولاً باید با دسترسی ریشه (root) آغاز شود، اما پس از راه‌اندازی با تغییر شناسه به یک کاربر دیگر، مجوزهای ریشه را رها می‌کند. معمولاً این کاربر "nobody" است اما می‌توان با این سوییچ آن را بازنویسی کرد.
تعیین گروهی که dnsmasq تحت آن اجرا خواهد شد. پیش‌فرض در صورت موجود بودن "dip" است تا دسترسی به /etc/ppp/resolv.conf را که معمولاً برای همگان خواندنی نیست تسهیل کند.
چاپ شماره نسخه.
شنود روی <port> به جای پورت استاندارد DNS یعنی (53). تنظیم این مقدار روی صفر عملکرد DNS را کاملاً غیرفعال می‌کند و فقط DHCP و/یا TFTP باقی می‌ماند.
تعیین بزرگ‌ترین بسته UDP از نوع EDNS.0 که توسط هدایت‌کننده DNS پشتیبانی می‌شود. پیش‌فرض 1232 است که اندازه توصیه‌شده پس از رویداد DNS flag day در سال 2020 می‌باشد. تنها در صورتی این مقدار را افزایش دهید که دقیقاً بدانید چه می‌کنید.
ارسال پرس‌وجوهای DNS خروجی از، و شنود برای پاسخ‌های آن‌ها روی، پورت خاص UDP یعنی <query_port> به جای استفاده از پورت‌های تصادفی. توجه داشته باشید که استفاده از این گزینه امنیت dnsmasq را در برابر حملات جعل DNS کاهش می‌دهد، اما ممکن است سریع‌تر باشد و منابع کمتری مصرف کند. تنظیم این گزینه روی صفر باعث می‌شود dnsmasq از یک پورت اختصاص‌یافته توسط سیستم‌عامل استفاده کند: این رفتار پیش‌فرض در نسخه‌های پیش از 2.43 بود.
به طور پیش‌فرض، هنگام ارسال یک پرس‌وجو از طریق پورت‌های تصادفی به چندین سرور بالادستی یا تلاش مجدد برای یک پرس‌وجو، dnsmasq از یک پورت تصادفی واحد برای همه تلاش‌ها/تلاش‌های مجدد استفاده می‌کند. این گزینه اجازه می‌دهد تعداد بیشتری پورت استفاده شود که می‌تواند پایداری را در برخی پیکربندی‌های شبکه افزایش دهد. توجه داشته باشید که افزایش این مقدار به بیش از دو یا سه پورت می‌تواند پیامدهای امنیتی و مصرف منابع به همراه داشته باشد و تنها با آگاهی از این موارد باید انجام شود.
از پورت‌های کمتر از مقدار ارائه‌شده به عنوان مبدا برای پرس‌وجوهای DNS خروجی استفاده نکند. برنامه Dnsmasq پورت‌های تصادفی را به عنوان مبدا پرس‌وجوهای خروجی انتخاب می‌کند: هنگامی که این گزینه تعیین شود، پورت‌های مورد استفاده همیشه بزرگ‌تر از مقدار مشخص‌شده خواهند بود. این قابلیت برای سامانه‌های پشت دیواره آتش کاربردی است. در صورت عدم تعیین، پیش‌فرض 1024 است.
استفاده از پورت‌های پایین‌تر از مقدار ارائه‌شده به عنوان مبدا برای پرس‌وجوهای DNS خروجی. برنامه Dnsmasq پورت‌های تصادفی را به عنوان مبدا پرس‌وجوهای خروجی انتخاب می‌کند: هنگامی که این گزینه تعیین شود، پورت‌های مورد استفاده همیشه پایین‌تر از مقدار مشخص‌شده خواهند بود. برای سامانه‌های پشت دیواره آتش مفید است.
شنود فقط روی رابط(های) شبکه مشخص‌شده. هنگامی که از گزینه --interface استفاده می‌شود، dnsmasq به طور خودکار رابط لوپ‌بک (loopback) محلی را به فهرست رابط‌های مورد استفاده اضافه می‌کند. اگر هیچ‌یک از گزینه‌های --interface یا --listen-address مشخص نشده باشند، dnsmasq روی تمام رابط‌های شبکه موجود به جز موارد ذکرشده در گزینه‌های --except-interface شنود می‌کند. در لینوکس، زمانی که --bind-interfaces یا --bind-dynamic فعال باشند، برچسب‌های رابط مستعار IP (مانند "eth1:0") به جای نام رابط‌ها بررسی می‌شوند. در حالت ساده‌ای که یک رابط فقط یک آدرس دارد، این کار تفاوتی ایجاد نمی‌کند، اما زمانی که یک رابط چندین آدرس دارد، امکان کنترل بر روی اینکه کدام‌یک از آن آدرس‌ها پذیرفته شوند را فراهم می‌سازد. همین نتیجه در حالت پیش‌فرض با استفاده از --listen-address نیز قابل دستیابی است. می‌توان از یک نویسه عام ساده شامل یک '*' در انتها، در گزینه‌های --interface و --except-interface استفاده کرد.
روی رابط شبکه مشخص‌شده شنود نکند. توجه داشته باشید که ترتیب گزینه‌های --listen-address --interface و --except-interface اهمیتی ندارد و گزینه‌های --except-interface همیشه اولویت داشته و بر سایرین چیره می‌شوند. توضیحات مربوط به برچسب‌های رابط برای --listen-address در اینجا نیز صدق می‌کند.
فعال‌سازی حالت سرور معتبر DNS برای پرس‌وجوهایی که به یک رابط یا آدرس می‌رسند. توجه داشته باشید که نیازی نیست نام رابط یا آدرس در پیکربندی --interface یا --listen-address ذکر شده باشد؛ در واقع --auth-server این موارد را بازنویسی کرده و یک سرویس DNS متفاوت روی رابط مشخص‌شده ارائه می‌دهد. پارامتر <domain> همان "رکورد چسبنده" (glue record) است. این نام باید در DNS سراسری به یک رکورد A و/یا AAAA حل‌وفصل شود که به آدرسی که dnsmasq روی آن در حال شنود است اشاره دارد. هنگامی که یک رابط مشخص می‌شود، می‌توان آن را با "/4" یا "/6" مقید کرد تا فقط آدرس‌های IPv4 یا IPv6 مرتبط با آن رابط مشخص شوند. از آنجا که تمام منطقه‌های معتبر تعریف‌شده به عنوان بخشی از سرویس DNS بازگشتی عادی ارائه‌شده توسط dnsmasq نیز در دسترس هستند، تعریف اعلان --auth-server بدون رابط یا آدرس و صرفاً با مشخص کردن کارساز نام خارجی اصلی نیز می‌تواند منطقی باشد.
بدون پارامتر یا با پارامتر net، سرویس‌دهی را به شبکه متصل محدود می‌کند. پرس‌وجوهای DNS را فقط از میزبان‌هایی می‌پذیرد که آدرس آن‌ها روی یک زیرشبکه محلی قرار دارد؛ یعنی زیرشبکه‌ای که یک رابط شبکه برای آن روی سرور وجود دارد. با پارامتر host، فقط روی رابط lo شنود کرده و پرس‌وجوها را تنها از localhost می‌پذیرد. این گزینه تنها زمانی اثرگذار است که هیچ‌یک از گزینه‌های --interface، --except-interface، --listen-address یا --auth-server تعریف نشده باشند. این گزینه برای این طراحی شده است که به عنوان پیش‌فرض هنگام نصب تنظیم شود، تا نصب‌های پیکربندی‌نشده ضمن مفید بودن، از سوءاستفاده در حملات تقویت DNS نیز ایمن بمانند.
-2, --no-dhcp-interface=<interface name>;
روی رابط شبکه مشخص‌شده خدمات DHCP، TFTP یا اعلان مسیریاب ارائه ندهد، اما سرویس DNS را ارائه کند.
غیرفعال کردن تنها DHCP نگارش ۴ (IPv4) روی رابط شبکه مشخص‌شده.
غیرفعال کردن DHCP نگارش ۶ (IPv6) و اعلان مسیریاب روی رابط شبکه مشخص‌شده.
شنود روی آدرس(های) IP مشخص‌شده. می‌توان هر دو گزینه --interface و --listen-address را همزمان تعیین کرد که در این صورت مجموعه‌ای از هر دو رابط‌ها و آدرس‌ها استفاده می‌شود. توجه داشته باشید اگر هیچ گزینه --interface تعیین نشده باشد، اما --listen-address مشخص شده باشد، dnsmasq به طور خودکار روی رابط لوپ‌بک محلی شنود نخواهد کرد. برای دستیابی به این منظور، آدرس IP آن، 127.0.0.1، باید به طور صریح به عنوان یک گزینه --listen-address مشخص گردد.
در سیستم‌هایی که از آن پشتیبانی می‌کنند، dnsmasq آدرس عام را متصل (bind) می‌کند، حتی زمانی که تنها روی برخی از رابط‌ها در حال شنود است. سپس درخواست‌هایی را که نباید به آن‌ها پاسخ دهد نادیده می‌گیرد. این امر این مزیت را دارد که حتی با قطع و وصل شدن رابط‌ها و تغییر آدرس آن‌ها نیز کار می‌کند. این گزینه dnsmasq را مجبور می‌کند که واقعاً فقط به رابط‌هایی متصل شود که روی آن‌ها در حال شنود است. تقریباً تنها زمانی که این گزینه مفید است، هنگام اجرای یک سرور نام دیگر (یا نمونه دیگری از dnsmasq) روی همان رایانه است. تنظیم این گزینه همچنین امکان اجرای چندین نمونه از dnsmasq را که خدمات DHCP ارائه می‌دهند روی یک ماشین فراهم می‌سازد.
فعال‌سازی یک حالت شبکه که ترکیبی میان --bind-interfaces و حالت پیش‌فرض است. Dnsmasq به آدرس تک‌تک رابط‌های شبکه متصل می‌شود و امکان اجرای چند نمونه از dnsmasq را فراهم می‌کند، اما اگر رابط‌ها یا آدرس‌های جدیدی ظاهر شوند، به‌طور خودکار روی آن‌ها نیز شنود می‌کند (مشروط به هرگونه پیکربندی کنترل دسترسی). این کار باعث می‌شود رابط‌های شبکه‌ای که به‌طور پویا ایجاد می‌شوند به همان شیوه حالت پیش‌فرض کار کنند. پیاده‌سازی این گزینه نیازمند رابط‌های برنامه‌نویسی غیر استاندارد شبکه بوده و تنها در لینوکس در دسترس است. در سایر پلتفرم‌ها به حالت --bind-interfaces بازمی‌گردد.
پاسخ‌های پرس‌وجوهای DNS از /etc/hosts و --interface-name و --dynamic-host را بسته به رابط شبکه‌ای که پرس‌وجو از طریق آن دریافت شده بازمی‌گرداند. اگر نامی دارای بیش از یک آدرس مرتبط باشد، و دست‌کم یکی از آن آدرس‌ها در همان زیرشبکه رابطی باشد که پرس‌وجو به آن ارسال شده، آن‌گاه فقط آدرس(های) موجود در آن زیرشبکه را برمی‌گرداند و در غیر این صورت، تمام آدرس‌های موجود بازگردانده می‌شوند. این امکان به یک کارساز اجازه می‌دهد تا در /etc/hosts چندین آدرس متناظر با هر یک از رابط‌های شبکه خود داشته باشد، و میزبان‌ها بر اساس شبکه‌ای که به آن متصل هستند آدرس صحیح را دریافت خواهند کرد. در حال حاضر این قابلیت به IPv4 محدود است.
جستجوهای معکوس ساختگی خصوصی. تمام جستجوهای معکوس برای محدوده‌های IP خصوصی (یعنی 192.168.x.x و غیره) که در /etc/hosts یا فایل اجاره‌های DHCP یافت نمی‌شوند، به جای هدایت به بالادستی با پاسخ «دامنه وجود ندارد» (no such domain) پاسخ داده می‌شوند. مجموعه پیشوندهای تحت تأثیر، فهرست ارائه‌شده در RFC6303 برای IPv4 و IPv6 است. فعال‌سازی این گزینه همچنین اعتبارسنجی DNSSEC را برای جستجوهای معکوس در محدوده‌های خصوصی به گونه‌ای ظریف تغییر می‌دهد که یک رکورد نامطمئن DS به‌عنوان اثباتی بر امضا نشدن آن محدوده پذیرفته می‌شود. این کار رفتار سرویس‌های عمومی DNS را دور می‌زند که ظاهراً اثبات اعتبارسنجی‌شده عدم وجود (proof-of-non-existence) را برای رکوردهای DS در این دامنه‌ها برنمی‌گردانند.
تغییر آدرس‌های IPv4 بازگردانده‌شده از کارسازهای نام بالادستی؛ old-ip با new-ip جایگزین می‌شود. اگر ماسک اختیاری مشخص شده باشد، هر آدرسی که با old-ip ماسک‌شده مطابقت داشته باشد بازنویسی خواهد شد. بنابراین، برای نمونه --alias=1.2.3.0,6.7.8.0,255.255.255.0 آدرس 1.2.3.56 را به 6.7.8.56 و 1.2.3.67 را به 6.7.8.67 نگاشت می‌کند. این همان چیزی است که رهیاب‌های سیسکو PIX آن را «دستکاری DNS» (یا DNS doctoring) می‌نامند. اگر IP قدیمی به عنوان یک محدوده داده شود، به جای کل یک زیرشبکه، تنها آدرس‌های موجود در آن محدوده بازنویسی می‌شوند. بنابراین --alias=192.168.0.10-192.168.0.40,10.0.0.0,255.255.255.0 محدوده 192.168.0.10->192.168.0.40 را به 10.0.0.10->10.0.0.40 نگاشت می‌کند.
تبدیل پاسخ‌هایی که حاوی آدرس یا زیرشبکه مشخص‌شده هستند به پاسخ‌های «دامنه وجود ندارد» (No such domain). از هر دو پروتکل IPv4 و IPv6 پشتیبانی می‌شود. هدف این گزینه مقابله با اقدام فریبکارانه وریزلاین (Verisign) در سپتامبر ۲۰۰۳ است که در پاسخ به پرس‌وجوهای مربوط به نام‌های ثبت‌نشده، به جای پاسخ صحیح NXDOMAIN، آدرس یک صفحه وب تبلیغاتی را برمی‌گرداند. این گزینه به dnsmasq می‌گوید در صورت مشاهده این رفتار، پاسخ صحیح را جعل کند. تا سپتامبر ۲۰۰۳، آدرس IP بازگردانده‌شده توسط وریزلاین 64.94.110.11 بود.
نادیده گرفتن پاسخ‌های مربوط به پرس‌وجوهای A یا AAAA که شامل آدرس یا زیرشبکه مشخص‌شده هستند. هیچ خطایی تولید نمی‌شود، dnsmasq فقط به شنود برای دریافت پاسخی دیگر ادامه می‌دهد. این گزینه برای خنثی کردن راهبردهای مسدودسازی که متکی بر ارسال سریع یک پاسخ جعلی به یک درخواست DNS برای دامنه‌ای خاص پیش از رسیدن پاسخ واقعی هستند، کاربردی است.
نسخه‌های جدیدتر ویندوز درخواست‌های دوره‌ای DNS ارسال می‌کنند که پاسخ‌های معقولی از DNS عمومی دریافت نمی‌کنند و می‌توانند با به کار انداختن پیوندهای اتصال بر حسب تقاضا (dial-on-demand) باعث بروز مشکل شوند. این پرچم گزینه‌ای را برای پالایش چنین درخواست‌هایی فعال می‌کند. درخواست‌های مسدودشده شامل رکوردهای نوع ANY است که نام درخواستی آن‌ها دارای خط زیرین (_) باشد تا درخواست‌های LDAP را به دام اندازد، و همچنین تمام رکوردهای از نوع SOA و SRV.
حذف رکوردهای A از پاسخ‌ها. هیچ آدرس IPv4 بازگردانده نخواهد شد.
حذف رکوردهای AAAA از پاسخ‌ها. هیچ آدرس IPv6 بازگردانده نخواهد شد.
حذف رکوردهای نوع (یا انواع) مشخص‌شده از پاسخ‌ها. حالت --filter-rr=ANY که در غیر این صورت بی‌معنی به نظر می‌رسید، معنای ویژه‌ای دارد: پاسخ‌ها به پرس‌وجوهای نوع ANY را پالایش می‌کند. هر چیزی غیر از رکوردهای A، AAAA، MX و CNAME حذف می‌شود. از آنجا که پرس‌وجوهای ANY با آدرس‌های مبدأ جعلی می‌توانند در حملات تقویت DNS (حملات DNS amplification که در آن‌ها پاسخ پرس‌وجوهای ANY می‌تواند بسیار حجیم باشد) به کار روند، این گزینه چنین حملاتی را خنثی می‌کند، در حالی که همچنان از تنها کاربرد احتمالی باقی‌مانده برای پرس‌وجوهای ANY پشتیبانی می‌نماید. برای جزئیات به بند 4.3 در RFC 8482 مراجعه کنید.
به‌طور پیش‌فرض، dnsmasq انواع رکوردهای DNS شامل A، AAAA، CNAME و SRV را در حافظه نهان (کَش) ذخیره می‌کند. این گزینه انواع دیگر رکوردها را نیز به حافظه نهان می‌افزاید. نوع رکورد منبع (RR-type) می‌تواند به صورت نامی مانند TXT یا MX یا یک عدد ده‌دهی مشخص شود. یک گزینه --cache-rr منفرد می‌تواند فهرستی از انواع RR جداشده با کاما دریافت کند و استفاده از بیش از یک گزینه --cache-rr نیز مجاز است. برای فعال کردن ذخیره تمام انواع RR در حافظه نهان از --cache-rr=ANY استفاده کنید.
خواندن آدرس‌های IP کارسازهای نام بالادستی از <file> به‌جای /etc/resolv.conf. برای قالب این فایل به resolv.conf(5) مراجعه کنید. تنها خطوط مرتبط با dnsmasq خطوط nameserver هستند. می‌توان به dnsmasq دستور داد بیش از یک فایل resolv.conf را بررسی دوره‌ای (poll) کند؛ نخستین نام فایل مشخص‌شده جایگزین پیش‌فرض می‌شود و موارد بعدی به فهرست اضافه می‌گردند. این کار تنها هنگام بررسی دوره‌ای مجاز است؛ فایلی که در حال حاضر جدیدترین زمان ویرایش را داشته باشد مورد استفاده قرار می‌گیرد.
فایل /etc/resolv.conf خوانده نشود. کارسازهای بالادستی تنها از خط فرمان یا فایل پیکربندی dnsmasq دریافت شوند.
-1, --enable-dbus[=<service-name>]
امکان به‌روزرسانی پیکربندی dnsmasq از طریق فراخوانی متدهای DBus را فراهم می‌کند. پیکربندی‌هایی که می‌توانند تغییر کنند شامل کارسازهای DNS بالادستی (و دامنه‌های متناظر) و پاک‌سازی حافظه نهان (کَش) است. نیازمند این است که dnsmasq با پشتیبانی از DBus کامپایل شده باشد. اگر نام سرویس مشخص شود، dnsmasq سرویس‌دهی را با آن نام ارائه می‌دهد، نه با نام پیش‌فرض که uk.org.thekelleys.dnsmasq است.
فعال‌سازی رابط UBus در dnsmasq. این گزینه در رویدادهای DHCPACK و DHCPRELEASE اعلان‌هایی را از طریق UBus ارسال می‌کند. افزون بر این، معیارهای اندازه‌گیری (metrics) را ارائه می‌دهد و امکان پیکربندی پالایش بر اساس نشانه‌های ردیابی اتصال لینوکس (Linux connection track mark) را فراهم می‌سازد. هنگامی که پالایش پرس‌وجوهای DNS بر اساس نشانه‌های ردیابی اتصال لینوکس فعال باشد، اعلان‌های UBus برای هر پرس‌وجوی DNS تحلیل‌شده یا پالایش‌شده تولید می‌شوند. نیازمند این است که dnsmasq با پشتیبانی از UBus کامپایل شده باشد. اگر نام سرویس داده شود، dnsmasq سرویس را تحت آن فضای نام ارائه می‌دهد، نه تحت نام پیش‌فرض که dnsmasq است.
به‌طور پیش‌فرض، dnsmasq پرس‌وجوها را به هر یک از کارسازهای بالادستی که می‌شناسد ارسال می‌کند و تلاش می‌کند کارسازهایی را که فعال بودن آن‌ها مشخص شده ترجیح دهد. تنظیم این پرچم، dnsmasq را وادار می‌کند تا هر پرس‌وجو را دقیقاً به همان ترتیبی که کارسازها در /etc/resolv.conf ظاهر شده‌اند، با هر یک از آن‌ها امتحان کند.
به‌طور پیش‌فرض، هنگامی که dnsmasq بیش از یک کارساز بالادستی در دسترس دارد، پرس‌وجوها را فقط به یک کارساز ارسال می‌کند. تنظیم این پرچم dnsmasq را ملزم می‌سازد تمام پرس‌وجوها را به تمام کارسازهای در دسترس بفرستد. پاسخی که از کارسازی که زودتر پاسخ دهد دریافت شود، به درخواست‌کننده اصلی بازگردانده خواهد شد.
فعال‌سازی کد شناسایی حلقه‌های هدایت DNS؛ یعنی وضعیتی که پرس‌وجوی ارسالی به یکی از کارسازهای بالادستی در نهایت به عنوان یک پرس‌وجوی جدید به نمونه dnsmasq بازمی‌گردد. این فرایند با ایجاد پرس‌وجوهای TXT به فرمت <hex>.test و ارسال آن‌ها به هر کارساز بالادستی کار می‌کند. مقدار هگز یک شناسه یکتا (UID) است که نمونه فرستنده dnsmasq و کارساز بالادستی دریافت‌کننده را کدگذاری می‌کند. اگر پرس‌وجو به کارساز فرستنده بازگردد، آن‌گاه کارساز بالادستی که پرس‌وجو از طریق آن ارسال شده غیرفعال می‌شود و این رویداد در لاگ ثبت می‌گردد. هر بار که مجموعه کارسازهای بالادستی تغییر کند، این آزمون روی تمام آن‌ها، از جمله مواردی که قبلاً غیرفعال شده بودند، دوباره اجرا می‌شود.
رد کردن (و ثبت در لاگ) آدرس‌های بازگردانده‌شده از کارسازهای نام بالادستی که در محدوده‌های خصوصی قرار دارند. این کار مانع حمله‌ای می‌شود که در آن از یک مرورگر پشت دیوار آتش برای بررسی دستگاه‌های شبکه محلی استفاده می‌گردد. برای IPv6، محدوده خصوصی شامل آدرس‌های نگاشت‌شده IPv4 در فضای خصوصی به همراه تمام آدرس‌های محلی پیوند (link-local یا LL) و محلی سایت (site-local یا ULA) است.
معاف کردن 127.0.0.0/8 و ::1 از بررسی‌های بازپیوندی (rebinding). این محدوده آدرس توسط کارسازهای سیاه‌چاله بلادرنگ (realtime black hole) بازگردانده می‌شود، بنابراین مسدود کردن آن ممکن است این سرویس‌ها را از کار بیندازد.
عدم شناسایی و مسدودسازی dns-rebind برای پرس‌وجوهای این دامنه‌ها. آرگومان می‌تواند یک دامنه منفرد، یا چندین دامنه محصور در '/' باشد، مانند ساختار نحوی --server، به عنوان نمونه: --rebind-domain-ok=/domain1/domain2/domain3/
بررسی دوره‌ای (poll) فایل /etc/resolv.conf برای تغییرات انجام نشود.
هر زمان که /etc/resolv.conf مجدداً خوانده شود یا کارسازهای بالادستی از طریق DBus تنظیم گردند، حافظه نهان (کَش) DNS پاک‌سازی شود. این ویژگی زمانی مفید است که کارسازهای نام جدید ممکن است داده‌های متفاوتی نسبت به آنچه در حافظه نهان نگهداری می‌شود داشته باشند.
به dnsmasq دستور می‌دهد که هرگز پرس‌وجوهای A یا AAAA برای نام‌های ساده (بدون نقطه یا بخش‌های دامنه) را به کارسازهای نام بالادستی هدایت نکند. اگر نام از طریق /etc/hosts یا DHCP شناخته‌شده نباشد، پاسخ «یافت نشد» (not found) بازگردانده می‌شود.
مشخص کردن مستقیم کارسازهای بالادستی. تنظیم این پرچم مانع خواندن /etc/resolv.conf نمی‌شود، برای انجام این کار از --no-resolv استفاده کنید. اگر یک یا چند دامنه اختیاری مشخص شود، آن کارساز فقط برای همان دامنه‌ها استفاده می‌شود و پرس‌وجوی آن دامنه‌ها تنها از طریق کارساز مشخص‌شده انجام می‌گیرد. این ویژگی برای کارسازهای نام خصوصی در نظر گرفته شده است: اگر در شبکه خود یک کارساز نام دارید که به نام‌هایی به شکل xxx.internal.thekelleys.org.uk در آدرس 192.168.1.1 رسیدگی می‌کند، دادن پرچم --server=/internal.thekelleys.org.uk/192.168.1.1 تمام پرس‌وجوهای مربوط به دستگاه‌های داخلی را به آن کارساز نام ارسال می‌کند و سایر موارد به کارسازهای موجود در /etc/resolv.conf فرستاده می‌شوند. مشخص کردن دامنه خالی، // معنای خاص «تنها نام‌های فاقد صلاحیت» (unqualified names) یعنی نام‌های بدون هرگونه نقطه را دارد. یک درگاه (پورت) غیر استاندارد را می‌توان به عنوان بخشی از آدرس IP با استفاده از نویسه # مشخص کرد. استفاده از بیش از یک پرچم --server با تکرار بخش‌های دامنه یا آدرس IP بر حسب نیاز مجاز است.

دامنه‌های خاص‌تر بر دامنه‌های عمومی‌تر اولویت دارند، بنابراین: --server=/google.com/1.2.3.4 --server=/www.google.com/2.3.4.5 پرس‌وجوها را برای google.com و gmail.google.com به 1.2.3.4 می‌فرستد، اما www.google.com به 2.3.4.5 ارسال خواهد شد.

تطبیق دامنه‌ها معمولاً بر اساس برچسب‌های کامل انجام می‌شود، بنابراین /google.com/ با google.com و www.google.com مطابقت دارد اما با supergoogle.com مطابقت ندارد. این رفتار را می‌توان فقط با قرار دادن یک * در ابتدای یک الگو لغو کرد: /*google.com/ با google.com و www.google.com و همچنین با supergoogle.com مطابقت خواهد داشت. شکل بدون نویسه عام (wildcard) اولویت دارد، بنابراین اگر هر دو حالت /google.com/ و /*google.com/ مشخص شده باشند، google.com و www.google.com با /google.com/ تطبیق داده می‌شوند و /*google.com/ فقط با supergoogle.com تطبیق خواهد یافت.

به دلایل تاریخی، الگوی /.google.com/ معادل /google.com/ است؛ اگر می‌خواهید هر زیردامنه‌ای از google.com به جز خود google.com مطابقت داشته باشد، از /*.google.com/ استفاده کنید.

آدرس کارساز ویژه '#' به معنای «استفاده از کارسازهای استاندارد» است، بنابراین --server=/google.com/1.2.3.4 --server=/www.google.com/# پرس‌وجوها را برای google.com و زیردامنه‌های آن به 1.2.3.4 ارسال می‌کند، به جز www.google.com (و زیردامنه‌های آن) که مانند معمول هدایت خواهند شد.

همچنین استفاده از پرچم -S که یک دامنه را بدون آدرس IP مشخص می‌کند مجاز است؛ این کار به dnsmasq می‌گوید که یک دامنه محلی است و می‌تواند به پرس‌وجوهای آن از /etc/hosts یا DHCP پاسخ دهد اما هرگز نباید پرس‌وجوهای آن دامنه را به هیچ کارساز بالادستی هدایت کند. --local مترادفی برای --server است تا فایل‌های پیکربندی در چنین مواردی واضح‌تر باشند.

آدرس‌های IPv6 ممکن است شامل یک scope-id رابط (%interface) باشند، مانند fe80::202:a412:4512:7bbf%eth0.

رشته اختیاری پس از نویسه @ به dnsmasq می‌گوید مبدأ پرس‌وجوها به این کارساز نام را چگونه تنظیم کند. این مقدار می‌تواند یک آدرس IP، نام یک رابط شبکه یا هر دو باشد. آدرس IP باید متعلق به دستگاهی باشد که dnsmasq روی آن اجرا می‌شود، در غیر این صورت این خط کارساز در لاگ ثبت شده و سپس نادیده گرفته می‌شود. اگر نام رابط مشخص شود، پرس‌وجوها به آن کارساز اجباراً از طریق آن رابط شبکه ارسال می‌شوند؛ اگر آدرس IP مشخص شود، آدرس مبدأ پرس‌وجوها روی آن آدرس تنظیم خواهد شد؛ و اگر هر دو مشخص شوند، ترکیبی از آدرس IP و نام رابط برای هدایت درخواست‌ها به کارساز استفاده خواهد شد. پرچم query-port برای هر کارسازی که آدرس مبدأ برای آن تعیین شده باشد نادیده گرفته می‌شود، اما درگاه را می‌توان مستقیماً به عنوان بخشی از آدرس مبدأ مشخص کرد. اجبار پرس‌وجوها به یک رابط شبکه در تمام پلتفرم‌های پشتیبانی‌شده توسط dnsmasq پیاده‌سازی نشده است.

کارسازهای بالادستی را می‌توان به جای آدرس IP با یک نام میزبان (hostname) نیز مشخص کرد. در این حالت، dnsmasq تلاش خواهد کرد تا در طول راه‌اندازی با استفاده از تحلیل‌گر سیستم (system resolver) آدرس IP کارساز را به دست آورد. اگر تحلیل نام شکست بخورد، راه‌اندازی dnsmasq نیز با شکست مواجه می‌شود. چنانچه پیکربندی سیستم به گونه‌ای باشد که تحلیل‌گر سیستم پرس‌وجوهای DNS را از طریق همان نمونه dnsmasq در حال راه‌اندازی ارسال کند، این فرایند دچار وقفه زمانی (time-out) شده و شکست خواهد خورد.

این گزینه از نظر عملکردی همانند --server, است، اما ساختار نگارشی ساده‌تری (syntactic sugar) فراهم می‌کند تا تعیین پرس‌وجوهای تبدیل آدرس به نام آسان‌تر شود. برای نمونه --rev-server=1.2.3.0/24,192.168.0.1 دقیقاً معادل --server=/3.2.1.in-addr.arpa/192.168.0.1 است. طول پیشوندهای مجاز 1-32 برای (IPv4) و 1-128 برای (IPv6) است. اگر طول پیشوند حذف شود، dnsmasq مقدار 32 (در IPv4) یا 128 (در IPv6) را جایگزین می‌کند.
یک آدرس IP را برای بازگرداندن به هر میزبانی در دامنه‌های داده‌شده مشخص می‌کند. پرس‌وجوهای A (یا AAAA) در این دامنه‌ها هرگز هدایت نمی‌شوند و همیشه با آدرس IP مشخص‌شده که ممکن است IPv4 یا IPv6 باشد پاسخ داده می‌شوند. برای اختصاص چند آدرس یا هر دو نوع آدرس IPv4 و IPv6 برای یک دامنه، از تکرار پرچم‌های --address استفاده کنید. توجه داشته باشید که /etc/hosts و اجاره‌های DHCP این تنظیم را برای نام‌های جداگانه لغو می‌کنند. یک کاربرد متداول این گزینه هدایت کل دامنه doubleclick.net به یک وب‌کارساز محلی بی‌خطر برای جلوگیری از بنرهای تبلیغاتی است. تعیین دامنه به همان شیوه --server کار می‌کند، با این امکان اضافی که /#/ با هر دامنه‌ای مطابقت دارد. بنابراین --address=/#/1.2.3.4 همیشه برای هر پرس‌وجویی که از /etc/hosts یا DHCP پاسخ داده نشده و توسط یک دستور مشخص‌تر --server به کارساز نام بالادستی ارسال نشده باشد، 1.2.3.4 را بازمی‌گرداند. همانند --server، یک یا چند دامنه بدون آدرس، پاسخ «دامنه وجود ندارد» را برمی‌گرداند؛ بنابراین --address=/example.com/ معادل --server=/example.com/ است و برای example.com و تمام زیردامنه‌های آن پاسخ NXDOMAIN را برمی‌گرداند. آدرسی که به صورت '#' مشخص شود به آدرس NULL یعنی 0.0.0.0 و معادل IPv6 آن یعنی :: ترجمه می‌شود؛ بنابراین --address=/example.com/# آدرس‌های NULL را برای example.com و زیردامنه‌های آن برمی‌گرداند. این تا حدی تسهیل نگارشی برای --address=/example.com/0.0.0.0 و --address=/example.com/:: است، اما در مقایسه با آوردن هر دو به عنوان خطوط پیکربندی جداگانه کارآمدتر نیز هست. توجه داشته باشید که آدرس‌های NULL معمولاً به همان شیوه localhost عمل می‌کنند، بنابراین مراقب باشید که کلاینت‌هایی که این نام‌ها را جستجو می‌کنند احتمالاً در نهایت با خودشان ارتباط برقرار خواهند کرد.

توجه داشته باشید که رفتار برای پرس‌وجوهایی که با آدرس مشخص‌شده مطابقت ندارند در نسخه 2.86 تغییر کرده است. نسخه‌های پیشین، هنگامی که برای نمونه با --address=/example.com/1.2.3.4 پیکربندی می‌شدند و سپس برای یک نوع RR غیر از A مورد پرس‌وجو قرار می‌گرفتند، پاسخ NoData را بازمی‌گرداندند. از نسخه 2.86 به بعد، پرس‌وجو به بالادستی ارسال می‌شود. برای بازگرداندن رفتار پیش از 2.86، از پیکربندی --address=/example.com/1.2.3.4 --local=/example.com/ استفاده کنید.

آدرس‌های IP تحلیل‌شده ناشی از پرس‌وجوها برای یک یا چند دامنه را در مجموعه IP (IP set) نت‌فیلتر مشخص‌شده قرار می‌دهد. اگر نام چندین مجموعه داده شود، آدرس‌ها در هر یک از آن‌ها قرار می‌گیرند، مشروط به محدودیت‌های یک مجموعه IP (آدرس‌های IPv4 نمی‌توانند در یک مجموعه IP از نوع IPv6 ذخیره شوند و برعکس). دامنه‌ها و زیردامنه‌ها به همان شیوه --address تطبیق داده می‌شوند. این مجموعه‌های IP باید از قبل وجود داشته باشند. برای جزئیات بیشتر به ipset(8) مراجعه کنید.
مشابه گزینه --ipset است، اما یک یا چند مجموعه nftables را برای افزودن آدرس‌های IP می‌پذیرد. این مجموعه‌ها باید از قبل وجود داشته باشند. برای جزئیات بیشتر به nft(8) مراجعه کنید. خانواده (family)، جدول (table) و مجموعه (set) مستقیماً به nft تحویل داده می‌شوند. اگر مشخصه با #4 یا #6 آغاز شود، به ترتیب تنها رکوردهای A یا AAAA به مجموعه اضافه می‌شوند. از آنجا که یک nftset تنها می‌تواند آدرس‌های IPv4 یا IPv6 را نگه دارد، این ویژگی مانع ثبت خطاها در لاگ برای آدرس‌های با نوع نادرست می‌شود.
پالایش پرس‌وجوهای ورودی DNS دارای نشانه‌های ردیابی اتصال لینوکس (Linux connection track marks) را بر اساس فهرست‌های مجاز اختصاصی که از طریق مجموعه‌ای از گزینه‌های --connmark-allowlist پیکربندی شده‌اند، فعال می‌کند. پرس‌وجوهای غیرمجاز هدایت نمی‌شوند؛ آن‌ها با کد خطای REFUSED رد می‌شوند. پرس‌وجوهای DNS تنها در صورتی مجاز هستند که نشانه ردیابی اتصال لینوکس مرتبطی نداشته باشند، یا دامنه‌های مورد پرس‌وجو با الگوهای DNS پیکربندی‌شده برای نشانه ردیابی اتصال لینوکس مرتبط مطابقت داشته باشند. اگر هیچ فهرست مجازی برای یک نشانه ردیابی اتصال لینوکس پیکربندی نشده باشد، تمام پرس‌وجوهای DNS مرتبط با آن نشانه رد می‌شوند. اگر یک ماسک مشخص شده باشد، نشانه‌های ردیابی اتصال لینوکس پیش از پردازش، ابتدا با ماسک داده‌شده به صورت بیتی AND می‌شوند.
الگوهای DNS مجاز در پرس‌وجوهای DNS مرتبط با نشانه ردیابی اتصال لینوکس داده‌شده را پیکربندی می‌کند. اگر یک ماسک مشخص شده باشد، نشانه‌های ردیابی اتصال لینوکس پیش از مقایسه با نشانه ردیابی اتصال داده‌شده، ابتدا با ماسک مشخص‌شده به صورت بیتی AND می‌شوند. الگوها از ساختار نحوی نام‌های DNS پیروی می‌کنند، اما علاوه بر این اجازه می‌دهند نویسه عام «*» حداکثر تا دو بار در هر برچسب برای تطبیق ۰ یا چند نویسه در آن برچسب استفاده شود. توجه داشته باشید که نویسه عام هرگز با نقطه تطبیق پیدا نمی‌کند (برای نمونه، «*.example.com» با «api.example.com» تطبیق دارد اما با «api.us.example.com» مطابقت ندارد). الگوها باید کاملاً باصلاحیت (fully qualified) باشند، یعنی دست‌کم از دو برچسب تشکیل شده باشند. برچسب پایانی نباید کاملاً عددی باشد و نباید دامنه سطح‌بالای شبه‌محلی «local» باشد. یک الگو باید دست‌کم با دو برچسب دقیق (غیر عام) پایان یابد. به جای یک الگو، می‌توان «*» را برای غیرفعال کردن کامل پالایش فهرست مجاز برای یک نشانه ردیابی اتصال لینوکس مشخص کرد.
یک رکورد MX با نام <mx name> بازمی‌گرداند که به نام میزبان ارائه‌شده (در صورت ارائه) یا به میزبانی که در سوییچ --mx-target مشخص شده، یا اگر آن سوییچ مشخص نشده باشد، به میزبانی که dnsmasq روی آن در حال اجراست اشاره می‌کند. حالت پیش‌فرض برای هدایت ایمیل‌ها از سیستم‌های موجود در یک شبکه محلی (LAN) به یک سرور مرکزی مفید است. مقدار اولویت (preference) اختیاری است و در صورت عدم تعیین، مقدار پیش‌فرض آن ۱ خواهد بود. می‌توان بیش از یک رکورد MX برای یک میزبان مشخص کرد.
هدف پیش‌فرض را برای رکورد MX بازگردانده‌شده توسط dnsmasq مشخص می‌کند. به --mx-host مراجعه کنید. اگر --mx-target داده شود اما --mx-host مشخص نشود، آنگاه dnsmasq یک رکورد MX حاوی هدف MX برای پرس‌وجوهای MX روی نام میزبان ماشینی که dnsmasq روی آن در حال اجراست بازمی‌گرداند.
برای هر ماشین محلی یک رکورد MX بازمی‌گرداند که به خودش اشاره دارد. ماشین‌های محلی مواردی هستند که در /etc/hosts آمده‌اند یا اجاره‌های DHCP دارند.
برای هر ماشین محلی، یک رکورد MX بازمی‌گرداند که به میزبان ارائه‌شده توسط --mx-target (یا ماشینی که dnsmasq روی آن در حال اجراست) اشاره دارد. ماشین‌های محلی مواردی هستند که در /etc/hosts ثبت شده‌اند یا دارای اجاره‌های DHCP هستند.
یک رکورد SRV DNS بازمی‌گرداند. برای جزئیات به RFC2782 مراجعه کنید. در صورت مشخص نشدن، دامنه به‌طور پیش‌فرض همان دامنه‌ای خواهد بود که توسط --domain. تعیین شده است. مقدار پیش‌فرض برای دامنه مقصد خالی است، پیش‌فرض برای پورت یک است و مقادیر پیش‌فرض برای وزن (weight) و اولویت (priority) صفر هستند. هنگام انتقال داده‌ها از فایل‌های زون BIND دقت کنید: ترتیب اعداد پورت، وزن و اولویت متفاوت است. تعریف بیش از یک رکورد SRV برای یک سرویس/دامنه مشخص مجاز است، و تمام موارد منطبق بازگردانده می‌شوند.
رکوردهای A، AAAA و PTR را به DNS اضافه می‌کند. این گزینه یک یا چند نام را با رکوردهای متناظر IPv4 (A) و IPv6 (AAAA) به DNS می‌افزاید. یک نام ممکن است در بیش از یک --host-record ظاهر شود و بنابراین بیش از یک آدرس به آن اختصاص یابد. تنها اولین آدرس، یک رکورد PTR برای پیوند دادن آدرس به نام ایجاد می‌کند. این همان قاعده‌ای است که هنگام خواندن فایل‌های hosts استفاده می‌شود. گزینه‌های --host-record طوری در نظر گرفته می‌شوند که گویی پیش از فایل‌های hosts خوانده شده‌اند، بنابراین نامی که در اینجا ظاهر شود مانع از ایجاد رکورد PTR در صورت حضور آن نام در فایل hosts نیز می‌گردد. برخلاف فایل‌های hosts، نام‌ها حتی زمانی که --expand-hosts فعال باشد نیز بسط داده نمی‌شوند. نام‌های کوتاه و طولانی می‌توانند در یک --host-record, مشترک بیایند، مانند: --host-record=laptop,laptop.thekelleys.org,192.168.0.1,1234::100

اگر طول عمر (time-to-live) مشخص شود، مقدار پیش‌فرض را که صفر یا مقدار --local-ttl است بازنویسی می‌کند. این مقدار یک عدد صحیح مثبت است و طول عمر را بر حسب ثانیه مشخص می‌کند.

رکوردهای A، AAAA و PTR را در همان زیرشبکه رابط شبکه مشخص‌شده به DNS اضافه می‌کند. آدرس از بخش شبکه (network part) هر آدرس مرتبط با رابط شبکه، و بخش میزبان (host part) از آدرس مشخص‌شده مشتق می‌شود. برای مثال: --dynamic-host=example.com,0.0.0.8,eth0 زمانی که eth0 دارای آدرس 192.168.78.x و ماسک شبکه 255.255.255.0 باشد، به نام example.com یک رکورد A برای 192.168.78.8 می‌دهد. همین اصل برای آدرس‌های IPv6 نیز صدق می‌کند. توجه داشته باشید اگر یک رابط شبکه بیش از یک آدرس داشته باشد، بیش از یک رکورد A یا AAAA ایجاد خواهد شد. مقدار TTL این رکوردها همواره صفر است و هرگونه تغییر در آدرس‌های رابط شبکه بلافاصله در آن‌ها منعکس خواهد شد.
یک رکورد TXT DNS بازمی‌گرداند. مقدار رکورد TXT مجموعه‌ای از رشته‌هاست، بنابراین می‌توان هر تعدادی از آن‌ها را که با کاما از هم جدا شده‌اند درج کرد؛ برای قرار دادن کاما در داخل یک رشته از علامت نقل‌قول استفاده کنید. توجه داشته باشید که بیشینه طول یک رشته منفرد ۲۵۵ نویسه است؛ رشته‌های طولانی‌تر به قطعات ۲۵۵ نویسه‌ای تقسیم می‌شوند.
یک رکورد PTR DNS بازمی‌گرداند.
یک رکورد NAPTR DNS را همان‌طور که در RFC3403 مشخص شده بازمی‌گرداند.
یک رکورد CAA DNS را همان‌طور که در RFC6844 مشخص شده بازمی‌گرداند.
یک رکورد CNAME بازمی‌گرداند که نشان می‌دهد <cname> در واقع همان <target> است. یک محدودیت اساسی درباره هدف وجود دارد؛ هدف باید یک رکورد DNS باشد که برای dnsmasq شناخته‌شده است و نه رکورد DNSای که از یک سرور بالادستی دریافت می‌شود. نام مستعار (cname) باید یکتا باشد، اما داشتن بیش از یک cname که به یک هدف یکسان اشاره کنند مجاز است. در واقع امکان اعلام چندین cname برای یک هدف در یک خط وجود دارد، مانند: --cname=cname1,cname2,target

اگر طول عمر (time-to-live) مشخص شود، مقدار پیش‌فرض را که صفر یا مقدار --local-ttl است بازنویسی می‌کند. این مقدار یک عدد صحیح مثبت است و طول عمر را بر حسب ثانیه مشخص می‌کند.

یک رکورد منبع (Resource Record) دلخواه DNS بازمی‌گرداند. این شماره، نوع رکورد است (که همیشه در کلاس C_IN قرار دارد). مقدار رکورد توسط داده‌های هگزادسیمال ارائه می‌شود که می‌تواند به صورت 01:23:45 یا 01 23 45 یا 012345 یا هر ترکیبی از این‌ها باشد.
رکوردهای DNSای بازمی‌گرداند که نام را به آدرس(های) رابط شبکه ارائه‌شده مرتبط می‌کنند. این فلگ یک رکورد A یا AAAA را برای نام داده‌شده دقیقاً همانند یک خط در /etc/hosts مشخص می‌کند، با این تفاوت که آدرس ثابت نیست، بلکه از رابط شبکه ارائه‌شده گرفته می‌شود. به دنبال رابط شبکه می‌تواند "/4" یا "/6" بیاید تا مشخص کند فقط آدرس‌های IPv4 یا IPv6 رابط شبکه باید استفاده شوند. اگر رابط شبکه غیرفعال (down)، پیکربندی‌نشده یا ناموجود باشد، یک رکورد خالی بازگردانده می‌شود. رکورد PTR منطبق نیز ایجاد شده و آدرس رابط شبکه را به نام نگاشت می‌کند. با تکرار این فلگ می‌توان بیش از یک نام را به یک آدرس رابط شبکه مرتبط کرد؛ در این حالت اولین نمونه برای نگاشت معکوس آدرس به نام استفاده می‌شود. توجه داشته باشید نامی که در --interface-name استفاده می‌شود نباید در /etc/hosts وجود داشته باشد.
رکوردهای ساختگی A/AAAA و PTR را برای یک محدوده آدرس ایجاد می‌کند. این رکوردها یا شماره‌های متوالی هستند یا خود آدرس که در آن نقطه‌ها (یا دو‌نقطه‌ها برای IPv6) با خط تیره جایگزین شده‌اند.

مثال‌ها این موضوع را روشن‌تر می‌کنند. ابتدا شماره‌های متوالی: --synth-domain=thekelleys.org.uk,192.168.0.50,192.168.0.70,internal-* باعث می‌شود که نام internal-0.thekelleys.org.uk آدرس 192.168.0.50، نام internal-1.thekelleys.org.uk آدرس 192.168.0.51 و به همین ترتیب را بازگرداند (به * توجه کنید). همین اصل برای آدرس‌های IPv6 نیز صدق می‌کند (که در آن‌ها اعداد ممکن است بسیار بزرگ باشند). جستجوهای معکوس از آدرس به نام طبق انتظار عمل می‌کنند.

دوم: --synth-domain=thekelleys.org.uk,192.168.0.0/24,internal- (no *) باعث می‌شود که یک پرس‌وجو برای internal-192-168-0-56.thekelleys.org.uk آدرس 192.168.0.56 را بازگرداند و پرس‌وجوی معکوس نیز برعکس عمل کند. همین امر برای IPv6 نیز صدق می‌کند؛ در نمایش آن از قابلیت فشرده‌سازی :: یا نمایش ویژه آدرس‌های IPv6 نگاشت‌شده به V4 استفاده نمی‌شود زیرا این موارد می‌توانند نام‌های دامنه غیرمجاز تولید کنند، بنابراین تمام دامنه‌ها به این شکل خواهند بود: internal-1000-0000-0000-0000-0000-0000-0008.example.com

محدوده آدرس در هر دو شکل این گزینه می‌تواند به صورت <start address>,<end address> یا <ip address>/<prefix-length> باشد. برای IPv6 آدرس‌های آغازین و پایانی باید در یک شبکه /64 قرار گیرند، یا طول پیشوند باید بزرگ‌تر یا مساوی ۶۴ باشد، به جز اینکه طول پیشوندهای کوتاه‌تر از ۶۴ تنها در صورتی مجاز است که از نام‌های غیرمتوالی استفاده شود.

مکان فایلی با قالب pcap را مشخص می‌کند که dnsmasq برای ذخیره رونوشت بسته‌های شبکه جهت اهداف اشکال‌زدایی از آن استفاده می‌کند. اگر هنگام شروع به کار dnsmasq این فایل وجود داشته باشد، حذف نمی‌شود؛ بسته‌های جدید به انتهای آن افزوده می‌شوند. این فایل می‌تواند یک لوله نام‌گذاری‌شده (named-pipe) باشد که Wireshark در حال شنود آن است.
مشخص می‌کند چه انواعی از بسته‌ها باید به dumpfile اضافه شوند. این آرگومان باید حاصل OR بیتی از ماسک‌های بیت برای هر نوع بسته مورد نظر جهت ثبت باشد: می‌توان آن را طبق معمول با قرار دادن 0x قبل از عدد در قالب هگزادسیمال مشخص کرد. هر بار که بسته‌ای در dumpfile نوشته می‌شود، dnsmasq دنباله بسته و ماسک نشان‌دهنده نوع آن را ثبت می‌کند. انواع فعلی عبارتند از: 0x0001 - پرس‌وجوهای DNS از سوی کلاینت‌ها، 0x0002 - پاسخ‌های DNS به کلاینت‌ها، 0x0004 - پرس‌وجوهای DNS به بالادستی، 0x0008 - پاسخ‌های DNS از سوی بالادستی، 0x0010 - پرس‌وجوهای ارسال‌شده به بالادستی برای اعتبارسنجی DNSSEC، 0x0020 - پاسخ‌ها به پرس‌وجوهای اعتبارسنجی DNSSEC، 0x0040 - پاسخ‌ها به پرس‌وجوهای کلاینت که اعتبارسنجی DNSSEC آن‌ها شکست خورده است، 0x0080 - پاسخ‌ها به پرس‌وجوهای اعتبارسنجی DNSSEC که اعتبارسنجی آن‌ها با شکست مواجه شده است، 0x1000 - پروتکل DHCPv4، 0x2000 - پروتکل DHCPv6، 0x4000 - اعلان مسیریاب (Router advertisement)، 0x8000 - پروتکل TFTP.
آدرس MAC درخواست‌کننده را به پرس‌وجوهای DNSای که به بالادستی هدایت می‌شوند اضافه می‌کند. این می‌تواند برای فیلتر کردن DNS توسط سرور بالادستی استفاده شود. آدرس MAC تنها زمانی می‌تواند اضافه شود که درخواست‌کننده در همان زیرشبکه سرور dnsmasq باشد. توجه داشته باشید که سازوکار مورد استفاده برای دستیابی به این هدف (یک گزینه EDNS0) هنوز استانداردسازی نشده است، بنابراین این قابلیت باید آزمایشی در نظر گرفته شود. همچنین توجه داشته باشید که افشای آدرس‌های MAC از این طریق ممکن است پیامدهای امنیتی و حریم خصوصی به همراه داشته باشد. هشدار مربوط به حافظه نهان (کَش) که برای --add-subnet ذکر شده در مورد --add-mac نیز صدق می‌کند. یک کدگذاری جایگزین برای MAC به صورت base64 با افزودن پارامتر "base64" فعال می‌شود و کدگذاری خوانا برای انسان به صورت هگزادسیمال و دو‌نقطه با افزودن پارامتر "text" در دسترس قرار می‌گیرد.
هرگونه اطلاعات آدرس MAC موجود در پرس‌وجوهای پایین‌دستی را پیش از ارسال به بالادستی حذف می‌کند.
یک رشته شناسایی دلخواه را به پرس‌وجوهای DNS ارسالی به بالادستی اضافه می‌کند.
یک آدرس زیرشبکه را به پرس‌وجوهای DNSای که به بالادستی هدایت می‌شوند اضافه می‌کند. اگر آدرسی در این فلگ مشخص شده باشد، از آن استفاده خواهد شد؛ در غیر این صورت، از آدرس درخواست‌کننده استفاده می‌شود. میزان ارسال آدرس به پارامتر طول پیشوند بستگی دارد: مقدار ۳۲ (۱۲۸ برای IPv6) کل آدرس را ارسال می‌کند، و صفر هیچ بخشی از آن را ارسال نمی‌کند اما همچنان درخواست را علامت‌گذاری می‌کند تا هیچ سرور نام بالادستی نیز اطلاعات آدرس کلاینت را اضافه نکند. مقدار پیش‌فرض برای هر دو IPv4 و IPv6 صفر است. توجه داشته باشید که سرورهای نام بالادستی ممکن است طوری پیکربندی شده باشند که بر اساس این اطلاعات نتایج متفاوتی را برگردانند، اما حافظه نهان (کَش) dnsmasq این موضوع را لحاظ نمی‌کند. بنابراین ذخیره در حافظه نهان برای چنین پاسخ‌هایی غیرفعال است، مگر اینکه آدرس زیرشبکه اضافه‌شده ثابت باشد.

برای مثال: --add-subnet=24,96 به ترتیب زیرشبکه‌های /24 و /96 درخواست‌کننده را برای درخواست‌کنندگان IPv4 و IPv6 اضافه می‌کند. --add-subnet=1.2.3.4/24 مقدار 1.2.3.0/24 را برای درخواست‌کنندگان IPv4 و ::/0 را برای درخواست‌کنندگان IPv6 اضافه می‌کند. --add-subnet=1.2.3.4/24,1.2.3.4/24 مقدار 1.2.3.0/24 را برای هر دو دسته درخواست‌کنندگان IPv4 و IPv6 اضافه می‌کند.

هرگونه آدرس زیرشبکه موجود در پرس‌وجوی پایین‌دستی را پیش از ارسال به بالادستی حذف می‌کند. اگر --add-subnet تنظیم شده باشد، این گزینه همچنین تضمین می‌کند که هر زیرشبکه ارائه‌شده از سوی پایین‌دستی با زیرشبکه اضافه‌شده توسط dnsmasq جایگزین شود. در غیر این صورت، dnsmasq زیرشبکه موجود در پرس‌وجو را جایگزین نخواهد کرد.
آدرس IP درخواست‌کننده را در پرس‌وجوهای DNS ارسالی به بالادستی تعبیه می‌کند. اگر شناسه دستگاه (device id)، شناسه دارایی (asset id) یا شناسه سازمان (organization id) مشخص شده باشند، این اطلاعات در پرس‌وجوهای هدایت‌شده گنجانده می‌شود و ممکن است بتوان از آن در سیاست‌های فیلترینگ و گزارش‌گیری استفاده کرد. ترتیب مشخصه‌های شناسه بی‌اهمیت است، اما باید با کاما از یکدیگر جدا شوند. Deviceid یک عدد هگزادسیمال شانزده رقمی است و شناسه‌های org و asset اعداد ده‌دهی هستند.
اندازه حافظه نهان (کَش) dnsmasq را تعیین می‌کند. مقدار پیش‌فرض ۱۵۰ نام است. تنظیم اندازه حافظه نهان روی صفر، کَش کردن را غیرفعال می‌کند. نکته: اندازه بسیار بزرگ حافظه نهان بر کارایی تاثیر می‌گذارد.
حافظه نهان منفی (negative caching) را غیرفعال می‌کند. حافظه نهان منفی به dnsmasq اجازه می‌دهد پاسخ‌های «چنین دامنه‌ای وجود ندارد» را از سرورهای نام بالادستی به خاطر بسپارد و به پرس‌وجوهای یکسان بدون ارسال مجدد آن‌ها پاسخ دهد.
نرم‌افزار dnsmasq به‌طور معمول برای تعادل بار، ترتیب رکوردهای A یا AAAA را برای یک نام یکسان در پرس‌وجوهای پیاپی جابه‌جا می‌کند. این گزینه آن رفتار را غیرفعال می‌کند تا رکوردها همواره به همان ترتیبی که از بالادستی دریافت شده‌اند بازگردانده شوند.
نرم‌افزار dnsmasq می‌تواند بزرگی و کوچکی حروف را در پرس‌وجوهای DNS که به بالادستی ارسال می‌کند به عنوان یک ویژگی امنیتی درهم بریزد. این روش می‌تواند با سرورهای DNS معیوب نادری که بزرگی و کوچکی حروف پرس‌وجو را در پاسخ خود حفظ نمی‌کنند، تداخل نامطلوب ایجاد کند. اولین باری که پاسخی دریافت شود که از همه جهات به جز بزرگی و کوچکی حروف با پرس‌وجو مطابقت دارد، یک هشدار ثبت خواهد شد. اگر این امر با کار نکردن DNS هم‌زمان شود، لازم است این ویژگی غیرفعال گردد. از نسخه 2.91، کدگذاری 0x20 به‌طور پیش‌فرض غیرفعال است و باید با --do-0x20-encode فعال شود. ممکن است این پیش‌فرض در آینده تغییر کند، بنابراین برای اطمینان از وضعیت آن پس از یک ارتقا، --do-0x20-encode یا --no-0x20-encode را در پیکربندی خود تنظیم کنید. گزینه --no-0x20-encode بر --do-0x20-encode یا پیش‌فرض‌های فعال‌سازی 0x20 در آینده اولویت دارد.
در صورت تنظیم، اگر یک نام DNS در حافظه نهان وجود داشته باشد اما طول عمر آن منقضی شده باشد، dnsmasq در هر صورت داده را بازمی‌گرداند. (پس از بازگرداندن داده کهنه، تلاش می‌کند داده‌ها را با یک پرس‌وجو از بالادستی تازه‌سازی کند.) این امر می‌تواند سرعت و قابلیت اطمینان را بهبود بخشد. البته به بهای بازگرداندن گاه‌به‌گاه داده‌های منسوخ و بهره‌وری کمتر حافظه نهان تمام می‌شود، چرا که داده‌های قدیمی با منقضی شدن TTL پاک نمی‌شوند و بنابراین حافظه نهان عمدتاً بر اساس کمترین استفاده اخیر (LRU) اداره می‌شود. برای کاهش مشکلات ناشی از پاسخ‌های DNS بسیار قدیمی، بیشینه زمان فرسودگی رکوردهای ذخیره‌شده در حافظه نهان را می‌توان بر حسب ثانیه مشخص کرد (پیش‌فرض این است که هیچ داده‌ای قدیمی‌تر از یک روز ارائه نشود). تنظیم زمان مازاد TTL روی صفر باعث ارائه داده‌های کهنه حافظه نهان صرف‌نظر از مدت زمان انقضای آن‌ها خواهد شد.
-0, --dns-forward-max=<queries>
بیشینه تعداد پرس‌وجوهای هم‌زمان DNS را تنظیم می‌کند. مقدار پیش‌فرض ۱۵۰ است که باید برای بیشتر محیط‌ها مناسب باشد. تنها وضعیت شناخته‌شده‌ای که نیاز به افزایش این مقدار دارد، هنگام استفاده از تفکیک‌کننده‌های فایل لاگ وب‌سرور است که می‌توانند شمار زیادی پرس‌وجوی هم‌زمان ایجاد کنند. این پارامتر در واقع تعداد پرس‌وجوهای هم‌زمان را به ازای هر گروه سرور کنترل می‌کند، که در آن گروه سرور مجموعه‌ای از سرور(ها) است که به یک دامنه منفرد متصل هستند. بنابراین اگر دامنه‌ای از طریق --server=/example.com/1.2.3.4 سرور اختصاصی خود را داشته باشد و 1.2.3.4 پاسخگو نباشد، اما پرس‌وجوها برای *.example.com نتوانند به جای دیگری بروند، سایر پرس‌وجوها تحت تأثیر قرار نخواهند گرفت. در پیکربندی‌هایی با تعداد زیادی از این گروه‌های سرور و منابع محدود، ممکن است نیاز به کاهش این مقدار باشد.
پاسخ‌های DNS را اعتبارسنجی کرده و داده‌های DNSSEC را در حافظه نهان ذخیره می‌کند. هنگام هدایت پرس‌وجوهای DNS، dnsmasq رکوردهای DNSSEC مورد نیاز برای اعتبارسنجی پاسخ‌ها را درخواست می‌کند. پاسخ‌ها اعتبارسنجی شده و نتیجه به عنوان بیت داده معتبر (Authenticated Data) در بسته DNS بازگردانده می‌شود. علاوه بر این، رکوردهای DNSSEC در حافظه نهان ذخیره می‌شوند که اعتبارسنجی توسط کلاینت‌ها را کارآمدتر می‌سازد. توجه داشته باشید که اعتبارسنجی توسط کلاینت‌ها امن‌ترین حالت DNSSEC است، اما برای کلاینت‌هایی که قادر به انجام اعتبارسنجی نیستند، استفاده از بیت AD تنظیم‌شده توسط dnsmasq در صورتی که شبکه میان سرور dnsmasq و کلاینت مورد اعتماد باشد سودمند است. dnsmasq باید با فعال بودن HAVE_DNSSEC کامپایل شده باشد و لنگرهای اعتماد DNSSEC فراهم شوند؛ به --trust-anchor. مراجعه کنید. از آنجا که فرآیند اعتبارسنجی DNSSEC از حافظه نهان استفاده می‌کند، کاهش اندازه حافظه نهان به کمتر از مقدار پیش‌فرض در زمان فعال بودن DNSSEC مجاز نیست. سرورهای نام بالادستی dnsmasq باید قابلیت DNSSEC داشته باشند، یعنی بتوانند رکوردهای DNSSEC را همراه با داده‌ها بازگردانند. اگر چنین نباشند، آنگاه dnsmasq قادر به تعیین وضعیت اعتماد پاسخ‌ها نخواهد بود و این بدان معناست که سرویس DNS کاملاً مختل خواهد شد.
رکوردهای DS را به عنوان لنگرهای اعتماد برای اعتبارسنجی DNSSEC فراهم می‌کند. کلاس به‌طور پیش‌فرض IN است. معمولاً این‌ها رکورد(های) DS برای کلید(های) امضای کلید (KSK) زون ریشه خواهند بود، اما لنگرهای اعتماد برای دامنه‌های محدود نیز امکان‌پذیر هستند. یک لنگر اعتماد منفی (یعنی اثبات اینکه یک رکورد DS وجود ندارد) را می‌توان با مشخص کردن صرف نام یا صرف نام و کلاس پیکربندی کرد. این امر می‌تواند برای وادار کردن dnsmasq به رفتار با زون‌های واگذارشده از طریق --server=/<domain>/<ip-address> به عنوان زون‌های امضانشده مفید باشد. لنگرهای اعتماد فعلی زون ریشه را می‌توان از https://data.iana.org/root-anchors/root-anchors.xml دریافت کرد.
به‌طور پیش‌فرض، dnsmasq بررسی می‌کند که پاسخ‌های DNS امضانشده قانونی باشند: این امر مستلزم پرس‌وجوهای اضافی احتمالی حتی برای اکثریت زون‌های DNS است که در حال حاضر امضا نشده‌اند. اگر --dnssec-check-unsigned=no در پیکربندی ظاهر شود، آنگاه چنین پاسخ‌هایی معتبر فرض شده و به جلو فرستاده می‌شوند (البته بدون اینکه بیت "authentic data" تنظیم شود). این کار در برابر مهاجمی که پاسخ‌های امضانشده را برای زون‌های امضاشده DNS جعل می‌کند محافظتی نمی‌کند، اما سریع است.

نسخه‌های dnsmasq پیش از 2.80 به‌طور پیش‌فرض پاسخ‌های امضانشده را بررسی نمی‌کردند و از --dnssec-check-unsigned برای فعال کردن آن استفاده می‌کردند. چنین پیکربندی‌هایی مانند گذشته به کار خود ادامه می‌دهند، اما مواردی که از پیش‌فرض عدم بررسی استفاده می‌کردند باید تغییر یابند تا صراحتاً عدم بررسی را مشخص کنند. پیش‌فرض جدید به این دلیل است که خاموش کردن بررسی پاسخ‌های امضانشده ذاتاً خطرناک است. این کار نه تنها احتمال پاسخ‌های جعلی را باز می‌گذارد، بلکه باعث می‌شود حتی زمانی که سرورهای نام بالادستی از DNSSEC پشتیبانی نمی‌کنند همه چیز به ظاهر کار کند، و در این حالت هیچ اعتبارسنجی DNSSEC رخ نمی‌دهد.

امضاهای DNSSEC تنها برای پنجره‌های زمانی مشخصی معتبر هستند و در خارج از این بازه‌ها باید رد شوند. این امر یک معمای جالب مرغ و تخم‌مرغ را برای ماشین‌هایی که ساعت بی‌درنگ سخت‌افزاری ندارند ایجاد می‌کند. برای این ماشین‌ها، تعیین زمان صحیح معمولاً نیازمند استفاده از NTP و بنابراین DNS است، اما اعتبارسنجی DNS مستلزم آن است که زمان صحیح از قبل مشخص باشد. تنظیم این فلگ بررسی پنجره زمانی را (نه سایر اعتبارسنجی‌های DNSSEC) تنها تا زمانی که فرآیند dnsmasq سیگنال SIGINT را دریافت کند حذف می‌کند. هدف این است که dnsmasq زمانی با این فلگ راه‌اندازی شود که پلتفرم تشخیص می‌دهد زمان قابل اعتماد در حال حاضر در دسترس نیست. به محض اینکه زمان قابل اعتماد برقرار شد، باید یک سیگنال SIGINT به dnsmasq ارسال گردد که بررسی زمان را فعال کرده و حافظه نهان را از رکوردهای DNSای که به طور کامل بررسی نشده‌اند پاک می‌کند.

نسخه‌های قبلی dnsmasq از سیگنال SIGHUP (که بخش زیادی از پیکربندی را مجدداً می‌خواند) برای فعال‌سازی اعتبارسنجی زمان نیز استفاده می‌کردند.

اگر dnsmasq در حالت اشکال‌زدایی (فلگ --no-daemon) اجرا شود، SIGINT معنای معمول خود مبنی بر خاتمه دادن به فرآیند dnsmasq را حفظ خواهد کرد.

روشی جایگزین را برای بررسی اعتبار زمان سیستم جهت DNSSEC فعال می‌کند (به --dnssec-no-timecheck مراجعه کنید). در این حالت، به محض اینکه زمان سیستم از برچسب زمانی روی فایل مشخص‌شده جلوتر بیفتد، معتبر در نظر گرفته می‌شود. فایل ایجاد شده و برچسب زمانی آن به صورت خودکار توسط dnsmasq تنظیم می‌گردد. فایل باید روی یک فایل‌سیستم ماندگار ذخیره شود تا خود آن و مقدار mtime آن در راه‌اندازی‌های مجدد سیستم حفظ شوند. فایل برچسب زمانی پس از آنکه dnsmasq دسترسی ریشه (root) را رها کرد ساخته می‌شود، بنابراین باید در مکانی با دسترسی نوشتن برای کاربر غیرممتازی باشد که dnsmasq تحت هویت آن اجرا می‌شود.
بیت Authenticated Data مربوط به DNSSEC را از سرورهای بالادستی به کلاینت‌های پایین‌دستی رونوشت می‌کند. این یک روش جایگزین برای اعتبارسنجی DNSSEC توسط خود dnsmasq است، اما به امنیت شبکه میان dnsmasq و سرورهای بالادستی و میزان اعتماد به سرورهای بالادستی بستگی دارد. توجه داشته باشید که ذخیره کردن بیت Authenticated Data در حافظه نهان به درستی در تمام حالات از نظر فنی امکان‌پذیر نیست. اگر قرار است هنگام استفاده از این گزینه به بیت AD اتکا شود، حافظه نهان باید با استفاده از --cache-size=0 غیرفعال گردد. در بیشتر حالات، فعال‌سازی اعتبارسنجی DNSSEC درون dnsmasq گزینه بهتری است. برای جزئیات به --dnssec مراجعه کنید.
محدودیت‌های پیش‌فرض منابع اعمال‌شده بر اعتبارسنجی DNSSEC را بازنویسی می‌کند. عملیات رمزنگاری سنگین هستند و دامنه‌های ساختگی می‌توانند با وادار کردن یک اعتبارسنج DNSSEC به انجام صدها هزار عملیات از این نوع، آن را دچار محرومیت از سرویس (DoS) کنند. برای جلوگیری از این موضوع، کد اعتبارسنجی dnsmasq محدودیت‌هایی را برای میزان کار صرف‌شده در اعتبارسنجی اعمال می‌کند. اگر از هر یک از این محدودیت‌ها فراتر رود، اعتبارسنجی با شکست مواجه شده و با دامنه به عنوان BOGUS (جعلی) رفتار می‌شود. چهار محدودیت به ترتیب وجود دارد (مقادیر پیش‌فرض در پرانتز): تعداد شکست‌های اعتبارسنجی امضا در هر RRset (۲۰)، تعداد اعتبارسنجی‌های امضا و محاسبات هش در هر پرس‌وجو (۲۰۰)، تعداد زیرپرس‌وجوها برای دریافت RRsetهای DS و DNSKEY در هر پرس‌وجو (۴۰)، و تعداد تکرارها در یک رکورد NSEC3 (۱۵۰). بیشینه مقادیر حاصل‌شده در طول اعتبارسنجی ذخیره می‌شوند و به عنوان بخشی از آمار تولید‌شده توسط SIGUSR1 تخلیه می‌گردند. مشخص کردن مقدار ۰ برای یک محدودیت، پیش‌فرض را در جای خود باقی می‌گذارد؛ بنابراین --dnssec-limits=0,0,20 تعداد زیرپرس‌وجوها را روی ۲۰ تنظیم می‌کند در حالی که سایر محدودیت‌ها را در مقادیر پیش‌فرض نگه می‌دارد.
حالت اشکال‌زدایی را برای اعتبارسنجی DNSSEC فعال می‌کند، بیت Checking Disabled را روی پرس‌وجوهای بالادستی تنظیم می‌نماید، و پاسخ‌هایی را که اعتبارسنجی نمی‌شوند به پاسخ‌هایی با کد بازگشتی SERVFAIL تبدیل نمی‌کند. توجه داشته باشید که تنظیم این گزینه ممکن است رفتار DNS را به شیوه‌ای نامطلوب تحت تأثیر قرار دهد، این یک فلگ لاگ‌گیری اضافی نیست و نباید در محیط عملیاتی تنظیم شود.
تعریف یک ناحیه DNS که در آن dnsmasq به عنوان کارگزار رسمی (authoritative) عمل می‌کند. رکوردهای DNS تعریف‌شده محلی که در این دامنه قرار دارند ارائه خواهند شد. اگر زیرشبکه(ها) مشخص شده باشند، رکوردهای A و AAAA باید در یکی از زیرشبکه‌های تعیین‌شده قرار داشته باشند.

به عنوان جایگزینی برای تعیین مستقیم زیرشبکه‌ها، امکان ارائه نام یک رابط شبکه وجود دارد؛ در این حالت زیرشبکه‌های حاصل از نشانی‌های پیکربندی‌شده و netmask/طول پیشوند آن رابط شبکه استفاده می‌شوند. این قابلیت هنگام استفاده از محدوده‌های ساخت‌یافته در DHCP سودمند است، زیرا نشانی واقعی پویا بوده و هنگام پیکربندی dnsmasq مشخص نیست. نشانی‌های رابط شبکه را می‌توان با استفاده از <interface>/6 تنها به نشانی‌های IPv6 یا با استفاده از <interface>/4 تنها به نشانی‌های IPv4 محدود کرد. این مورد زمانی کاربرد دارد که یک رابط شبکه دارای نشانی‌های پویای سراسری IPv6 باشد که باید در ناحیه نمایش داده شوند، اما دارای نشانی‌های RFC1918 برای IPv4 باشد که نباید در ناحیه ظاهر شوند. مشخصه‌های نام رابط شبکه و زیرشبکه با نشانی صریح (address-literal) را می‌توان آزادانه در یک اعلان --auth-zone یکسان استفاده کرد.

امکان مستثنی کردن برخی نشانی‌های IP از پاسخ‌ها وجود دارد. از این ویژگی می‌توان برای اطمینان از اینکه پاسخ‌ها تنها شامل نشانی‌های IP سراسری و قابل مسیریابی هستند استفاده کرد (با مستثنی کردن نشانی‌های لوپ‌بک، RFC1918 و ULA).

زیرشبکه(ها) همچنین برای تعریف دامنه‌های in-addr.arpa و ip6.arpa که برای پرس‌وجوهای معکوس DNS ارائه می‌شوند به کار می‌روند. در صورت مشخص نشدن، طول پیشوند به طور پیش‌فرض برای IPv4 برابر با 24 و برای IPv6 برابر با 64 است. برای زیرشبکه‌های IPv4، طول پیشوند باید دارای مقدار 8، 16 یا 24 باشد مگر اینکه با RFC 2317 آشنایی داشته باشید و تفویض (delegation) مربوط به in-addr.arpa را بر همان اساس مرتب کرده باشید. توجه داشته باشید که اگر هیچ زیرشبکه‌ای مشخص نشود، به هیچ پرس‌وجوی معکوسی پاسخ داده نخواهد شد.

مشخص کردن فیلدهای رکورد SOA مرتبط با ناحیه‌های رسمی (authoritative). توجه داشته باشید که این گزینه اختیاری است و تمام مقادیر بر روی پیش‌فرض‌های معقول تنظیم شده‌اند.
مشخص کردن هرگونه کارگزار ثانویه برای ناحیه‌ای که dnsmasq برای آن کارگزار رسمی است. این کارگزارها باید طوری پیکربندی شوند که داده‌های ناحیه را از طریق انتقال ناحیه (zone transfer) از dnsmasq دریافت کرده و به پرس‌وجوهای همان ناحیه‌های رسمی مشابه dnsmasq پاسخ دهند.
مشخص کردن نشانی‌های کارگزارهای ثانویه که مجاز به آغاز درخواست‌های انتقال ناحیه (AXFR) برای ناحیه‌هایی هستند که dnsmasq برای آن‌ها کارگزار رسمی است. اگر این گزینه داده نشود اما --auth-sec-servers مشخص شده باشد، در این صورت درخواست‌های AXFR از هر کارگزار ثانویه‌ای پذیرفته خواهد شد. مشخص کردن --auth-peer بدون --auth-sec-servers انتقال ناحیه را فعال می‌کند، اما کارگزار ثانویه را در رکوردهای NS بازگردانده‌شده توسط dnsmasq اعلان نمی‌نماید.
خواندن نشان (mark) ردیابی اتصال لینوکس (conntrack) مرتبط با پرس‌وجوهای ورودی DNS و تنظیم همان مقدار نشان بر روی ترافیک بالادستی مورد استفاده برای پاسخ به آن پرس‌وجوها. این کار اجازه می‌دهد ترافیک ایجادشده توسط dnsmasq با پرس‌وجوهایی که باعث آن شده‌اند مرتبط شود که برای حسابداری پهنای باند و فایروال سودمند است. dnsmasq باید به همراه پشتیبانی از conntrack کامپایل شده باشد و هسته نیز باید پشتیبانی از conntrack را فعال و پیکربندی کرده باشد. این گزینه را نمی‌توان با --query-port. ترکیب کرد.

فعال‌سازی کارگزار DHCP. نشانی‌ها از محدوده <start-addr> تا <end-addr> و از نشانی‌های تعریف‌شده به صورت ایستا در گزینه‌های --dhcp-host تخصیص داده خواهند شد. اگر زمان اجاره مشخص شده باشد، اجاره‌ها برای همان مدت زمان اعطا می‌شوند. زمان اجاره بر حسب ثانیه، یا دقیقه (مانند 45m)، ساعت (مانند 1h)، روز (2d)، هفته (1w) یا «infinite» (نامحدود) است. در صورت مشخص نشدن، زمان اجاره پیش‌فرض برای IPv4 یک ساعت و برای IPv6 یک روز است. حداقل زمان اجاره دو دقیقه است. برای محدوده‌های IPv6، زمان اجاره می‌تواند «deprecated» باشد؛ این کار طول عمر ترجیحی (preferred lifetime) ارسال‌شده در اجاره DHCP یا اعلان مسیریاب را روی صفر تنظیم می‌کند که باعث می‌شود کلاینت‌ها در صورت وجود، برای اتصالات جدید از نشانی‌های دیگر استفاده کنند که مقدمه‌ای برای شماره‌گذاری مجدد شبکه (renumbering) است.

این گزینه ممکن است با نشانی‌های مختلف تکرار شود تا سرویس DHCP برای بیش از یک شبکه فعال گردد. برای شبکه‌های متصل مستقیم (یعنی شبکه‌هایی که رایانه اجراکننده dnsmasq روی آن‌ها یک رابط شبکه دارد)، ماسک شبکه اختیاری است: dnsmasq آن را از پیکربندی رابط شبکه تشخیص می‌دهد. برای شبکه‌هایی که سرویس DHCP را از طریق یک عامل بازپخش (relay agent) دریافت می‌کنند، dnsmasq نمی‌تواند ماسک شبکه را خودش تعیین کند، بنابراین باید مشخص شود؛ در غیر این صورت dnsmasq باید بر اساس کلاس نشانی شبکه (A، B یا C) آن را حدس بزند. نشانی برودکست (پخش همگانی) همواره اختیاری است. داشتن بیش از یک --dhcp-range در یک زیرشبکه منفرد همیشه مجاز است.

برای IPv6، پارامترها کمی متفاوت هستند: به جای ماسک شبکه و نشانی برودکست، یک طول پیشوند اختیاری وجود دارد که باید برابر یا بزرگ‌تر از طول پیشوند روی رابط شبکه محلی باشد. در صورت مشخص نشدن، مقدار پیش‌فرض آن 64 است. بر خلاف مورد IPv4، طول پیشوند به طور خودکار از پیکربندی رابط شبکه استخراج نمی‌شود. حداقل اندازه طول پیشوند 64 است.

پروتکل IPv6 (تنها) از نوع دیگری از محدوده پشتیبانی می‌کند. در این حالت، نشانی آغازین و نشانی پایانی اختیاری تنها شامل بخش شبکه هستند (یعنی ::1) و پس از آن‌ها constructor:<interface>. می‌آید. این ساختار یک الگو تشکیل می‌دهد که نحوه ایجاد محدوده‌ها را بر اساس نشانی‌های تخصیص‌یافته به رابط شبکه توصیف می‌کند. به عنوان مثال:

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

به دنبال نشانی‌ها روی eth0 می‌گردد و سپس محدوده‌ای از <network>::1 تا <network>::400 ایجاد می‌کند. اگر بیش از یک شبکه به رابط شبکه اختصاص داده شده باشد، محدوده‌های مربوطه به صورت خودکار ایجاد می‌شوند، و با منسوخ شدن و سپس حذف نشانی، این محدوده‌ها نیز منسوخ و در نهایت حذف خواهند شد. نام رابط شبکه می‌تواند در انتها دارای نویسه عام «*» باشد. توجه داشته باشید که هر نشانی روی eth0 مناسب نخواهد بود: این نشانی نباید خودکار پیکربندی‌شده (autoconfigured)، نشانی حریم خصوصی (privacy address)، یا منسوخ‌شده (deprecated) باشد.

اگر یک --dhcp-range تنها برای DHCP بدون حالت (stateless) و/یا SLAAC استفاده شود، نشانی می‌تواند به سادگی :: باشد:

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

عبارت اختیاری set:<tag> یک برچسب الفبایی-عددی تنظیم می‌کند که این شبکه را نشانه‌گذاری می‌نماید تا بتوان گزینه‌های DHCP را بر مبنای هر شبکه تعیین کرد. هنگامی که به جای آن پیشوند «tag:» قرار گیرد، معنای آن از تنظیم یک برچسب به تطبیق آن تغییر می‌یابد. تنها یک برچسب را می‌توان تنظیم کرد، اما بیش از یک برچسب می‌تواند تطبیق داده شود.

کلیدواژه اختیاری <mode> می‌تواند static باشد که به dnsmasq می‌گوید DHCP را برای شبکه مشخص‌شده فعال کند، اما نشانی‌های IP را به صورت پویا تخصیص ندهد: تنها میزبان‌هایی که دارای نشانی‌های ایستا از طریق --dhcp-host یا از فایل /etc/ethers هستند سرویس‌دهی خواهند شد. یک زیرشبکه فقط-ایستا (static-only) با نشانی تمام صفر می‌تواند به عنوان نشانی فراگیر (catch-all) استفاده شود تا پاسخ به تمام بسته‌های Information-request را روی زیرشبکه‌ای که با DHCPv6 بدون حالت ارائه می‌شود فعال کند، یعنی: --dhcp-range=::,static

برای IPv4، مقدار <mode> می‌تواند proxy باشد که در این حالت dnsmasq قابلیت proxy-DHCP را روی زیرشبکه مشخص‌شده ارائه خواهد داد. (برای جزئیات به --pxe-prompt و --pxe-service مراجعه کنید.)

برای IPv6، حالت می‌تواند ترکیبی از موارد ra-only, slaac, ra-names, ra-stateless, ra-advrouter, off-link. باشد.

ra-only به dnsmasq می‌گوید که تنها اعلان مسیریاب (Router Advertisement) را روی این زیرشبکه ارائه دهد، نه سرویس DHCP.

slaac به dnsmasq می‌گوید اعلان مسیریاب را روی این زیرشبکه ارائه دهد و بیت A را در اعلان مسیریاب تنظیم کند تا کلاینت از نشانی‌های SLAAC استفاده نماید. هنگامی که همراه با یک محدوده DHCP یا نشانی ایستای DHCP استفاده شود، نتیجه این خواهد بود که کلاینت هم نشانی تخصیص‌یافته توسط DHCP و هم نشانی SLAAC را خواهد داشت.

ra-stateless اعلان‌های مسیریاب را با بیت‌های O و A تنظیم‌شده ارسال می‌کند و سرویس DHCP بدون حالت (stateless) را فراهم می‌سازد. کلاینت از یک نشانی SLAAC استفاده خواهد کرد و برای دریافت سایر اطلاعات پیکربندی از DHCP بهره می‌گیرد.

ra-names حالتی را فعال می‌کند که به میزبان‌های دوپشته‌ای (dual-stack) که برای IPv6 از SLAAC استفاده می‌کنند، نام‌های DNS اختصاص می‌دهد. dnsmasq از اجاره IPv4 میزبان برای استخراج نام، قطعه شبکه و نشانی MAC استفاده می‌کند و فرض می‌نماید که میزبان روی همان قطعه شبکه، دارای یک نشانی IPv6 محاسبه‌شده با الگوریتم SLAAC نیز خواهد بود. این نشانی پینگ می‌شود و در صورت دریافت پاسخ، یک رکورد AAAA برای این نشانی IPv6 به DNS افزوده می‌شود. توجه داشته باشید که این اتفاق تنها برای شبکه‌های متصل مستقیم رخ می‌دهد (نه شبکه‌ای که DHCP را از طریق بازپخش/relay انجام می‌دهد) و در صورتی که میزبان از افزونه‌های حریم خصوصی (privacy extensions) استفاده کند کار نخواهد کرد. ra-names می‌تواند با ra-stateless و slaac. ترکیب شود.

ra-advrouter حالتی را فعال می‌کند که در آن به جای پیشوند(ها)، نشانی(های) مسیریاب در اعلان‌ها گنجانده می‌شوند. این مورد در بخش 7.2 از RFC-3775 شرح داده شده و در mobile IPv6 استفاده می‌شود. در این حالت گزینه فاصله زمانی (interval) نیز همان‌طور که در بخش 7.3 از RFC-3775 توضیح داده شده گنجانده می‌شود.

off-link به dnsmasq می‌گوید که پیشوند را بدون تنظیم بیت on-link (یا همان بیت L) اعلان کند.

مشخص کردن پارامترهای اختصاصی به ازای هر میزبان برای کارگزار DHCP. این امکان را فراهم می‌سازد که به یک رایانه با نشانی سخت‌افزاری معین همواره همان نام میزبان، نشانی IP و زمان اجاره یکسان تخصیص یابد. نام میزبانی که به این صورت مشخص می‌شود بر هر نام ارائه‌شده توسط کلاینت DHCP روی آن رایانه برتری دارد. همچنین حذف نشانی سخت‌افزاری و درج نام میزبان مجاز است که در این حالت نشانی IP و زمان‌های اجاره برای هر رایانه‌ای که مدعی آن نام باشد اعمال خواهد شد. به عنوان مثال: --dhcp-host=00:20:e0:3b:13:af,wap,infinite به dnsmasq می‌گوید به رایانه‌ای با نشانی سخت‌افزاری 00:20:e0:3b:13:af نام wap و یک اجاره DHCP نامحدود اختصاص دهد. --dhcp-host=lap,192.168.0.199 به dnsmasq می‌گوید که همواره به رایانه lap نشانی IP مقدار 192.168.0.199 را اختصاص دهد.

نشانی‌های تخصیص‌یافته به این روش مقید به قرار داشتن در محدوده تعیین‌شده توسط گزینه --dhcp-range نیستند، اما باید در همان زیرشبکه یک dhcp-range معتبر باشند. برای زیرشبکه‌هایی که نیازی به استخر نشانی‌های تخصیص‌یافته پویا ندارند، از کلیدواژه «static» در اعلان --dhcp-range استفاده کنید.

استفاده از شناسه‌های کلاینت (که در دنیای IPv6، شناسه DUID کلاینت نامیده می‌شود) به جای نشانی‌های سخت‌افزاری برای شناسایی میزبان‌ها با افزودن پیشوند «id:» مجاز است. بنابراین: --dhcp-host=id:01:02:03:04,..... به میزبانی با شناسه کلاینت 01:02:03:04 اشاره دارد. همچنین مشخص کردن شناسه کلاینت به صورت متنی نیز مجاز است، مانند: --dhcp-host=id:clientidastext,.....

یک گزینه منفرد --dhcp-host می‌تواند شامل یک نشانی IPv4 یا یک یا چند نشانی IPv6 یا هر دو باشد. نشانی‌های IPv6 باید در قلاب‌ها (کروشه‌ها) محصور شوند، به این صورت: --dhcp-host=laptop,[1234::56] نشانی‌های IPv6 ممکن است تنها شامل بخش شناسه میزبان باشند: --dhcp-host=laptop,[::56] که در این صورت به عنوان نویسه عام در محدوده‌های ساخت‌یافته DHCP عمل می‌کنند و بخش مناسب شبکه در آن‌ها درج می‌شود. برای IPv6، یک نشانی می‌تواند شامل طول پیشوند باشد: --dhcp-host=laptop,[1234:50/126] که (در این حالت) چهار نشانی از 1234::50 تا 1234::53 را مشخص می‌کند. این قابلیت (و توانایی تعیین چندین نشانی) زمانی سودمند است که یک میزبان نام یا شناسه سخت‌افزاری ثابتی ارائه می‌دهد، اما DUIDهای متفاوتی دارد؛ زیرا به dnsmasq امکان می‌دهد تخصیص نشانی ایستا را رعایت کرده اما برای هر DUID نشانی متفاوتی تخصیص دهد. این وضعیت معمولاً هنگام راه‌اندازی شبکه‌ای زنجیره‌ای (chain netbooting) رخ می‌دهد، چرا که هر مرحله از زنجیره به نوبه خود یک نشانی دریافت می‌کند.

توجه داشته باشید که در DHCP پروتکل IPv6، نشانی سخت‌افزاری ممکن است در دسترس نباشد، هرچند معمولاً برای کلاینت‌های متصل مستقیم یا کلاینت‌هایی که از رله‌های DHCP با پشتیبانی از RFC 6939 استفاده می‌کنند در دسترس است.

برای DHCPv4، گزینه ویژه id:* به معنای «نادیده گرفتن هرگونه client-id و استفاده صرف از نشانی‌های MAC» است. این مورد زمانی سودمند است که یک کلاینت گاهی اوقات یک client-id ارائه می‌دهد و گاهی ارائه نمی‌دهد.

اگر نامی در /etc/hosts ظاهر شود، نشانی مرتبط می‌تواند به یک اجاره DHCP اختصاص یابد، اما تنها در صورتی که گزینه --dhcp-host که نام را مشخص می‌کند نیز وجود داشته باشد. در یک گزینه --dhcp-host تنها یک نام میزبان را می‌توان مشخص کرد، اما ایجاد نام‌های مستعار با استفاده از CNAMEها امکان‌پذیر است. (به --cname مراجعه کنید). توجه داشته باشید هنگامی که بخش کارگزار DNS در dnsmasq با تنظیم درگاه کارگزار DNS روی صفر غیرفعال شده باشد، از /etc/hosts استفاده نمی‌شود.

بیش از یک --dhcp-host می‌تواند (از طریق نام، نشانی سخت‌افزاری یا UID) با یک میزبان مرتبط شود. اینکه کدام‌یک استفاده می‌شود (و بنابراین کدام نشانی توسط DHCP تخصیص یافته و در DNS ظاهر می‌شود) به زیرشبکه‌ای بستگی دارد که میزبان آخرین بار اجاره DHCP را روی آن دریافت کرده است: گزینه --dhcp-host با نشانی درون آن زیرشبکه استفاده خواهد شد. اگر بیش از یک نشانی درون زیرشبکه باشد، نتیجه نامشخص خواهد بود. نتیجه فرعی این موضوع این است که نام مرتبط با میزبان با استفاده از --dhcp-host تا زمانی که میزبان یک اجاره DHCP دریافت نکند در DNS ظاهر نخواهد شد.

کلیدواژه ویژه ignore به dnsmasq می‌گوید که هرگز یک اجاره DHCP به رایانه ارائه ندهد. رایانه می‌تواند با نشانی سخت‌افزاری، شناسه کلاینت یا نام میزبان مشخص شود. برای مثال: --dhcp-host=00:20:e0:3b:13:af,ignore. این قابلیت می‌تواند زمانی سودمند باشد که کارگزار DHCP دیگری روی شبکه وجود داشته باشد که باید توسط برخی رایانه‌ها استفاده شود.

ساختار set:<tag> هر زمان که این دستورالعمل --dhcp-host در حال استفاده باشد، برچسب را تنظیم می‌کند. از این ویژگی می‌توان برای ارسال انتخابی گزینه‌های DHCP صرفاً برای این میزبان استفاده کرد. بیش از یک برچسب می‌تواند در دستورالعمل --dhcp-host تنظیم شود (اما نه در بخش‌های دیگر که set:<tag> مجاز است). هنگامی که یک میزبان با هر دستورالعمل --dhcp-host (یا دستورالعمل ناشی از /etc/ethers) تطبیق یابد، برچسب ویژه known تنظیم می‌شود. این موضوع امکان می‌دهد dnsmasq طوری پیکربندی شود که درخواست‌های رایانه‌های ناشناخته را با استفاده از --dhcp-ignore=tag:!known نادیده بگیرد. اگر میزبان تنها با یک دستورالعمل --dhcp-host تطبیق یابد که به دلیل مشخص کردن نشانی در زیرشبکه‌ای متفاوت قابل استفاده نیست، برچسب known-othernet تنظیم خواهد شد.

ساختار tag:<tag> فیلتر می‌کند که کدام دستورالعمل‌های dhcp-host استفاده شوند. بیش از یک برچسب را می‌توان ارائه داد. در این حالت، درخواست باید با تمام برچسب‌ها تطبیق داشته باشد. دستورالعمل‌های برچسب‌دار نسبت به موارد بدون برچسب در اولویت قرار دارند. توجه داشته باشید که همچنان باید یکی از موارد <hwaddr>، <client_id> یا <hostname> مشخص شود (می‌تواند نویسه عام باشد).

نشانی‌های اترنت (نه شناسه‌های کلاینت) می‌توانند دارای بایت‌های نویسه عام (wildcard) باشند، بنابراین برای مثال --dhcp-host=00:20:e0:3b:13:*,ignore باعث خواهد شد dnsmasq محدوده داده‌شده از نشانی‌های سخت‌افزاری را نادیده بگیرد. توجه داشته باشید که علامت «*» در خط فرمان باید اسکیپ یا درون نقل‌قول قرار گیرد، اما در فایل پیکربندی نیازی به آن نیست.

نشانی‌های سخت‌افزاری معمولاً با هر نوع شبکه (ARP) مطابقت دارند، اما می‌توان آن‌ها را با قرار دادن نوع ARP (در مبنای شانزده/HEX) و «-» پیش از آن‌ها، به یک نوع ARP منفرد محدود کرد. بنابراین --dhcp-host=06-00:20:e0:3b:13:af,1.2.3.4 تنها با یک نشانی سخت‌افزاری Token-Ring مطابقت خواهد داشت، زیرا نوع نشانی ARP برای token ring برابر با 6 است.

به عنوان یک حالت خاص، در DHCPv4 می‌توان بیش از یک نشانی سخت‌افزاری را درج کرد، مانند: --dhcp-host=11:22:33:44:55:66,12:34:56:78:90:12,192.168.0.2. این کار اجازه می‌دهد یک نشانی IP با چندین نشانی سخت‌افزاری مرتبط شود و به dnsmasq اجازه می‌دهد زمانی که نشانی سخت‌افزاری دیگری درخواست اجاره می‌کند، اجاره DHCP اختصاص‌یافته به یکی از نشانی‌ها را رها کند. توجه داشته باشید که این اقدامی خطرناک است: این ویژگی تنها در صورتی با قابلیت اطمینان کار خواهد کرد که فقط یکی از نشانی‌های سخت‌افزاری در هر زمان فعال باشد و هیچ راهی برای dnsmasq جهت اعمال اجباری این شرط وجود ندارد. برای مثال، این کار برای اختصاص یک نشانی IP پایدار به یک لپ‌تاپ که دارای هر دو رابط شبکه سیمی و بی‌سیم است سودمند است.

اطلاعات میزبان‌های DHCP را از فایل مشخص‌شده می‌خواند. اگر یک دایرکتوری داده شود، تمام فایل‌های موجود در آن دایرکتوری را به ترتیب حروف الفبا می‌خواند. فایل شامل اطلاعات یک میزبان در هر سطر است. قالب هر سطر همانند متن سمت راست «=» در --dhcp-host است. مزیت ذخیره اطلاعات میزبان DHCP در این فایل این است که می‌توان آن را بدون راه‌اندازی مجدد dnsmasq تغییر داد: هنگامی که dnsmasq سیگنال SIGHUP دریافت کند، فایل دوباره خوانده خواهد شد.
اطلاعات گزینه‌های DHCP را از فایل مشخص‌شده می‌خواند. اگر یک دایرکتوری داده شود، تمام فایل‌های موجود در آن دایرکتوری را به ترتیب حروف الفبا می‌خواند. مزیت استفاده از این گزینه همانند --dhcp-hostsfile است: هنگامی که dnsmasq سیگنال SIGHUP دریافت کند، --dhcp-optsfile دوباره خوانده خواهد شد. توجه داشته باشید که امکان کدگذاری اطلاعات موجود در فلگ --dhcp-boot به‌عنوان گزینه‌های DHCP، با استفاده از نام‌های گزینه bootfile-name ،server-ip-address و tftp-server وجود دارد. این کار اجازه می‌دهد این موارد در یک --dhcp-optsfile گنجانده شوند.
این گزینه معادل --dhcp-hostsfile است، به‌جز موارد زیر: مسیر حتماً باید یک دایرکتوری باشد و نه یک فایل منفرد. فایل‌های تغییریافته یا جدید درون دایرکتوری به‌طور خودکار و بدون نیاز به ارسال SIGHUP خوانده می‌شوند. اگر فایلی پس از خوانده شدن توسط dnsmasq حذف شود یا تغییر کند، رکورد میزبان موجود در آن باقی می‌ماند تا زمانی که dnsmasq یک سیگنال SIGHUP دریافت کند یا مجدداً راه‌اندازی شود؛ یعنی رکوردهای میزبان فقط به‌صورت پویا افزوده می‌شوند. ترتیب خواندن فایل‌ها در یک دایرکتوری تعریف‌نشده است.
این گزینه معادل --dhcp-optsfile است، با همان تفاوت‌هایی که برای --dhcp-hostsdir ذکر شد.
فایل /etc/ethers را برای اطلاعات مربوط به میزبان‌های کارساز DHCP می‌خواند. قالب /etc/ethers یک نشانی سخت‌افزاری (MAC) و در ادامه یک نام میزبان یا یک نشانی IP چهاربخشی با نقطه (dotted-quad) است. هنگام خوانده شدن توسط dnsmasq، این خطوط دقیقاً همان اثری را دارند که گزینه‌های --dhcp-host حاوی همان اطلاعات دارند. با دریافت سیگنال SIGHUP توسط dnsmasq، فایل /etc/ethers مجدداً خوانده می‌شود. نشانی‌های IPv6 از /etc/ethers خوانده نمی‌شوند.
گزینه‌های اضافی گوناگونی را به کلاینت‌های DHCP ارسال می‌کند. به‌طور پیش‌فرض، dnsmasq برخی گزینه‌های استاندارد را به کلاینت‌های DHCP می‌فرستد؛ ماسک شبکه (netmask) و نشانی پخش همگانی (broadcast) برابر با مقادیر میزبان اجراکننده dnsmasq تنظیم می‌شوند و کارساز DNS و مسیر پیش‌فرض (default route) روی نشانی دستگاه اجراکننده dnsmasq قرار می‌گیرند. (قوانین معادل برای IPv6 نیز اعمال می‌شود.) اگر گزینه نام دامنه تنظیم شده باشد، ارسال می‌گردد. این پیکربندی امکان بازنویسی این مقادیر پیش‌فرض یا تعیین سایر گزینه‌ها را فراهم می‌کند. گزینه‌ای که باید ارسال شود می‌تواند به‌صورت یک عدد ده‌دهی یا به‌صورت option:<option-name> داده شود.

شماره‌های گزینه‌ها در RFC2132 و RFCهای بعدی مشخص شده‌اند. مجموعه نام گزینه‌های شناخته‌شده برای dnsmasq با اجرای dnsmasq --help dhcp قابل مشاهده است. برای نمونه، جهت تنظیم گزینه مسیر پیش‌فرض روی 192.168.4.4 از --dhcp-option=3,192.168.4.4 یا --dhcp-option=option:router,192.168.4.4 و برای تنظیم نشانی کارساز زمان روی 192.168.0.4 از --dhcp-option=42,192.168.0.4 یا --dhcp-option=option:ntp-server,192.168.0.4 استفاده کنید. نشانی ویژه 0.0.0.0 به‌معنای «نشانی سیستمی است که dnsmasq روی آن اجرا می‌شود».

گزینه بدون داده نیز معتبر است و فقط شامل خود گزینه بدون هیچ داده‌ای می‌شود. (در حال حاضر برای DHCPv4 تنها یک گزینه با فیلد داده با طول صفر تعریف شده است، 80:rapid commit، بنابراین این ویژگی در عمل چندان کاربردی نیست). گزینه‌هایی که dnsmasq معمولاً مقادیر پیش‌فرضی برای آن‌ها ارائه می‌دهد را می‌توان با تعریف گزینه بدون داده حذف کرد. این موارد عبارتند از: netmask، broadcast، router، کارساز DNS، نام دامنه (domainname) و نام میزبان (hostname). بنابراین، برای DHCPv4 دستور --dhcp-option = option:router منجر به ارسال نشدن گزینه روتر می‌شود، به‌جای اینکه نشانی پیش‌فرض میزبانی که dnsmasq روی آن اجرا می‌شود ارسال گردد. برای DHCPv6، همین موضوع در مورد گزینه‌های کارساز DNS و زمان تازه‌سازی (refresh time) صدق می‌کند.

انواع داده‌های مجاز عبارتند از: نشانی‌های IPv4 چهاربخشی جداشده با کاما، نشانی‌های IPv6 احاطه‌شده در []، عدد ده‌دهی، ارقام هگزادسیمال جداشده با دو‌نقطه و رشته‌های متنی. اگر تگ‌های اختیاری مشخص شوند، این گزینه تنها در صورتی ارسال می‌شود که تمام تگ‌ها مطابقت داشته باشند.

روی آرگومان متنی گزینه 119 پردازش ویژه‌ای انجام می‌شود تا با RFC 3397 مطابقت داشته باشد. آرگومان‌های متنی یا نشانی‌های IP چهاربخشی با نقطه برای گزینه 120 طبق RFC 3361 مدیریت می‌شوند. نشانی‌های IP چهاربخشی با نقطه که به دنبال آن‌ها یک اسلش و سپس اندازه ماسک شبکه می‌آید، همان‌طور که در RFC 3442 شرح داده شده کدگذاری می‌شوند.

گزینه‌های IPv6 با استفاده از کلیدواژه option6: و به دنبال آن شماره گزینه یا نام گزینه مشخص می‌شوند. فضای نام گزینه‌های IPv6 از فضای نام گزینه‌های IPv4 مجزاست. نشانی‌های IPv6 در گزینه‌ها باید داخل براکت قرار گیرند، مانند --dhcp-option=option6:ntp-server,[1234::56]. برای IPv6، مقدار [::] به‌معنای «نشانی سراسری دستگاه اجراکننده dnsmasq» است، در حالی که [fd00::] با ULA (در صورت وجود) و [fe80::] با نشانی پیوند-محلی جایگزین می‌شود.

دقت کنید: مناسب بودن نوع داده برای شماره گزینه ارسال‌شده بررسی نمی‌شود. با استفاده نسنجیده از این فلگ، کاملاً امکان دارد که dnsmasq وادار به تولید بسته‌های DHCP نامعتبر شود. هنگامی که مقدار یک عدد ده‌دهی است، dnsmasq باید اندازه آیتم داده را تعیین کند. این کار را با بررسی شماره گزینه و/یا مقدار انجام می‌دهد، اما می‌توان با افزودن یک فلگ تک‌حرفی به شرح زیر آن را بازنویسی کرد: b = یک بایت، s = دو بایت، i = چهار بایت. این مورد عمدتاً برای گزینه‌های کپسوله‌شده کلاس سازنده (به ادامه مراجعه کنید) که dnsmasq نمی‌تواند اندازه داده را از روی شماره گزینه تعیین کند، مفید است. داده‌های گزینه‌ای که تنها شامل نقطه و ارقام باشند، توسط dnsmasq به‌عنوان یک نشانی IP تفسیر شده و به همین شکل در گزینه درج می‌شوند. برای اجبار به استفاده از یک رشته حرفی، از گیومه استفاده کنید. برای مثال، هنگام استفاده از گزینه 66 جهت ارسال یک نشانی IP به‌صورت رشته برای نام کارساز TFTP، لازم است به‌صورت --dhcp-option=66,"1.2.3.4" عمل شود.

گزینه‌های کپسوله‌شده کلاس سازنده (فقط IPv4) را نیز می‌توان با استفاده از --dhcp-option مشخص کرد؛ برای نمونه: --dhcp-option=vendor:PXEClient,1,0.0.0.0 گزینه کپسوله‌شده اختصاصی کلاس سازنده "mftp-address=0.0.0.0" را به هر کلاینتی که vendor-class آن با "PXEClient" مطابقت داشته باشد ارسال می‌کند. تطبیق vendor-class بر اساس زیررشته انجام می‌شود (برای جزئیات به --dhcp-vendorclass مراجعه کنید). اگر یک گزینه vendor-class (شماره 60) توسط dnsmasq ارسال شود، آنگاه در اولویت نسبت به هر مورد ارسالی توسط کلاینت، برای انتخاب گزینه‌های کپسوله‌شده استفاده می‌شود. می‌توان vendorclass را کاملاً حذف کرد: --dhcp-option=vendor:,1,0.0.0.0 که در این صورت گزینه کپسوله‌شده همیشه ارسال می‌شود.

گزینه‌ها ممکن است درون سایر گزینه‌ها کپسوله شوند (فقط IPv4): برای نمونه: --dhcp-option=encap:175, 190, iscsi-client0 گزینه 175 را ارسال می‌کند که در درون آن گزینه 190 قرار دارد. اگر چندین گزینه داده شود که با همان شماره گزینه کپسوله شده‌اند، به‌درستی در یک گزینه کپسوله‌شده ادغام خواهند شد. encap: و vendor: نباید هر دو در یک --dhcp-option یکسان تنظیم شوند.

گونه پایانی گزینه‌های کپسوله‌شده، «گزینه‌های سازنده مشخص‌کننده سازنده» (Vendor-Identifying Vendor Options) طبق RFC3925 است. این موارد به این صورت نشان داده می‌شوند: --dhcp-option=vi-encap:2, 10, text عدد موجود در بخش vi-encap: شماره سازمانی در IANA است که برای شناسایی این گزینه استفاده می‌شود. این نوع کپسوله‌سازی در IPv6 نیز پشتیبانی می‌شود.

نشانی 0.0.0.0 در گزینه‌های کپسوله‌شده رفتار ویژه‌ای ندارد.

این گزینه دقیقاً به همان روش --dhcp-option عمل می‌کند، با این تفاوت که گزینه همیشه ارسال خواهد شد، حتی اگر کلاینت در فهرست درخواست پارامتر آن را نخواسته باشد. این رفتار گاهی مورد نیاز است؛ برای مثال هنگام ارسال گزینه‌ها به PXELinux.
گونه‌ای از --dhcp-option که گزینه‌هایی را تعریف می‌کند که فقط در پاسخ به کلاینت‌های PXE ارسال می‌شوند. علاوه بر این، برخلاف گزینه‌های دیگر، چنین گزینه‌هایی زمانی که dnsmasq به‌عنوان پراکسی PXE عمل می‌کند در پاسخ به کلاینت‌های PXE ارسال می‌گردند. یک مورد استفاده متداول، گزینه 175 است که به iPXE ارسال می‌شود.
(فقط IPv4) استفاده مجدد از فیلدهای servername و filename در DHCP به‌عنوان فضای اضافی برای گزینه‌ها را غیرفعال می‌کند. در صورت امکان، dnsmasq اطلاعات کارساز بوت و نام فایل را (از --dhcp-boot) از فیلدهای اختصاصی خود خارج کرده و به داخل گزینه‌های DHCP منتقل می‌کند. این کار فضای بیشتری را در بسته DHCP برای گزینه‌ها فراهم می‌آورد، اما در موارد نادر ممکن است کلاینت‌های قدیمی یا معیوب را دچار سردرگمی کند. این فلگ رفتار «ساده و ایمن» را اجبار می‌کند تا در چنین مواردی از بروز مشکل جلوگیری شود.
قابلیت leasequery مربوط به RFC 4388 را فعال می‌کند. کارساز DHCP برنامه dnsmasq در صورت مشخص شدن این گزینه، به پیام‌های LEASEQUERY از رله‌های DHCP پاسخ خواهد داد. اگر یک نشانی یا زیرشبکه مشخص شود، تنها پرس‌وجوها از یک رله در آن مبدا مجاز خواهند بود. گزینه --leasequery را تکرار کنید تا چندین مبدا مجاز را مشخص نمایید. برای پاسخگویی صحیح به پرس‌وجوهای اجاره، ذخیره داده‌های اضافی در پایگاه‌داده اجاره‌ها ضروری است که این امر نیز با گزینه --leasequery فعال می‌شود. فیلدهای اضافی (agent-info و vendorclass) به‌شیوه‌ای که تا حدی با نسخه‌های قبلی سازگار باشد در فایل اجاره‌ها ذخیره می‌شوند. فعال‌سازی و سپس غیرفعال‌سازی leasequery مشکلی ایجاد نخواهد کرد؛ اطلاعات اضافی به‌مرور زمان از پایگاه‌داده خارج (منقضی) خواهند شد. با این حال، فعال کردن leasequery در انتشار 2.92 یا بالاتر، ذخیره اجاره‌هایی که از طریق رله‌های DHCP می‌آیند که داده‌های agent-info مربوط به گزینه 82 را اضافه می‌کنند، و سپس بازگشت به باینری dnsmasq قبل از نسخه 2.92 ممکن است باعث بروز مشکل در خواندن فایل اجاره‌ها شود. از نسخه 2.92 به بعد، leasequery فقط برای DHCPv4 پشتیبانی می‌شود.
برنامه dnsmasq را برای انجام رله DHCP پیکربندی می‌کند. نشانی محلی نشانی‌ای است که به یک رابط شبکه روی میزبان اجراکننده dnsmasq اختصاص داده شده است. تمام درخواست‌های DHCP که به آن رابط شبکه می‌رسند، به یک کارساز DHCP از راه دور در نشانی کارساز رله می‌شوند. با استفاده از چندین پیکربندی --dhcp-relay با نشانی محلی یکسان و نشانی‌های کارساز متفاوت، امکان رله کردن از یک نشانی محلی منفرد به چندین کارساز از راه دور وجود دارد. نشانی کارساز باید یک نشانی IP صریح باشد و نه نام دامنه. اگر نشانی کارساز حذف شود، درخواست به‌صورت پخش همگانی (IPv4) یا چندپخشی (IPv6) فوروارد می‌شود. در این حالت باید رابط شبکه مشخص شود و نمی‌تواند نویسه عام باشد. نشانی کارساز می‌تواند یک درگاه غیراستاندارد را برای رله کردن تعیین کند. اگر از این قابلیت استفاده شود، احتمالاً --dhcp-proxy نیز باید تنظیم گردد، در غیر این صورت بخش‌هایی از گفتگوی DHCP که از رله عبور نمی‌کنند به درگاه اشتباهی تحویل داده خواهند شد.

کنترل دسترسی برای کلاینت‌های DHCP قوانین یکسانی با کارساز DHCP دارد؛ به --interface، --except-interface و غیره مراجعه کنید. نام اختیاری رابط شبکه در پیکربندی --dhcp-relay عملکرد متفاوتی دارد: کنترل می‌کند که پاسخ‌های DHCP از کارساز روی کدام رابط شبکه پذیرفته شوند. این ویژگی برای پیکربندی‌هایی در نظر گرفته شده که سه رابط شبکه دارند: رابط اول که رله از آن انجام می‌شود، رابط دوم که به کارساز DHCP متصل است، و رابط سوم که شبکه غیرقابل اعتماد است (معمولاً اینترنت عمومی). این کار از احتمال ورود پاسخ‌های جعلی از طریق این رابط سوم جلوگیری می‌کند.

مجاز است که dnsmasq روی یک مجموعه از رابط‌های شبکه به‌عنوان کارساز DHCP عمل کند و از یک مجموعه مجزا از رابط‌های شبکه عملیات رله را انجام دهد. توجه داشته باشید در حالی که کاملاً ممکن است پیکربندی‌هایی بنویسید که به نظر برسد روی یک رابط شبکه یکسان هم به‌عنوان کارساز و هم به‌عنوان رله عمل می‌کنند، این حالت پشتیبانی نمی‌شود: عملکرد رله اولویت خواهد داشت.

هر دو رله DHCPv4 و DHCPv6 پشتیبانی می‌شوند. رله کردن DHCPv4 به یک کارساز DHCPv6 یا برعکس امکان‌پذیر نیست.

عملکرد رله DHCP برای IPv6 شامل قابلیت رصد تفویض پیشوند (prefix-delegation) از تراکنش‌های رله‌شده DHCP است. برای جزئیات به --dhcp-script مراجعه کنید.

یک نسخه ارتقایافته و کاربردی از رله DHCPv4. پروتکل DHCP در IPv4 معمولاً از یک نشانی منفرد برای دو عملکرد استفاده می‌کند: توسط کارساز DHCP برای تعیین اینکه نشانی روی کدام شبکه تخصیص یابد استفاده می‌شود، و همچنین به‌عنوان نشانی رله‌ای که کارساز بسته‌ها را به آن ارسال می‌کند استفاده می‌گردد.

این نسخه از رله DHCP این عملکردها را تفکیک می‌کند. از نشانی رابط رله رو به کارساز یا یک نشانی مستقیماً مشخص‌شده به‌عنوان نشانی‌ای که کارساز با آن گفتگو می‌کند استفاده می‌نماید. نشانی رابط شبکه رو به کلاینت (اولین مورد در پیکربندی) برای تعیین زیرشبکه کلاینت استفاده می‌شود. نشانی محلی همچنین به‌عنوان بازنویسی شناسه کارساز (server-ID override) استفاده می‌شود تا کلاینت همواره درخواست‌ها را از طریق رله ارسال کند. اثر این کار این است که کارساز نیازی به مسیر به شبکه کلاینت ندارد و کلاینت‌ها نیز نیازی به مسیری به کارساز ندارند.

پارامتر سوم اجباری است. اگر نام یک رابط شبکه باشد، نمی‌تواند نویسه عام باشد و همان فیلترسازی شرح‌داده‌شده در --dhcp-relay اعمال می‌شود؛ پاسخ‌های کارساز حتماً باید از طریق رابط شبکه مشخص‌شده دریافت شوند. اگر پارامتر سوم یک نشانی IP باشد، باید نشانی یک رابط شبکه محلی باشد که از سمت کارساز قابل مسیریابی است؛ در این حالت هیچ فیلترسازی انجام نمی‌شود و بسته‌های پاسخ می‌توانند از هر مسیری دریافت شوند.

اگر شبکه‌ای را راه‌اندازی می‌کنید که شبکه‌های کلاینت دارای مسیریابی محدودی هستند، در پیکربندی کارساز DHCP دقت کنید. برنامه dnsmasq به‌عنوان کارساز DHCP، مسیر پیش‌فرض را روی رابط رله رو به کلاینت تنظیم می‌کند مگر اینکه به‌طور صریح پیکربندی شود: این یک مقدار پیش‌فرض معقول است. کارساز DNS پیش‌فرض معمولی (نشانی مشابه با کارساز DHCP) زمانی که هیچ مسیری بین این دو وجود نداشته باشد مناسب نخواهد بود، بنابراین باید به‌طور صریح پیکربندی شود.

یک رشته vendor-class (کلاس سازنده) را به یک تگ نگاشت می‌کند. بیشتر کلاینت‌های DHCP یک «کلاس سازنده» ارائه می‌دهند که به‌نوعی نشان‌دهنده نوع میزبان است. این گزینه کلاس‌های سازنده را به تگ‌ها نگاشت می‌کند تا بتوان گزینه‌های DHCP را به‌طور گزینشی به کلاس‌های مختلف میزبان‌ها ارائه داد. برای مثال --dhcp-vendorclass=set:printers,Hewlett-Packard JetDirect امکان تنظیم گزینه‌ها را فقط برای چاپگرهای HP به‌این‌صورت فراهم می‌کند: --dhcp-option=tag:printers,3,192.168.4.4 رشته vendor-class برای امکان تطبیق فازی، بر اساس زیررشته با vendor-class ارائه‌شده توسط کلاینت تطبیق داده می‌شود. پیشوند set: اختیاری است اما برای یکدستی مجاز می‌باشد.

توجه داشته باشید که فقط در IPv6، کلاس‌های سازنده با یک شماره سازمانی تخصیص‌یافته توسط IANA تفکیک فضای نام می‌شوند. این مورد می‌تواند با کلیدواژه enterprise: داده شود و مشخص می‌کند که فقط کلاس‌های سازنده مطابق با شماره مشخص‌شده باید جستجو شوند. به‌طور مشابه، می‌توان یک شماره سازمانی را بدون رشته vendor-class ارائه داد؛ این حالت همیشه با کلاس‌های سازنده‌ای که شماره سازمانی داده‌شده را دارند مطابقت خواهد داشت.

یک رشته user-class (کلاس کاربر) را به یک تگ نگاشت می‌کند (با تطبیق زیررشته، همانند کلاس‌های سازنده). بیشتر کلاینت‌های DHCP یک «کلاس کاربر» ارائه می‌دهند که قابل پیکربندی است. این گزینه کلاس‌های کاربر را به تگ‌ها نگاشت می‌کند تا گزینه‌های DHCP به‌طور انتخابی به کلاس‌های مختلفی از میزبان‌ها تحویل داده شوند. برای مثال، می‌توان از این گزینه برای تنظیم کارساز چاپگر متفاوتی برای میزبان‌های کلاس "accounts" نسبت به میزبان‌های کلاس "engineering" استفاده کرد.
-4, --dhcp-mac=set:<tag>,<MAC address>
یک نشانی MAC را به یک تگ نگاشت می‌کند. نشانی MAC می‌تواند شامل نویسه‌های عام باشد. برای مثال --dhcp-mac=set:3com,01:34:23:*:*:* تگ "3com" را برای هر میزبانی که نشانی MAC آن با الگو مطابقت داشته باشد تنظیم می‌کند.
گزینه‌های عامل رله RFC3046 را به تگ‌ها نگاشت می‌کند. این داده‌ها ممکن است توسط عامل‌های رله DHCP ارائه شوند. circuit-id یا remote-id معمولاً به‌صورت هگزادسیمال جداشده با دونقطه داده می‌شود، اما استفاده از یک رشته ساده نیز مجاز است. اگر تطابق دقیقی بین circuit یا agent ID و مقدار ارائه‌شده توسط عامل رله حاصل شود، تگ تنظیم می‌گردد.

--dhcp-remoteid (اما نه --dhcp-circuitid) در IPv6 پشتیبانی می‌شود.

(در IPv4 و IPv6) گزینه‌های عامل رله subscriber-id مربوط به RFC3993 را به تگ‌ها نگاشت می‌کند.
(فقط IPv4) یک عامل رله معمولی DHCP تنها برای فوروارد بخش‌های اولیه یک تعامل DHCP به کارساز DHCP استفاده می‌شود. هنگامی که یک کلاینت پیکربندی شد، مستقیماً با کارساز ارتباط برقرار می‌کند. اگر عامل رله اطلاعات اضافی مانند آنچه توسط --dhcp-circuitid و --dhcp-remoteid استفاده می‌شود را به بسته‌های DHCP اضافه کند، این ارتباط مستقیم نامطلوب خواهد بود. یک پیاده‌سازی کامل رله می‌تواند از گزینه serverid-override در RFC 5107 استفاده کند تا کارساز DHCP را مجبور سازد از رله به‌عنوان یک پراکسی کامل استفاده کند و تمام بسته‌ها از طریق آن عبور کنند. این فلگ یک روش جایگزین برای انجام همین کار برای رله‌هایی که از RFC 5107 پشتیبانی نمی‌کنند فراهم می‌آورد. اگر به‌تنهایی داده شود، server-id را برای همه تعاملات از طریق رله‌ها دستکاری می‌کند. اگر فهرستی از نشانی‌های IP داده شود، تنها تعاملات از طریق رله‌های مستقر در آن نشانی‌ها تحت تأثیر قرار می‌گیرند.
بدون <value>، اگر کلاینت یک option در DHCP با شماره یا نام داده‌شده ارسال کند، <tag> را تنظیم می‌کند. با <value>، تنها در صورتی <tag> را تنظیم می‌کند که کلاینت گزینه option منطبق با یا حاوی <value> را ارسال کند.

مقدار می‌تواند به فرم "01:ff:*:02" باشد که در این حالت مقدار باید مطابقت داشته باشد (صرف‌نظر از نویسه‌های عام)، اما گزینه ارسالی می‌تواند داده‌های تطبیق‌نیافته‌ای فراتر از انتهای مقدار داشته باشد. همچنین مقدار می‌تواند به همان فرم موجود در --dhcp-option باشد که در این حالت با گزینه ارسالی مانند یک آرایه رفتار می‌شود و باید یکی از عناصر مطابقت داشته باشد. --dhcp-match=set:efi-ia32,option:client-arch,6 در صورتی که عدد 6 در فهرست معماری‌های ارسالی کلاینت در گزینه 93 ظاهر شود، تگ efi-ia32 را تنظیم می‌کند. (برای جزئیات به RFC 4578 مراجعه کنید.) اگر مقدار یک رشته باشد، تطبیق زیررشته استفاده می‌شود.

فرم ویژه با vi-encap:<enterprise number> با کلاس‌های سازنده مشخص‌کننده سازنده برای سازمان مشخص‌شده مطابقت داده می‌شود. لطفاً برای جزئیات بیشتر در مورد این ساختارهای کمیاب و جالب به RFC 3925 مراجعه کنید.

در صورتی که <name> مشخص‌شده توسط یک کارخواه DHCP ارائه شود، یک <tag> را تنظیم می‌کند. می‌تواند یک نویسه عام * منفرد با مفهوم glob در انتهای نام وجود داشته باشد. ترکیب این گزینه با dhcp-ignore یا dhcp-ignore-names قابلیت نادیده گرفتن برخی کارخواه‌ها بر اساس نام، یا جلوگیری از ثبت برخی نام‌های میزبان توسط یک کارخواه را فراهم می‌سازد.
عملیات بولی را روی برچسب‌ها انجام می‌دهد. تمام برچسب‌های set:<tag> در صورتی تنظیم می‌شوند که تمام برچسب‌های tag:<tag> از قبل تنظیم شده باشند (یا در صورت استفاده از tag:!<tag> تنظیم نشده باشند). اگر هیچ tag:<tag> مشخص نشود، برچسب‌های set:<tag> بدون قید و شرط تنظیم می‌شوند. هر تعداد از حالت‌های set: و tag: می‌توانند به هر ترتیبی ظاهر شوند. خطوط --tag-if به ترتیب اجرا می‌شوند، بنابراین اگر برچسب موجود در tag:<tag> برچسبی باشد که توسط یک --tag-if دیگر تنظیم شده است، خطی که برچسب را تنظیم می‌کند باید پیش از خطی که آن را آزمایش می‌کند قرار گیرد.

به عنوان یک قابلیت تکمیلی، عبارت‌های tag:<tag> از تطبیق نویسه عام محدود، مشابه تطبیق در دستورالعمل --interface پشتیبانی می‌کنند. این امر اجازه می‌دهد تا در مثال --tag-if=set:ppp,tag:ppp* برچسب 'ppp' برای تمام درخواست‌های دریافت شده روی هر رابط شبکه منطبق (ppp0، ppp1 و غیره) تنظیم شود. این حالت می‌تواند در ترکیب با قالب tag:!<tag> استفاده شود به این مفهوم که هیچ برچسبی منطبق با نویسه عام نباید تنظیم شده باشد.

هنگامی که تمام برچسب‌های مشخص‌شده در مجموعه برچسب‌ها وجود داشته باشند، میزبان را نادیده گرفته و هیچ اجاره DHCP به آن اختصاص نمی‌دهد.
هنگامی که تمام برچسب‌های مشخص‌شده در مجموعه برچسب‌ها وجود داشته باشند، هرگونه نام میزبان ارائه‌شده توسط میزبان را نادیده می‌گیرد. توجه داشته باشید که برخلاف --dhcp-ignore، مجاز است که هیچ برچسبی ارائه نشود، که در این حالت نام‌های میزبان ارائه‌شده توسط کارخواه DHCP همواره نادیده گرفته می‌شوند، و میزبان‌های DHCP فقط با استفاده از پیکربندی --dhcp-host در dnsmasq و محتویات /etc/hosts و /etc/ethers به DNS اضافه می‌شوند.
(فقط IPv4) برای کارخواه‌های DHCP که فاقد نام هستند، با استفاده از آدرس MAC که در مبنای شانزده (هگز) بیان شده و با خط تیره از هم جدا شده است، یک نام ایجاد می‌کند. توجه داشته باشید اگر میزبانی نامی ارائه دهد، ترجیحاً به جای این نام استفاده خواهد شد، مگر اینکه --dhcp-ignore-names تنظیم شده باشد.
(فقط IPv4) هنگامی که تمام برچسب‌های مشخص‌شده در مجموعه برچسب‌ها وجود داشته باشند، در صورت پیکربندی نشدن میزبان، همواره از پخش همگانی (broadcast) برای ارتباط با آن استفاده می‌کند. ارائه ندادن هیچ برچسبی مجاز است، که در این صورت این حالت بدون قید و شرط خواهد بود. بیشتر کارخواه‌های DHCP که به پاسخ‌های پخش همگانی نیاز دارند فلگی را در درخواست‌های خود تنظیم می‌کنند تا این امر به صورت خودکار رخ دهد، اما برخی کارخواه‌های قدیمی BOOTP این کار را انجام نمی‌دهند.
(فقط IPv4) گزینه‌های BOOTP را جهت بازگردانده شدن توسط کارساز DHCP تنظیم می‌کند. نام و آدرس کارساز اختیاری هستند: اگر ارائه نشوند، نام خالی گذاشته شده و آدرس روی آدرس ماشینی که dnsmasq را اجرا می‌کند تنظیم می‌شود. اگر dnsmasq در حال ارائه سرویس TFTP باشد (ببینید --enable-tftp )، در این صورت برای فعال‌سازی بوت از طریق شبکه تنها نام فایل در اینجا مورد نیاز است. اگر برچسب(های) اختیاری ارائه شده باشند، برای ارسال این پیکربندی باید مطابقت داشته باشند. به جای آدرس IP، آدرس کارساز TFTP می‌تواند به صورت یک نام دامنه ارائه شود که در /etc/hosts جستجو می‌گردد. این نام می‌تواند در /etc/hosts با چندین آدرس IP مرتبط شود که به صورت چرخشی (round-robin) استفاده می‌شوند. این قابلیت می‌تواند برای توزیع بار کاری tftp میان مجموعه‌ای از کارسازها استفاده شود.
برنامه Dnsmasq به گونه‌ای طراحی شده است که آدرس‌های IP را برای کارخواه‌های DHCP با استفاده از یک هش از آدرس MAC کارخواه انتخاب کند. این امر به طور معمول اجازه می‌دهد آدرس یک کارخواه در بلندمدت پایدار بماند، حتی اگر کارخواه گاهی اجازه دهد اجاره DHCP آن منقضی شود. در این حالت پیش‌فرض، آدرس‌های IP به صورت شبه‌تصادفی روی کل محدوده آدرس‌های در دسترس توزیع می‌شوند. گاهی شرایطی پیش می‌آید (معمولاً در استقرار کارسازها) که در آن مناسب‌تر است آدرس‌های IP به صورت ترتیبی، با شروع از کمترین آدرس موجود تخصیص یابند، و تنظیم این فلگ این حالت را فعال می‌کند. توجه داشته باشید که در حالت ترتیبی، کارخواه‌هایی که اجازه انقضای یک اجاره را می‌دهند با احتمال بسیار بیشتری آدرس IP متفاوتی دریافت خواهند کرد؛ به همین دلیل عموماً نباید مورد استفاده قرار گیرد.
برنامه Dnsmasq گزینه 'client identifier' (استاندارد RFC 2131) ارسال‌شده توسط کارخواه‌ها (در صورت موجود بودن) را جهت شناسایی کارخواه‌ها می‌خواند. این ویژگی امکان ارائه یک آدرس IP یکسان را برای میزبانی که از چند رابط شبکه استفاده می‌کند فراهم می‌سازد. از این گزینه برای غیرفعال کردن خواندن
بیشتر موارد استفاده از ROMهای بوت PXE صرفاً به سیستم PXE اجازه می‌دهند یک آدرس IP دریافت کند و سپس فایل مشخص‌شده توسط --dhcp-boot را بارگیری و اجرا نماید. با این حال سیستم PXE در صورت پشتیبانی توسط یک کارساز DHCP مناسب، قادر به انجام عملکردهای پیچیده‌تری است.

این گزینه یک گزینه بوت را مشخص می‌کند که ممکن است در منوی بوت PXE ظاهر شود. <CSA> نوع سیستم کارخواه است، و تنها سرویس‌های از نوع صحیح در یک منو ظاهر خواهند شد. انواع شناخته‌شده عبارتند از x86PC، PC98، IA64_EFI، Alpha، Arc_x86، Intel_Lean_Client، IA32_EFI، x86-64_EFI، Xscale_EFI، BC_EFI، ARM32_EFI و ARM64_EFI؛ برای سایر انواع می‌توان از یک عدد صحیح استفاده کرد. پارامتر پس از متن منو می‌تواند یک نام فایل باشد، که در این صورت dnsmasq به عنوان یک کارساز بوت عمل کرده و کارخواه PXE را هدایت می‌کند تا فایل را از طریق TFTP بارگیری کند، خواه از خود dnsmasq (گزینه --enable-tftp باید برای این کار تنظیم شده باشد) یا از یک کارساز TFTP دیگر در صورتی که آدرس/نام کارساز نهایی مشخص شده باشد. توجه داشته باشید که پسوند "layer" (معمولاً ".0") توسط PXE ارائه می‌شود و نیازی به افزودن آن به basename نیست. همچنین basename می‌تواند یک نام فایل همراه با پسوند کامل باشد که در این صورت هیچ پسوند لایه‌ای افزوده نمی‌شود. اگر به جای basename یک نوع سرویس بوت به صورت عدد صحیح ارائه شود، کارخواه PXE در شبکه به دنبال یک سرویس بوت مناسب برای آن نوع خواهد گشت. این جستجو ممکن است از طریق پخش همگانی، یا در صورت ارائه آدرس IP/نام کارساز مستقیماً به سمت کارساز انجام شود. اگر هیچ نوع سرویس بوت یا نام فایلی ارائه نشود (یا نوع سرویس بوت 0 مشخص گردد) آن‌گاه مدخل منو فرآیند بوت شبکه را لغو کرده و بوت را از رسانه محلی ادامه می‌دهد. آدرس کارساز می‌تواند به صورت یک نام دامنه ارائه شود که در /etc/hosts جستجو می‌گردد. این نام می‌تواند در /etc/hosts با چندین آدرس IP مرتبط شود که به صورت چرخشی (round-robin) مورد استفاده قرار می‌گیرند.

تنظیم این گزینه پیامی را فراهم می‌کند تا پس از بوت PXE نمایش داده شود. اگر زمان مهلت (timeout) ارائه شود، پس از سپری شدن این زمان مهلت بدون ورودی صفحه‌کلید، اولین گزینه موجود در منو به صورت خودکار اجرا خواهد شد. اگر زمان مهلت صفر باشد، اولین گزینه موجود در منو بلافاصله اجرا می‌شود. اگر --pxe-prompt حذف شود، سیستم در صورت وجود چندین گزینه در منو منتظر ورودی کاربر می‌ماند، اما در صورتی که فقط یک گزینه وجود داشته باشد بلافاصله بوت می‌شود. برای جزئیات گزینه‌های منو به --pxe-service مراجعه کنید.

برنامه Dnsmasq از "proxy-DHCP" در PXE پشتیبانی می‌کند، در این حالت یک کارساز DHCP دیگر در شبکه مسئول تخصیص آدرس‌های IP است و dnsmasq صرفاً اطلاعات ارائه‌شده در --pxe-prompt و --pxe-service را برای امکان‌پذیر ساختن بوت از طریق شبکه ارائه می‌دهد. این حالت با استفاده از کلمه کلیدی proxy در --dhcp-range فعال می‌شود. اگر کارساز DHCP "دیگر" در یک شبکه دوردست باشد، پیکربندی dnsmasq هم به عنوان کارساز PXE proxy-DHCP و هم به عنوان یک بازپخش‌کننده DHCP به کارساز DHCP دوردست امکان‌پذیر و سودمند است. برای جزئیات به --dhcp-relay مراجعه کنید. در حال حاضر PXE تنها روی IPv4 پشتیبانی می‌شود.

مطابق با مشخصات UEFI و PXE، بسته‌های DHCP میان کارخواه‌های PXE و کارسازهای پراکسی PXE باید حاوی PXEClient در فیلد vendor-class خود باشند. با این حال، سفت‌افزار (فریم‌ور) رایانه‌های چند سازنده به گونه‌ای سفارشی‌سازی شده است که شناسه متفاوتی را در آن فیلد حمل کند. این گزینه جهت معتبر دانستن چنین شناسه‌هایی برای شناسایی کارخواه‌های PXE به کار می‌رود. برای مثال:

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

این امکان را به dnsmasq می‌دهد که خدمات پراکسی PXE را به آن دسته از کارخواه‌های PXE که HW-Client را به عنوان شناسه خود دارند نیز ارائه دهد.

برنامه dnsmasq را به حداکثر تعداد مشخص‌شده از اجاره‌های DHCP محدود می‌کند. مقدار پیش‌فرض ۱۰۰۰ است. این محدودیت برای جلوگیری از حملات DoS از سوی میزبان‌هایی است که هزاران اجاره ایجاد کرده و حافظه زیادی را در فرآیند dnsmasq مصرف می‌کنند.
باید زمانی تنظیم شود که dnsmasq قطعاً تنها کارساز DHCP روی یک شبکه است. برای DHCPv4، رفتار برنامه را از تطابق دقیق با RFC تغییر می‌دهد تا درخواست‌های DHCP مربوط به اجاره‌های ناشناخته از میزبان‌های ناشناخته نادیده گرفته نشوند. این امر به میزبان‌های جدید اجازه می‌دهد تحت هر شرایطی بدون وقفه زمانی خسته‌کننده یک اجاره دریافت کنند. همچنین به dnsmasq اجازه می‌دهد در صورت از دست رفتن پایگاه داده، بدون نیاز به دریافت مجدد اجاره توسط هر کارخواه، پایگاه داده اجاره خود را بازسازی کند. برای DHCPv6 همان رفتار DHCPv4 را با اجاره‌های مفقود کنترل می‌کند (به جز عدم تطابق با RFC - استانداردهای RFC مربوط به DHCPv6 در صورت پیکربندی، این رفتار را مجاز می‌دانند). همچنین اولویت را در پاسخ‌ها به جای 0 (حداقل) روی 255 (حداکثر) تنظیم می‌کند.
گزینه Rapid Commit مربوط به DHCPv4 مشخص‌شده در RFC 4039 را فعال می‌کند. در صورت فعال بودن، dnsmasq به پیام DHCPDISCOVER شامل یک گزینه Rapid Commit با یک پیام DHCPACK حاوی گزینه Rapid Commit و اطلاعات آدرس و پیکربندی کاملاً ثبت‌شده پاسخ خواهد داد. فقط باید زمانی فعال شود که کارساز یا تنها کارساز برای زیرشبکه باشد، یا چندین کارساز حضور داشته باشند و هر یک از آن‌ها یک ثبت اتصال (binding) را برای تمام کارخواه‌ها متعهد شوند.
(فقط IPv4) درگاه‌های مورد استفاده برای DHCP را از حالت پیش‌فرض تغییر می‌دهد. اگر این گزینه به تنهایی، بدون آرگومان مشخص شود، درگاه‌های مورد استفاده برای DHCP را از 67 و 68 به 1067 و 1068 تغییر می‌دهد. اگر یک آرگومان منفرد ارائه شود، آن شماره درگاه برای کارساز و شماره درگاه به علاوه یک برای کارخواه استفاده می‌شود. در نهایت، مشخص کردن دو شماره درگاه اجازه تعیین دلخواه هر دو درگاه کارساز و کارخواه را برای DHCP می‌دهد.
-3, --bootp-dynamic[=<network-id>[,<network-id>]]
(فقط IPv4) تخصیص پویای آدرس‌های IP را برای کارخواه‌های BOOTP فعال می‌کند. از این گزینه با احتیاط استفاده کنید، زیرا هر آدرس اختصاص‌یافته به یک کارخواه BOOTP برای همیشه اجاره داده می‌شود، و بنابراین برای استفاده مجدد توسط سایر میزبان‌ها به طور دائمی غیرقابل دسترس می‌گردد. اگر این گزینه بدون برچسب‌ها داده شود، به طور نامشروط تخصیص پویا را فعال می‌کند. با برچسب‌ها، تنها زمانی فعال می‌شود که تمام برچسب‌ها تنظیم شده باشند. این گزینه می‌تواند با مجموعه‌های برچسب متفاوت تکرار شود.
-5, --no-ping
(فقط IPv4) به طور پیش‌فرض، کارساز DHCP پیش از تخصیص یک آدرس به یک میزبان، تلاش می‌کند از عدم استفاده از آن اطمینان حاصل کند. این کار را با ارسال یک درخواست انعکاس ICMP (یا همان "ping") به آدرس مورد نظر انجام می‌دهد. اگر پاسخی دریافت کند، نشان‌دهنده آن است که آدرس از قبل در حال استفاده است، و آدرس دیگری آزمایش می‌شود. این فلگ این بررسی را غیرفعال می‌کند. با احتیاط استفاده شود.
ثبت گزارش‌های اضافی برای DHCP: تمام گزینه‌های ارسال‌شده به کارخواه‌های DHCP و برچسب‌های استفاده‌شده برای تعیین آن‌ها را ثبت می‌کند.
از ثبت گزارش‌های عملیات معمول این پروتکل‌ها جلوگیری می‌کند. خطاها و مشکلات همچنان ثبت خواهند شد. گزینه --quiet-tftp عدم یافتن فایل را یک خطا تلقی نمی‌کند. گزینه‌های --quiet-dhcp و quiet-dhcp6 توسط --log-dhcp نادیده گرفته و جایگزین می‌شوند.
از فایل مشخص‌شده برای ذخیره اطلاعات اجاره DHCP استفاده می‌کند.
(فقط IPv6) شناسه یکتای ماندگار کارساز (UID) را که کارساز DHCPv6 استفاده خواهد کرد، مشخص می‌کند. این گزینه معمولاً مورد نیاز نیست چرا که dnsmasq یک DUID را به صورت خودکار هنگامی که برای اولین بار مورد نیاز باشد ایجاد می‌کند. در صورت ارائه، این گزینه داده‌های مورد نیاز برای ایجاد یک DUID از نوع DUID-EN را به dnsmasq ارائه می‌دهد. توجه داشته باشید که پس از تنظیم، DUID در پایگاه داده اجاره ذخیره می‌شود، بنابراین برای تغییر بین DUID-EN و DUIDهای ایجادشده به صورت خودکار یا برعکس، پایگاه داده اجاره باید مجدداً مقداردهی اولیه شود. enterprise-id توسط IANA تخصیص داده می‌شود، و uid یک رشته از هشت‌بایتی‌های (اکتت‌های) هگزادسیمال است که برای یک دستگاه خاص منحصر‌به‌فرد است.
-6 --dhcp-script=<path>
هرگاه یک اجاره جدید DHCP ایجاد شود، یا یک اجاره قدیمی حذف گردد، یا یک انتقال فایل TFTP تکمیل شود، فایل اجرایی مشخص‌شده توسط این گزینه اجرا می‌گردد. <path> باید یک مسیر مطلق باشد، هیچ جستجویی در متغیر PATH انجام نمی‌شود. آرگومان‌های ارسالی به پردازش عبارتند از "add"، "old" یا "del"، آدرس MAC میزبان (یا DUID برای IPv6)، آدرس IP، و نام میزبان در صورت مشخص بودن. "add" به معنای ایجاد شدن اجاره است، "del" به معنای حذف شدن آن، و "old" اعلانی از یک اجاره موجود هنگام شروع به کار dnsmasq یا تغییر در آدرس MAC یا نام میزبان یک اجاره موجود است (همچنین در صورت تنظیم --leasefile-ro مدت زمان اجاره یا انقضا و client-id، و در صورت تنظیم --script-on-renewal زمان انقضای اجاره). اگر آدرس MAC متعلق به نوع شبکه‌ای غیر از اترنت باشد، نوع شبکه در ابتدای آن افزوده می‌شود؛ مانند "06-01:23:45:67:89:ab" برای token ring. این پردازش با دسترسی ریشه (root) اجرا می‌شود (با این فرض که dnsmasq در ابتدا به عنوان ریشه اجرا شده باشد) حتی اگر dnsmasq طوری پیکربندی شده باشد که UID را به یک کاربر فاقد امتیاز تغییر دهد.

متغیرهای محیطی از فراخواننده dnsmasq به ارث برده می‌شوند، و برخی یا همه متغیرهای زیر به آن افزوده می‌شوند:

هم برای IPv4 و هم برای IPv6:

متغیر DNSMASQ_DOMAIN: در صورتی که نام دامنه کاملاً واجد شرایط (FQDN) میزبان مشخص باشد، روی بخش دامنه تنظیم می‌شود. (توجه داشته باشید که نام میزبان ارسال‌شده به اسکریپت به عنوان یک آرگومان هرگز به صورت کاملاً واجد شرایط نیست.)

اگر کارخواه نام میزبان ارائه دهد، DNSMASQ_SUPPLIED_HOSTNAME

اگر کارخواه رده‌های کاربری را ارائه دهد، DNSMASQ_USER_CLASS0..DNSMASQ_USER_CLASSn

اگر dnsmasq با HAVE_BROKEN_RTC کامپایل شده باشد، آن‌گاه طول مدت اجاره (به ثانیه) در DNSMASQ_LEASE_LENGTH ذخیره می‌شود؛ در غیر این صورت زمان انقضای اجاره در DNSMASQ_LEASE_EXPIRES ذخیره می‌گردد. تعداد ثانیه‌ها تا زمان انقضای اجاره همواره در DNSMASQ_TIME_REMAINING ذخیره می‌شود.

متغیر DNSMASQ_DATA_MISSING در طول رویدادهای "old" برای اجاره‌های موجود تولیدشده در زمان راه‌اندازی روی "1" تنظیم می‌شود تا نشان دهد داده‌هایی که در پایگاه داده ماندگار اجاره ذخیره نشده‌اند وجود نخواهند داشت. این شامل همه چیز به جز آدرس IP، نام میزبان، آدرس MAC، شناسه DUID، شناسه IAID و طول مدت اجاره یا زمان انقضا است.

اگر اجاره‌ای قبلاً دارای نام میزبان بوده باشد که اکنون حذف شده است، یک رویداد "old" با وضعیت جدید اجاره (یعنی بدون نام) تولید می‌شود و نام قبلی در متغیر محیطی DNSMASQ_OLD_HOSTNAME ارائه می‌گردد.

متغیر DNSMASQ_INTERFACE نام رابط شبکه‌ای را که درخواست از آن رسیده ذخیره می‌کند؛ این متغیر برای اقدامات "old" هنگام راه‌اندازی مجدد dnsmasq تنظیم نمی‌شود.

متغیر DNSMASQ_RELAY_ADDRESS در صورتی تنظیم می‌شود که کارخواه از یک بازپخش‌کننده DHCP برای ارتباط با dnsmasq استفاده کرده باشد و آدرس IP بازپخش‌کننده مشخص باشد.

متغیر DNSMASQ_TAGS حاوی تمام برچسب‌های تنظیم‌شده در طول تراکنش DHCP است که با فاصله از هم جدا شده‌اند.

متغیر DNSMASQ_LOG_DHCP در صورتی تنظیم می‌شود که --log-dhcp فعال باشد.

متغیر DNSMASQ_REQUESTED_OPTIONS: رشته‌ای شامل مقادیر دسیمل در گزینه Parameter Request List که با کاما جدا شده‌اند، در صورتی که این گزینه توسط کارخواه ارائه شده باشد.

متغیر DNSMASQ_MUD_URL: نشانی اینترنتی Manufacturer Usage Description در صورت ارائه توسط کارخواه. (برای جزئیات به RFC 8520 مراجعه کنید.)

فقط برای IPv4:

متغیر DNSMASQ_CLIENT_ID اگر میزبان یک client-id ارائه دهد.

متغیرهای DNSMASQ_CIRCUIT_ID، DNSMASQ_SUBSCRIBER_ID، DNSMASQ_REMOTE_ID در صورتی که یک عامل بازپخش DHCP هر یک از این گزینه‌ها را افزوده باشد.

اگر کارخواه vendor-class را ارائه دهد، DNSMASQ_VENDOR_CLASS.

فقط برای IPv6:

اگر کارخواه vendor-class را ارائه دهد، متغیر DNSMASQ_VENDOR_CLASS_ID، شامل شناسه سازمانی IANA برای آن رده، و DNSMASQ_VENDOR_CLASS0..DNSMASQ_VENDOR_CLASSn برای داده‌ها.

متغیر DNSMASQ_SERVER_DUID شامل DUID کارساز: این مقدار برای هر فراخوانی اسکریپت یکسان است.

متغیر DNSMASQ_IAID شامل IAID برای این اجاره. اگر اجاره یک تخصیص موقت باشد، با 'T' پیشوندگذاری می‌شود.

متغیر DNSMASQ_MAC شامل آدرس MAC کارخواه، در صورت مشخص بودن.

توجه داشته باشید که داده‌های hostname، vendorclass و userclass ارائه‌شده تنها برای اقدامات "add" یا اقدامات "old" هنگامی که میزبان یک اجاره موجود را از سر می‌گیرد ارسال می‌شوند، زیرا این داده‌ها در پایگاه داده اجاره dnsmasq نگهداری نمی‌شوند.

تمام توصیف‌کننده‌های پرونده بسته می‌شوند به جز stdin که به روی /dev/null باز است، و stdout و stderr که خروجی را جهت ثبت در گزارش توسط dnsmasq دریافت می‌کنند. (در حالت اشکال‌زدایی، فایل‌های stdin، stdout و stderr به همان صورتی که از فراخواننده dnsmasq به ارث برده شده‌اند رها می‌شوند).

اسکریپت به صورت همزمان فراخوانی نمی‌شود: در هر لحظه حداکثر یک نمونه از اسکریپت در حال اجراست (dnsmasq پیش از اجرای نمونه بعدی، منتظر خروج نمونه در حال اجرای اسکریپت می‌ماند). تغییرات در پایگاه داده اجاره که نیازمند فراخوانی اسکریپت هستند، در صف منتظر خروج نمونه در حال اجرا می‌مانند. اگر این صف‌بندی باعث شود چندین تغییر وضعیت روی یک اجاره منفرد پیش از امکان اجرای اسکریپت رخ دهد، وضعیت‌های پیشین دور ریخته شده و وضعیت فعلی آن اجاره هنگامی که اسکریپت در نهایت اجرا می‌شود منعکس خواهد شد.

در زمان راه‌اندازی dnsmasq، اسکریپت برای تمام اجاره‌های موجود هم‌زمان با خوانده شدن آن‌ها از فایل اجاره فراخوانی خواهد شد. اجاره‌های منقضی‌شده با "del" و سایر اجاره‌ها با "old" فراخوانی می‌شوند. هنگامی که dnsmasq یک سیگنال HUP دریافت می‌کند، اسکریپت برای اجاره‌های موجود با یک رویداد "old" فراخوانی خواهد شد.

پنج اقدام دیگر نیز وجود دارند که ممکن است به عنوان نخستین آرگومان به اسکریپت ارسال شوند: "init"، "arp-add"، "arp-del"، "relay-snoop" و "tftp". ممکن است در آینده موارد بیشتری افزوده شود، بنابراین اسکریپت‌ها باید به گونه‌ای نوشته شوند که اقدامات ناشناخته را نادیده بگیرند. اقدام "init" در زیر ذیل --leasefile-ro شرح داده شده است.

اقدام "tftp" هنگامی فراخوانی می‌شود که یک انتقال فایل TFTP تکمیل گردد: آرگومان‌ها عبارتند از اندازه فایل به بایت، آدرسی که فایل به آن ارسال شده، و نام مسیر کامل فایل.

اقدام "relay-snoop" زمانی فراخوانی می‌شود که dnsmasq به عنوان یک بازپخش‌کننده DHCP برای DHCPv6 پیکربندی شده باشد و یک تفویض پیشوند را به یک کارخواه بازپخش کند. آرگومان‌ها عبارتند از نام رابط شبکه‌ای که کارخواه به آن متصل است، آدرس آن (link-local) روی آن رابط شبکه و پیشوند تفویض‌شده. این اطلاعات جهت ایجاد مسیرها به پیشوند تفویض‌شده یک مسیریاب کافی است. برای جزئیات بیشتر در مورد پیکربندی بازپخش DHCP به --dhcp-relay مراجعه کنید.

اقدامات "arp-add" و "arp-del" تنها در صورتی فراخوانی می‌شوند که با --script-arp فعال شده باشند. آن‌ها با یک آدرس MAC و آدرس IP به عنوان آرگومان ارائه می‌شوند. "arp-add" نشان‌دهنده ورود یک مدخل جدید در جدول ARP یا جدول همسایگی (neighbour table) است، و "arp-del" نشان‌دهنده حذف آن است.

یک اسکریپت نوشته‌شده به زبان Lua را مشخص می‌کند تا هنگام ایجاد، حذف یا تغییر اجاره‌ها اجرا شود. برای استفاده از این گزینه، dnsmasq باید با پشتیبانی مناسب کامپایل شده باشد. مفسر Lua یک بار هنگام شروع dnsmasq مقداردهی اولیه می‌شود تا متغیرهای سراسری بین رویدادهای مختلف اجاره پایدار بمانند. کد Lua باید یک تابع lease تعریف کند، و می‌تواند توابع init و shutdown را نیز ارائه دهد که بدون آرگومان هنگام شروع به کار و خاتمه dnsmasq فراخوانی می‌شوند. همچنین می‌تواند یک تابع tftp ارائه دهد.

تابع lease اطلاعات شرح داده شده در --dhcp-script را دریافت می‌کند. این تابع دو آرگومان می‌گیرد: اولی اقدام مورد نظر (action) است که یک رشته شامل "add" ،"old" یا "del" می‌باشد، و دومی یک جدول از جفت‌های برچسب و مقدار (tag-value) است. این برچسب‌ها عمدتاً با متغیرهای محیطی ذکر شده در بالا مطابقت دارند؛ برای نمونه برچسب "domain" حاوی همان داده‌های متغیر محیطی DNSMASQ_DOMAIN است. چند برچسب اضافی نیز وجود دارد که داده‌های ارائه‌شده به عنوان آرگومان به --dhcp-script را در بر دارند. این برچسب‌ها عبارتند از: mac_address, ip_address و hostname برای IPv4، و client_duid, ip_address و hostname برای IPv6.

تابع tftp به همان روش تابع lease فراخوانی می‌شود و جدول آن شامل برچسب‌های destination_address, file_name و file_size. است.

توابع arp و arp-old فقط زمانی فراخوانی می‌شوند که با گزینه --script-arp فعال شده باشند و جدولی دارند که شامل برچسب‌های mac_address و client_address. است.

کاربری را مشخص می‌کند که اسکریپت تغییر اجاره یا اسکریپت Lua با هویت آن اجرا شود. مقدار پیش‌فرض root است، اما با استفاده از این فلگ می‌توان آن را به کاربر دیگری تغییر داد.
توابع "arp" و "arp-old" را در --dhcp-script و --dhcp-luascript فعال می‌کند.
-9, --leasefile-ro
استفاده از فایل پایگاه‌داده اجاره‌ها را به طور کامل متوقف می‌کند. این فایل ایجاد، خوانده یا نوشته نخواهد شد. نحوه فراخوانی اسکریپت تغییر اجاره (در صورت وجود) را تغییر می‌دهد تا پایگاه‌داده اجاره‌ها بتواند توسط اسکریپت در یک فضای ذخیره‌سازی خارجی نگهداری شود. علاوه بر فراخوانی‌های ذکر شده در --dhcp-script اسکریپت تغییر اجاره یک بار در زمان راه‌اندازی dnsmasq با تک‌آرگومان "init" فراخوانی می‌شود. هنگام فراخوانی به این شکل، اسکریپت باید وضعیت ذخیره‌شده پایگاه‌داده اجاره را در قالب leasefile برنامه dnsmasq در stdout بنویسد و با کد خروج صفر خارج شود. تنظیم این گزینه همچنین باعث می‌شود اسکریپت تغییر اجاره هنگام تغییر در شناسه کلاینت (client-id)، طول مدت اجاره و زمان انقضا نیز فراخوانی شود.
هنگام تغییر زمان انقضای اجاره، برای نمونه زمانی که اجاره تمدید می‌شود، اسکریپت DHCP را فراخوانی می‌کند.
با درخواست‌های DHCP (نسخه ۴ و ۶) و بسته‌های Router Solicit در IPv6 که به هر یک از رابط‌های شبکه <alias> می‌رسند، طوری رفتار می‌کند که گویی به <interface> رسیده‌اند. این گزینه به dnsmasq امکان می‌دهد تا سرویس‌های DHCP و RA را روی رابط‌های شبکه اترنت فاقد آدرس و بدون پل (unbridged) ارائه دهد؛ مانند میزبان محاسباتی OpenStack که در آن هر یک از این رابط‌ها یک رابط TAP متصل به ماشین مجازی (VM) است، یا مانند پل‌زنی به سبک قدیمی در پلتفرم‌های BSD. در هر <alias> می‌توان از نویسه عام '*' در انتها استفاده کرد.

افزودن بیش از یک نام مستعار (alias) با استفاده از چندین گزینه --bridge-interface مجاز است، زیرا --bridge-interface=int1,alias1,alias2 دقیقاً معادل --bridge-interface=int1,alias1 --bridge-interface=int1,alias2 است.

سرور DHCP بر اساس شبکه‌ای که درخواست DHCP از آن می‌رسد و پیکربندی IP رابط شبکه سرور روی آن شبکه، مشخص می‌کند کدام دامنه‌های DHCP برای تخصیص آدرس به کلاینت DHCP قابل استفاده هستند. گزینه shared-network زیرشبکه‌های موجود (و در نتیجه دامنه‌های DHCP) را به فراتر از زیرشبکه‌های پیکربندی‌شده روی رابط شبکه دریافت‌کننده گسترش می‌دهد.

آرگومان نخست یا نام یک رابط شبکه است یا آدرسی که روی یک رابط شبکه محلی پیکربندی شده است، و آرگومان دوم آدرسی است که زیرشبکه دیگری را تعریف می‌کند که می‌توان از آن آدرس تخصیص داد.

برای کاربردی بودن، باید یک dhcp-range مناسب وجود داشته باشد که اجازه تخصیص آدرس در این زیرشبکه را بدهد و این dhcp-range حتماً باید شامل ماسک شبکه (netmask) باشد.

استفاده از shared-network همچنین نیازمند توجه ویژه به مسیریابی است. dnsmasq اطلاعات معمولی که برای تعیین مسیر پیش‌فرض استفاده می‌کند را در اختیار ندارد، بنابراین گزینه مسیر پیش‌فرض (یا سایر تنظیمات مسیریابی) حتماً باید به صورت دستی پیکربندی شوند. کلاینت باید مسیری به سرور داشته باشد: اگر از ساختار دو-آدرسی shared-network استفاده شود، این مسیر باید به نخستین آدرس مشخص‌شده باشد. اگر از ساختار رابط شبکه و آدرس (interface,address) استفاده شود، باید به تمام آدرس‌های پیکربندی‌شده روی رابط شبکه مسیر وجود داشته باشد.

ساختار دو-آدرسی shared-network با رله DHCP (یا DHCP relay) نیز قابل استفاده است: آدرس اول، آدرس رله است و آدرس دوم، مانند قبل، زیرشبکه اضافی را مشخص می‌کند که آدرس‌ها می‌توانند از آن تخصیص یابند.

دامنه‌های DNS را برای سرور DHCP مشخص می‌کند. دامنه‌ها را می‌توان بدون شرط (بدون محدوده IP) یا برای محدوده‌های IP خاص تعیین کرد. این کار دو نتیجه دارد: نخست این که باعث می‌شود سرور DHCP دامنه را به هر میزبانی که آن را درخواست کند بازگرداند، و دوم اینکه دامنه‌ای را تعیین می‌کند که ادعای آن برای میزبان‌های پیکربندی‌شده با DHCP مجاز است. هدف از این کار محدود کردن نام‌های میزبان است تا یک میزبان غیرقابل اعتماد روی شبکه محلی (LAN) نتواند نام خود را از طریق DHCP برای نمونه به عنوان "microsoft.com" اعلام کند و ترافیکی را که برای آن در نظر گرفته نشده است برباید. اگر هیچ پسوند دامنه‌ای مشخص نشود، هر نام میزبان DHCP با بخش دامنه (یعنی همراه با نقطه) رد شده و در لاگ ثبت می‌شود. اگر پسوند مشخص شود، نام‌های میزبان دارای بخش دامنه در صورتی که بخش دامنه آن‌ها با پسوند مطابقت داشته باشد مجاز خواهند بود. علاوه بر این، هنگامی که پسوند تنظیم می‌شود، برای نام‌های میزبان بدون بخش دامنه، این پسوند به عنوان یک بخش دامنه اختیاری اضافه می‌شود. برای نمونه در شبکه خود می‌توانم --domain=thekelleys.org.uk را تنظیم کنم و دستگاهی داشته باشم که نام میزبان DHCP آن "laptop" باشد. آدرس IP آن دستگاه از طریق dnsmasq هم به عنوان "laptop" و هم به عنوان "laptop.thekelleys.org.uk" در دسترس خواهد بود. اگر دامنه به صورت "#" داده شود، دامنه از نخستین دستور "search" در /etc/resolv.conf (یا معادل آن) خوانده می‌شود.

محدوده آدرس می‌تواند به شکل <ip address>,<ip address> یا <ip address>/<netmask> یا فقط یک <ip address> باشد. گزینه --dhcp-fqdn را ببینید که می‌تواند رفتار dnsmasq را در قبال دامنه‌ها تغییر دهد.

اگر محدوده آدرس به صورت ip-address/network-size داده شود، می‌توان یک فلگ اضافی "local" نیز ارائه داد که اثر آن افزودن اعلان‌های --local برای پرس‌وجوهای مستقیم و معکوس DNS است. به عنوان مثال: --domain=thekelleys.org.uk,192.168.0.0/24,local دقیقاً معادل است با: --domain=thekelleys.org.uk,192.168.0.0/24 --local=/thekelleys.org.uk/ --local=/0.168.192.in-addr.arpa/

محدوده آدرس همچنین می‌تواند به عنوان نام رابط شبکه داده شود که در این صورت تمام زیرشبکه‌هایی که در حال حاضر به رابط شبکه اختصاص داده شده‌اند برای تطبیق آدرس استفاده می‌شوند. این ویژگی اجازه می‌دهد تا به میزبان‌ها در زیرشبکه‌های فیزیکی مختلف، دامنه‌های متفاوتی اختصاص داده شود، به گونه‌ای که با تغییر آدرس‌های رابط شبکه به صورت خودکار به‌روزرسانی شوند.

در حالت پیش‌فرض، dnsmasq نام‌های غیراختصاصی (unqualified) کلاینت‌های DHCP را وارد DNS می‌کند. به همین دلیل، نام‌ها باید یکتا باشند، حتی اگر دو کلاینت با نام یکسان در دامنه‌های متفاوتی باشند. اگر کلاینت DHCP دومی با همان نام کلاینت قبلی ظاهر شود، نام به کلاینت جدید منتقل می‌شود. اگر --dhcp-fqdn تنظیم شود، این رفتار تغییر می‌کند: نام غیراختصاصی دیگر در DNS قرار نمی‌گیرد و تنها نام کامل (qualified) وارد می‌شود. دو کلاینت DHCP با نام یکسان می‌توانند نام خود را حفظ کنند، مشروط بر اینکه بخش دامنه آن‌ها متفاوت باشد (یعنی نام‌های دامنه کاملاً مشخص یا FQDN آن‌ها فرق داشته باشد). برای اطمینان از اینکه همه نام‌ها دارای بخش دامنه هستند، در زمان تنظیم --dhcp-fqdn باید حداقل یک گزینه --domain بدون مشخص کردن آدرس تعریف شده باشد.
به طور معمول هنگام اعطای اجاره DHCP، برنامه dnsmasq پرچم‌هایی را در گزینه FQDN تنظیم می‌کند تا به کلاینت بگوید تلاشی برای به‌روزرسانی DDNS با نام و آدرس IP خود انجام ندهد؛ چرا که جفت نام-IP به صورت خودکار به نمای DNS برنامه dnsmasq افزوده می‌شود. این فلگ آن رفتار را غیرفعال می‌کند که برای نمونه جهت اجازه دادن به کلاینت‌های ویندوز برای به‌روزرسانی سرورهای Active Directory مفید است. برای جزئیات به RFC 4702 مراجعه کنید.
قابلیت Router Advertisement در IPv6 را برای dnsmasq فعال می‌کند. DHCPv6 پیکربندی کامل شبکه را مانند DHCPv4 مدیریت نمی‌کند. کشف روتر و (احتمالاً) کشف پیشوند برای ایجاد خودکار آدرس توسط پروتکل متفاوتی انجام می‌شود. هنگامی که DHCP در حال استفاده است، تنها زیرمجموعه‌ای از این فرایند مورد نیاز است و dnsmasq می‌تواند با استفاده از پیکربندی موجود DHCP برای ارائه بیشتر داده‌ها، آن را مدیریت کند. هنگامی که RA فعال است، dnsmasq برای هر --dhcp-range یک پیشوند را اعلان می‌کند و روتر پیش‌فرض را برابر با آدرس link-local مربوطه روی دستگاه اجراکننده dnsmasq قرار می‌دهد. به طور پیش‌فرض، بیت‌های "managed address" تنظیم شده و بیت "use SLAAC" بازنشانی می‌شود. این مورد را می‌توان برای هر زیرشبکه با کلمات کلیدی حالت (mode) که در --dhcp-range. توضیح داده شده تغییر داد. پارامترهای DNS مطابق با RFC6106 در اعلان‌ها گنجانده می‌شوند. به طور پیش‌فرض، آدرس link-local مربوط به سیستم اجراکننده dnsmasq به عنوان سرور بازگشتی DNS ارسال می‌شود. در صورت ارائه، گزینه‌های dns-server و domain-search در DHCPv6 برای سرور DNS (یا RDNSS) و فهرست جستجوی دامنه (DNSSL) استفاده می‌شوند.
مقادیر غیرپیش‌فرض را برای اعلان‌های روتر (router advertisements) ارسال‌شده از طریق یک رابط شبکه تنظیم می‌کند. فیلد اولویت برای روتر می‌تواند از مقدار پیش‌فرض medium تغییر کند؛ مانند: --ra-param=eth0,high. فاصله زمانی بین اعلان‌های روتر را می‌توان (به ثانیه) تنظیم کرد؛ مانند: --ra-param=eth0,60. طول عمر مسیر (route lifetime) را می‌توان تغییر داد یا روی صفر تنظیم کرد که به روتر اجازه می‌دهد پیشوندها را اعلان کند اما مسیری را از طریق خود ارائه ندهد: --ra-param=eth0,0,0 (مقدار صفر برای فاصله زمانی به معنای مقدار پیش‌فرض است). هر چهار پارامتر را می‌توان همزمان تنظیم کرد: --ra-param=eth0,mtu:1280,low,60,1200

فیلد رابط شبکه می‌تواند شامل نویسه عام (wildcard) باشد.

پارامتر :mtu می‌تواند نام دلخواهی از یک رابط شبکه باشد که در این صورت مقدار MTU آن رابط شبکه استفاده می‌شود. این ویژگی برای نمونه جهت اعلان MTU یک رابط شبکه WAN روی سایر رابط‌های یک روتر کاربرد دارد.

ارسال پاسخ‌های DHCPOFFER و PROXYDHCP را حداقل به تعداد ثانیه‌های مشخص‌شده به تاخیر می‌اندازد. این گزینه می‌تواند به عنوان راهکاری موقت برای باگ‌های فریم‌ویر بوت PXE استفاده شود که هنگام دریافت پاسخ آنی به درستی عمل نمی‌کند. این گزینه زمان سپری‌شده در انتظار (برای نمونه انجام بررسی ping) را در صورت وجود لحاظ می‌کند.
عملکرد سرور TFTP را فعال می‌کند. این قابلیت به صورت عمدی به موارد مورد نیاز برای بوت کلاینت از طریق شبکه (net-boot) محدود شده است. فقط خواندن مجاز است؛ افزونه‌های tsize و blksize پشتیبانی می‌شوند (tsize فقط در حالت octet پشتیبانی می‌شود). بدون آرگومان، سرویس TFTP برای همان مجموعه رابط‌های شبکه‌ای که سرویس DHCP ارائه می‌شود، فعال خواهد شد. اگر فهرستی از رابط‌های شبکه ارائه شود، تعیین می‌کند کدام رابط‌ها سرویس TFTP را دریافت کنند.
فایل‌های مورد نظر برای انتقال با TFTP را نسبت به دایرکتوری مشخص‌شده جستجو می‌کند. هنگامی که این گزینه تنظیم شود، مسیرهای TFTP شامل ".." رد می‌شوند تا از دسترسی کلاینت‌ها به خارج از ریشه (root) مشخص‌شده جلوگیری شود. مسیرهای مطلق (شروع شده با /) مجاز هستند، اما باید درون tftp-root باشند. اگر آرگومان اختیاری رابط شبکه داده شود، این دایرکتوری فقط برای درخواست‌های TFTP از طریق آن رابط شبکه استفاده می‌شود.
در صورت غیرقابل دسترس بودن دایرکتوری‌های ریشه مشخص‌شده برای tftp، راه‌اندازی برنامه را لغو نمی‌کند.
آدرس IP یا آدرس سخت‌افزاری (MAC) کلاینت TFTP را به عنوان یک بخش مسیر به انتهای TFTP-root اضافه می‌کند. این گزینه فقط در صورتی معتبر است که --tftp-root تنظیم شده و دایرکتوری وجود داشته باشد. حالت پیش‌فرض، افزودن آدرس IP (در قالب استاندارد چهارگانه نقطه‌دار) است. برای نمونه اگر --tftp-root برابر با "/tftp" باشد و کلاینت 1.2.3.4 فایل "myfile" را درخواست کند، مسیر موثر در صورت وجود "/tftp/1.2.3.4" برابر با "/tftp/1.2.3.4/myfile" خواهد بود و در غیر این صورت "/tftp/myfile" در نظر گرفته می‌شود. هنگامی که "=mac" مشخص شود، در عوض آدرس MAC با استفاده از ارقام با حروف کوچک پرشده با صفر که با خط تیره از هم جدا شده‌اند پیوست می‌شود، مانند: 01-02-03-04-aa-bb توجه داشته باشید که تشخیص آدرس MAC تنها در صورتی امکان‌پذیر است که کلاینت در شبکه محلی باشد یا یک اجاره DHCP از ما دریافت کرده باشد.
حالت امن TFTP را فعال می‌کند: بدون این گزینه، هر فایلی که تحت قوانین معمول کنترل دسترسی یونیکس توسط فرآیند dnsmasq قابل خواندن باشد، از طریق TFTP در دسترس خواهد بود. هنگامی که فلگ --tftp-secure داده شود، تنها فایل‌های متعلق به کاربری که فرآیند dnsmasq را اجرا می‌کند قابل دسترسی خواهند بود. اگر dnsmasq به عنوان root اجرا شود، قوانین متفاوتی اعمال می‌شود: --tftp-secure اثری ندارد، اما فقط فایل‌هایی که بیت قابل خواندن برای همگان (world-readable) در آن‌ها تنظیم شده باشد در دسترس هستند. اجرای dnsmasq به عنوان root در حالی که TFTP فعال است توصیه نمی‌شود، و به ویژه هرگز نباید بدون تعیین --tftp-root انجام شود؛ چرا که انجام این کار می‌تواند هر فایل قابل خواندن همگانی روی سرور را برای هر میزبانی در شبکه فاش سازد.
نام فایل‌ها را در درخواست‌های TFTP به طور کامل به حروف کوچک تبدیل می‌کند. این قابلیت برای درخواست‌های ارسالی از سیستم‌های ویندوزی مفید است که سیستم‌فایل‌های حساس به حروف بزرگ و کوچک ندارند و در رعایت حروف بزرگ و کوچک نام فایل‌ها بی‌دقت هستند. توجه داشته باشید که سرور tftp در dnsmasq همیشه "\" را در نام فایل‌ها به "/" تبدیل می‌کند.
حداکثر تعداد مجاز اتصالات همزمان TFTP را تنظیم می‌کند. مقدار پیش‌فرض ۵۰ است. هنگام پاسخ‌گویی به تعداد زیادی از اتصالات TFTP، ممکن است محدودیت توصیف‌گر فایل (file descriptor) به ازای هر فرایند پیش بیاید. dnsmasq برای هر اتصال همزمان TFTP به یک توصیف‌گر فایل و برای هر فایل یکتا به یک توصیف‌گر فایل (به همراه چند مورد دیگر) نیاز دارد. بنابراین پاسخ‌گویی همزمان به n کلاینت برای یک فایل یکسان به حدود n + 10 توصیف‌گر فایل نیاز دارد و پاسخ‌گویی به فایل‌های مختلف به طور همزمان برای n کلاینت حدود (2*n) + 10 توصیف‌گر نیاز خواهد داشت. اگر --tftp-port-range مشخص شده باشد، می‌تواند بر تعداد اتصالات همزمان تأثیر بگذارد.
از مقدار size به عنوان سقف MTU پشتیبانی‌شده توسط شبکه واسط هنگام مذاکره بر سر اندازه بلوک (blocksize) در TFTP استفاده می‌کند، و در صورتی که تنظیمات MTU رابط شبکه محلی بزرگتر باشد، آن را بازنویسی می‌کند.
مانع از مذاکره سرور TFTP درباره گزینه "blocksize" با کلاینت می‌شود. برخی کلاینت‌های دارای نقص فنی این گزینه را درخواست می‌کنند اما پس از پذیرفته شدن آن، رفتار نامناسبی نشان می‌دهند.
سرور TFTP برای شروع اتصال به یک پورت شناخته‌شده (۶۹) گوش می‌دهد، اما برای هر اتصال از یک پورت اختصاص‌یافته پویا نیز استفاده می‌کند. به طور معمول این پورت‌ها توسط سیستم‌عامل تخصیص می‌یابند، اما این گزینه محدوده‌ای از پورت‌ها را برای انتقال‌های TFTP مشخص می‌کند. این قابلیت زمانی که TFTP مجبور است از دیوار آتش (فایروال) عبور کند می‌تواند مفید باشد. ابتدای محدوده نمی‌تواند کمتر از ۱۰۲۵ باشد مگر اینکه dnsmasq به عنوان root اجرا شود. تعداد اتصالات همزمان TFTP با اندازه محدوده پورت‌ها محدود می‌شود.
سرور TFTP را در حالتی اجرا می‌کند که برای سمت خود در انتقال TFTP تنها از پورت شناخته‌شده (۶۹) استفاده کند. این قابلیت امکان فعالیت TFTP را در شرایطی که NAT در مسیر بین کلاینت و سرور قرار دارد فراهم می‌سازد. توجه داشته باشید که این حالت کاملاً با RFCهای مشخص‌کننده پروتکل TFTP سازگار نیست؛ مسئولیت استفاده بر عهده خودتان است.
یک فایل پیکربندی را مشخص می‌کند. وجود این گزینه مانع از خواندن فایل پیکربندی پیش‌فرض (که معمولاً /etc/dnsmasq.conf است) توسط dnsmasq می‌شود. می‌توان با تکرار این گزینه در خط فرمان یا درون فایل‌های پیکربندی، چندین فایل را مشخص کرد. نام فایل "-" باعث می‌شود dnsmasq پیکربندی را از stdin بخواند.
-7, --conf-dir=<directory>[,<file-extension>......],
تمام فایل‌های موجود در دایرکتوری داده‌شده را به عنوان فایل‌های پیکربندی بخوان. اگر پسوند(هایی) داده شده باشد، از هر فایلی که به آن پسوندها ختم شود صرف‌نظر می‌شود. فایل‌هایی که نام آن‌ها به ~ ختم شود یا با . شروع شود یا با # شروع شده و پایان یابد، همیشه نادیده گرفته می‌شوند. اگر پسوند با * آغاز شود، فقط فایل‌هایی که آن پسوند را دارند بارگذاری می‌شوند. بنابراین --conf-dir=/path/to/dir,*.conf تمام فایل‌های دارای پسوند .conf در /path/to/dir را بارگذاری می‌کند. این فلگ ممکن است در خط فرمان یا درون یک فایل پیکربندی مشخص شود. در صورت ارائه در خط فرمان، مطمئن شوید که نویسه‌های * را اسکیپ می‌کنید. فایل‌ها به ترتیب الفبایی نام فایل بارگذاری می‌شوند.
حالت خاصی از --conf-file که از دو جهت تفاوت دارد. نخست، تنها --server و --rev-server در فایل پیکربندی گنجانده‌شده مجاز هستند. دوم، هنگامی که dnsmasq سیگنال SIGHUP دریافت می‌کند، فایل مجدداً خوانده شده و پیکربندی درون آن به‌روزرسانی می‌شود.
فایل <file> را اجرا کن و آنچه را که در خروجی استاندارد (stdout) منتشر می‌کند، به عنوان محتوای یک فایل پیکربندی در نظر بگیر. اگر اسکریپت با کد خروج غیرصفر خارج شود، dnsmasq این وضعیت را به عنوان یک خطای مهلک در نظر می‌گیرد. می‌توان آرگومان‌هایی را با فاصله از نام فایل و از یکدیگر به اسکریپت فرستاد؛ به عنوان مثال --conf-dir="/etc/dnsmasq-uncompress-ads /share/ads-domains.gz"

به همراه فایل /etc/dnsmasq-uncompress-ads شامل

set -e

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

exit 0

و /share/ads-domains.gz شامل یک فهرست فشرده از دامنه‌های سرورهای تبلیغاتی، در فهرست‌های بزرگ مسدودسازی سرورهای تبلیغاتی باعث صرفه‌جویی در فضای دیسک خواهد شد.

به پرس‌وجوهای کلاس CHAOS و نوع TXT در دامنه bind پاسخ نده.

بدون تنظیم این گزینه، آمار حافظه نهان (کَش) نیز در DNS به عنوان پاسخ به پرس‌وجوهای کلاس CHAOS و نوع TXT در دامنه bind در دسترس خواهد بود. نام‌های دامنه عبارتند از cachesize.bind، insertions.bind، evictions.bind، misses.bind، hits.bind، auth.bind و servers.bind مگر اینکه در زمان کامپایل غیرفعال شده باشند. یک دستور نمونه برای پرس‌وجوی این مورد با استفاده از ابزار dig به این صورت خواهد بود:

dig +short chaos txt cachesize.bind

حداکثر تعداد اتصالات هم‌زمان TCP. برنامه برای رسیدگی به هر درخواست TCP منشعب (fork) می‌شود. حداکثر مقدار پیش‌فرض ۲۰ است.

هنگام راه‌اندازی، dnsmasq در صورت وجود فایل /etc/dnsmasq.conf, را می‌خواند. (در سیستم‌عامل FreeBSD، این فایل /usr/local/etc/dnsmasq.conf است) (اما گزینه‌های --conf-file و --conf-dir را نیز ببینید.) قالب این فایل شامل یک گزینه در هر خط است، دقیقاً مانند گزینه‌های طولانی شرح داده‌شده در بخش OPTIONS اما بدون "--" در ابتدا. خطوطی که با # شروع می‌شوند کامنت بوده و نادیده گرفته می‌شوند. برای گزینه‌هایی که تنها یک بار قابل تعیین هستند، فایل پیکربندی بر خط فرمان اولویت دارد. نقل‌قول در فایل پیکربندی مجاز است: میان نشانه‌های نقل‌قول " معانی خاص ,:. و # حذف می‌شوند و گریزهای زیر مجاز هستند: \\ \" \t \e \b \r و \n. دنباله‌های اخیر به ترتیب معادل تب، escape، backspace، return و خط جدید (newline) هستند.

هنگامی که سیگنال SIGHUP دریافت شود، dnsmasq حافظه نهان (کَش) خود را پاک کرده و سپس /etc/hosts و /etc/ethers و هر فایل مشخص‌شده با --dhcp-hostsfile، --dhcp-hostsdir، --dhcp-optsfile، --dhcp-optsdir، --addn-hosts یا --hostsdir را مجدداً بارگذاری می‌کند. اسکریپت تغییر اجاره DHCP برای تمام اجاره‌های موجود DHCP فراخوانی می‌شود. اگر --no-poll تنظیم شده باشد، SIGHUP همچنین /etc/resolv.conf. را مجدداً می‌خواند. SIGHUP فایل پیکربندی را مجدداً بازخوانی نمی‌کند.

هنگامی که سیگنال SIGUSR1 دریافت شود، dnsmasq آمارها را در گزارش سیستم ثبت می‌کند. این برنامه اندازه حافظه نهان (کَش)، تعداد نام‌هایی که برای باز کردن فضا برای نام‌های جدید پیش از انقضا باید از حافظه نهان حذف می‌شدند و تعداد کل نام‌هایی که در حافظه نهان درج شده‌اند را می‌نویسد. تعداد اصابت‌ها (hits) و خطاهای حافظه نهان (misses) و تعداد پرس‌وجوهای معتبر (authoritative) پاسخ‌داده‌شده نیز ارائه می‌شوند. برای هر سرور بالادستی، تعداد پرس‌وجوهای ارسال‌شده و تعدادی که منجر به خطا شده‌اند را ارائه می‌دهد. همچنین اطلاعاتی در مورد تعداد انشعاب‌ها (forks) برای اتصالات TCP ارائه می‌دهد. در حالت --no-daemon یا زمانی که ثبت گزارش کامل فعال است (--log-queries)، یک رونوشت (dump) کامل از محتوای حافظه نهان ایجاد می‌شود.

هنگامی که SIGUSR2 دریافت شود و برنامه مستقیماً در یک فایل گزارش می‌نویسد (ببینید --log-facility ) dnsmasq فایل گزارش را بسته و دوباره باز می‌کند. توجه داشته باشید که در طول این عملیات، dnsmasq به عنوان کاربر ریشه (root) اجرا نخواهد شد. هنگامی که dnsmasq برای نخستین بار فایل گزارش را ایجاد می‌کند، مالکیت فایل را به کاربر غیرریشه‌ای که تحت آن اجرا خواهد شد تغییر می‌دهد. پیش از ارسال SIGUSR2، ابزار logrotate باید طوری پیکربندی شود که فایل گزارش جدیدی با مالکیت منطبق با فایل موجود ایجاد کند. اگر پرس‌وجوهای TCP DNS در حال انجام باشند، فایل گزارش قدیمی در فرآیندهای فرزندی که پرس‌وجوهای TCP را پردازش می‌کنند باز خواهد ماند و ممکن است نوشتن در آن ادامه یابد. یک محدودیت ۱۵۰ ثانیه‌ای وجود دارد که پس از آن تمام فرآیندهای TCP موجود منقضی خواهند شد: به همین دلیل، عاقلانه نیست که برای فایل‌های گزارشی که به تازگی چرخش داده شده‌اند (rotated)، فشرده‌سازی فایل گزارش پیکربندی شود. در استفاده از logrotate، گزینه‌های مورد نیاز عبارتند از create و delaycompress.

برنامه Dnsmasq یک بازفرستنده (forwarder) پرس‌وجوی DNS است: این برنامه قادر به پاسخ‌دهی بازگشتی (recursive) به پرس‌وجوهای دلخواه با شروع از سرورهای ریشه نیست، بلکه چنین پرس‌وجوهایی را به یک سرور DNS بالادستی کاملاً بازگشتی که معمولاً توسط ISP ارائه می‌شود، هدایت می‌کند. به طور پیش‌فرض، dnsmasq فایل /etc/resolv.conf را می‌خواند تا آدرس‌های IP سرورهای نام بالادستی که باید استفاده کند را بیابد، زیرا این اطلاعات معمولاً در آنجا ذخیره می‌شود. مگر اینکه --no-poll استفاده شود، dnsmasq زمان تغییر فایل /etc/resolv.conf (یا معادل آن در صورت استفاده از --resolv-file ) را بررسی کرده و در صورت تغییر، آن را مجدداً می‌خواند. این به سرورهای DNS اجازه می‌دهد به صورت پویا توسط PPP یا DHCP تنظیم شوند، زیرا هر دو پروتکل این اطلاعات را ارائه می‌دهند. عدم وجود /etc/resolv.conf خطا نیست، زیرا ممکن است پیش از برقراری اتصال PPP هنوز ایجاد نشده باشد. Dnsmasq تنها به بررسی ادامه می‌دهد تا در صورت ایجاد /etc/resolv.conf در هر زمانی، آن را بخواند. می‌توان به Dnsmasq دستور داد که بیش از یک فایل resolv.conf را تجزیه کند. این روی لپ‌تاپ که ممکن است هم PPP و هم DHCP استفاده شود بسیار مفید است: dnsmasq را می‌توان طوری تنظیم کرد که هر دو فایل /etc/ppp/resolv.conf و /etc/dhcpc/resolv.conf را نظارت (poll) کند و از محتوای هر کدام که دیرتر تغییر کرده است استفاده نماید، که این امر جابه‌جایی خودکار بین سرورهای DNS را فراهم می‌سازد.

سرورهای بالادستی ممکن است در خط فرمان یا در فایل پیکربندی نیز مشخص شوند. این مشخصات سرور به صورت اختیاری می‌توانند یک نام دامنه دریافت کنند که به dnsmasq می‌گوید از آن سرور فقط برای یافتن نام‌ها در آن دامنه خاص استفاده کند.

به منظور پیکربندی dnsmasq برای عمل کردن به عنوان حافظه نهان (کَش) برای میزبانی که روی آن در حال اجراست، عبارت "nameserver 127.0.0.1" را در /etc/resolv.conf قرار دهید تا فرآیندهای محلی وادار شوند پرس‌وجوها را به dnsmasq ارسال کنند. سپس یا سرورهای بالادستی را مستقیماً با استفاده از گزینه‌های --server به dnsmasq معرفی کنید، یا آدرس‌های واقعی آن‌ها را در فایل دیگری مانند /etc/resolv.dnsmasq قرار دهید و dnsmasq را با گزینه --resolv-file /etc/resolv.dnsmasq اجرا نمایید. این تکنیک دوم امکان به‌روزرسانی پویای آدرس‌های سرور توسط PPP یا DHCP را فراهم می‌سازد.

آدرس‌های موجود در /etc/hosts آدرس‌های متفاوت برای نام‌های مشابه در DNS بالادستی را پوشش می‌دهند (shadow می‌کنند)؛ بنابراین "mycompany.com 1.2.3.4" در /etc/hosts تضمین خواهد کرد که پرس‌وجوها برای "mycompany.com" همیشه 1.2.3.4 را برمی‌گردانند، حتی اگر پرس‌وجوها در DNS بالادستی آدرس متفاوتی را بازگردانند. یک استثنا در این مورد وجود دارد: اگر DNS بالادستی شامل یک CNAME باشد که به یک نام پوشش‌داده‌شده اشاره دارد، جستجوی CNAME از طریق dnsmasq منجر به دریافت آدرس پوشش‌نیافته مرتبط با مقصد آن CNAME خواهد شد. برای دور زدن این مشکل، CNAME را به /etc/hosts اضافه کنید تا آن CNAME نیز پوشش داده شود.

سیستم برچسب‌گذاری (tag) به این صورت کار می‌کند: dnsmasq هر درخواست DHCP را با برچسب‌های برگرفته از خطوط پیکربندی معتبر شامل set:<tag> برچسب‌گذاری می‌کند، یعنی:

set:<tag> برگرفته از --dhcp-range که برای تخصیص آدرس استفاده شده است؛

set:<tag> برگرفته از هر --dhcp-host منطبق (به همراه برچسب known یا known-othernet).

درخواست‌های BOOTP برچسب bootp می‌خورند. هر درخواست همچنین با نام رابط شبکه‌ای که درخواست از طریق آن وارد شده است، برچسب‌گذاری می‌شود.

هر خط پیکربندی شامل یک یا چند ساختار tag:<tag>، زمانی اعمال می‌شود که تمام برچسب‌های آن در درخواست موجود باشند. یعنی:

پیکربندی tag:A بر روی یک درخواست با برچسب set:tagged A اعمال می‌شود.

پیکربندی tag:B بر روی یک درخواست با برچسب set:tagged B اعمال می‌شود.

پیکربندی tag:A+B بر روی یک درخواست با برچسب set:tagged A اعمال نمی‌شود.

پیکربندی tag:A+B بر روی یک درخواست با برچسب set:tagged B اعمال نمی‌شود.

پیکربندی‌های tag:A+B، tag:A و tag:B بر روی یک درخواست با برچسب set:tagged A+B اعمال می‌شوند.

ساختارهای set:<tag> در --dhcp-range و --dhcp-host درخواست‌ها را برچسب‌گذاری می‌کنند.

از tag:<tag>ها در --dhcp-optionها استفاده کنید تا با set:<tag> مطابقت پیدا کرده و پیکربندی‌ها را اعمال نمایند.

یک --dhcp-option دارای tag:<tag> نسبت به یک --dhcp-option بدون برچسب ترجیح داده می‌شود، به شرطی که all (تمام) برچسب‌های آن در جایی از مجموعه گردآوری‌شده در بالا مطابقت داشته باشند.

پیشوند برچسب '!' به معنای 'not' است. عبارت --dhcp-option=tag:!purple,3,1.2.3.4 این گزینه را زمانی ارسال می‌کند که درخواست با purple برچسب‌گذاری نشده باشد. (نویسه کنترلی شل '!' در خط فرمان باید اسکیپ شود، اما در یک فایل پیکربندی نیازی به اسکیپ ندارد).

هنگام انتخاب --dhcp-optionها، یک برچسب --dhcp-range در مقایسه با سایر برچسب‌ها درجه دو محسوب می‌شود تا بازنویسی گزینه‌ها برای میزبان‌های منفرد آسان باشد، بنابراین:

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

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

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

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

دامنه NIS-domain را برای میزبان‌های موجود در محدوده برابر با domain1 تنظیم می‌کند، اما برای یک میزبان خاص که ممکن است در آن محدوده قرار بگیرد یا نگیرد، آن را برابر با domain2 قرار می‌دهد.

توجه داشته باشید که برای --dhcp-range هر دو ساختار tag:<tag> و set:<tag> امکان‌پذیر هستند، تا هم محدوده مورد استفاده بر اساس (مثلاً) --dhcp-host انتخاب شود، و هم بر اساس محدوده انتخاب‌شده گزینه‌های ارسالی تحت تاثیر قرار گیرند.

سیستم برچسب‌گذاری از یک سیستم پیشین و محدودتر تکامل یافته است. برای سازگاری با نسخه‌های قبلی، می‌توان به جای "tag:" از "net:" استفاده کرد و "set:" را حذف نمود. (به جز در --dhcp-host, که می‌توان به جای "set:" از "net:" استفاده کرد.) به همین دلیل، می‌توان از '#' به جای '!' برای نشان دادن NOT استفاده نمود.

سرور DHCP در dnsmasq به عنوان سرور BOOTP نیز عمل خواهد کرد، به شرطی که آدرس MAC و آدرس IP برای کلاینت‌ها مشخص شده باشند؛ خواه با استفاده از پیکربندی‌های --dhcp-host یا در /etc/ethers ، و یک گزینه پیکربندی --dhcp-range برای فعال‌سازی سرور DHCP روی یک شبکه خاص وجود داشته باشد. (تنظیم --bootp-dynamic نیاز به نگاشت‌های آدرس ایستا را برطرف می‌کند.) پارامتر filename در یک درخواست BOOTP به عنوان یک برچسب استفاده می‌شود، همان‌طور که برچسب bootp عمل می‌کند، که امکان کنترلی نسبی بر گزینه‌های بازگردانده‌شده به دسته‌های مختلف میزبان‌ها را فراهم می‌آورد.

پیکربندی dnsmasq برای عمل به‌عنوان یک کارساز DNS معتبر (authoritative)، به این دلیل پیچیده است که مستلزم پیکربندی کارسازهای DNS خارجی برای انجام تفویض اختیار (delegation) است. ما سه سناریو با پیچیدگی فزاینده را بررسی خواهیم کرد. پیش‌نیازهای تمام این سناریوها عبارتند از یک آدرس IP با دسترسی سراسری، یک رکورد A یا AAAA که به آن آدرس اشاره می‌کند، و یک کارساز DNS خارجی که قادر به تفویض ناحیه مورد نظر باشد. برای بخش اول این توضیحات، رکورد A (یا AAAA) برای آدرس با دسترسی سراسری را server.example.com و ناحیه‌ای که dnsmasq برای آن معتبر است را our.zone.com می‌نامیم.

ساده‌ترین پیکربندی شامل دو خط از تنظیمات dnsmasq است؛ چیزی شبیه به:

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

و دو رکورد در DNS خارجی:

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

رابط شبکه خارجی eth0 رابطی است که dnsmasq روی آن گوش می‌دهد و آدرس (با دسترسی سراسری) 192.0.43.10 را دارد.

توجه داشته باشید که آدرس IP خارجی ممکن است پویا باشد (یعنی توسط DHCP یا PPP از یک ISP اختصاص داده شده باشد). در این صورت، رکورد A باید از طریق یکی از سیستم‌های متداول DNS پویا (Dynamic DNS) به این تخصیص پویا پیوند داده شود.

پیکربندی پیچیده‌تر، اما از نظر کاربردی مفیدتر، به این صورت است که رکورد آدرس مربوط به IP با دسترسی سراسری در همان ناحیه معتبری که dnsmasq سرویس‌دهی می‌کند قرار گیرد، که معمولاً در ریشه قرار دارد. اکنون این موارد را داریم:

--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 برای our.zone.com اکنون به یک رکورد چسبان (glue record) تبدیل شده است؛ این رکورد مسئله مرغ و تخم‌مرغ را برای پیدا کردن آدرس IP کارساز نام our.zone.com در حالتی که رکورد A درون همان ناحیه است حل می‌کند. توجه داشته باشید که این تنها وظیفه این رکورد است: از آنجا که اکنون dnsmasq برای our.zone.com معتبر است، خود آن نیز باید این رکورد را ارائه دهد. اگر آدرس خارجی ایستا باشد، این کار می‌تواند با یک مدخل در /etc/hosts یا گزینه --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

اگر آدرس خارجی پویا باشد، آدرس مرتبط با our.zone.com باید از آدرس رابط شبکه مربوطه مشتق شود. این کار با استفاده از --interface-name انجام می‌شود؛ چیزی شبیه به:

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

(آرگومان "eth0" در --auth-zone زیرشبکه حاوی آدرس پویای eth0 را به ناحیه اضافه می‌کند، تا --interface-name آدرس را در پرس‌وجوهای خارجی بازگرداند.)

پیکربندی نهایی ما بر اساس موارد فوق ساخته شده، اما یک کارساز DNS ثانویه (secondary) را نیز اضافه می‌کند. این یک کارساز DNS دیگر است که داده‌های DNS ناحیه را از طریق انتقال ناحیه (zone transfer) می‌آموزد و در صورتی که کارساز اصلی غیرقابل‌دسترس شود، به‌عنوان پشتیبان عمل می‌کند. پیکربندی کارساز ثانویه فراتر از دامنه این صفحه راهنما است، اما پیکربندی اضافی dnsmasq ساده است:

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

و

our.zone.com           NS    secondary.myisp.com

افزودن auth-sec-servers قابلیت انتقال ناحیه را در dnsmasq فعال می‌کند تا به کارساز ثانویه اجازه دهد داده‌های DNS را جمع‌آوری کند. اگر مایلید این داده‌ها را به میزبان‌های خاصی محدود کنید:

--auth-peer=<IP address of secondary>

این کار را انجام خواهد داد.

برنامه dnsmasq به‌عنوان یک کارساز معتبر برای دامنه‌های in-addr.arpa و ip6.arpa مرتبط با زیرشبکه‌های مشخص‌شده در اعلان‌های --auth-zone عمل می‌کند، بنابراین جستجوهای معکوس (آدرس به نام) می‌توانند به‌سادگی با یک رکورد NS مناسب پیکربندی شوند؛ برای مثال در این نمونه، که در آن به آدرس‌های 1.2.3.0/24 اجازه می‌دهیم:

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

توجه داشته باشید که در حال حاضر، نواحی معکوس (in-addr.arpa و ip6.arpa) در انتقال ناحیه در دسترس نیستند، بنابراین تنظیم کارسازهای ثانویه برای جستجوهای معکوس بی‌فایده است.

هنگامی که dnsmasq برای عمل به‌عنوان یک کارساز معتبر پیکربندی می‌شود، از داده‌های زیر برای پر کردن ناحیه معتبر استفاده می‌گردد:

--mx-host, --srv-host, --dns-rr, --txt-record, --naptr-record, --caa-record, تا زمانی که نام‌های رکورد در دامنه معتبر باشند.

--synth-domain تا زمانی که دامنه در ناحیه معتبر باشد و برای پرس‌وجوهای معکوس (PTR)، آدرس در زیرشبکه مربوطه قرار داشته باشد.

--cname تا زمانی که نام رکورد در دامنه معتبر باشد. اگر مقصد CNAME بدون نام کامل (unqualified) باشد، با نام ناحیه معتبر تکمیل و واجد شرایط (qualified) می‌شود. CNAMEهایی که (فقط) به این روش استفاده می‌شوند می‌توانند حاوی نویسه عام (wildcard) باشند، مانند:

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

آدرس‌های IPv4 و IPv6 از ‎/etc/hosts (و --addn-hosts ) و --host-record و --interface-name و ---dynamic-host به شرطی که آدرس در یکی از زیرشبکه‌های مشخص‌شده در --auth-zone قرار گیرد.

آدرس‌های اجاره‌های DHCP، به شرطی که آدرس در یکی از زیرشبکه‌های مشخص‌شده در --auth-zone قرار گیرد. (اگر محدوده‌های DHCP ساخته‌شده در حال استفاده باشند که به آدرس اختصاص‌یافته پویا به یک رابط شبکه وابسته‌اند، باید از شکلی از --auth-zone که زیرشبکه‌ها را بر اساس آدرس پویای یک رابط شبکه تعریف می‌کند استفاده شود تا اطمینان حاصل شود که این شرط برآورده می‌شود.)

در حالت پیش‌فرض، که در آن یک اجاره DHCP دارای یک نام ناکامل (unqualified) و احتمالاً یک نام کامل ساخته‌شده با استفاده از --domain است، نام موجود در ناحیه معتبر از نام ناکامل و دامنه ناحیه ساخته می‌شود. این مقدار ممکن است با مقدار مشخص‌شده توسط --domain برابر باشد یا نباشد. اگر --dhcp-fqdn تنظیم شده باشد، نام‌های کاملاً معتبر دامنه (FQDN) مرتبط با اجاره‌های DHCP استفاده می‌شوند و باید با دامنه ناحیه مطابقت داشته باشند.

0 - برنامه Dnsmasq با موفقیت به پس‌زمینه فورک شد، یا در صورتی که اجرای پس‌زمینه فعال نباشد، به‌صورت عادی خاتمه یافت.

1 - مشکلی در پیکربندی شناسایی شد.

2 - مشکلی در دسترسی به شبکه رخ داد (آدرس در حال استفاده است، تلاش برای استفاده از درگاه‌های دارای دسترسی ویژه بدون داشتن مجوز).

3 - مشکلی در عملیات فایل‌سیستم رخ داد (نبود فایل/دایرکتوری، عدم وجود مجوزها).

4 - شکست در تخصیص حافظه.

5 - سایر مشکلات متفرقه.

11 یا بزرگ‌تر - یک کد بازگشتی غیرصفر از فراخوانی "init" فرآیند lease-script یا از یک فایل --conf-script دریافت شد. کد خروج dnsmasq برابر با کد خروج اسکریپت به‌علاوه 10 خواهد بود.

مقادیر پیش‌فرض برای محدودیت‌های منابع در dnsmasq عموماً محافظه‌کارانه و مناسب برای دستگاه‌های نوع روتر تعبیه‌شده با پردازنده‌های کند و حافظه محدود هستند. روی سخت‌افزارهای توانمندتر، می‌توان محدودیت‌ها را افزایش داد و کلاینت‌های بسیار بیشتری را مدیریت کرد. موارد زیر برای dnsmasq-2.37 اعمال می‌شود: نسخه‌های قبلی به این خوبی مقیاس‌پذیر نبودند.

برنامه Dnsmasq قادر است DNS و DHCP را برای حداقل هزار کلاینت مدیریت کند. زمان‌های اجاره DHCP نباید خیلی کوتاه باشند (کمتر از یک ساعت). مقدار --dns-forward-max می‌تواند افزایش یابد: ابتدا آن را برابر با تعداد کلاینت‌ها قرار دهید و اگر DNS کند به نظر رسید، آن را افزایش دهید. توجه داشته باشید که کارایی DNS به عملکرد کارسازهای نام بالادستی نیز بستگی دارد. اندازه حافظه نهان (کَش) DNS می‌تواند افزایش یابد: سقف قطعی ۱۰,۰۰۰ نام است و مقدار پیش‌فرض (۱۵۰) بسیار کم است. ارسال سیگنال SIGUSR1 به dnsmasq باعث می‌شود اطلاعاتی را ثبت کند که برای تنظیم دقیق اندازه حافظه نهان مفید است. برای جزئیات به بخش یادداشت‌ها (NOTES) مراجعه کنید.

کارساز داخلی TFTP قادر به انجام انتقال همزمان فایل‌های بسیاری است: محدودیت مطلق به تعداد دستگیره‌های فایل (file-handles) مجاز برای یک فرآیند و توانایی فراخوانی سیستمی select() برای مدیریت تعداد زیادی از دستگیره‌های فایل وابسته است. اگر این محدودیت با استفاده از --tftp-max خیلی بالا تنظیم شود، کاهش یافته و محدودیت واقعی هنگام راه‌اندازی ثبت می‌شود. توجه داشته باشید هنگامی که یک فایل یکسان در حال ارسال است، انتقال‌های بیشتری نسبت به زمانی که هر انتقال یک فایل متفاوت را ارسال می‌کند امکان‌پذیر است.

می‌توان از dnsmasq برای مسدود کردن تبلیغات وب با استفاده از فهرستی از کارسازهای شناخته‌شده تبلیغات بنری که همگی به 127.0.0.1 یا 0.0.0.0 اشاره می‌کنند، در /etc/hosts یا یک فایل hosts اضافی استفاده کرد. این فهرست می‌تواند بسیار طولانی باشد؛ dnsmasq با موفقیت با یک میلیون نام آزمایش شده است. فایلی با این اندازه به یک پردازنده ۱ گیگاهرتزی و حدود ۶۰ مگابایت رم نیاز دارد.

برنامه Dnsmasq می‌تواند برای پشتیبانی از بین‌المللی‌سازی کامپایل شود. برای این منظور، باید از هدف‌های make با عنوان "all-i18n" و "install-i18n" به جای هدف‌های استاندارد "all" و "install" استفاده شود. هنگامی که پشتیبانی از بین‌المللی‌سازی کامپایل شده باشد، dnsmasq پیام‌های ثبت گزارش را به زبان محلی تولید کرده و از نام‌های دامنه بین‌المللی‌شده (IDN) پشتیبانی می‌کند. نام‌های دامنه در /etc/hosts، /etc/ethers و /etc/dnsmasq.conf که حاوی نویسه‌های غیر ASCII هستند، به نمایش داخلی punycode در DNS ترجمه می‌شوند. توجه داشته باشید که dnsmasq هم زبان پیام‌ها و هم مجموعه نویسه‌های (charset) فرضی برای فایل‌های پیکربندی را از متغیر محیطی LANG تعیین می‌کند. این متغیر باید توسط اسکریپت مسئول راه‌اندازی dnsmasq روی مقدار پیش‌فرض سیستم تنظیم شود. هنگام ویرایش فایل‌های پیکربندی دقت کنید که این کار را فقط با استفاده از لوکال پیش‌فرض سیستم انجام دهید و نه لوکال مختص کاربر، زیرا dnsmasq راه مستقیمی برای تشخیص مجموعه نویسه‌های مورد استفاده ندارد و باید فرض کند که همان پیش‌فرض سیستم است.

/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)

این صفحه راهنما توسط Simon Kelley <simon@thekelleys.org.uk> نوشته شده است.

2025-02-05