Re: [Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Kevin Darbyshire-Bryant]

> On 5 Jul 2021, at 21:12, Simon Kelley  wrote:
> 
> On 05/07/2021 19:31, Kevin Darbyshire-Bryant wrote:
>> 
>> 
>>> On 5 Jul 2021, at 16:53, Dominik DL6ER  wrote:
>>> 
>>> Hey Simon,
>>> 
>>> the current dnsmasq master version contains a bug rewriting all
>>> NXDOMAIN replies from upstream with NOERROR.
>>> 
>>> The error has been introduced in commit
>>> d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
>>> ultimately caused by
>> 
>> Oooh what fun! :-)
>> 
>> Attached patch fixes for me
>> 
>> 
> 
> That's not the correct fix.


Goes to show how much I really know :-D

At least I got one fix right.

Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A



signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Simon Kelley]

On 05/07/2021 16:53, Dominik DL6ER wrote:
> Hey Simon,
> 
> the current dnsmasq master version contains a bug rewriting all
> NXDOMAIN replies from upstream with NOERROR.
> 
> The error has been introduced in commit
> d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
> ultimately caused by
> 
>> lookup_domain(daemon->namebuff, F_CONFIG, NULL, NULL)
> 
> at line 668/669 returning 1 when it shouldn't.
> 
> How to reproduce:
> 
> 1. Start dnsmasq
> 2. Query a non-existing domain such as "google.comxxx".
> 
> dnsmasq 6860cf932baeaf1c2f09c2a58e38be189ae394de (and older) replies
> with NXDOMAN (as expected)
> dnsmasq d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (and newer) replies
> incorrectly with NOERROR and sets the AA bit.
> 
> Let me know if you need any further information.
> 

Nice catch, thanks. I believe that
df25f204ba822c9c00bc9372c85da58e9aff6e86
should fix this.

Cheers,

Simon.

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

Re: [Dnsmasq-discuss] blocklists, blocking servers, rebind attacks & general aaarrggh

[Simon Kelley]

On 05/07/2021 12:34, Rockwell, Dennis wrote:
> I have a situation for which extending those features would be the exact
> solution.
> 


The code is there at the bleeding edge now.

https://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=5bcca1219af8bad328352d7a656bc9b1e9d61b92


Simon.

> Dennis
> 
> On Jul 4, 2021 5:21 PM, Simon Kelley  wrote:
> On 04/07/2021 21:32, Simon Kelley wrote:
>> On 30/06/2021 10:40, Kevin Darbyshire-Bryant wrote:
>>> As an ‘experiment’ I tried switching from my own local ‘adblocking’ 
>>> solution to using an upstream adblocking resolver, eg. cloudflare’s 1.1.1.2 
>>> or 1.1.1.3 service.
>>>
>>> The local adblock solution uses (multiple!) ‘—address/naughtydomain.foo/‘ 
>>> lines that cause dnsmasq to return ’NXDOMAIN’ - fair enough.
>>>
>>> Cloudflare (& others I’ve tested) return ‘0.0.0.0’ or ‘::’ instead, not 
>>> NXDOMAIN.  With rebind protection enabled (--stop-dns-rebind), even with 
>>> --rebind-localhost-ok I get log ’spam’ warning of possible rebind attacks 
>>> due to the ‘0.0.0.0’ address response.
>>>
>>> I can turn ‘0.0.0.0’ into NXDOMAIN by using --bogus-nxdomain=0.0.0.0 and 
>>> that works fine and stops the rebind warnings.  However ‘::’ still gets 
>>> through if an  is specifically requested.  There is no equivalent 
>>> bogus-nxdomain for ipv6.
>>>
>>> The dnsmasq manpage (under —address) advised "Note that NULL addresses 
>>> [0.0.0.0 & ::] normally work in the same way as localhost, so beware that 
>>> clients looking up these names are likely to end up talking to themselves.” 
>>>  Ideally then 0.0.0.0 & :: would both be turned into NXDOMAIN.
>>>
>>> Should ‘0.0.0.0/32’ be excluded from the rebind checks/accepted by the 
>>> ‘—rebind-localhost-ok’ option.  It’s currently being caught by a 
>>> ‘0.0.0.0/8’ check.
>>>
>> 
>> I looked at the code that determines private addresses for --bogus-priv
>> and rebind: It's a bit unruly for IPv6, so I've rationalised things and
>> included :: and 0.0.0.0 in the --rebind-localhost-ok coverage, which at
>> least avoids the log spam.
>> 
>> 
>> I wonder if bogus-nxdomain should be extended to IPv6, or we could add
>> another option which is the equivalent of
>> 
>> bogus-nxdomain=0.0.0.0,::
>> 
>> Or both.
>> 
>> Simon.
>> 
> 
> AT the least, bogus-nxdomain should be extended to IPv6, that would
> extend --ignore-address too, for free.
> 
> 
> In progress.
> 
> Simon.
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> https://urldefense.com/v3/__https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss__;!!GjvTz_vk!G5VhBaG2LcDjkUOkXosk2wo1PHeuWlbg5rEhJreyBTz0RI4-Cn81DdAnrqJqq6o$
> 
> 


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

