[Dnsmasq-discuss] Ignore single hosts for DHCPv4 but not for DHCPv6/SLAAC, SLAAC name resolution

[Ziggy SpaceRat]

Greetings,

I would like to know if there is any way to achieve this:

While  I generally assign IPv4 addresses to all hosts in my network, I
do  not  want  to  do  this  for  a  few ones (Those that I've already
switched to IP(v6)-only operation).

I know that I can disable DHCP entirely for a specific host using

dhcp-host=00:1d:ec:12:34:56,ignore

but what I want is more like

dhcp-host=00:1d:ec:12:34:56,hostname

-» Gets no IPv4 address and no IPv6 address (as none entered), but the
entry is still used for host name probing in conjunction with SLAAC.

However what this really does is:
Gets a random IPv4 (and/or IPv6) address from the pool(s).


Is there any way I can configure this for *single* hosts?
- DHCPv4 completely disabled
- DHCPv6 announcing DNS server only (Just O flag)
- Still able to resolve name based on SLAAC

For the SLAAC resolution, I know that DNSMasq tries this:
When  a  DHCP  host entry exists, DNSMasq builds the stateless address
this  MAC  would  result  in  without the bullshit extensions and then
pings that host.

I  also  see  why  *this*  method  can not work for hosts without DHCP
address  assigning: DNSMasq doesn't notice *when* they configure their
addresses, as the triggering event (DHCP) is missing.

But I have two different approaches which might work even better:
1. Periodically check the NDP neighbourhood for hosts
and/or
2.  Build  the stateless address when the host's name gets queried and
ping it (Same method as now, just a different/additional trigger)
Would  of course delay the response but it's better than no resolution
at all ...

BTW:  Hosts  that  are  configured for DHCPv4 on the host side but are
ignored  by  DNSMasq  are  causing  terribly  high CPU load while they
hammer DNSMasq for a DHCP lease ...

-- 
Kind regards
Ziggy SpaceRat


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

Re: [Dnsmasq-discuss] dnsmasq not providing a response to client

[Bill Warren]

Hi Albert,

My issues were caused by running dnsmasq in a FreeBSD jail.  Basic jails (using 
iocage as the jail manager, at least) use shared IP networking that is not a 
complete network stack.  All other services I host inside jails work fine, but 
apparently I will need to change to use VNET/VIMAGE networking for the jails to 
allow dnsmasq to respond properly.  

Sorry for the false alarm, since this is not a dnsmasq issue.  I did learn a 
good amount, though :-)

Best regards,

Bill


> On Sep 9, 2016, at 16:39, Albert ARIBAUD  wrote:
> 
> Hi Bill,
> 
> Le Fri, 9 Sep 2016 16:10:35 -0400
> Bill Warren  a écrit:
> 
>> Hi Albert,
>> 
>> I tried installing dnsmasq in a virtualized, fresh FreeBSD
>> installation ... and it is working.  I will go through my hardening
>> configurations to see what, if anything, I can isolate as the cause.
> 
> I would have said as much from reading the second tcpdump, which shows
> the answer from google to the dnsmasq server host (...1.14) but not the
> answer from the server host to the original client. I bet the iptables
> layer drops the packet for some reason.
> 
>> to be continued …
> 
> Let us know when you find out.
> 
> Amicalement,
> -- 
> Albert.


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

Re: [Dnsmasq-discuss] [PATCH] rfc2131: Fix range address assignment not honoring vendor option filters

[Simon Kelley]

On 05/09/16 15:35, Hans Dedecker wrote:
> Problem is visible when using multiple dhcp-ranges; one dhcp-range is a 
> "catch-all"
> range without tags while the second dhcp-range has tags based on 
> vendor-class/user-class/...
> If a client sends a DORA with no specific IP and no vendor/user class it will 
> get an IP addres
> from the "catch-all" range; if the client renews (or restarts) with a 
> vendor/user class
> and a request IP option holding the "catch-all" IP it will get DHCP options 
> from the
> dhcp-range based on vendor-class/user-class but will get the requested IP 
> address acked.
> This patch solves this problem as it detects a tag is assigned based on the 
> vendor-class/user-class
> and actually checks if the requested IP belongs to the correct dhcp-range; if 
> not the client will
> be nacked to it can restart its DORA sequence.
> 


I'm happy to work on understanding this patch if it's really necessary,
but an alternative way of working around this client behaviour, without
code changes, may be to abandon the "catch all" range, and declare the
two ranges explicitly,

