a7ypical ly
2018-03-17 17:00:42 UTC
Hi,
I'm using --server and --ipset to redirect some traffic through a VPN.
The issue is that if a dns reply contains CNAME and this CNAME is later
queried, dnsmasq does not redirect it to the upstream server.
For example:
--server=/example.com/1.1.1.1
--ipset=/example.com/set1
Querying for example.com will go to 1.1.1.1 and be added to set1 as
expected. But if the reply contains something like:
exampe.com -> CNAME c.example.com TTL 1000
c.example.com -> 2.2.2.2 TTL 60
A client may later on query for c.example.com directly (as its TTL is lower
than the cname pointer) and dnsmasq will not use the upstream server and
will not add it to the ipset set.
Since I couldn't find any similar reports on this issue I assume this is
pretty specific for my use case and probably won't be fixed/changed. I'd
like to hack something quick and dirty to fix this for me and wonder if
anyone could point me to a possible solution? I think a possible solution
would be to add a new cache entry with c.example.compointing back to
example.com with a new flag that I can use to look it up when c.example.com is
queried and figure out it needs an upstream server and ipset entry. Is
there anything like that I can use? I think I saw that all the 16 bits for
a flag in the cache are already used. Any suggestions?
Thanks!
I'm using --server and --ipset to redirect some traffic through a VPN.
The issue is that if a dns reply contains CNAME and this CNAME is later
queried, dnsmasq does not redirect it to the upstream server.
For example:
--server=/example.com/1.1.1.1
--ipset=/example.com/set1
Querying for example.com will go to 1.1.1.1 and be added to set1 as
expected. But if the reply contains something like:
exampe.com -> CNAME c.example.com TTL 1000
c.example.com -> 2.2.2.2 TTL 60
A client may later on query for c.example.com directly (as its TTL is lower
than the cname pointer) and dnsmasq will not use the upstream server and
will not add it to the ipset set.
Since I couldn't find any similar reports on this issue I assume this is
pretty specific for my use case and probably won't be fixed/changed. I'd
like to hack something quick and dirty to fix this for me and wonder if
anyone could point me to a possible solution? I think a possible solution
would be to add a new cache entry with c.example.compointing back to
example.com with a new flag that I can use to look it up when c.example.com is
queried and figure out it needs an upstream server and ipset entry. Is
there anything like that I can use? I think I saw that all the 16 bits for
a flag in the cache are already used. Any suggestions?
Thanks!