Re: [Dnsmasq-discuss] blocklists, blocking servers, rebind attacks & general aaarrggh

[Simon Kelley]

On 05/07/2021 09:20, Kevin Darbyshire-Bryant wrote:
> 
>> I looked at the code that determines private addresses for --bogus-priv
>> and rebind: It's a bit unruly for IPv6, so I've rationalised things and
>> included :: and 0.0.0.0 in the --rebind-localhost-ok coverage, which at
>> least avoids the log spam.
>>
>>
>> I wonder if bogus-nxdomain should be extended to IPv6, or we could add
>> another option which is the equivalent of
>>
>> bogus-nxdomain=0.0.0.0,::
>>
>> Or both.
> 
> Thanks Simon, definitely looks more rational, will give it a try.
> 
> Incidentally, is there a typo in a92c6d77dcd475579c39bdff141f5eb128e2a048 ? - 
> I think you mean to de-ref the pointer, not compare the pointer.
> 
> 
> diff --git a/src/domain-match.c b/src/domain-match.c
> index f82bbdb..97ae9c5 100644
> --- a/src/domain-match.c
> +++ b/src/domain-match.c
> @@ -591,7 +591,7 @@ int add_update_server(int flags,
>else if (*domain == '*')
>  {
>domain++;
> -  if (domain != 0)
> +  if (*domain)
> flags |= SERV_WILDCARD;
>  }
> 
> 

Thanks for catching that. Patch applied.


Simon.


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

Re: [Dnsmasq-discuss] DHCP lease hostname with multiple hosts of the same name

[Simon Kelley]

On 05/07/2021 12:49, Petr Menšík wrote:
> Hi,
> 
> more below.
> 
> On 7/2/21 6:18 PM, Simon Kelley wrote:
>> On 02/07/2021 15:42, Petr Menšík wrote:
>>> Hi,
>>>
>>> current dnsmasq has a bug [1] in handling hostname setting. When two
>>> hosts request equal hostname, dnsmasq will reset name in previous lease
>>> and change registered name to the most recent requestor adddress.
>>>
>>> It does not work well with lease-script used by libvirt, because when
>>> lease name is reset, such change is not propagated to script. It changes
>>> only when dnsmasq is restarted. It does not load leases the same way,
>>> only one of leases would contain name.
>>>
>>> I have attached simple fix to propagate change to lease script. It would
>>> make lease handler report correct state and it works nice with libvirt.
>>>
>>> I am not sure current algorithm is the best one for leases reservation.
>>> Replacement of previous lease hostname works even without restart after
>>> attached change.
>>>
>>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1910621
>>>
>>>
>> Patch applied, that's clearly the correct thing to do, thanks.
> You're welcome.
>> As to why the handling of names is the way it is, it's been a very long
>> time since that was designed, but it was designed. It takes into account
>> that the most likely case is that a host gets unplugged from a network
>> and plugged into a new one. (or changes SSID), or changes from a wired
>> to a wireless network (and hence changes MAC address). The most sensible
>> thing to do in that case is to assume that the old lease is defunct (at
>> least as far as naming is concerned, the address reservation persists)
>> and give the name to the new one.
> 
> I have noticed it behaves different way with IPv6 leases with DUID
> present. I think it may protect clients who sent DUID even over IPv4. If
> lease_tmp were registered also with client id, we can expect the same
> host would send DUID also from another interface with another hw address.
> 
> It might then prevent clients with different DUID from stealing the
> name. It would not allow the same machine to keep the name with dualboot
> for example. Might be also issue on netboot, if DUID does not match. Who
> needs name registration on netboot? Does it ever send hostname during
> netboot? Would it make sense for IPv4 leases to implement the same
> algorithm as on IPv6 and set both IP addresses on the name, until
> previous lease expires?
> 
> It would work fine with any application supporting happy eyeballs
> algorithm and would indicate there is clash for the name. It would allow
> connecting to both wired and wireless interface at the same time. I
> think there is no way to set higher priority of wired interface lease in
> a DHCP request. It just fights for the name now. With short lease time
> it would make name address constantly changing.
> 
>> It's not secure, but assigning DNS names based information supplied by
>> DHCP is inherently insecure anyway. We do take care to honour explicit
>> assignment of names to MAC addresses or client-ids in the dnsmasq
>> configuration, so that random hosts can't hijack names in that case.
> 
> True. I just never considered DHCP registered names are still without
> any guarantee just like mDNS. Maybe even worse, because mdns has a
> protocol to avoid and solve conflicts. Even when there is a server,
> which can act as an arbiter, it is not protected. Not even by first
> come, first acquired solution. No one demands change anyway, this is
> just my thinking whether current implementation is the best one.
> 


Change, and risk breaking some installation somewhere that's been
working since 2005, or leave alone, and don't work as well for new
applications. The joys of a 20+ year-old codebase!


Simon.

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

Re: [Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Simon Kelley]

On 05/07/2021 19:31, Kevin Darbyshire-Bryant wrote:
> 
> 
>> On 5 Jul 2021, at 16:53, Dominik DL6ER  wrote:
>>
>> Hey Simon,
>>
>> the current dnsmasq master version contains a bug rewriting all
>> NXDOMAIN replies from upstream with NOERROR.
>>
>> The error has been introduced in commit
>> d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
>> ultimately caused by
> 
> Oooh what fun! :-)
> 
> Attached patch fixes for me
> 
> 

