Re: [Dnsmasq-discuss] how to configure lot of static routes

2015-06-30 Thread Maciej Soltysiak
On Tue, Jun 30, 2015 at 3:24 PM, Albert ARIBAUD albert.arib...@free.fr
wrote:

 Bonjour Michał,

 Le Tue, 30 Jun 2015 13:54:11 +0200, Michał Lipka michal@lipka.email a
 écrit :

  2015-06-30 12:10 GMT+02:00 Maciej Soltysiak mac...@soltysiak.com:
 
   On Tue, Jun 30, 2015 at 4:03 AM, wkitt...@gmail.com 
 wkitt...@gmail.com
   wrote:
  
  
   On 06/29/2015 04:01 PM, Michał Lipka wrote:
  
  
   2015-06-25 16:02 GMT+02:00 wkitt...@gmail.com
   does breaking the line work?
  
   eg:
   dhcp-option=249,10.0.0.1/32,1.2.3.4,192.168.13.15/32,1.2.3.4
   http://10.0.0.1/32,1.2.3.4,192.168.13.15/32,1.2.3.4, \
   192.168.13.16/32,1.2.3.4,192.168.13.17/32,1.2.3.4
   http://192.168.13.16/32,1.2.3.4,192.168.13.17/32,1.2.3.4, \
   192.168.13.18/32,1.2.3.4,192.168.13.19/32,1.2.3.4
   http://192.168.13.18/32,1.2.3.4,192.168.13.19/32,1.2.3.4, \
   192.168.13.20/32,1.2.3.4 http://192.168.13.20/32,1.2.3.4
  
  
   Thank you for this idea. Unfortunately it does not work. dnsmasq
 fails
   at first
   line which has no option:
  
  
   sounds like an option that should maybe be implemented... especially
   since it is an apparent standard that so many tools do follow ;)
  
   I think dnsmasq has a 1024 characters for config lines. I browsed the
   source briefly last night but couldn't find it.
  
 
  I checked it more precisely and it turned out that is not line length
 that
  bothers dnsmasq. It's routes count.
  I can set up to 28 routes in single dhcp-option line. It doesn't matter
 if
  it will take 600 or 800 characters. If I set 29th route dnsmasq complains
  about option too long:
 
  dnsmasq: dhcp-option too long at line 320 of /etc/dnsmasq.conf
  Can you check the code once again and try to find this limit (28) ? Why
 it
  is like that?

 Could it be that the total DHCP packet size goes over the maximum
 allowed size for an UDP frame?