dhcp-vendorclass=set:special, ...

dhcp-range = tag:special, ..

# range used for hosts that don't have a special class
dhcp-range = tag:!special, ..


If there are multiple special classes, the catch-all becomes

dhcp-range = tag:!special1, tag:!special2, tag:!special3

Doing it like this, when a previously ordinary client acquires "special"
status, the catch-all range ceases to apply, and the re-addressing
should happen automatically.


Cheers,

Simon.






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

Re: [Dnsmasq-discuss] dnsmasq not providing a response to client

[Bill Warren]

Hi Albert,

I tried installing dnsmasq in a virtualized, fresh FreeBSD installation ... and 
it is working.  I will go through my hardening configurations to see what, if 
anything, I can isolate as the cause.

to be continued …


> On Sep 8, 2016, at 00:30, Bill Warren  wrote:
> 
> Hello Albert,
> 
> Thank you so much for the helpful response.  This is my first time using 
> tcpdump, so please excuse any novice mistakes.
> 
>> On Sep 7, 2016, at 01:54, Albert ARIBAUD  wrote:
>> 
>> Hello Bill,
>> 
>> Le Tue, 6 Sep 2016 19:17:56 -0400
>> Bill Warren  a écrit:
>> 
>>> Greetings from a new user of dnsmasq v.2.76 on FreeBSD v.10.3
>>> 
>>> dnsmasq is receiving queries and obtaining responses (confirmed in
>>> --no-daemon mode).
>> 
>> Rather than paraphrasing the dnsmasq output, can you copy-paste it,
>> including [a reasonable amount of] the lines which you think are
>> irrelevant? I'm asking this because in your description, you don't
>> indicate what dnsmasq says about the response once it got it from the
>> upstream (I don't think it discards it, but hey, troubleshooting is
>> about checking what you don't think can go wrong).
>> 
> 
> Here is the output from dnsmasq during the client’s dig query.  It was 
> exactly the same when querying from the server (tcpdump later)
> 
>> /usr/local/sbin/dnsmasq --no-daemon -x /var/run/dnsmasq.pid -C 
>> /usr/local/etc/dnsmasq.conf
> dnsmasq: started, version 2.76 cachesize 150
> dnsmasq: compile time options: IPv6 GNU-getopt no-DBus no-i18n IDN DHCP 
> DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect no-inotify
> dnsmasq: reading /etc/resolv.conf
> dnsmasq: using nameserver 8.8.8.8#53
> dnsmasq: using nameserver 8.8.4.4#53
> dnsmasq: read /etc/hosts - 2 addresses
> dnsmasq: query[A] www.google.com from 192.168.1.161
> dnsmasq: forwarded www.google.com to 8.8.8.8
> dnsmasq: forwarded www.google.com to 8.8.4.4
> dnsmasq: reply www.google.com is 216.58.219.196
> dnsmasq: query[A] www.google.com from 192.168.1.161
> dnsmasq: cached www.google.com is 216.58.219.196
> dnsmasq: query[A] www.google.com from 192.168.1.161
> dnsmasq: cached www.google.com is 216.58.219.196
> 
>>> However, the client never receives a response ...
>>> dig @192.168.1.14 www.google.com
>>> results in
>>> […]
>>> connection timed out; no servers could be reached
>>> 
>>> I disabled the pf firewall to ensure it wasn’t filtering traffic, to
>>> no avail.
>> 
>> What about the server? Can you try dig on the same machine as dnsmasq
>> is running? Especially considering this:
>> 
>>> I cannot figure out why my clients aren’t getting the response from
>>> dnsmasq even though it received and looked-up the query.  
>> 
>> So it affects several clients. All the more a reason to check whether
>> the dnsmasq server itself can dig its own dnsmasq.
> 
> I should have mentioned, I did test this with "host www.google.com 127.0.0.1" 
> on the dnsmasq server, with the same results.  I do show the separate tcpdump 
> output below.
> 
>> 
>>> Any suggestions would be greatly appreciated!  I stumbled onto
>>> dnsmasq and think it will be the perfect solution … once I get it
>>> working properly.
>> 
>> In addition to trying dig on the server itself, I also suggest doing a
>> tcpdump on the server machine's interface while doing the dig, in order
>> to cross-check whether the server process physically sends the response
>> out.
>> 
> 
> Below is the output from “sudo tcpdump host 192.168.1.14” on the server 
> (mostly).  I needed the host parameter because dnsmasq is in a FreeBSD jail, 
> but I couldn’t run tcpdump from within the jail so I ran it outside the jail. 
>  192.168.1.14 is the jailed dnsmasq server.
> 
> 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 00:26:13.418521 IP 192.168.1.14.33761 > 
> google-public-dns-a.google.com.domain: 8349+ A? www.google.com. (32)
> 00:26:13.418538 IP 192.168.1.14.33761 > 
> google-public-dns-b.google.com.domain: 8349+ A? www.google.com. (32)
> 00:26:13.529979 ARP, Request who-has 192.168.1.14 tell 192.168.1.1, length 46
> 00:26:13.529983 ARP, Reply 192.168.1.14 is-at d0:50:99:1b:92:f6 (oui 
> Unknown), length 28
> 00:26:13.530774 IP google-public-dns-a.google.com.domain > 
> 192.168.1.14.33761: 8349 1/0/0 A 172.217.2.4 (48)
> 00:26:13.530871 IP google-public-dns-b.google.com.domain > 
> 192.168.1.14.33761: 8349 1/0/0 A 172.217.5.4 (48)
> 
> 
>> Then, same with digging from a client, but running two tcpdumps: one on
>> the server's physical interface, and one on the client's physical
>> interface.
>> 
> 
> Below is the tcpdump output from the server while querying from dig on client 
> IP 192.168.1.161.
> 
> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
> listening on re0, link-type EN10MB (Ethernet), capture size 65535 bytes
> 23:43:21.228911 ARP, 

Re: [Dnsmasq-discuss] dnsmasq not providing a response to client

[Albert ARIBAUD]

Hi Bill,

Le Fri, 9 Sep 2016 16:10:35 -0400
Bill Warren  a écrit:

> Hi Albert,
> 
> I tried installing dnsmasq in a virtualized, fresh FreeBSD
> installation ... and it is working.  I will go through my hardening
> configurations to see what, if anything, I can isolate as the cause.

I would have said as much from reading the second tcpdump, which shows
the answer from google to the dnsmasq server host (...1.14) but not the
answer from the server host to the original client. I bet the iptables
layer drops the packet for some reason.

> to be continued …

Let us know when you find out.

Amicalement,
-- 
Albert.

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

Re: [Dnsmasq-discuss] Hiding/obscuring version.bind

[Simon Kelley]

Applied.

Something to think about: with this in effect, queries to *.bind get
treated like all others, ie they get forwarded upstream, so the
requestor may get an answer from an upstream nameserver. I've added a
comment to this effect to the definition of NO_ID.

Cheers,

Simon.



On 07/09/16 11:34, Kevin Darbyshire-Bryant wrote:
> Attached (in case the git send-email didn't work)
> 
> Kevin :-)
> 
> On 06/09/16 21:23, Simon Kelley wrote:
> a) I tend to agree that it's pointless.
> b) Not a run-time option, there are too many of those already.
> c) Maybe the simplest solution is something like a NO_ID compile time
> option that suppresses the whole .bind domain thing?
> 
> Certainly happy to take the patch.
> 
> 
> Cheers,
> 
> Simon.
> 
> 
> On 06/09/16 16:14, Kevin Darbyshire-Bryant wrote:
 Hi Simon & all,

 There has been a bit of activity on the security front in LEDE and
 a recent change proposed removing version numbers from software to
 avoid it leaking to 'the bad guys'.  I'll say upfront that I'm not
 a fan of this approach feeling that it's more of the 'security
 through obscurity' route but minds cleverer than mine have thought
 about this so from a LEDE point of view 'we're stuck with it'.

 LEDE's approach is to simply change the VERSION file to 'UNKNOWN'
 at build time.  I dislike this because it also removes any info
 from the startup logs or even 'dnsmasq --version' and on the basis
 that 'version number' is a somewhat basic requirement when
 providing advice/support here.  A suggestion has been made to
 introduce a compile time option that replaces 'version.bind' with
 "dnsmasq-UNKNOWN', leaving all the usual version strings intact.
 The suggestion was also made rather than having a LEDE specific
 patch that 'upstream' dnsmasq might like this feature.

 I'm willing to do what should be a simple patch for that behaviour
 but is it a) a good idea?  b) should it be a run-time option
 instead?  c) should we consider obscuring other info as well?

 Cheers,

 Kevin


 ___ 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