That's not the correct fix.

check_for_local_domain() returns true for names which are handled and
looked up in the cache, from /etc/hosts, or configuration, like
--host-record.

lookup_domain(..., F_CONFIG, .) checks for addresses associated with
whole domains, so if the query is www.example.com and there exists
--address=/example.com/1.2.3.4

so OR is the correct conjunction. The problem was that the new code in
lookup_domain() got the wrong answer sometimes.

df25f204ba822c9c00bc9372c85da58e9aff6e86 fixes.



Cheers,

Simon.


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

Re: [Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Kevin Darbyshire-Bryant]

> On 5 Jul 2021, at 16:53, Dominik DL6ER  wrote:
> 
> Hey Simon,
> 
> the current dnsmasq master version contains a bug rewriting all
> NXDOMAIN replies from upstream with NOERROR.
> 
> The error has been introduced in commit
> d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
> ultimately caused by

Oooh what fun! :-)

Attached patch fixes for me


Cheers,

Kevin D-B

gpg: 012C ACB2 28C6 C53E 9775  9123 B3A2 389B 9DE2 334A


0001-fix-lookups.patch
Description: Binary data


signature.asc
Description: Message signed with OpenPGP
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

[Dnsmasq-discuss] [BUG] dnsmasq rewriting NXDOMAIN to NOERROR

[Dominik DL6ER]

Hey Simon,

the current dnsmasq master version contains a bug rewriting all
NXDOMAIN replies from upstream with NOERROR.