Perhaps. The offending code is related to the length of the dhcp option,
not the number of routes per se:

  if (!is6 
  ((new-len  255) ||
  (new-len  253  (new-flags  (DHOPT_VENDOR | DHOPT_ENCAPSULATE)))
||
   (new-len  250  (new-flags  DHOPT_RFC3925
ret_err(_(dhcp-option too long));

I guess you can stick more than 255 bytes in a dhcp packet, anyone knows if
the limit is coming from RFCs or elsewhere?

Amicalement,
 --
 Albert.

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


Re: [Dnsmasq-discuss] how to configure lot of static routes

2015-06-30 Thread Maciej Soltysiak
On Tue, Jun 30, 2015 at 4:03 AM, wkitt...@gmail.com wkitt...@gmail.com
wrote:


 On 06/29/2015 04:01 PM, Michał Lipka wrote:


 2015-06-25 16:02 GMT+02:00 wkitt...@gmail.com
 does breaking the line work?

 eg:
 dhcp-option=249,10.0.0.1/32,1.2.3.4,192.168.13.15/32,1.2.3.4
 http://10.0.0.1/32,1.2.3.4,192.168.13.15/32,1.2.3.4, \
 192.168.13.16/32,1.2.3.4,192.168.13.17/32,1.2.3.4
 http://192.168.13.16/32,1.2.3.4,192.168.13.17/32,1.2.3.4, \
 192.168.13.18/32,1.2.3.4,192.168.13.19/32,1.2.3.4
 http://192.168.13.18/32,1.2.3.4,192.168.13.19/32,1.2.3.4, \
 192.168.13.20/32,1.2.3.4 http://192.168.13.20/32,1.2.3.4


 Thank you for this idea. Unfortunately it does not work. dnsmasq fails at
 first
 line which has no option:


 sounds like an option that should maybe be implemented... especially since
 it is an apparent standard that so many tools do follow ;)

I think dnsmasq has a 1024 characters for config lines. I browsed the
source briefly last night but couldn't find it.
Anyway, I too hit this when I configure dummy zones to return NXDOMAIN.
What I do to get around this is to use mutliple directives, e.g.:
server=/doubleclick.net/...bla bla bla bla bla /
server=/nextline.goes.here/more.domains.to.return.nxdomain.for/

Would it work if you did something similar:
dhcp-option=249,routes go here,routes go here,
dhcp-option=249,more routes go here,...
dhcp-option=249,even more routes go here,...

So that each line is less than 1024 characters?

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


Re: [Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9

2015-06-14 Thread Maciej Soltysiak
Hi,

On Sun, Jun 14, 2015 at 9:06 AM, Stéphane Guedon steph...@22decembre.eu
wrote:

 Le vendredi 12 juin 2015, 13:16:09 Maciej Soltysiak a écrit :
  A user on my service, who has dnssec-check-unsigned enabled gets an
  unsigned response from a signed zone and the intended reaction of dnsmasq
  kicks in.
 
  Not a bug then. Is my understanding correct?

 As far as I understand, I have the same issue (except that dnsmasq itself
 is
 serving the non signed zone and unbound the signed) !

 To solve that, I propose to make the unsigned zone on another domain or
 zone
 than the signed one.

 server.domain.org is signed and the public face of your server.

 server.intern.domain.org is unsigned. Your users can then use this
 address,
 and the dns can still have different answer depending where they are.

 Do you understand me ?

 Do you think it is a good idea ? (I am thinking of using it for my case).

Yes, I understand, I think it would work and it's a clever workaround for
the issue, however in my case it does not help to maintain the end goal
which was to provide authenticated response to that domain so that it is
always trustworthy.

That actually is becoming a DNSSEC question. Is there a way to provide
split-horizon answers on signed zones? Can one name have 2 different valid
answers and RRSIGs? perhaps if the signature could be for a name/ttl pair,
not just the name and have different ttls on those names? Dunno.

Perhaps me trying to use dns records to test whether the responses are
coming over dnscrypt or not is flawed in nature.

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


Re: [Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9

2015-06-14 Thread Maciej Soltysiak
On Fri, Jun 12, 2015 at 10:18 PM, Simon Kelley si...@thekelleys.org.uk
wrote:

 On 12/06/15 12:16, Maciej Soltysiak wrote:
  I think I have discovered what the problem is and it's unlikely to be
  dnsmasq.

 Without doing an exhaustive analysis (I've done too many DNSSEC
 post-mortems recently) that seems to a reasonable explanation.
 Certainly, using.dnscrypt.pl validates fine here.

Right, and thanks for checking. It must be the weird thing I'm doing...

Simon.

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


[Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9

2015-06-12 Thread Maciej Soltysiak
Hi,

One of my users raised an issue that using.dnscrypt.pl does not resolve
when dnssec-check-unsigned is turned on.
I replicated the issue with most recent openwrt Chaos Calmer package:
dnsmasq-full.

When dnssec and trust anhcor are set and dnssec-check-unsigned is as well,
dnsmasq says BOGUS DS:
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A]
using.dnscrypt.pl from fdea:7beb:d9e3:0:d928:e795:8461:1896
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded
using.dnscrypt.pl to 127.0.0.1
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS]
using.dnscrypt.pl to 127.0.0.1
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl
is BOGUS DS
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation
using.dnscrypt.pl is BOGUS
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl
is 178.62.233.48
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A]
using.dnscrypt.pl from 192.168.1.206
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded
using.dnscrypt.pl to 127.0.0.1
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A]
using.dnscrypt.pl from fdea:7beb:d9e3:0:d928:e795:8461:1896
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded
using.dnscrypt.pl to 127.0.0.1
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS]
using.dnscrypt.pl to 127.0.0.1
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS]
using.dnscrypt.pl to 127.0.0.1
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl
is BOGUS DS
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation
using.dnscrypt.pl is BOGUS
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl
is 178.62.233.48
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl
is BOGUS DS
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation
using.dnscrypt.pl is BOGUS
Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply using.dnscrypt.pl
is 178.62.233.48

