date:20200317

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

2020-03-17 Thread Sasha Litvak

Simon,

Hosts in domain .consul are resolved by DNS servers forwarding requests to
a consul clusters.  I also have hard coded direct consul server records for
.consul in dnsmasq config.  Nothing in /etc/hosts . Consul returns records
with  TTL 0 .  I perhaps wrongly thought it meant they are not cached.
That is why I added ttl-min 5s.

On Tue, Mar 17, 2020, 10:46 AM Simon Kelley  wrote:

> On 17/03/2020 01:31, Sasha Litvak wrote:
> > I couldn't find a specific answer anywhere so hopefully someone has a
> > clue on this list
> >
> > We are using dnsmasq on our servers as a caching dns solution.
> >
> > Most of our domains are resolved by a wildcard record like this
> >
> > $TTL 3600   ; 1 hour
> > A   10.10.10.23
> > $ORIGIN example.net.
> > *   CNAME   excontainers
> > excontainersCNAME   exservice.service.consul
> >
> > dnsmasq handles resolution of .consul domain directly but the DNS
> > server itself also forwards .consul to consul servers.
> ^
>
>
> Can you elaborate? How does dnsmasq handle the resolution of the .consul
> domain? If you have something like
>
> 10.0.48.13 exservice.service.consul
>
> in /etc/hosts
>
> then that defines, effectively, an immortal record for
> exservice.service.consul, so a CNAME chain of two records, each with a
> TTL of one hour, would result in that answer being returned for an hour.
>
> >
> > I added min-ttl 5s to decrease the number of queries to consul
> >
> > So when I do dig foo.example.net  @127.0.0.1 I get
> >
> > foo.example.net. 3600 IN CNAME excontainers.example.net.
> > excontainers.example.net. 3600 IN CNAME exservice.service.consul.
> > exservice.service.consul. 5 IN A 10.0.48.13
>
> This might be misleading: is you do that query to dnsmasq with a clean
> cache, it will forward the query upstream, and return the complete
> result it gets, including the A record with a 5s TTL, but further
> queries from the cache would return a 0 (infinite) TTL for the A record
> of it's defined locally.
>
> The fix for this is to define the .consul A record using --host-record,
> which allows you to specify the 5s TTL.
>
>
>
> >
> > Now we often need to migrate subdomains by pointing them to a
> > different consul cluster.  So our script uses nsupdate and creates a
> > dynamic DNS record resulting in this reply
> >
> > foo.example.net. 60 IN CNAME  exservice2.service.consul.
> >  exservice2.service.consul. 5 IN A 10.0.48.35
> >
> > So we have a record that is more explicit and it takes precedence over
> > wild card.   On servers with little traffic, domain switch happens
> > within a few seconds, but on the main busy server with 100s of queries
> > a second, it takes an hour for dnsmasq to change its cache.  We see
> > dnsmasq sending requests to the DNS server getting correct new records
> > but still sending the old cached records to a client.
> >
> > When we are going back from distinct to default wild card (removing
> > distinct record in DNS) cache change happens almost immediately (a
> > couple of seconds) regardless of how busy the server is.
> >
> > Sorry for the long description but I would like to find out a reason
> > why during switching from wild card to more explicit record dnsmasq
> > cache update takes such a long time.
> >
>
> I'm guessing at exactly what's going on here: more details would be
> useful, but if I guessed right, that's the solution.
>
>
> Simon.
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

2020-03-17 Thread Simon Kelley

On 17/03/2020 21:48, Dominik wrote:
> Patch attached.


and applied. Thanks.

Simon.