The error has been introduced in commit
d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (see attached diff) and is
ultimately caused by

> lookup_domain(daemon->namebuff, F_CONFIG, NULL, NULL)

at line 668/669 returning 1 when it shouldn't.

How to reproduce:

1. Start dnsmasq
2. Query a non-existing domain such as "google.comxxx".

dnsmasq 6860cf932baeaf1c2f09c2a58e38be189ae394de (and older) replies
with NXDOMAN (as expected)
dnsmasq d0ae3f5a4dc094e8fe2a3c607028c1c59f42f473 (and newer) replies
incorrectly with NOERROR and sets the AA bit.

Let me know if you need any further information.

Best regards,
Dominik
diff --git a/src/domain-match.c b/src/domain-match.c
index 85ce76e..f7bb506 100644
--- a/src/domain-match.c
+++ b/src/domain-match.c
@@ -75,6 +75,8 @@ void build_server_array(void)
A flag of F_DNSSECOK returns a DNSSEC capable server only and
also disables NODOTS servers from consideration.
A flag of F_DOMAINSRV returns a domain-specific server only.
+   A flag of F_CONFIG returns anything that generates a local
+   reply of IPv4 or IPV6.
return 0 if nothing found, 1 otherwise.
 */
 int lookup_domain(char *qdomain, int flags, int *lowout, int *highout)
@@ -85,8 +87,6 @@ int lookup_domain(char *qdomain, int flags, int *lowout, int *highout)
   int nlow = 0, nhigh = 0;
   char *cp;
 
-  int compares = 0;
-
   /* may be no configured servers. */
   if (daemon->serverarraysz == 0)
 return 0;
@@ -121,8 +121,6 @@ int lookup_domain(char *qdomain, int flags, int *lowout, int *highout)
 	{
 	  try = (low + high)/2;
 
-	  compares++;
-
 	  if ((rc = order(qdomain, leading_dot, qlen, daemon->serverarray[try])) == 0)
 	break;
 	  
@@ -186,8 +184,6 @@ int lookup_domain(char *qdomain, int flags, int *lowout, int *highout)
   qdomain += crop_query;
 }
 
-  printf("compares: %d\n", compares);
-  
   /* domain has no dots, and we have at least one server configured to handle such,
  These servers always sort to the very end of the array. 
  A configured server eg server=/lan/ will take precdence. */
@@ -240,47 +236,56 @@ int filter_servers(int seed, int flags, int *lowout, int *highout)
  
  See which of those match our query in that priority order and narrow (low, high) */
 
-  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_6ADDR); i++);
-
-  if (i != nlow && (flags & F_IPV6))
+#define SERV_LOCAL_ADDRESS (SERV_6ADDR | SERV_4ADDR | SERV_ALL_ZEROS)
+  
+  for (i = nlow; (flags & F_CONFIG) && i < nhigh && (daemon->serverarray[i]->flags & SERV_LOCAL_ADDRESS); i++);
+  
+  if (i != nlow)
 nhigh = i;
   else
 {
-   nlow = i;
-
-   for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_4ADDR); i++);
+  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_6ADDR); i++);
   
-  if (i != nlow && (flags & F_IPV4))
+  if (i != nlow && (flags & F_IPV6))
 	nhigh = i;
   else
 	{
 	  nlow = i;
 	  
-	  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_ALL_ZEROS); i++);
+	  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_4ADDR); i++);
 	  
-	  if (i != nlow && (flags & (F_IPV4 | F_IPV6)))
+	  if (i != nlow && (flags & F_IPV4))
 	nhigh = i;
 	  else
 	{
 	  nlow = i;
 	  
-	  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_LITERAL_ADDRESS); i++);
+	  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_ALL_ZEROS); i++);
 	  