Verisign dnssec check are ok:
http://dnssec-debugger.verisignlabs.com/using.dnscrypt.pl

Oddly, dnscrypt.pl resolves fine. It also works fine if
dnssec-check-unsigned is turned off.

Not sure if rc10 fixes it, it's not in openwrt repo yet.
Any ideas?

Best regards,
Maciej Soltysiak
DNSCrypt Poland
https://dnscrypt.pl
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] dnssec-check-unsigned failure with v2.73rc9

2015-06-12 Thread Maciej Soltysiak
I think I have discovered what the problem is and it's unlikely to be
dnsmasq.

What I do is that I have a setup which is basically a split horizon:
- users who are not on the service get A record for using.dnscrypt from a
DNSSEC signed zone
- users who are on the service get *a different* A record for
using.dnscrypt.pl from unbound, without sigs!

A user on my service, who has dnssec-check-unsigned enabled gets an
unsigned response from a signed zone and the intended reaction of dnsmasq
kicks in.

Not a bug then. Is my understanding correct?

Best regards,
Maciej

On Fri, Jun 12, 2015 at 10:19 AM, Maciej Soltysiak mac...@soltysiak.com
wrote:

 Hi,

 One of my users raised an issue that using.dnscrypt.pl does not resolve
 when dnssec-check-unsigned is turned on.
 I replicated the issue with most recent openwrt Chaos Calmer package:
 dnsmasq-full.

 When dnssec and trust anhcor are set and dnssec-check-unsigned is as well,
 dnsmasq says BOGUS DS:
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A]
 using.dnscrypt.pl from fdea:7beb:d9e3:0:d928:e795:8461:1896
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded
 using.dnscrypt.pl to 127.0.0.1
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS]
 using.dnscrypt.pl to 127.0.0.1
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply
 using.dnscrypt.pl is BOGUS DS
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation
 using.dnscrypt.pl is BOGUS
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply
 using.dnscrypt.pl is 178.62.233.48
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A]
 using.dnscrypt.pl from 192.168.1.206
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded
 using.dnscrypt.pl to 127.0.0.1
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: query[A]
 using.dnscrypt.pl from fdea:7beb:d9e3:0:d928:e795:8461:1896
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: forwarded
 using.dnscrypt.pl to 127.0.0.1
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS]
 using.dnscrypt.pl to 127.0.0.1
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: dnssec-query[DS]
 using.dnscrypt.pl to 127.0.0.1
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply
 using.dnscrypt.pl is BOGUS DS
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation
 using.dnscrypt.pl is BOGUS
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply
 using.dnscrypt.pl is 178.62.233.48
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply
 using.dnscrypt.pl is BOGUS DS
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: validation
 using.dnscrypt.pl is BOGUS
 Fri Jun 12 10:14:34 2015 daemon.info dnsmasq[6769]: reply
 using.dnscrypt.pl is 178.62.233.48

 Verisign dnssec check are ok:
 http://dnssec-debugger.verisignlabs.com/using.dnscrypt.pl

 Oddly, dnscrypt.pl resolves fine. It also works fine if
 dnssec-check-unsigned is turned off.

 Not sure if rc10 fixes it, it's not in openwrt repo yet.
 Any ideas?

 Best regards,
 Maciej Soltysiak
 DNSCrypt Poland
 https://dnscrypt.pl



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


Re: [Dnsmasq-discuss] dnssec-check-unsigned breaks linux.conf.au

2015-06-07 Thread Maciej Soltysiak
  On Sat 06 Jun 2015 23.16.42 Simon Kelley wrote:
  Turns out that this domain has a weird by valid use of NSEC3
  which broke dnsmasq's corner-case code.
 
  2.73rc9 should fix it.
 
  Thanks, it looks like it works.
Awesome! Thanks to both of you. I am not impacted by this but I love such
stories of corner cases being discovered, reported, fixed and even
explained!

 A longer explanation (using NSEC because it's easier to understand,
 NSEC3, which was used in this case, has the same principle but it less
 obvious to understand.)
