Please add DHCP option 119

[ptr727]

Please add DHCP option 119 for domain search, accompanies DHCP option 15.
[https://www.rfc-editor.org/rfc/rfc3397]

I am not sure how to interpret multiple strings as per RFC vs. OptionFormat.str?

As FYI: In my environment the search domain typically just matches the domain name. Some OS's (even some versions of Win11) ignore option 15 and use option 119 for the default domain, which is how I ended up adding option 119.

[sjackson0109]

Are you not looking for 'dns search suffix'?

Simon

On Fri, 11 Aug 2023 at 17:46, Pieter Viljoen @.***> wrote:

Please add DHCP option 119 for domain search, accompanies DHCP option 15. [https://www.rfc-editor.org/rfc/rfc3397]

I am not sure how to interpret multiple strings as per RFC vs. OptionFormat.str?

As FYI: In my environment the search domain typically just matches the domain name. Some OS's (even some versions of Win11) ignore option 15 and use option 119 for the default domain, which is how I ended up adding option 119.

— Reply to this email directly, view it on GitHub https://github.com/CyberShadow/dhcptest/issues/35, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJCQ5PU3NBN4HB6QTTAOPMLXUZOVZANCNFSM6AAAAAA3NFC6RY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[CyberShadow]

I think the main difficulty is compression:

https://www.rfc-editor.org/rfc/rfc1035#section-4.1.4

Do you have any example packets with this option?

[ptr727]

The examples I saw use interface config as a string, and it works on Windows and Linux, so not sure the RFC encoding is always required.
Here are some resources I consulted:
[https://jjjordan.github.io/dhcp119/]
[https://blogs.blackmarble.co.uk/rhepworth/adding-dhcp-option-119-domain-search-list-to-windows-server-2008-r2/]
[https://blog.it-playground.eu/dhcp-option-119-domain-search-on-juniper-srx/]
[https://learn.microsoft.com/en-us/windows-server/networking/technologies/dhcp/what-s-new-in-dhcp#new-dhcp-client-side-features-in-the-windows-10-april-2018-update]
[https://ictfella.com/how-to-configure-dhcp-option-119-in-windows-dhcp-server-and-cisco-switch/]
[https://knowledgebase.paloaltonetworks.com/KCSArticleDetail?id=kA14u000000saawCAA]

And comments in dnsmasq config:
[https://github.com/mirror/dd-wrt/blob/master/src/router/dnsmasq/dnsmasq.conf.example#L410]

And from dhcpoptions docs:

option domain-search domain-list;
The domain-search option specifies a 'search list' of Domain Names to be used by the client to locate not-fully-qualified domain names. The difference between this option and historic use of the domain-name option for the same ends is that this option is encoded in RFC1035 compressed labels on the wire. For example:
option domain-search "example.com", "sales.example.com",
                     "eng.example.com";

This config on my Firewalla appliance and it works on Windows and Linux clients (I use numeric 119 and not domain-search as I only saw that text label later):

.router/config/dhcp/conf/br0.conf:

dhcp-option=tag:br0,119,foo.bar.net

This is the capture from a Win11 client:

> .\dhcptest-0.7-win64.exe --query
dhcptest v0.7 - Created by Vladimir Panteleev
https://github.com/CyberShadow/dhcptest
Run with --help for a list of command-line options.

Listening for DHCP replies on port 68.
Sending packet:
  op=BOOTREQUEST chaddr=A0:C8:99:DE:24:E6 hops=0 xid=6A5F9469 secs=0 flags=8000
  ciaddr=0.0.0.0 yiaddr=0.0.0.0 siaddr=0.0.0.0 giaddr=0.0.0.0 sname= file=
  1 options:
     53 (DHCP Message Type): discover
Received packet from 192.168.1.1:67:
  op=BOOTREPLY chaddr=A0:C8:99:DE:24:E6 hops=0 xid=6A5F9469 secs=0 flags=8000
  ciaddr=0.0.0.0 yiaddr=192.168.1.128 siaddr=192.168.1.1 giaddr=0.0.0.0 sname= file=
  11 options:
     53 (DHCP Message Type): offer
     54 (Server Identifier): 192.168.1.1
     51 (IP Address Lease Time): 86400 (1 day)
     58 (Renewal (T1) Time Value): 43200 (12 hours)
     59 (Rebinding (T2) Time Value): 75600 (21 hours)
      1 (Subnet Mask): 255.255.255.0
     28 (Broadcast Address Option): 192.168.1.255
    119 (Unknown): 04 68 6F 6D 65 0C 69 6E 73 61 6E 65 67 65 6E 69 75 73 03 6E 65 74 00
     15 (Domain Name): home.insanegenius.net
      6 (Domain Name Server Option): 192.168.1.1
      3 (Router Option): 192.168.1.1

[CyberShadow]

From reading that section of RFC1035, it looks like the compression is optional (so a 7-bit string is always valid, but decoding may require implementing decompression). But also, I see now that the value itself is not just a string, but a list (or a hierarchy?) of length-prefixed strings.

The example in RFC 3397 also shows an example of that format.

I think it would also be the first option in dhcptest in which a single value can span and be represented by several occurrences of the option within a packet.

In short, it's doable but needs some work.

[ptr727]

If I use the the jjordan test encoder, and I use the hex 04 68 6F 6D 65 0C 69 6E 73 61 6E 65 67 65 6E 69 75 73 03 6E 65 74 00 reported by dhcptest I do get the expected output of home.insanegenius.net.

On the same page the encoding results in 0x04'home'0x0C'insanegenius'0x03'net'0x00, but in my own testing and online docs using the string as is seems to work in configurations, I wonder if some DHCP servers convert to the correct format from text, or if the client takes the simple text form.

It would be good progress if you cover the basic cases, even if not all more complex cases.