> 
> On 17.03.20 21:54, Simon Kelley wrote:
>>
>> On 11/03/2020 07:55, Dominik wrote:
>>> Hey Buck,
>>>
>>> dnsmasq blocks all IPv4 address replies in the "private" subnets when 
>>> enabling stop-dns-rebind. For IPv6, it blocks only the IPv4-mapped address 
>>> ranges matching said private subnets.
>>>
>>> Neither ULAs nor LLs (link-locals) are blocked in the IPv6 range. I agree 
>>> this should be added.
>>>
>>> I can provide a patch for this, maybe tomorrow, if this is wanted. However, 
>>> I'm afraid it might already be too late for 2.81, cfm. Simon.
>> Apologies for that late reply. A patch sometime this week should be fine
>> for 2.81.
>>
>> Simon.
>>
>>> Best,
>>> Dominik
>>>
>>> Am 11. März 2020 00:47:02 MEZ schrieb buckh...@weibsvolk.org:
 I am using dnsmasq version pi-hole-2.80 as embedded in Pi-hole, with my

 router set as its sole upstream server (server=192.168.178.1#53).

 When evaluating DNS rebind protection provided by dnsmasq (by adding 
 stop-dns-rebind), I observed that dnsmasq correctly detects and 
 suppresses IPv4 answers, but fails to do the same for IPv6 ULA
 addresses 
 (maybe even for IPv6 in general).

 E.g. "nslookup wpad.fritz.box" from a Windows client results in the 
 following log entries:

 09:58:08 dnsmasq[20063]: query[A] wpad.fritz.box from 192.168.178.200
 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
 09:58:08 dnsmasq[20063]: possible DNS-rebind attack detected: 
 wpad.fritz.box
 09:58:08 dnsmasq[20063]: query[] wpad.fritz.box from
 192.168.178.200
 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
 09:58:08 dnsmasq[20063]: reply wpad.fritz.box is 
 fd00::2ba:dcff:feca:fe00

 Shouldn't IPv6 ULA and link-local addresses also be suppressed?
 Does dnsmasq exhibit this behaviour by intention, or could this be seen

 as a possible gap in rebind protection?

 Kind regards,

 Buck



 ___
 Dnsmasq-discuss mailing list
 Dnsmasq-discuss@lists.thekelleys.org.uk
 http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>> ___
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>>


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

2020-03-17 Thread Dominik

Patch attached.

On 17.03.20 21:54, Simon Kelley wrote:
>
> On 11/03/2020 07:55, Dominik wrote:
>> Hey Buck,
>>
>> dnsmasq blocks all IPv4 address replies in the "private" subnets when 
>> enabling stop-dns-rebind. For IPv6, it blocks only the IPv4-mapped address 
>> ranges matching said private subnets.
>>
>> Neither ULAs nor LLs (link-locals) are blocked in the IPv6 range. I agree 
>> this should be added.
>>
>> I can provide a patch for this, maybe tomorrow, if this is wanted. However, 
>> I'm afraid it might already be too late for 2.81, cfm. Simon.
> Apologies for that late reply. A patch sometime this week should be fine
> for 2.81.
>
> Simon.
>
>> Best,
>> Dominik
>>
>> Am 11. März 2020 00:47:02 MEZ schrieb buckh...@weibsvolk.org:
>>> I am using dnsmasq version pi-hole-2.80 as embedded in Pi-hole, with my
>>>
>>> router set as its sole upstream server (server=192.168.178.1#53).
>>>
>>> When evaluating DNS rebind protection provided by dnsmasq (by adding 
>>> stop-dns-rebind), I observed that dnsmasq correctly detects and 
>>> suppresses IPv4 answers, but fails to do the same for IPv6 ULA
>>> addresses 
>>> (maybe even for IPv6 in general).
>>>
>>> E.g. "nslookup wpad.fritz.box" from a Windows client results in the 
>>> following log entries:
>>>
>>> 09:58:08 dnsmasq[20063]: query[A] wpad.fritz.box from 192.168.178.200
>>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>>> 09:58:08 dnsmasq[20063]: possible DNS-rebind attack detected: 
>>> wpad.fritz.box
>>> 09:58:08 dnsmasq[20063]: query[] wpad.fritz.box from
>>> 192.168.178.200
>>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>>> 09:58:08 dnsmasq[20063]: reply wpad.fritz.box is 
>>> fd00::2ba:dcff:feca:fe00
>>>
>>> Shouldn't IPv6 ULA and link-local addresses also be suppressed?
>>> Does dnsmasq exhibit this behaviour by intention, or could this be seen
>>>
>>> as a possible gap in rebind protection?
>>>
>>> Kind regards,
>>>
>>> Buck
>>>
>>>
>>>
>>> ___
>>> Dnsmasq-discuss mailing list
>>> Dnsmasq-discuss@lists.thekelleys.org.uk
>>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>From f8640ee04cb79cc565ba54d24f1f16148adba0c9 Mon Sep 17 00:00:00 2001
From: DL6ER 
Date: Tue, 17 Mar 2020 21:40:24 +
Subject: [PATCH] Extend stop-dns-rebind to reject IPv6 link-local (LL) and
 unique local addresses (ULA). We also reject the loopback address if
 rebind-localhost-ok is NOT set.

Signed-off-by: DL6ER 
---
 man/dnsmasq.8 |  8 +---
 src/rfc1035.c | 28 +---
 2 files changed, 26 insertions(+), 10 deletions(-)

diff --git a/man/dnsmasq.8 b/man/dnsmasq.8
index 52a7df0..2032a37 100644
--- a/man/dnsmasq.8
+++ b/man/dnsmasq.8
@@ -395,11 +395,13 @@ were previously disabled.
 .TP
 .B --stop-dns-rebind
 Reject (and log) addresses from upstream nameservers which are in the
-private IP ranges. This blocks an attack where a browser behind a
-firewall is used to probe machines on the local network.
+private ranges. This blocks an attack where a browser behind a
+firewall is used to probe machines on the local network. For IPv6, the
+private range covers the IPv4-mapped addresses in private space plus
+all link-local (LL) and site-local (ULA) addresses.
 .TP
 .B --rebind-localhost-ok
-Exempt 127.0.0.0/8 from rebinding checks. This address range is
+Exempt 127.0.0.0/8 and ::1 from rebinding checks. This address range is
 returned by realtime black hole servers, so blocking it may disable
 these services.
 .TP 
diff --git a/src/rfc1035.c b/src/rfc1035.c
index f1edc45..fefe63d 100644
--- a/src/rfc1035.c
+++ b/src/rfc1035.c
@@ -843,17 +843,31 @@ int extract_addresses(struct dns_header *header, size_t qlen, char *name, time_t
 			  if ((flags & F_IPV4) &&
   private_net(addr.addr4, !option_bool(OPT_LOCAL_REBIND)))
 return 1;
-			  
-			  if ((flags & F_IPV6) &&
-  IN6_IS_ADDR_V4MAPPED())
+
+			  /* Block IPv4-mapped IPv6 addresses in private IPv4 address space */
+			  if (flags & F_IPV6)
 {
-  struct in_addr v4;
-  v4.s_addr = ((const uint32_t *) ())[3];
-  if (private_net(v4, !option_bool(OPT_LOCAL_REBIND)))
+  if (IN6_IS_ADDR_V4MAPPED())
+{
+  struct in_addr v4;
+  v4.s_addr = ((const uint32_t *) ())[3];
+  if (private_net(v4, !option_bool(OPT_LOCAL_REBIND)))
+	return 1;
+}
+
+  /* Check for link-local (LL) and site-local (ULA) IPv6 addresses */
+  if (IN6_IS_ADDR_LINKLOCAL() ||
+  IN6_IS_ADDR_SITELOCAL())
+return 1;
+
+  /* Check for the IPv6 loopback address (::1) when
+ option rebind-localhost-ok is NOT set */
+  if (!option_bool(OPT_LOCAL_REBIND) &&
+  IN6_IS_ADDR_LOOPBACK())
 return 1;
 }

Re: [Dnsmasq-discuss] 'tidying' unused variable warnings

2020-03-17 Thread Simon Kelley

I'm inclined not to take these, on the grounds that complicated
preprocessor stuff is a greater evil than false-positive warnings on
unusual platforms for build configurations.

Simon.


On 10/03/2020 10:25, Kevin 'ldir' Darbyshire-Bryant wrote:
> Hi Simon,
> 
> Feel free to throw these patches away!  Prompted by the recent unused var 
> warning fixes when building on macos, I pondered if the warning suppression 
> was a bit too global.  Some warnings are prompted by not including some code 
> (e.g. DHCPV6 vs no DHCPV6) and I wondered if the warning suppression should 
> be made (inverse) conditional.  It means that if some future change genuinely 
> ends up with us not using a variable we will get a warning.
> 
> Probably done at the same time as the whitespace cleanup, if at all :-)
> 
> Cheers,
> 
> Kevin D-B
> 
> gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

2020-03-17 Thread Simon Kelley



On 11/03/2020 07:55, Dominik wrote:
> Hey Buck,
> 
> dnsmasq blocks all IPv4 address replies in the "private" subnets when 
> enabling stop-dns-rebind. For IPv6, it blocks only the IPv4-mapped address 
> ranges matching said private subnets.
> 
> Neither ULAs nor LLs (link-locals) are blocked in the IPv6 range. I agree 
> this should be added.
> 
> I can provide a patch for this, maybe tomorrow, if this is wanted. However, 
> I'm afraid it might already be too late for 2.81, cfm. Simon.

Apologies for that late reply. A patch sometime this week should be fine
for 2.81.

Simon.

> 
> Best,
> Dominik
> 
> Am 11. März 2020 00:47:02 MEZ schrieb buckh...@weibsvolk.org:
>> I am using dnsmasq version pi-hole-2.80 as embedded in Pi-hole, with my
>>
>> router set as its sole upstream server (server=192.168.178.1#53).
>>
>> When evaluating DNS rebind protection provided by dnsmasq (by adding 
>> stop-dns-rebind), I observed that dnsmasq correctly detects and 
>> suppresses IPv4 answers, but fails to do the same for IPv6 ULA
>> addresses 
>> (maybe even for IPv6 in general).
>>
>> E.g. "nslookup wpad.fritz.box" from a Windows client results in the 
>> following log entries:
>>
>> 09:58:08 dnsmasq[20063]: query[A] wpad.fritz.box from 192.168.178.200
>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>> 09:58:08 dnsmasq[20063]: possible DNS-rebind attack detected: 
>> wpad.fritz.box
>> 09:58:08 dnsmasq[20063]: query[] wpad.fritz.box from
>> 192.168.178.200
>> 09:58:08 dnsmasq[20063]: forwarded wpad.fritz.box to 192.168.178.1
>> 09:58:08 dnsmasq[20063]: reply wpad.fritz.box is 
>> fd00::2ba:dcff:feca:fe00
>>
>> Shouldn't IPv6 ULA and link-local addresses also be suppressed?
>> Does dnsmasq exhibit this behaviour by intention, or could this be seen
>>
>> as a possible gap in rebind protection?
>>
>> Kind regards,
>>
>> Buck
>>
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

2020-03-17 Thread Simon Kelley



On 10/03/2020 14:25, Petr Menšík wrote:


> That is a pity. Is there anything I can help to include it in 2.81? If
> you have any objections to part of it or whole concept, please say so. I
> would rebase the change again.
> 
> I was added to Fedora as downstream in late summer [1], have not yet
> seen any new bug related to it. It seems not broken entirely, maybe it
> just works.
> 
> Anyway, if there is anything I can do, please let me know. Feel free to
> add me into CC.
>>
>

Could you get me a rebased patch this week?

Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] What it is

2020-03-17 Thread Geert Stappers

On Tue, Mar 17, 2020 at 09:08:15AM -0500, Sasha Litvak wrote:
> On Tue, Mar 17, 2020, 1:48 AM Geert Stappers wrote:
> > On Mon, Mar 16, 2020 at 08:31:17PM -0500, Sasha Litvak wrote:
> > >   ...
> > > We are using dnsmasq on our servers as a caching dns solution.
> > >   ...
> > > dnsmasq handles resolution of .consul domain directly but the DNS
> > > server itself also forwards .consul to consul servers.
> > >   ...
> >
> > $ host -t ns org
> > org name server d0.org.afilias-nst.org.
> > org name server b2.org.afilias-nst.org.
> > org name server a0.org.afilias-nst.info.
> > org name server a2.org.afilias-nst.info.
> > org name server b0.org.afilias-nst.org.
> > org name server c0.org.afilias-nst.info.
> > $ host -t ns consul
> > Host consul not found: 3(NXDOMAIN)
> > $
> >
> 
> What is the meaning of this?

Choose from:
 * Invitation to tell more about toplevel domain ".consul"
 * Confirmation that your posting has been seen
 * Thank you for testing the mailinglist [1]
 * Welcome, do known that you are not ignored 

> 
> Geert,


I'm on the mailinglist, no need for getting personal.



Regards
Geert Stappers

[1] Visit 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/date.html#start
and note that are  5  days silence between
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013884.html
and 
http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2020q1/013885.html
It's been a while ago we, this mailinglist, had such a long silence
-- 
Silence is hard to parse

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

2020-03-17 Thread Simon Kelley

On 17/03/2020 01:31, Sasha Litvak wrote:
> I couldn't find a specific answer anywhere so hopefully someone has a
> clue on this list
> 
> We are using dnsmasq on our servers as a caching dns solution.
> 
> Most of our domains are resolved by a wildcard record like this
> 
> $TTL 3600   ; 1 hour
> A   10.10.10.23
> $ORIGIN example.net.
> *   CNAME   excontainers
> excontainersCNAME   exservice.service.consul
> 
> dnsmasq handles resolution of .consul domain directly but the DNS
> server itself also forwards .consul to consul servers.
^


Can you elaborate? How does dnsmasq handle the resolution of the .consul
domain? If you have something like

10.0.48.13 exservice.service.consul

in /etc/hosts

then that defines, effectively, an immortal record for
exservice.service.consul, so a CNAME chain of two records, each with a
TTL of one hour, would result in that answer being returned for an hour.

> 
> I added min-ttl 5s to decrease the number of queries to consul
> 
> So when I do dig foo.example.net  @127.0.0.1 I get
> 
> foo.example.net. 3600 IN CNAME excontainers.example.net.
> excontainers.example.net. 3600 IN CNAME exservice.service.consul.
> exservice.service.consul. 5 IN A 10.0.48.13

This might be misleading: is you do that query to dnsmasq with a clean
cache, it will forward the query upstream, and return the complete
result it gets, including the A record with a 5s TTL, but further
queries from the cache would return a 0 (infinite) TTL for the A record
of it's defined locally.

The fix for this is to define the .consul A record using --host-record,
which allows you to specify the 5s TTL.



> 
> Now we often need to migrate subdomains by pointing them to a
> different consul cluster.  So our script uses nsupdate and creates a
> dynamic DNS record resulting in this reply
> 
> foo.example.net. 60 IN CNAME  exservice2.service.consul.
>  exservice2.service.consul. 5 IN A 10.0.48.35
> 
> So we have a record that is more explicit and it takes precedence over
> wild card.   On servers with little traffic, domain switch happens
> within a few seconds, but on the main busy server with 100s of queries
> a second, it takes an hour for dnsmasq to change its cache.  We see
> dnsmasq sending requests to the DNS server getting correct new records
> but still sending the old cached records to a client.
> 
> When we are going back from distinct to default wild card (removing
> distinct record in DNS) cache change happens almost immediately (a
> couple of seconds) regardless of how busy the server is.
> 
> Sorry for the long description but I would like to find out a reason
> why during switching from wild card to more explicit record dnsmasq
> cache update takes such a long time.
> 

I'm guessing at exactly what's going on here: more details would be
useful, but if I guessed right, that's the solution.


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

2020-03-17 Thread Sasha Litvak

Geert,

What is the meaning of this?

On Tue, Mar 17, 2020, 1:48 AM Geert Stappers  wrote:

> On Mon, Mar 16, 2020 at 08:31:17PM -0500, Sasha Litvak wrote:
> > I couldn't find a specific answer anywhere so hopefully someone has a
> > clue on this list
> >
> > We are using dnsmasq on our servers as a caching dns solution.
> >
> > Most of our domains are resolved by a wildcard record like this
> >
> > $TTL 3600   ; 1 hour
> > A   10.10.10.23
> > $ORIGIN example.net.
> > *   CNAME   excontainers
> > excontainersCNAME   exservice.service.consul
> >
> > dnsmasq handles resolution of .consul domain directly but the DNS
> > server itself also forwards .consul to consul servers.
> >
> > I added min-ttl 5s to decrease the number of queries to consul
> >
> > So when I do dig foo.example.net  @127.0.0.1 I get
> >
> > foo.example.net. 3600 IN CNAME excontainers.example.net.
> > excontainers.example.net. 3600 IN CNAME exservice.service.consul.
> > exservice.service.consul. 5 IN A 10.0.48.13
> >
> > Now we often need to migrate subdomains by pointing them to a
> > different consul cluster.  So our script uses nsupdate and creates a
> > dynamic DNS record resulting in this reply
> >
> > foo.example.net. 60 IN CNAME  exservice2.service.consul.
> >  exservice2.service.consul. 5 IN A 10.0.48.35
> >
> > So we have a record that is more explicit and it takes precedence over
> > wild card.   On servers with little traffic, domain switch happens
> > within a few seconds, but on the main busy server with 100s of queries
> > a second, it takes an hour for dnsmasq to change its cache.  We see
> > dnsmasq sending requests to the DNS server getting correct new records
> > but still sending the old cached records to a client.
> >
> > When we are going back from distinct to default wild card (removing
> > distinct record in DNS) cache change happens almost immediately (a
> > couple of seconds) regardless of how busy the server is.
> >
> > Sorry for the long description but I would like to find out a reason
> > why during switching from wild card to more explicit record dnsmasq
> > cache update takes such a long time.
>
> $ host -t ns org
> org name server d0.org.afilias-nst.org.
> org name server b2.org.afilias-nst.org.
> org name server a0.org.afilias-nst.info.
> org name server a2.org.afilias-nst.info.
> org name server b0.org.afilias-nst.org.
> org name server c0.org.afilias-nst.info.
> $ host -t ns consul
> Host consul not found: 3(NXDOMAIN)
> $
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

2020-03-17 Thread Sasha Litvak

Geert,

Just in case,  .consul is not a registered domain name.  It is assigned
with Hashicorp consul service discovery product and is internal to us.
Whence forwarders.

On Tue, Mar 17, 2020, 9:08 AM Sasha Litvak 
wrote:

> Geert,
>
> What is the meaning of this?
>
> On Tue, Mar 17, 2020, 1:48 AM Geert Stappers  wrote:
>
>> On Mon, Mar 16, 2020 at 08:31:17PM -0500, Sasha Litvak wrote:
>> > I couldn't find a specific answer anywhere so hopefully someone has a
>> > clue on this list
>> >
>> > We are using dnsmasq on our servers as a caching dns solution.
>> >
>> > Most of our domains are resolved by a wildcard record like this
>> >
>> > $TTL 3600   ; 1 hour
>> > A   10.10.10.23
>> > $ORIGIN example.net.
>> > *   CNAME   excontainers
>> > excontainersCNAME   exservice.service.consul
>> >
>> > dnsmasq handles resolution of .consul domain directly but the DNS
>> > server itself also forwards .consul to consul servers.
>> >
>> > I added min-ttl 5s to decrease the number of queries to consul
>> >
>> > So when I do dig foo.example.net  @127.0.0.1 I get
>> >
>> > foo.example.net. 3600 IN CNAME excontainers.example.net.
>> > excontainers.example.net. 3600 IN CNAME exservice.service.consul.
>> > exservice.service.consul. 5 IN A 10.0.48.13
>> >
>> > Now we often need to migrate subdomains by pointing them to a
>> > different consul cluster.  So our script uses nsupdate and creates a
>> > dynamic DNS record resulting in this reply
>> >
>> > foo.example.net. 60 IN CNAME  exservice2.service.consul.
>> >  exservice2.service.consul. 5 IN A 10.0.48.35
>> >
>> > So we have a record that is more explicit and it takes precedence over
>> > wild card.   On servers with little traffic, domain switch happens
>> > within a few seconds, but on the main busy server with 100s of queries
>> > a second, it takes an hour for dnsmasq to change its cache.  We see
>> > dnsmasq sending requests to the DNS server getting correct new records
>> > but still sending the old cached records to a client.
>> >
>> > When we are going back from distinct to default wild card (removing
>> > distinct record in DNS) cache change happens almost immediately (a
>> > couple of seconds) regardless of how busy the server is.
>> >
>> > Sorry for the long description but I would like to find out a reason
>> > why during switching from wild card to more explicit record dnsmasq
>> > cache update takes such a long time.
>>
>> $ host -t ns org
>> org name server d0.org.afilias-nst.org.
>> org name server b2.org.afilias-nst.org.
>> org name server a0.org.afilias-nst.info.
>> org name server a2.org.afilias-nst.info.
>> org name server b0.org.afilias-nst.org.
>> org name server c0.org.afilias-nst.info.
>> $ host -t ns consul
>> Host consul not found: 3(NXDOMAIN)
>> $
>>
>>
>> ___
>> Dnsmasq-discuss mailing list
>> Dnsmasq-discuss@lists.thekelleys.org.uk
>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>>
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

2020-03-17 Thread Geert Stappers

On Mon, Mar 16, 2020 at 08:31:17PM -0500, Sasha Litvak wrote:
> I couldn't find a specific answer anywhere so hopefully someone has a
> clue on this list
> 
> We are using dnsmasq on our servers as a caching dns solution.
> 
> Most of our domains are resolved by a wildcard record like this
> 
> $TTL 3600   ; 1 hour
> A   10.10.10.23
> $ORIGIN example.net.
> *   CNAME   excontainers
> excontainersCNAME   exservice.service.consul
> 
> dnsmasq handles resolution of .consul domain directly but the DNS
> server itself also forwards .consul to consul servers.
> 
> I added min-ttl 5s to decrease the number of queries to consul
> 
> So when I do dig foo.example.net  @127.0.0.1 I get
> 
> foo.example.net. 3600 IN CNAME excontainers.example.net.
> excontainers.example.net. 3600 IN CNAME exservice.service.consul.
> exservice.service.consul. 5 IN A 10.0.48.13
> 
> Now we often need to migrate subdomains by pointing them to a
> different consul cluster.  So our script uses nsupdate and creates a
> dynamic DNS record resulting in this reply
> 
> foo.example.net. 60 IN CNAME  exservice2.service.consul.
>  exservice2.service.consul. 5 IN A 10.0.48.35
> 
> So we have a record that is more explicit and it takes precedence over
> wild card.   On servers with little traffic, domain switch happens
> within a few seconds, but on the main busy server with 100s of queries
> a second, it takes an hour for dnsmasq to change its cache.  We see
> dnsmasq sending requests to the DNS server getting correct new records
> but still sending the old cached records to a client.
> 
> When we are going back from distinct to default wild card (removing
> distinct record in DNS) cache change happens almost immediately (a
> couple of seconds) regardless of how busy the server is.
> 
> Sorry for the long description but I would like to find out a reason
> why during switching from wild card to more explicit record dnsmasq
> cache update takes such a long time.

$ host -t ns org
org name server d0.org.afilias-nst.org.
org name server b2.org.afilias-nst.org.
org name server a0.org.afilias-nst.info.
org name server a2.org.afilias-nst.info.
org name server b0.org.afilias-nst.org.
org name server c0.org.afilias-nst.info.
$ host -t ns consul
Host consul not found: 3(NXDOMAIN)
$ 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

Re: [Dnsmasq-discuss] 'tidying' unused variable warnings

Re: [Dnsmasq-discuss] stop-dns-rebind and IPv6

Re: [Dnsmasq-discuss] [PATCH] DHCPv6 - List or Range reservation for single host

Re: [Dnsmasq-discuss] What it is

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

Re: [Dnsmasq-discuss] TTL in nested wild card CNAME

11 matches

Site Navigation

Mail list logo

Footer information