-	  /* --local=/domain/, only return if we don't need a server. */
-	  if (i != nlow && !(flags & (F_DNSSECOK | F_DOMAINSRV | F_SERVER)))
+	  if (i != nlow && (flags & (F_IPV4 | F_IPV6)))
 		nhigh = i;
 	  else
 		{
 		  nlow = i;
-		  /* If we want a server that can do DNSSEC, and this one can't, 
-		 return nothing. */
-		  if ((flags & F_DNSSECOK) && !(daemon->serverarray[nlow]->flags & SERV_DO_DNSSEC))
-		nlow = nhigh;
+		  
+		  for (i = nlow; i < nhigh && (daemon->serverarray[i]->flags & SERV_LITERAL_ADDRESS); i++);
+		  
+		  /* --local=/domain/, only return if we don't need a server. */
+		  if (i != nlow && !(flags & (F_DNSSECOK | F_DOMAINSRV | F_SERVER)))
+		nhigh = i;
+		  else
+		{
+		  nlow = i;
+		  /* If we want a server that can do DNSSEC, and this one can't, 
+			 return nothing. */
+		  if ((flags & F_DNSSECOK) && !(daemon->serverarray[nlow]->flags & SERV_DO_DNSSEC))
+			nlow = nhigh;
+		}
 		}
 	}
 	}
 }
-
+  
   *lowout = nlow;
   *highout = nhigh;
   