> 


___
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 vs sharepoint.com

[/dev/rob0]

On Fri, Sep 09, 2016 at 03:24:34PM +0100, Kevin Darbyshire-Bryant wrote:
> Having some issues with my 'onedrive for business' application 
> which in turn uses 'sharepoint.com'.  Short version: dnsmasq 2.76 
> thinks sharepoint.com is bogus.  Directly querying upstream servers 
> is okay:
> 
> # drill -D @8.8.8.8 sharepoint.com
> ;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45014
> ;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
> ;; QUESTION SECTION:
> ;; sharepoint.com.  IN  A
> 
> ;; ANSWER SECTION:
> sharepoint.com. 20224   IN  CNAME   sharepoint.microsoft.com.

This is broken.

> sharepoint.microsoft.com.   3346IN  A   64.4.6.100
> sharepoint.microsoft.com.   3346IN  A   65.55.39.10
snip

> If I disable 'check unsigned' on the router's dnsmasq instance 
> things work ok.
> 
> Why does dnsmasq think bogus, but google think ok?

$ dig sharepoint.com. any @f.gtld-servers.net. +norec +dnssec

; <<>> DiG 9.10.3 <<>> sharepoint.com. any @f.gtld-servers.net. +norec +dnssec
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23615
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 8, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;sharepoint.com.IN  ANY

