[Dnsmasq-discuss] interface-name and IPv6 temporary addresses

Michael Gorbach michael at mgorbach.name
Thu Dec 18 16:08:08 GMT 2014

Just compiled and tested. Looking good! It’s returning only the correct (global) address for forward queries, and returning temporary addresses for reverse queries. Thanks for the fix, Simon!

~ M.

> On Dec 17, 2014, at 7:43 AM, Simon Kelley <simon at thekelleys.org.uk> wrote:
> Hash: SHA256
> I just pushed changes to the git repo to implement this. Michael,
> please could you seen if it now behaves as you'd like?
> Cheers,
> Simon.
> On 01/12/14 18:49, Michael Gorbach wrote:
>> On Nov 30, 2014, at 11:17 AM, Simon Kelley
>> <simon at thekelleys.org.uk> wrote:
>>> On 29/11/14 19:18, Michael Gorbach wrote:
>>>> Hi All,
>>>> I've got a question and potential enhancement request. It looks
>>>> like right now, the (very useful) interface-name feature pulls
>>>> all (global) addresses from the interface. One of my machines
>>>> uses IPv6 privacy extensions (known in Linux as use_tempaddr),
>>>> which means that in addition to link-local and permanent global
>>>> addresses, it has a rotating cast of ~ 5 temporary addresses. I
>>>> suggest that dnsmasq should detect those temporary addresses
>>>> and not return them for queries that would otherwise hit
>>>> interface-name. Returning them as it does now means > 5 AAAA
>>>> records for a single name, which causes repeated confusion due
>>>> to things like SSH warning about an unknown host because it has
>>>> suddenly picked a previously-unknown temporary address to
>>>> connect to. Thoughts?
>>> Sounds like a sensible suggestion. This facility was added before
>>> I was really familiar with IPv6 and all its extra complications.
>>> Most of those 5 temporary addresses will be "deprecated" ie
>>> hanging around for the use of existing connections, but not used
>>> for new ones. They definitely shouldn't appear, but I'm pretty
>>> convinced, unless anyone can come up with a good reason why not,
>>> that all privacy addresses should be elided, without exception.
>>> I wonder, though, if that's only true for forward (ie AAAA)
>>> lookups. Should a reverse lookup on an old privacy address still
>>> yield the name of the host it belongs to?
>> Thanks, Simon. I’d agree that all the temporary addresses should be
>> skipped in forward resolution. In terms of reverse, I’d say there’s
>> a high amount of value in having at least the current temporary
>> address resolve to the correct host name. Temporary addresses are
>> often preferred for outbound connections, so if we don’t have
>> reverse resolution here then for example SSH is going to complain
>> that it can’t check reverse DNS. There’s probably some value in
>> reverse resolution for deprecated temporary addresses, for example
>> if you wanted to track down some client in your system logs from
>> several days ago, but it’s significantly lower. If that’s a large
>> amount of work, to me it’s something that wouldn’t be
>> top-priority.
>> Yours, ~ M.
>>> Cheers,
>>> Simon.
>>> _______________________________________________ Dnsmasq-discuss
>>> mailing list Dnsmasq-discuss at lists.thekelleys.org.uk
>>> <mailto:Dnsmasq-discuss at lists.thekelleys.org.uk> 
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>> <http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss>
> Version: GnuPG v1
> 9yC/jow4juxmtNoLVwZ7vLwTyvCSG9kpUDhDh6Rn2x674iXbOa8HpU6wAWSOdL6o
> HRPYmutJk9cO6Pq6mQrzK02afDEfLwpRVazIgIznuq3LmjIV4oEACQItItXsbRxE
> e6VTfO/MbXlKSvuShPreTotLPInpd1+crj4iNWPpAZzby+H3lLcHc2+VtUF1Tkou
> pkK1WHDYLK1aqn2xgao8/d3YF6JQmQMD6D9wo+jYF0FYerP0zPDsnaC2alt/RIrq
> R1o6kfcpAv6yY6PWbA3WLYUFn0j9q9Qv95jGWWmlsU0GiuvNZTPQ1RAXrdLbv2WM
> UeEU6HErEtwimnws6aG5Ou5ig3kWHaKdk+Cl1p3XAHHrPAmBU6ut7zm7s/kpbdgT
> /kR03mHf8+34aRWhyPCDVOghQQxmFWB6Dep3LxRjouZvdxke1Pht/FHA98GeqgdU
> eEhO3ySRNJqD+H8tSr+WRUfWfSN8d/eWiE9A/jeLhvhQOzC/d63I9mHZQUsdVE/W
> weqk4fVavTkvhNon8tXpqT8yggsD8S/m/KhCj691tY3he78iEM9u7WCFas3UC7fa
> R6avOGiKdq6aBbLAT0bBTRe/pdZGvk7zUMaO84Wd1aFT/UVpQ3/FAq8Ec8RZStLm
> oFi+BU4Vh5ZGcn9DKgol
> =civ9

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4145 bytes
Desc: not available
URL: <http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/attachments/20141218/5f2a833e/attachment.bin>

More information about the Dnsmasq-discuss mailing list