Thanks for the very nice and simple explanation, Simon.

 It's fun stuff, this DNSSEC.
It sure is.

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


Re: [Dnsmasq-discuss] Ignore certain returned DNS response?

2014-12-27 Thread Maciej Soltysiak
Cool feature! Congrats! I wonder if router vendors will implement this in
webguis though.

Best regards,
Maciej
PS. Excise my brevity. On mobile device.
On 27 Dec 2014 17:12, Simon Kelley si...@thekelleys.org.uk wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 Patch tidied and tweaked a little bit, and merged into the git repo.
 Many thanks for this, and sorry it took so long to get around to it.


 Cheers,

 Simon.


 On 19/11/14 01:42, Glen Huang wrote:
  Hey Simon,
 
  Is the patch good for merging?
 
  I have been personally using the patch for over a month without
  problems.
 
  On Oct 9, 2014, at 10:48 PM, Simon Kelley
  si...@thekelleys.org.uk wrote:
 
  On 08/10/14 13:13, Glen Huang wrote:
  Is it possible to ask dnsmasq to ignore DNS responses whose
  records match a certain list of ip, and keep waiting for
  another response?
 
  The rational behind this is that in China, when querying a
  domain like youtube.com or twitter.com, a fake ip is quickly
  returned, fooling dnsmasq to discard the genuine response that
  comes after it. Luckily the returned fake ips are of a limited
  set. So it’s relatively easy to distinguish such bogus
  responses.
 
  Sigh. Now if Twitter and Youtube did DNSSEC signatures, such
  silly games would no longer be possible.
 
  I can’t find an option which does this in the man page. So
  this might be a feature request. I guess it should work like
  the bogus-nxdomain option, but instead of treating the ip as
  nxdomain, dnsmasq would ignore it, and keep wait for another
  response.
 
  I’m willing to take a stab at this feature (it could take some
  time though, since I’m not familiar with the internels of
  dnsmasq). But before doing so, I want to make sure that I
  didn’t missing any option that already does that and this
  feature does belong to dnsmasq.
 
 
  There's no way to do this in the current dnsmasq releases, but
  I'd certainly consider a patch to implement it. You're right
  that the code can be modelled on bogus-nxdomain.
 
  You can use code like that in check_for_bogus_wildcard() to
  detect the bad answer (the option-parsing code would be
  identical) the check needs to be called from near the start of
  reply_query() and should just return from that function if bogus
  answer is detected.
 
 
  Cheers,
 
  Simon.
 
 
 
  Thank you. ___
  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
 
 
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBCAAGBQJUntJ+AAoJEBXN2mrhkTWiOugP/j+6uu26uhekhjC0A6CvcIks
 aUAh2jIr/oow5PHfKaGkNnnY8R4XH44okyyzZm0onmPhp6HaG0pQPS8S+hg0hQaY
 Lp8cnBKy+A0qMwUBT5elrwT9tUArsmTSUx9/u47YCGeIF62Sd8xPu73FalTlqq+/
 5/8EJH+7VWouTnLvqq3A8pBsaQDZ1YBGlZ76ByPUQrPMSD+8iybO7Uhu9DbKv5UF
 rA6BHgx89fq8mZ0qaRea3+NgFMX8lBdnElJLw+ZfZJz6MHQPU1bt5I9y1se1E979
 9CQ792PIvM0PFLQCrobjhGPdO1ntQQPBnYL4cK5VlwH4EO/Ygnk5cdFQjArZP/hL
 c8kL8VcZcziQc4x1trq8NZPJhz8jJEE9k5fw4YCA+FCPD6TMAjDkFxH//vK85Sj5
 7thVxxaWtWUJjW/538PHvmFthwszF1FRxwdSXpBU7hZwG7jCQxK6gciDjHQUw9EE
 vOS2bHb+hYWAeScG30tAOpPQ2iP5AMSkb0pCKPdHOGSQjWEkT1G2y3aCzVXAkpGl
 aT0kwq+msz4HKu1hx3grPa7MMO1AW9sLKKEKs8fKdg0rP1Or2VU+8os3AYV4rmUi
 X/wfjOPrZNGhcsDM6x7nACTQ4avx7Yikr5yPmlTPfW+EzKMzWeJ9z5/+tza+A60K
 7K9jikX3iwRybQVRZx37
 =lQlZ
 -END PGP SIGNATURE-

 ___
 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] DNSCrypt - the big picture