;; AUTHORITY SECTION:
sharepoint.com. 172800  IN  NS  ns1.bdm.microsoftonline.com.
sharepoint.com. 172800  IN  NS  ns2.bdm.microsoftonline.com.
sharepoint.com. 172800  IN  NS  ns3.bdm.microsoftonline.com.
sharepoint.com. 172800  IN  NS  ns4.bdm.microsoftonline.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - 
CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 
20160915044336 2016090806 27452 com. 
xNERKmnAlkb3XiEf76OahP52D10WKZLu7GcWpYhVT4be0SBbmq9Kn+XV 
AnaMG/Ywu1/4VPyMfDxnw+XJLMXLn3NJN7TbNLA9Z0TqcpbRZcnTq1Na 
cO9/iuAx32Oaf5pbJIwuSS7HAhfDY4tahpYuSYDz8xOQzyf5W6wnjWAL sAc=
3HGLO8KLU2RJ9G8IIOE1U9FPP77E8J3F.com. 86400 IN NSEC3 1 1 0 - 
3HGMM5Q6EQANHO53VDJUCIMH8GVFL0BU NS DS RRSIG
3HGLO8KLU2RJ9G8IIOE1U9FPP77E8J3F.com. 86400 IN RRSIG NSEC3 8 2 86400 
20160915042007 20160908031007 27452 com. 
sVonxyL0/UgM+9KOG56hO1KezbbM8nzXaEDQYkfJISKVXy+P4m3vF1CX 
pO54bvTDo+msHBjNfNnjZ/4W7NnCutFTs0MNGXYZHOmXJE0B58KXW3Ui 
xsS8lzMlvGKvRuqwe3sHVi1K7TVz2BS96oxljuQ2LXpB+m0MX3eyMt5l zO8=
...

Microsoft has a broken implementation here.  They have put a CNAME 
where NS already exists.  Some resolvers are fooled and will go along 
with it, but apparently dnsmasq can't do that while checking DNSSEC.

If you are paying them, complain.
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject:

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

[Dnsmasq-discuss] DNSSEC check unsigned vs sharepoint.com

[Kevin Darbyshire-Bryant]

Hi All,

Having some issues with my 'onedrive for business' application which in
turn uses 'sharepoint.com'.  Short version: dnsmasq 2.76 thinks
sharepoint.com is bogus.  Directly querying upstream servers is okay:

# drill -D @8.8.8.8 sharepoint.com
;; ->>HEADER<<- opcode: QUERY, rcode: NOERROR, id: 45014
;; flags: qr rd ra ; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;; sharepoint.com.  IN  A

;; ANSWER SECTION:
sharepoint.com. 20224   IN  CNAME   sharepoint.microsoft.com.
sharepoint.microsoft.com.   3346IN  A   64.4.6.100
sharepoint.microsoft.com.   3346IN  A   65.55.39.10

;; AUTHORITY SECTION:

;; ADDITIONAL SECTION:

;; Query time: 17 msec
;; EDNS: version 0; flags: do ; udp: 512
;; SERVER: 8.8.8.8
;; WHEN: Fri Sep  9 15:14:12 2016
;; MSG SIZE  rcvd: 110

If I disable 'check unsigned' on the router's dnsmasq instance things
work ok.

Why does dnsmasq think bogus, but google think ok?

Kevin

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