[Dnsmasq-discuss] [PATCH] Support Cisco Umbrella/OpenDNS Device ID & Remote IP

Brian Hartvigsen brian.andrew at brianandjenny.com
Wed Apr 7 20:40:00 UTC 2021

> On Apr 7, 2021, at 07:42, Petr Menšík <pemensik at redhat.com> wrote:
> Signed PGP part
> Hi Brian,
> I maintain dnsmasq on RHEL. What is primary reason organisation ID is
> embedded into each DNS query? It seems to me this is necessary only to
> work around network address translations on the way from dnsmasq to its
> forwarder. If no NAT is in the way, just source address should work as
> unique identified for the organization, right?

The best I can say on organization id is that is is being phased out as a required component.  Most of the time, not including it is fine.  In some situations it is still required, so easier to put it and not need it right now.

> How does it handle cases, when umbrella is already set its client? Ie. case:
> [client]-->[dnsmasq1]-->[dnsmasq2]-->[OpenDNS]
> When dnsmasq1 sets some umbrella id, should dnsmasq2 keep it and mark
> with own orgid just queries without the extension? Should it be
> configurable? Isn't there use case for it?

I am not aware of anyone actually using this use case that is using a modified version today.  Not saying it couldn't happen, but that would not be a typical network setup we see or support.  If that were to happen, the "correct" thing to do would be to discard the option code at dnsmasq2 and add a new one.  I believe (though would need to confirm) that the Cisco Umbrella resolvers will use the data in the first instance of the option present in the packet.

> Then OpenDNS can lookup orgid from sourceIP and DSCP pair, therefore it
> would not contain orgid inside EDNS, but just at IP packet level. Of
> course it would require more logic at OpenDNS, but that is the part
> using those metadata anyway, isn't it?

We used what we could prove survived various network environments and topologies that our customers were in.  Also, doing it in an EDNS0 option meant we had the ability to extend what we did buy keeping our definition loose/flexible.

> Does it send deviceid on each single query? I guess orgid is required,
> deviceid not much so. Do they both combined create unique pair? It seems
> like Client Subnets[2] reversed. It seems privacy dangerous without TLS
> encapsulation. It seems to me similar results could be archieved with
> some faked IPv6 address and --add-subnet.

deviceid is required if you want to report a specific device.  More important in mobile environments, but can be handy in other environments as well.  This option pre-dates ECS and what I have documented here is only the bits necessary for the functionality I and others used it for.  There are other bits that do other things but they don't make sense on dnsmasq.  This brings parity with something supported by BIND on the subscriber branch to dnsmasq.

Internally, the option is used when doing DNSCrypt/DoH though it can be sent in plaintext in some situations.  As to whether someone things it is a privacy violation, that is left up to the network administrator.

> By the way, couldn't be used --add-cpe-id? It seems to me it serves
> exactly the same purpose. Search EDNS0_OPTION_NOMCPEID in src/edns0.c.
> Could just --add-cpe-id="orgid:deviceid" be used?

No because the resolvers don't understand CPE ID and the format is incorrect.  Notice the string is parsed in to a array of bytes, not just a simple string.

I'm just documenting something that exists/works today.  Internally we have had and continue to have discussions about doing some of the things you have mentioned (leveraging ECS and CPE ID/Client ID), but there is other information that can be transmitted (that I have not documentated in this patch because it isn't useful) that makes using our own option code useful.

I hope that answers everything :)  Happy to provide more information or clarification.

-- Brian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20210407/7919234b/attachment.sig>

More information about the Dnsmasq-discuss mailing list