@@ -291,7 +296,7 @@ int is_local_answer(time_t now, int first, char *name)
 {
   int flags = 0;
   int rc = 0;
-
+  
   if ((flags = daemon->serverarray[first]->flags) & SERV_LITERAL_ADDRESS)
 {
   if (flags & SERV_4ADDR)
@@ -301,7 +306,19 @@ int is_local_answer(time_t now, int first, char *name)
   else if (flags & SERV_ALL_ZEROS)
 	rc = 

Re: [Dnsmasq-discuss] DHCP lease hostname with multiple hosts of the same name

[Petr Menšík]

Hi,

more below.

On 7/2/21 6:18 PM, Simon Kelley wrote:
> On 02/07/2021 15:42, Petr Menšík wrote:
>> Hi,
>>
>> current dnsmasq has a bug [1] in handling hostname setting. When two
>> hosts request equal hostname, dnsmasq will reset name in previous lease
>> and change registered name to the most recent requestor adddress.
>>
>> It does not work well with lease-script used by libvirt, because when
>> lease name is reset, such change is not propagated to script. It changes
>> only when dnsmasq is restarted. It does not load leases the same way,
>> only one of leases would contain name.
>>
>> I have attached simple fix to propagate change to lease script. It would
>> make lease handler report correct state and it works nice with libvirt.
>>
>> I am not sure current algorithm is the best one for leases reservation.
>> Replacement of previous lease hostname works even without restart after
>> attached change.
>>
>> 1. https://bugzilla.redhat.com/show_bug.cgi?id=1910621
>>
>>
> Patch applied, that's clearly the correct thing to do, thanks.
You're welcome.
> As to why the handling of names is the way it is, it's been a very long
> time since that was designed, but it was designed. It takes into account
> that the most likely case is that a host gets unplugged from a network
> and plugged into a new one. (or changes SSID), or changes from a wired
> to a wireless network (and hence changes MAC address). The most sensible
> thing to do in that case is to assume that the old lease is defunct (at
> least as far as naming is concerned, the address reservation persists)
> and give the name to the new one.

I have noticed it behaves different way with IPv6 leases with DUID
present. I think it may protect clients who sent DUID even over IPv4. If
lease_tmp were registered also with client id, we can expect the same
host would send DUID also from another interface with another hw address.

It might then prevent clients with different DUID from stealing the
name. It would not allow the same machine to keep the name with dualboot
for example. Might be also issue on netboot, if DUID does not match. Who
needs name registration on netboot? Does it ever send hostname during
netboot? Would it make sense for IPv4 leases to implement the same
algorithm as on IPv6 and set both IP addresses on the name, until
previous lease expires?

It would work fine with any application supporting happy eyeballs
algorithm and would indicate there is clash for the name. It would allow
connecting to both wired and wireless interface at the same time. I
think there is no way to set higher priority of wired interface lease in
a DHCP request. It just fights for the name now. With short lease time
it would make name address constantly changing.

> It's not secure, but assigning DNS names based information supplied by
> DHCP is inherently insecure anyway. We do take care to honour explicit
> assignment of names to MAC addresses or client-ids in the dnsmasq
> configuration, so that random hosts can't hijack names in that case.

True. I just never considered DHCP registered names are still without
any guarantee just like mDNS. Maybe even worse, because mdns has a
protocol to avoid and solve conflicts. Even when there is a server,
which can act as an arbiter, it is not protected. Not even by first
come, first acquired solution. No one demands change anyway, this is
just my thinking whether current implementation is the best one.

> Cheers,
>
> Simon

Cheers,

Petr

-- 
Petr Menšík
Software Engineer
Red Hat, http://www.redhat.com/
email: pemen...@redhat.com
PGP: DFCF908DB7C87E8E529925BC4931CA5B6C9FC5CB




OpenPGP_signature
Description: OpenPGP digital signature
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] blocklists, blocking servers, rebind attacks & general aaarrggh

[Rockwell, Dennis via Dnsmasq-discuss]

I have a situation for which extending those features would be the exact 
solution.

Dennis

On Jul 4, 2021 5:21 PM, Simon Kelley  wrote:
On 04/07/2021 21:32, Simon Kelley wrote:
> On 30/06/2021 10:40, Kevin Darbyshire-Bryant wrote:
>> As an ‘experiment’ I tried switching from my own local ‘adblocking’ solution 
>> to using an upstream adblocking resolver, eg. cloudflare’s 1.1.1.2 or 
>> 1.1.1.3 service.
>>
>> The local adblock solution uses (multiple!) ‘—address/naughtydomain.foo/‘ 
>> lines that cause dnsmasq to return ’NXDOMAIN’ - fair enough.
>>
>> Cloudflare (& others I’ve tested) return ‘0.0.0.0’ or ‘::’ instead, not 
>> NXDOMAIN.  With rebind protection enabled (--stop-dns-rebind), even with 
>> --rebind-localhost-ok I get log ’spam’ warning of possible rebind attacks 
>> due to the ‘0.0.0.0’ address response.
>>
>> I can turn ‘0.0.0.0’ into NXDOMAIN by using --bogus-nxdomain=0.0.0.0 and 
>> that works fine and stops the rebind warnings.  However ‘::’ still gets 
>> through if an  is specifically requested.  There is no equivalent 
>> bogus-nxdomain for ipv6.
>>
>> The dnsmasq manpage (under —address) advised "Note that NULL addresses 
>> [0.0.0.0 & ::] normally work in the same way as localhost, so beware that 
>> clients looking up these names are likely to end up talking to themselves.”  
>> Ideally then 0.0.0.0 & :: would both be turned into NXDOMAIN.
>>
>> Should ‘0.0.0.0/32’ be excluded from the rebind checks/accepted by the 
>> ‘—rebind-localhost-ok’ option.  It’s currently being caught by a ‘0.0.0.0/8’ 
>> check.
>>
>
> I looked at the code that determines private addresses for --bogus-priv
> and rebind: It's a bit unruly for IPv6, so I've rationalised things and
> included :: and 0.0.0.0 in the --rebind-localhost-ok coverage, which at
> least avoids the log spam.
>
>
> I wonder if bogus-nxdomain should be extended to IPv6, or we could add
> another option which is the equivalent of
>
> bogus-nxdomain=0.0.0.0,::
>
> Or both.
>
> Simon.
>

AT the least, bogus-nxdomain should be extended to IPv6, that would
extend --ignore-address too, for free.


In progress.

Simon.

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://urldefense.com/v3/__https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss__;!!GjvTz_vk!G5VhBaG2LcDjkUOkXosk2wo1PHeuWlbg5rEhJreyBTz0RI4-Cn81DdAnrqJqq6o$
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
https://lists.thekelleys.org.uk/cgi-bin/mailman/listinfo/dnsmasq-discuss