Hi Dominick,
more below
On 10/17/19 3:41 AM, Dominick C. Pastore wrote:
Hello,
I'm having a bit of a problem with the "cname" option in Dnsmasq. I have some configuration options
like these in dnsmasq.conf, where "host1" and "host2" have IPv4 addresses from DHCP:
On 26/10/2019 03:47, Dominick C. Pastore wrote:
> On Fri, Oct 25, 2019, at 4:48 PM, Simon Kelley wrote:
>> On 20/10/2019 17:55, Dominick C. Pastore wrote:
>>> I apologize for continuing the discussion on this. The patch (applied on
>>> top of 2.80-1 provided by Debian Buster) completely solved
On Fri, Oct 25, 2019, at 4:48 PM, Simon Kelley wrote:
> On 20/10/2019 17:55, Dominick C. Pastore wrote:
> > I apologize for continuing the discussion on this. The patch (applied on
> > top of 2.80-1 provided by Debian Buster) completely solved the issues I was
> > having, but I did notice a
I have no complaints about a new thread.
On Sun, Oct 20, 2019, at 6:47 PM, Kurt H Maier wrote:
> On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote:
> > 2. In fact, Dnsmasq never follows a CNAME for MX or TXT requests, even
> > when the CNAME does point to a host Dnsmasq knows
On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote:
> 2. In fact, Dnsmasq never follows a CNAME for MX or TXT requests, even
> when the CNAME does point to a host Dnsmasq knows locally. (I assume
> this is the reason for #1.)
RFC2181 explicitly forbids MX records from being
On Sun, Oct 20, 2019 at 12:55:44PM -0400, Dominick C. Pastore wrote:
> ... but I suspect this isn't intended behavior either,
> so it seemed worth mentioning.
Is it OK that I start a new thread (with matching Subject) for it?
[yes/no]
___
I apologize for continuing the discussion on this. The patch (applied on top of
2.80-1 provided by Debian Buster) completely solved the issues I was having,
but I did notice a couple other things.
First, locally configured CNAMEs and records other than A or do not seem
to play well
On Sat, Oct 19, 2019, at 6:16 AM, Simon Kelley wrote:
> The restriction still applies. indeed the patch relies on it.
>
> The origin of this is that, for architectural reasons, dnsmasq can only
> supply a reply which originates completely from locally known data, or
> completely from a reply from
The restriction still applies. indeed the patch relies on it.
The origin of this is that, for architectural reasons, dnsmasq can only
supply a reply which originates completely from locally known data, or
completely from a reply from upstream. Since a local CNAME to a target
in the public DNS
On Fri, Oct 18, 2019, at 7:41 AM, Simon Kelley wrote:
> I can see a strong argument that a query for a name which is configured
> as a CNAME in dnsmaq, but for a type which is not known to dnsmasq,
> should return a NODATA reply.
>
> In fact I can't see a downside to that.
>
> Anybody else?
>
>
On 18/10/2019 12:51, Simon Kelley wrote:
> On 18/10/2019 12:41, Simon Kelley wrote:
>
>> The obvious way is to provide an record for the "local names". The
>> problem with that is it has to be real, or timeouts and stuff will
>> happen, so those hosts need to be dual-stack.
>>
>> I can see a
On 17/10/2019 02:41, Dominick C. Pastore wrote:
> Hello,
>
> I'm having a bit of a problem with the "cname" option in Dnsmasq. I have some
> configuration options like these in dnsmasq.conf, where "host1" and "host2"
> have IPv4 addresses from DHCP:
>
> domain=philadelphia.example.com
>
On 18/10/2019 12:41, Simon Kelley wrote:
> The obvious way is to provide an record for the "local names". The
> problem with that is it has to be real, or timeouts and stuff will
> happen, so those hosts need to be dual-stack.
>
> I can see a strong argument that a query for a name which is
Hello,
I'm having a bit of a problem with the "cname" option in Dnsmasq. I have some
configuration options like these in dnsmasq.conf, where "host1" and "host2"
have IPv4 addresses from DHCP:
domain=philadelphia.example.com
local=/philadelphia.example.com/
14 matches
Mail list logo