2014-02-07 Thread Maciej Soltysiak
On Fri, Feb 7, 2014 at 2:55 PM, Lonnie Abelbeck
li...@lonnie.abelbeck.com wrote:

 On Feb 7, 2014, at 7:15 AM, Maciej Soltysiak wrote:

 On Fri, Feb 7, 2014 at 1:42 PM, Lonnie Abelbeck
 li...@lonnie.abelbeck.com wrote:
 I admit is is nice to know that no-one is silently altering DNS 
 queries/responses in transit to a trusted DNS server, but is that being 
 overly paranoid ?

 Appreciate any comments...
 I treat dnscrypt as a way to prevent query snooping by my ISP, not as
 means to prevent altering.

 Thanks for your thoughts Maciej, but since the ISP routes (and logs stats) 
 the network data anyway, there isn't much privacy to be gained by 
 preventing DNS query snooping, is there ?
Partly.
The ISP A that serves your trusted DNS server will be able to corelate
DNS queries and dnscrypt clients.
The ISP B that serves your dnsmasq + dnscrypt-proxy will just see
encrypted traffic. They would need to collude with ISP A.

Of course ISP A can see DNS traffic and then, say, a subsequent HTTP
query, so you're right. But client computers also leak DNS, e.g. even
when using VPN, some DNS queries might be sent outside it, so e.g.
company intranet, etc.

 I'm thinking DNSCrypt's best feature is preventing man-in-the-middle attacks 
 between the router and the trusted DNS server.
Agreed!

 Lonnie
Maciej

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


Re: [Dnsmasq-discuss] dnsmasq fails to parse long server directive

2013-12-29 Thread Maciej Soltysiak
On Sat, Dec 28, 2013 at 6:02 PM, Simon Kelley si...@thekelleys.org.uk wrote:
 On 27/12/13 18:43, Maciej Soltysiak wrote:
 Am I hitting some static limit of an array?

 Yes.


 Can I work around it?


 Split the server line up

 server=/domain.one/domain.two/


 is exactly equivalent to

 server=/domain.one/
 server=/domain.two/
Thanks for the response Simon. It seems to work!

 Cheers,

 Simon.
Maciej

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


[Dnsmasq-discuss] Fwd: How to return NXDomain?

2013-09-11 Thread Maciej Soltysiak
Hi everyone,

To return a specific address for an IN A query we can do this:
address=/double-click.net/127.0.0.1

Is it currently possible to return NXDOMAIN with similar syntax, e.g.:
address=/double-click.net/nxdomain

If it is not possible, would there be any objections to adding such
functionality?

Best regards,
Maciej Soltysiak
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss


Re: [Dnsmasq-discuss] Fwd: How to return NXDomain?

2013-09-11 Thread Maciej Soltysiak
 On Wed, Sep 11, 2013 at 11:40 AM, Simon Kelley si...@thekelleys.org.ukwrote:

 On 11/09/13 10:33, Maciej Soltysiak wrote:

 Hi everyone,

 To return a specific address for an IN A query we can do this:
 address=/double-click.net/127.**0.0.1 http://double-click.net/127.0.0.1

 Is it currently possible to return NXDOMAIN with similar syntax, e.g.:
 address=/double-click.net/**nxdomain http://double-click.net/nxdomain


 Yes, you can tell dnsmasq that there's no upstream server for that domain:
 eg.

 server=/double-click.net/

 that way, if the query can't be answered from /etc/hosts or DHCP leases
 etc, it will get an NXDOMAIN reply.

Great! That's better in some cases than returning 127.0.0.1 or other rabbit
hole.

I'm away from my router at the moment. I'm just wondering if I should
expect the openwrt luci compatible config for this to be:

config 'domain'
 option 'name' 'doubleclick'
 option 'ip'   ''

and work :)


 Cheers,

 Simon.

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