Re: [Dnsmasq-discuss] [Cerowrt-devel] Names not resolved on Wireless
Dear Dr. Dnsmasq: When cerowrt made the jump between dnsmasq-2.67-test10 and dnsmasq-2.67-test17, detection of interfaces other than the first started failing. It seems to be related to interfaces that come up after dnsmasq starts, as restarting it after the device is fully booted works. Have moved forward to 2.67-rc3 to no avail. (along the way we migrated from kernel 3.10.11 to 3.10.13 to 3.10.15 but I doubt that's the issue) Hot, fresh, firmware can be had at: http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ [10:39:25] has anyone had IPv4 DHCP problems in the last two 3.10.x builds? currently running 3.10.11-3 and it works flawlessly. upgraded to 3.10.13-2 and 3.10.15-1 and both present me with an identical issue. upon reboot after upgrading, DHCP leases are no longer handed out on the wireless interfaces. disabling and re-enabling DHCP on the wireless interfaces will fix the problem, but the problem [10:39:26] returns after a reboot. disable/reenable DHCP on the interface will again temporarily fix it. [10:42:03] also tried a fresh install (using reset to defaults option) to avoid anything not properly interpreted from the config of the previous version, but still get the same issue. On Thu, Oct 10, 2013 at 5:30 AM, David Personette wrote: > Just tested again with 3.10.15-2. My OSX (10.8.5) laptop worked, neither my > Nexus 7 (2013 w/CM10.2) or my Fedora 19 laptop could resolve DNS over > wireless. My wired Linux server (Ubuntu 12.04.3) was working fine as well. > Reverted to 3.10.11-3 once more. > > -- > David P. > > > On Mon, Oct 7, 2013 at 7:40 PM, David Personette wrote: >> >> I can confirm it as well. I wiped my config back to defaults, and it >> wasn't fixed. Reinstalled the 3.10.11-3 build, and restored my configs and >> all is well. >> >> -- >> David P. >> >> >> On Mon, Oct 7, 2013 at 7:07 PM, Fred Stratton >> wrote: >>> >>> True for the last two builds. Wired works as expected. >>> >>> Is this a problem with the development version of DNSMasq? What is the >>> recommended workaround? >>> >>> ___ >>> Cerowrt-devel mailing list >>> cerowrt-de...@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> > > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Names not resolved on Wireless
On Thu, Oct 10, 2013 at 9:54 AM, Simon Kelley wrote: > > Does reverting > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=397542b213ab4071734f1cdf4cc914d87100456f > > fix the issue? I fear it might. Seems likely. I reverted that patch and put it in this build http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.15-3/ I won't be in a position to test stuff myself til sunday but cero's devoted userbase seems to be hoovering over the reload button and will probably beat me to it > > Cheers, > > Simon. > > > > On 10/10/13 15:43, Dave Taht wrote: >> >> Dear Dr. Dnsmasq: >> >> When cerowrt made the jump between dnsmasq-2.67-test10 and >> dnsmasq-2.67-test17, detection of interfaces other than the first >> started failing. It seems to be related to interfaces that come up >> after dnsmasq starts, as restarting it after the device is fully >> booted works. Have moved forward to 2.67-rc3 to no avail. >> >> (along the way we migrated from kernel 3.10.11 to 3.10.13 to 3.10.15 >> but I doubt that's the issue) >> >> Hot, fresh, firmware can be had at: >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ >> >> >> [10:39:25] has anyone had IPv4 DHCP problems in the last two >> 3.10.x >> builds? currently running 3.10.11-3 and it works flawlessly. >> upgraded to 3.10.13-2 and 3.10.15-1 and both present me with an >> identical issue. upon reboot after upgrading, DHCP leases are no >> longer handed out on the wireless interfaces. disabling and >> re-enabling DHCP on the wireless interfaces will fix the problem, but >> the problem >> [10:39:26] returns after a reboot. disable/reenable DHCP on the >> interface will again temporarily fix it. >> [10:42:03] also tried a fresh install (using reset to defaults >> option) to avoid anything not properly interpreted from the config of >> the previous version, but still get the same issue. >> >> >> On Thu, Oct 10, 2013 at 5:30 AM, David Personette >> wrote: >>> >>> Just tested again with 3.10.15-2. My OSX (10.8.5) laptop worked, neither >>> my >>> Nexus 7 (2013 w/CM10.2) or my Fedora 19 laptop could resolve DNS over >>> wireless. My wired Linux server (Ubuntu 12.04.3) was working fine as >>> well. >>> Reverted to 3.10.11-3 once more. >>> >>> -- >>> David P. >>> >>> >>> On Mon, Oct 7, 2013 at 7:40 PM, David Personette >>> wrote: >>>> >>>> >>>> I can confirm it as well. I wiped my config back to defaults, and it >>>> wasn't fixed. Reinstalled the 3.10.11-3 build, and restored my configs >>>> and >>>> all is well. >>>> >>>> -- >>>> David P. >>>> >>>> >>>> On Mon, Oct 7, 2013 at 7:07 PM, Fred Stratton >>>> wrote: >>>>> >>>>> >>>>> True for the last two builds. Wired works as expected. >>>>> >>>>> Is this a problem with the development version of DNSMasq? What is the >>>>> recommended workaround? >>>>> >>>>> ___ >>>>> Cerowrt-devel mailing list >>>>> cerowrt-de...@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>> >>>> >>>> >>> >>> >>> ___ >>> Cerowrt-devel mailing list >>> cerowrt-de...@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >> >> >> > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Names not resolved on Wireless
3.10.15-4 is now out there, containing sufficient patches to get dnsmasq to the current head of tree, and including the patch below. http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.15-4/ On Thu, Oct 10, 2013 at 1:23 PM, Simon Kelley wrote: > Having thought about this more, this patch is necessary > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=8584c502d37627d8abe18213771b5f4f98cb4aa3 > > and should fix the bug iff > > 1) Dnsmasq is configured using --except-interface= and > there are no --interface= config > lines. > > 2) Exactly one interface that dnsmasq should be listening on is around when > it starts, but others arrive later. > > I can't explain why it just broke though, this bug has been around forever. > > > > Simon. > > > > > > On 10/10/13 19:30, Dave Taht wrote: >> >> On Thu, Oct 10, 2013 at 9:54 AM, Simon Kelley >> wrote: >>> >>> >>> Does reverting >>> >>> >>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=397542b213ab4071734f1cdf4cc914d87100456f >>> >>> fix the issue? I fear it might. >> >> >> Seems likely. >> >> I reverted that patch and put it in this build >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.15-3/ >> >> I won't be in a position to test stuff myself til sunday but cero's >> devoted userbase seems to be hoovering over the reload button and will >> probably beat me to it >> >> >>> >>> Cheers, >>> >>> Simon. >>> >>> >>> >>> On 10/10/13 15:43, Dave Taht wrote: >>>> >>>> >>>> Dear Dr. Dnsmasq: >>>> >>>> When cerowrt made the jump between dnsmasq-2.67-test10 and >>>> dnsmasq-2.67-test17, detection of interfaces other than the first >>>> started failing. It seems to be related to interfaces that come up >>>> after dnsmasq starts, as restarting it after the device is fully >>>> booted works. Have moved forward to 2.67-rc3 to no avail. >>>> >>>> (along the way we migrated from kernel 3.10.11 to 3.10.13 to 3.10.15 >>>> but I doubt that's the issue) >>>> >>>> Hot, fresh, firmware can be had at: >>>> >>>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ >>>> >>>> >>>>[10:39:25] has anyone had IPv4 DHCP problems in the last two >>>> 3.10.x >>>> builds? currently running 3.10.11-3 and it works flawlessly. >>>> upgraded to 3.10.13-2 and 3.10.15-1 and both present me with an >>>> identical issue. upon reboot after upgrading, DHCP leases are no >>>> longer handed out on the wireless interfaces. disabling and >>>> re-enabling DHCP on the wireless interfaces will fix the problem, but >>>> the problem >>>>[10:39:26] returns after a reboot. disable/reenable DHCP on >>>> the >>>> interface will again temporarily fix it. >>>>[10:42:03] also tried a fresh install (using reset to >>>> defaults >>>> option) to avoid anything not properly interpreted from the config of >>>> the previous version, but still get the same issue. >>>> >>>> >>>> On Thu, Oct 10, 2013 at 5:30 AM, David Personette >>>> wrote: >>>>> >>>>> >>>>> Just tested again with 3.10.15-2. My OSX (10.8.5) laptop worked, >>>>> neither >>>>> my >>>>> Nexus 7 (2013 w/CM10.2) or my Fedora 19 laptop could resolve DNS over >>>>> wireless. My wired Linux server (Ubuntu 12.04.3) was working fine as >>>>> well. >>>>> Reverted to 3.10.11-3 once more. >>>>> >>>>> -- >>>>> David P. >>>>> >>>>> >>>>> On Mon, Oct 7, 2013 at 7:40 PM, David Personette >>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>> I can confirm it as well. I wiped my config back to defaults, and it >>>>>> wasn't fixed. Reinstalled the 3.10.11-3 build, and restored my configs >>>>>> and >>>>>> all is well. >>>>>> >>>>>> -- >>>>>> David P. >>>>>> >>>>>> >>>>>> On Mon, Oct 7, 2013 at 7:07 PM, Fred Stratton >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>> True for the last two builds. Wired works as expected. >>>>>>> >>>>>>> Is this a problem with the development version of DNSMasq? What is >>>>>>> the >>>>>>> recommended workaround? >>>>>>> >>>>>>> ___ >>>>>>> Cerowrt-devel mailing list >>>>>>> cerowrt-de...@lists.bufferbloat.net >>>>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> ___ >>>>> Cerowrt-devel mailing list >>>>> cerowrt-de...@lists.bufferbloat.net >>>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>>> >>>> >>>> >>>> >>> >>> >>> ___ >>> Dnsmasq-discuss mailing list >>> Dnsmasq-discuss@lists.thekelleys.org.uk >>> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> >> >> >> > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Names not resolved on Wireless
On Oct 11, 2013 4:02 AM, "David Personette" wrote: > > Sorry, it's still behaving the same for me. Failed back to 3.10.11-3 once more. OK I will set aside time Sunday and Monday to poke deeply into this. I note you probably needent revert all the way back to this version. You can wget the version of DNSmasq from this versions packages and forcibly apply it on top of 3.10.15-4 using opkg. > -- > David P. > > > On Thu, Oct 10, 2013 at 8:01 PM, Dave Taht wrote: >> >> 3.10.15-4 is now out there, containing sufficient patches to get >> dnsmasq to the current head of tree, and including the patch below. >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.15-4/ >> >> On Thu, Oct 10, 2013 at 1:23 PM, Simon Kelley wrote: >> > Having thought about this more, this patch is necessary >> > >> > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=8584c502d37627d8abe18213771b5f4f98cb4aa3 >> > >> > and should fix the bug iff >> > >> > 1) Dnsmasq is configured using --except-interface= and >> > there are no --interface= config >> > lines. >> > >> > 2) Exactly one interface that dnsmasq should be listening on is around when >> > it starts, but others arrive later. >> > >> > I can't explain why it just broke though, this bug has been around forever. >> > >> > >> > >> > Simon. >> > >> > >> > >> > >> > >> > On 10/10/13 19:30, Dave Taht wrote: >> >> >> >> On Thu, Oct 10, 2013 at 9:54 AM, Simon Kelley >> >> wrote: >> >>> >> >>> >> >>> Does reverting >> >>> >> >>> >> >>> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=397542b213ab4071734f1cdf4cc914d87100456f >> >>> >> >>> fix the issue? I fear it might. >> >> >> >> >> >> Seems likely. >> >> >> >> I reverted that patch and put it in this build >> >> >> >> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/3.10.15-3/ >> >> >> >> I won't be in a position to test stuff myself til sunday but cero's >> >> devoted userbase seems to be hoovering over the reload button and will >> >> probably beat me to it >> >> >> >> >> >>> >> >>> Cheers, >> >>> >> >>> Simon. >> >>> >> >>> >> >>> >> >>> On 10/10/13 15:43, Dave Taht wrote: >> >>>> >> >>>> >> >>>> Dear Dr. Dnsmasq: >> >>>> >> >>>> When cerowrt made the jump between dnsmasq-2.67-test10 and >> >>>> dnsmasq-2.67-test17, detection of interfaces other than the first >> >>>> started failing. It seems to be related to interfaces that come up >> >>>> after dnsmasq starts, as restarting it after the device is fully >> >>>> booted works. Have moved forward to 2.67-rc3 to no avail. >> >>>> >> >>>> (along the way we migrated from kernel 3.10.11 to 3.10.13 to 3.10.15 >> >>>> but I doubt that's the issue) >> >>>> >> >>>> Hot, fresh, firmware can be had at: >> >>>> >> >>>> http://snapon.lab.bufferbloat.net/~cero2/cerowrt/wndr/ >> >>>> >> >>>> >> >>>>[10:39:25] has anyone had IPv4 DHCP problems in the last two >> >>>> 3.10.x >> >>>> builds? currently running 3.10.11-3 and it works flawlessly. >> >>>> upgraded to 3.10.13-2 and 3.10.15-1 and both present me with an >> >>>> identical issue. upon reboot after upgrading, DHCP leases are no >> >>>> longer handed out on the wireless interfaces. disabling and >> >>>> re-enabling DHCP on the wireless interfaces will fix the problem, but >> >>>> the problem >> >>>>[10:39:26] returns after a reboot. disable/reenable DHCP on >> >>>> the >> >>>> interface will again temporarily fix it. >> >>>>[10:42:03] also tried a fresh install (using reset to >> >>>> defaults >> >>>> option) to avoid anything not properly interpreted from the config of >> >>>> the previous version, but still get the same issue. >> >>>> >>
Re: [Dnsmasq-discuss] dumping current dhcp leases without always updating the leasefile curing normal ?
On Mon, Oct 14, 2013 at 9:42 AM, Simon Kelley wrote: > On 11/10/13 16:37, Rick Jones wrote: >> >> On 10/11/2013 07:16 AM, Simon Kelley wrote: >>> >>> On 11/10/13 01:39, Rick Jones wrote: I am still on the steep learning slope for dnsmasq. The manpage lists a -l/--dhcp-leasefile option into which dnsmasq will store lease information. I gather though that it will be updating that all the time as leases come and go. Is there a version post 2.59 where one can send dnsmasq a signal to cause it to dump a copy of its current lease information to a file, but without the continuous updates in normal operation? >>> >>> >>> >>> No. there's a mode meant for use on flash filesystems that updates the >>> lease file less often, if that helps. >> >> >> It might actually. I'll try to take a look at it. >> >> >>> See also this thread >>> >>> >>> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q3/007555.html >>> >> >> From that I should take away that the lease file format is not fixed >> and there but for the grace of the developers go I should I start >> grubbing through it, yes? I can accept that. >> >>> More context about what youre trying to achieve would help. >> >> >> What I would like to be able to do is "know" (make an informed guess) >> which of the clients which could have a lease probably have a lease (or >> probably do not have a lease), but in an environment where I might have >> either rather busy dnsmasq processes, or a large number of individually >> not very busy dnsmasq processes and want to minimize the storage load. >> But I don't need to know all the time, just occasionally and not >> necessarily on a schedule and not necessarily all the dnsmasq processes. >> So, I figured some sort of "dump your current leases" feature would >> satisfy that. >> >> I cannot really rely on the clients being willing to respond to the >> likes of ping, they may only respond to things they've initiated >> themselves. I also do not have other access to the clients (eg their >> console). So, all I can think of presently is trying to ask the dnsmasq >> process(es) what it believes its active leases happen to be. >> >> thanks, >> >> rick >> BTW, sorry about botching the last part of the subject there. >> > > You could achieve the two aims "minimise storage load" and "know about > dnsmasq leases" by implementing the lease database in some sort of > lightweight database. Dnsmasq is designed so it can be without a lease file > completely. At startup you prime the in-memory copy of the lease database > via a DHCP-script "init" call, and then whilst dnsmasq is running is makes > calls to the DHCP script as the data changes which can be used to update the > database. > > > Cheers, > > Simon. > There are also hooks for lua. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Fwd: [homenet] Fwd: WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd)
The problems cerowrt has with multicast dns over multiple interfaces are kind of universal. A new ietf working group is being formed to address the problems with service discovery beyond the local link and finally (I hope) re-unify mdns with regular DNS. See below for the announcement. One set of ideas also on the table is hybrid mdns: http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02 I'd really welcome a means of doing service discovery over routed links that was sane. To me, though, the grand unification of dns, needs a daemon written that integrates with things like dnsmasq much better than mdnsresponder or avahi currently do. There's a ton of things that are hard. For example dns parsing libs are generally all pretty limited, with the most comprehensive survey I've seen http://boston.conman.org/2010/12/06.1 and that's just the tip of the iceberg. What else is hard? The proxy needs to be small enough to run on routers, and powerful enough to scale to college campuses. I think there are some commercial possibilities, but not a lot, so it seems likely that hybrid dns needs to be an open source project. While I know there are quite a few people annoyed at present multicast dns behavior over local links - I don't know who would be interested in getting to exchange ideas from this wg and turn them into viable code, or who could fund the work? -- Forwarded message -- From: Tim Chown Date: Sat, Oct 26, 2013 at 12:54 AM Subject: [homenet] Fwd: WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd) To: "home...@ietf.org Group" Hi, For those who may have missed the announcement, the new dnssd WG has now been formed, see below. During the BoF phase the group was formerly known as mdnsext. The name of the mail list has thus also changed from mdns...@ietf.org to dn...@ietf.org (all subsrcibers of the former should have been moved to the latter). dnssd meets on Friday from 11:00am in Vancouver. The provisional agenda is here: https://datatracker.ietf.org/meeting/88/agenda/dnssd/ Tim Begin forwarded message: From: The IESG Subject: WG Action: Formed Extensions for Scalable DNS Service Discovery (dnssd) Date: 25 October 2013 18:06:40 BST To: IETF-Announce Cc: dnssd WG Reply-To: i...@ietf.org A new IETF working group has been formed in the Internet Area. For additional information please contact the Area Directors or the WG Chairs. Extensions for Scalable DNS Service Discovery (dnssd) Current Status: Proposed WG Chairs: Ralph Droms Tim Chown Assigned Area Director: Ted Lemon Mailing list Address: dn...@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/dnssd Archive: http://www.ietf.org/mail-archive/web/dnssd Charter: Background -- Zero configuration networking protocols are currently well suited to discover services within the scope of a single link. In particular, the DNS-SD [RFC 6763] and mDNS [RFC6762] protocol suite (sometimes referred to using Apple Computer Inc.'s trademark, Bonjour) are widely used for DNS-based service discovery and host name resolution on a single link. The DNS-SD/mDNS protocol suite is used in many scenarios including home, campus, and enterprise networks. However, the zero configuration mDNS protocol is constrained to link-local multicast scope by design, and therefore cannot be used to discover services on remote links. In a home network that consists of a single (possibly bridged) link, users experience the expected discovery behavior; available services appear because all devices share a common link. However, in multi-link home networks (as envisaged by the homenet WG) or in routed campus or enterprise networks, devices and users can only discover services on the same link, which is a significant limitation. This has led to calls, such as the Educause petition, to develop an appropriate service discovery solution to span multiple links or to perform discovery across a wide area, not necessarily on directly connected links. In addition, the "Smart Energy Profile 2 Application Protocol Standard", published by ZigBee Alliance and HomePlug Powerline Alliance specifies the DNS-SD/mDNS protocol suite as the basis for its method of zero configuration service discovery. However, its use of wireless mesh multi-link subnets in conjunction with traditional routed networks will require extensions to the DNS-SD/mDNS protocols to allow operation across multiple links. The scenarios in which multi-link service discovery is required may be zero configuration environments, environments where administrative configuration is supported, or a mixture of the two. As demand for service discovery across wider area routed networks grows, some vendors are beginning to ship proprietary solutions. It is thus both timely and important that efforts to develop improved, scalable, autonomous service discovery solutions for routed networks are coordinated towar
Re: [Dnsmasq-discuss] Can't ping when using FQDN
Using .local is generally reserved for multicast DNS. Don't do that. On Nov 8, 2013 1:37 AM, "Guillaume Betous" wrote: > > you must be right : > > domain domain.local > nameserver > nameserver > > 2013/11/8 Albert ARIBAUD : > > Le 08/11/2013 07:44, Guillaume Betous a écrit : > > > >> Hi ! > >> > >> I'm trying to setup my local network with a local domain (say > >> "domain.local"). > >> > >> In dnsmasq.conf : > >> - local=/domain.local/ > >> - domain=domain.local > >> - expand_hosts > >> > >> Only the server has a fixed IP address (192.168.0.11), all other use DNS : > >> DNS is based on machine hostname => this works great, all machine have > >> it's right IP address > >> e.g. : > >> - dhcp-host=foo,192.168.0.2,infinite > >> - dhcp-host=bar,192.168.0.30,infinite > >> > >> On the different machine, the /etc/resolv.conf seems to be correctly > >> updated : > >> domain domain.local > >> search domain.local > >> nameserver 192.168.0.11 > >> > >> > >> When I ping a computer, I have very different results following the test > >> case : > >> > >>> From other computer, with single name => OK > >> > >> > >> > >> guillaume@foo:~$ ping bar > >> PING bar.domain.local (192.168.0.30) 56(84) bytes of data. > >> 64 bytes from bar.domain.local (192.168.0.30): icmp_seq=1 ttl=64 time=110 > >> ms > >> 64 bytes from bar.domain.local (192.168.0.30): icmp_seq=2 ttl=64 time=153 > >> ms > >> 64 bytes from bar.domain.local (192.168.0.30): icmp_seq=3 ttl=64 time=78.1 > >> ms > >> > >>> From server, with single name => Not OK > >> > >> > >> > >> guillaume@server:~$ ping bar > >> ping: unknown host bar > >> > >>> From other computer or server, with full name => Not OK > >> > >> = > >> > >> guillaume@foo:~$ ping bar.domain.local > >> ping: unknown host bar.domain.local > >> > >> > >> Do you have an idea on what is wrong with my configuration ? > > > > > > Most probably the server is not configured to use itself as a DNS, and > > therefore relies on its /etc/hosts on for resolution; and as the names of > > the machine which dnsmasq serves are not in the server's /etc/hosts, they > > don't get resolved locally. > > > > What does /etc/resolv.conf contain on the server? > > > >> Thanks, > >> > >> gUI > > > > > > Amicalement, > > -- > > Albert. > > > > ___ > > Dnsmasq-discuss mailing list > > Dnsmasq-discuss@lists.thekelleys.org.uk > > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > -- > Pour la santé de votre ordinateur, préférez les logiciels libres. > Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/ > Browser le web : http://www.mozilla-europe.org/fr/products/firefox/ > Suite bureautique : http://www.libreoffice.org/download/ > > ___ > 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] Can't ping when using FQDN
On Nov 8, 2013 2:08 AM, "Guillaume Betous" wrote: > > what kind of local domain name can I use ? I thought the .local was > reserved for local networks... See http://en.wikipedia.org/wiki/.local > > gUI > > 2013/11/8 Dave Taht : > > > > Using .local is generally reserved for multicast DNS. > > > > Don't do that. > > > > On Nov 8, 2013 1:37 AM, "Guillaume Betous" > > wrote: > >> > >> you must be right : > >> > >> domain domain.local > >> nameserver > >> nameserver > >> > >> 2013/11/8 Albert ARIBAUD : > >> > Le 08/11/2013 07:44, Guillaume Betous a écrit : > >> > > >> >> Hi ! > >> >> > >> >> I'm trying to setup my local network with a local domain (say > >> >> "domain.local"). > >> >> > >> >> In dnsmasq.conf : > >> >> - local=/domain.local/ > >> >> - domain=domain.local > >> >> - expand_hosts > >> >> > >> >> Only the server has a fixed IP address (192.168.0.11), all other use > >> >> DNS : > >> >> DNS is based on machine hostname => this works great, all machine have > >> >> it's right IP address > >> >> e.g. : > >> >> - dhcp-host=foo,192.168.0.2,infinite > >> >> - dhcp-host=bar,192.168.0.30,infinite > >> >> > >> >> On the different machine, the /etc/resolv.conf seems to be correctly > >> >> updated : > >> >> domain domain.local > >> >> search domain.local > >> >> nameserver 192.168.0.11 > >> >> > >> >> > >> >> When I ping a computer, I have very different results following the > >> >> test > >> >> case : > >> >> > >> >>> From other computer, with single name => OK > >> >> > >> >> > >> >> > >> >> guillaume@foo:~$ ping bar > >> >> PING bar.domain.local (192.168.0.30) 56(84) bytes of data. > >> >> 64 bytes from bar.domain.local (192.168.0.30): icmp_seq=1 ttl=64 > >> >> time=110 > >> >> ms > >> >> 64 bytes from bar.domain.local (192.168.0.30): icmp_seq=2 ttl=64 > >> >> time=153 > >> >> ms > >> >> 64 bytes from bar.domain.local (192.168.0.30): icmp_seq=3 ttl=64 > >> >> time=78.1 > >> >> ms > >> >> > >> >>> From server, with single name => Not OK > >> >> > >> >> > >> >> > >> >> guillaume@server:~$ ping bar > >> >> ping: unknown host bar > >> >> > >> >>> From other computer or server, with full name => Not OK > >> >> > >> >> = > >> >> > >> >> guillaume@foo:~$ ping bar.domain.local > >> >> ping: unknown host bar.domain.local > >> >> > >> >> > >> >> Do you have an idea on what is wrong with my configuration ? > >> > > >> > > >> > Most probably the server is not configured to use itself as a DNS, and > >> > therefore relies on its /etc/hosts on for resolution; and as the names > >> > of > >> > the machine which dnsmasq serves are not in the server's /etc/hosts, > >> > they > >> > don't get resolved locally. > >> > > >> > What does /etc/resolv.conf contain on the server? > >> > > >> >> Thanks, > >> >> > >> >> gUI > >> > > >> > > >> > Amicalement, > >> > -- > >> > Albert. > >> > > >> > ___ > >> > Dnsmasq-discuss mailing list > >> > Dnsmasq-discuss@lists.thekelleys.org.uk > >> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > >> > >> > >> > >> -- > >> Pour la santé de votre ordinateur, préférez les logiciels libres. > >> Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/ > >> Browser le web : http://www.mozilla-europe.org/fr/products/firefox/ > >> Suite bureautique : http://www.libreoffice.org/download/ > >> > >> ___ > >> Dnsmasq-discuss mailing list > >> Dnsmasq-discuss@lists.thekelleys.org.uk > >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > -- > Pour la santé de votre ordinateur, préférez les logiciels libres. > Lire son mail : http://www.mozilla-europe.org/fr/products/thunderbird/ > Browser le web : http://www.mozilla-europe.org/fr/products/firefox/ > Suite bureautique : http://www.libreoffice.org/download/ ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dhcp-pd, and autoassigned internal interfaces issues
I have finally got my first-ever comcast ipv6 set of users up, and we have a problem with the interrelationship between addresses assigned dynamically by dhcpv6-pd and other means in dnsmasq 2.68. What happens now is that dhcpv6-pd works but dnsmasq 2.68 filters out the interface 13: sw00: mtu 1500 qlen 1000 inet6 2601:X:Y:9a1::1/64 scope global dynamic valid_lft 182420sec preferred_lft 182420sec so sends no ras. adding a second "stable" interface dnsmasq picks up. inet6 2601:3:8180:9a1::2/64 scope global valid_lft forever preferred_lft forever this check was not in dnsmasq 2.66, and was put in later for fairly sound reasons (like you don't want to start serving RAs on a SLAAC assigned address), but in the dhcp-pd case or otherwise assigned by the router (6in4) case, we do. Anyway the below patch "fixes it" but I'd like there to be some clear indicator of where things came from somehow. >From 4f55df81d69d20230e18c90d772904372b2b90a4 Mon Sep 17 00:00:00 2001 >From: Jonas Gorski >Date: Wed, 8 Jan 2014 11:55:08 +0100 >Subject: [PATCH] allow dhcp range construction with non-permanent addresses The linux kernel treats all addresses with a limited lifetime as being non permanent, but when taking over the prefix livetimes from upstream assigned prefixes through DHCP, addresses will always have a limited lifetime. Still reject temporary addresses, as they indicate autoconfigured interfaces. Contributed by T-Labs, Deutsche Telekom Innovation Laboratories Signed-off-by: Jonas Gorski --- src/netlink.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/netlink.c b/src/netlink.c index 3be94ee..d5de4ab 100644 --- a/src/netlink.c +++ b/src/netlink.c @@ -265,7 +265,7 @@ int iface_enumerate(int family, void *parm, int (*callback)()) if (ifa->ifa_flags & IFA_F_DEPRECATED) flags |= IFACE_DEPRECATED; -if (ifa->ifa_flags & IFA_F_PERMANENT) +if (!(ifa->ifa_flags & IFA_F_TEMPORARY)) flags |= IFACE_PERMANENT; if (addrp && callback_ok) -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-pd, and autoassigned internal interfaces issues
Both dnsmasq in git head and odhcpd in openwrt do as close to the right thing as possible now. I released a version of cerowrt that worked "right" in this scenario yesterday, specifically for comcast subscribers, with the patch for dnsmasq (if you want to use that) but with odhcpd support by default. The latter is upstream in openwrt, and dnsmasq 2.68 (with the less than desirable filter) is not there either, yet, so that's all good. On Wed, Jan 22, 2014 at 9:56 AM, John Gorkos wrote: > So, in this scenario, what's the appropriate configuration to allow machines > in the network served by the delegated prefix to get SLAAC addresses and > provide them with Route Advertisements? > This goes back to the question that I asked in November that got no > traction: > http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q4/007810.html > , as I'm using a Comcast DHCPv6 assigned address with prefix delegation as > well. > > John Gorkos > > > > On 1/22/14, 6:37 AM, Simon Kelley wrote: >> >> Patch applied. >> >> >> >> Cheers, >> >> Simon. >> >> On 21/01/14 16:19, Dave Taht wrote: >>> >>> I have finally got my first-ever comcast ipv6 set of users up, and we >>> have a problem >>> with the interrelationship between addresses assigned dynamically by >>> dhcpv6-pd and other means in dnsmasq 2.68. >>> >>> What happens now is that dhcpv6-pd works but dnsmasq 2.68 filters out the >>> interface >>> >>> 13: sw00: mtu 1500 qlen 1000 >>> inet6 2601:X:Y:9a1::1/64 scope global dynamic >>> valid_lft 182420sec preferred_lft 182420sec >>> >>> so sends no ras. >>> >>> adding a second "stable" interface dnsmasq picks up. >>> >>> >>> inet6 2601:3:8180:9a1::2/64 scope global >>> valid_lft forever preferred_lft forever >>> >>> >>> this check was not in dnsmasq 2.66, and was put in later for fairly >>> sound reasons >>> (like you don't want to start serving RAs on a SLAAC assigned >>> address), but in the >>> dhcp-pd case or otherwise assigned by the router (6in4) case, we do. >>> >>> Anyway the below patch "fixes it" but I'd like there to be some clear >>> indicator >>> of where things came from somehow. >>> >>>> From 4f55df81d69d20230e18c90d772904372b2b90a4 Mon Sep 17 00:00:00 2001 >>>> From: Jonas Gorski >>>> Date: Wed, 8 Jan 2014 11:55:08 +0100 >>>> Subject: [PATCH] allow dhcp range construction with non-permanent >>>> addresses >>> >>> >>> The linux kernel treats all addresses with a limited lifetime as being >>> non permanent, but when taking over the prefix livetimes from upstream >>> assigned prefixes through DHCP, addresses will always have a limited >>> lifetime. >>> >>> Still reject temporary addresses, as they indicate autoconfigured >>> interfaces. >>> >>> Contributed by T-Labs, Deutsche Telekom Innovation Laboratories >>> >>> Signed-off-by: Jonas Gorski >>> --- >>> src/netlink.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/src/netlink.c b/src/netlink.c >>> index 3be94ee..d5de4ab 100644 >>> --- a/src/netlink.c >>> +++ b/src/netlink.c >>> @@ -265,7 +265,7 @@ int iface_enumerate(int family, void *parm, int >>> (*callback)()) >>> if (ifa->ifa_flags& IFA_F_DEPRECATED) >>> flags |= IFACE_DEPRECATED; >>> >>> -if (ifa->ifa_flags& IFA_F_PERMANENT) >>> +if (!(ifa->ifa_flags& IFA_F_TEMPORARY)) >>> flags |= IFACE_PERMANENT; >>> >>> if (addrp&& callback_ok) >>> >>> >> >> >> ___ >> 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 -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dhcp-pd, and autoassigned internal interfaces issues
On Tue, Jan 21, 2014 at 5:13 PM, Simon Kelley wrote: > On 21/01/14 16:19, Dave Taht wrote: >> >> I have finally got my first-ever comcast ipv6 set of users up, and we >> have a problem >> with the interrelationship between addresses assigned dynamically by >> dhcpv6-pd and other means in dnsmasq 2.68. >> >> What happens now is that dhcpv6-pd works but dnsmasq 2.68 filters out the >> interface >> >> 13: sw00: mtu 1500 qlen 1000 >> inet6 2601:X:Y:9a1::1/64 scope global dynamic >> valid_lft 182420sec preferred_lft 182420sec >> >> so sends no ras. >> >> adding a second "stable" interface dnsmasq picks up. >> >> >> inet6 2601:3:8180:9a1::2/64 scope global >> valid_lft forever preferred_lft forever >> >> >> this check was not in dnsmasq 2.66, and was put in later for fairly >> sound reasons >> (like you don't want to start serving RAs on a SLAAC assigned >> address), but in the >> dhcp-pd case or otherwise assigned by the router (6in4) case, we do. >> >> Anyway the below patch "fixes it" but I'd like there to be some clear >> indicator >> of where things came from somehow. > > > Comparing the code in bpf.c (for *BSD) and netlink.c (for Linux) I think > it's clear what's meant: exclusion of privacy addresses and addresses > installed as a result of RAs received. The patch covers the first of those, > but there doesn't seem to be a Linux equivalent of the BSD IN6_IFF_AUTOCONF > flag to detect RA-originated addresses. I looked at the kernel source, and > there's no candidate I can see. > > I suspect that this patch is the best that can be done. Well, no, we can always go off and get this BSD IPv6 RA flag into the Linux kernel too. :) Looks needed and useful. And trivial. > > > Cheers, > > Simon. > > >> >>> From 4f55df81d69d20230e18c90d772904372b2b90a4 Mon Sep 17 00:00:00 2001 >>> From: Jonas Gorski >>> Date: Wed, 8 Jan 2014 11:55:08 +0100 >>> Subject: [PATCH] allow dhcp range construction with non-permanent >>> addresses >> >> >> The linux kernel treats all addresses with a limited lifetime as being >> non permanent, but when taking over the prefix livetimes from upstream >> assigned prefixes through DHCP, addresses will always have a limited >> lifetime. >> >> Still reject temporary addresses, as they indicate autoconfigured >> interfaces. >> >> Contributed by T-Labs, Deutsche Telekom Innovation Laboratories >> >> Signed-off-by: Jonas Gorski >> --- >> src/netlink.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/src/netlink.c b/src/netlink.c >> index 3be94ee..d5de4ab 100644 >> --- a/src/netlink.c >> +++ b/src/netlink.c >> @@ -265,7 +265,7 @@ int iface_enumerate(int family, void *parm, int >> (*callback)()) >> if (ifa->ifa_flags & IFA_F_DEPRECATED) >> flags |= IFACE_DEPRECATED; >> >> -if (ifa->ifa_flags & IFA_F_PERMANENT) >> +if (!(ifa->ifa_flags & IFA_F_TEMPORARY)) >> flags |= IFACE_PERMANENT; >> >> if (addrp && callback_ok) >> >> > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNSSEC enabled dnsmasq dies very quickly
Dnsmasq is barely in git with dnssec support, So it would help to clearly identify what commit number you are working from. ? And: Pull early, pull often. On Jan 26, 2014 5:47 PM, "e9hack" wrote: > Hi, > > for testing purpose, I compile dnsmasq with option -DHAVE_DNSSEC. After a > few name > queries, dnsmasq dies. In the example, I start firefox on Windows 7. After > a few queries, > dnsmasq isn't longer running: > > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: query[A] > secure.informaction.com from > 192.168.100.2 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > secure.informaction.com to > 192.168.26.1 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > secure.informaction.com to > 8.8.8.8 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > secure.informaction.com to > 2001:4860:4860:: > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > secure.informaction.com to > fe80::1 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: reply > secure.informaction.com is > 69.195.141.179 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: query[] > secure.informaction.com > from 192.168.100.2 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > secure.informaction.com to > 192.168.26.1 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: reply > secure.informaction.com is > NODATA-IPv6 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: query[A] > ocsp.godaddy.com from > 192.168.100.2 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > ocsp.godaddy.com to 192.168.26.1 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: reply ocsp.godaddy.comis > > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: reply > ocsp.godaddy.com.akadns.net is > 188.121.36.239 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: query[] > ocsp.godaddy.com from > 192.168.100.2 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: cached > ocsp.godaddy.com is > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: forwarded > ocsp.godaddy.com to 192.168.26.1 > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: reply ocsp.godaddy.comis > > Sun Jan 26 12:04:57 2014 daemon.info dnsmasq[1880]: reply > ocsp.godaddy.com.akadns.net is > NODATA-IPv6 > > My test setup is a carambola box with the current trunk of OpenWRT. If I > compile it > without -DHAVE_DNSSEC, it runs perfectly. > > Regards, > Hartmut > > ___ > 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] coping with ipv6 source routing and dns
I have been (mostly) happily fiddling with my new comcast ipv6 connection, trying to route all dns queries over ipv6 in particular, by disabling requesting the ipv4 dns addrs and relying on the dhcpv6 request to succeed. config interface eth0 option 'ifname' 'eth0' option 'proto' 'dhcp' option 'peerdns' '0' config interface wan6 option ifname @eth0 option protodhcpv6 option 'broadcast' '1' option 'metric' '2048' works. yea! no more nat holes for ipv4 dns. Problem is, I also have a hurricane electric tunnel. When I try to use both, addresses from one get used on the other and dns forward lookups fail. I think the right answer is to abandon resolv.conf.auto and instead explicitly assign ipv6 source addrs in dnsmasq... server=2001:558:feed::1@:comcast:assigned:ipv6:address server=2001:558:feed::2@:comcast.assigned:ipv6:address server=2001:470:20::2@my:hurricane:assigned:ipv6:address yes? (I'll be trying this in a bit) One thing of possible useful note is that (yea!) we can just select some arbitrary new ipv6 address within the assigned range, add it to the local dnsmasq server box, and source dns lookups from that, using up just that port space. then my own /etc/resolv.conf just points to localhost for hm.armory.com, so I fix that with server=/hm.armory.com/172.26.3.1/ server=/wifi.armory.com/172.26.2.1/ But this doesn't help in terms of reverse lookups (I think), where I might or might not have my own delegated subdomain. from someoption= comcast.assigned.ipv6.address.range/60 lookup via 2001:558:feed::1 or ::2 someoption= he.assigned.ipv6.address.range/48 lookup via 2001:470:20::2 ? and then there's splitting dns... where I might want nuc.hm.armory.com s available to the outside universe. somehow. ? My brain hurts. -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] coping with ipv6 source routing and dns
On Wed, Jan 29, 2014 at 2:02 PM, Toke Høiland-Jørgensen wrote: > Dave Taht writes: > >> works. yea! no more nat holes for ipv4 dns. > > Eh? Nat holes for DNS? What exactly are you doing, and what is your > setup? :) > > -Toke 1 case: Since most forwarders can't be trusted to return NXDOMAIN, an internal email box at several of my sites runs dns directly. A few dnsrbl providers offer ipv6 transport, so it's possible. One advantage of dnssec is we get NXDOMAIN working again, so a forwarder can be used... -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] coping with ipv6 source routing and dns
On Thu, Jan 30, 2014 at 1:57 AM, Simon Kelley wrote: > On 29/01/14 19:22, Dave Taht wrote: >> >> I have been (mostly) happily fiddling with my new comcast ipv6 connection, >> trying to route all dns queries over ipv6 in particular, by disabling >> requesting the ipv4 dns addrs and relying on the dhcpv6 request to >> succeed. >> >> config interface eth0 >> option 'ifname' 'eth0' >> option 'proto' 'dhcp' >> option 'peerdns' '0' >> >> config interface wan6 >> option ifname @eth0 >> option protodhcpv6 >> option 'broadcast' '1' >> option 'metric' '2048' >> >> works. yea! no more nat holes for ipv4 dns. >> >> Problem is, I also have a hurricane electric tunnel. When I try to use >> both, addresses from one get used on the other and dns forward >> lookups fail. >> >> I think the right answer is to abandon resolv.conf.auto >> and instead explicitly assign ipv6 source addrs in dnsmasq... >> >> server=2001:558:feed::1@:comcast:assigned:ipv6:address >> server=2001:558:feed::2@:comcast.assigned:ipv6:address >> server=2001:470:20::2@my:hurricane:assigned:ipv6:address To try to explain the reasoning for this better, the first two servers refuse requests from an address range assigned the third. This is probably because the first two are not open resolvers. >> >> yes? (I'll be trying this in a bit) >> >> One thing of possible useful note is that (yea!) we can just >> select some arbitrary new ipv6 address within the assigned range, >> add it to the local dnsmasq server box, and source dns lookups from >> that, using up just that port space. >> >> then my own /etc/resolv.conf just points to localhost >> for hm.armory.com, >> >> so I fix that with >> >> server=/hm.armory.com/172.26.3.1/ >> server=/wifi.armory.com/172.26.2.1/ >> >> But this doesn't help in terms of reverse lookups (I think), >> where I might or might not have my own delegated subdomain. >> >> from >> >> someoption= >> comcast.assigned.ipv6.address.range/60 lookup via 2001:558:feed::1 or ::2 >> someoption= >> he.assigned.ipv6.address.range/48 lookup via 2001:470:20::2 >> > > I'm not sure I follow all of this, but for reverse DNS something like > server=/.ip6.arpa/2001:558:feed::1 > > Will work. Syntactically having to have a tool to reverse the domain is a pita, what I'd like is reverse=#260x:x:y:z::/60#2001:558:feed::1# > >> ? >> >> and then there's splitting dns... where I might want nuc.hm.armory.com >> s available to the outside universe. somehow. > > > Have you looked at the dnsmasq auth stuff for this? head, hurting. > > > Simon. > >> >> ? >> >> >> My brain hurts. >> >> >> >> > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Fwd: [Cerowrt-devel] Fwd: Testers wanted: DNSSEC.
-- Forwarded message -- From: Toke Høiland-Jørgensen Date: Wed, Feb 5, 2014 at 12:10 PM Subject: Re: [Cerowrt-devel] Fwd: [Dnsmasq-discuss] Testers wanted: DNSSEC. To: Dave Taht Cc: "cerowrt-de...@lists.bufferbloat.net" Toke Høiland-Jørgensen writes: > Can add it to my bufferbloat OBS :) Right, so packages available for Arch, Debian 7 and Ubuntu 12.04, 12.10 and 13.10 are available from here: https://build.opensuse.org/project/repositories/home:tohojo:dnsmasq For some reason, signature verification is failing for me on the Arch repo. Also, installed it on my workstation, and it seems to do *something* at least. Running with --log-queries I get output like this: dnsmasq[19525]: dnssec-query[DNSKEY] tohojo.dk to 127.0.0.1 dnsmasq[19525]: dnssec-query[DNSKEY] tohojo.dk to 127.0.0.1 dnsmasq[19525]: dnssec-query[DS] tohojo.dk to 127.0.0.1 dnsmasq[19525]: dnssec-query[DS] tohojo.dk to 127.0.0.1 dnsmasq[19525]: reply tohojo.dk is DS keytag 49471 dnsmasq[19525]: reply tohojo.dk is DNSKEY keytag 30141 dnsmasq[19525]: reply tohojo.dk is DNSKEY keytag 49471 dnsmasq[19525]: validation result is SECURE (I'm still running BIND on localhost on a different port which is why it's forwarded to there...) And sometimes there's also lines saying dnsmasq[19525]: validation result is INSECURE but mostly from in-addr.arpa and other places that I wouldn't expect to be verified. Finally there's a bunch of queries that don't say anything about dnssec anywhere. Oh, and --dnssec-debug doesn't seem to do anything. -Toke -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html signature.asc Description: PGP signature ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Speed comparison dnsmasq <-> unbound?
On Sun, Feb 16, 2014 at 9:06 AM, /dev/rob0 wrote: > On Sun, Feb 16, 2014 at 07:38:37AM +0100, Oliver Rath wrote: >> did somebody some speed comparison tests for the dns caching >> functionality between dnsmasq and unbound (http://unbound.net/)? > > Compare apples to apples. You're not doing that. > > Dnsmasq is a DNS forwarder. Unbound is a DNS resolver. Unbound > actually does the work of accepting recursive queries and then > performing the iterative queries to find the answer. To be mildly more clear, DNSmasq is a caching forwarder, (although I just discovered caching is turned off in ubuntu's implementation) While not a recursing resolver, it can be configured as a primary dns server for a small set of (sub)domains easily. The fact that it caches, however, is very important. > Dnsmasq simply hands off these queries to a backend resolver, such as > BIND named or unbound. Accordingly, I'd expect dnsmasq to be faster, > but noting that the comparison is meaningless. > >> Ive read that unbound is the fastest dns caching server including >> dnssec support, but I could imagine, that dnsmasq has the same >> speed (or better). > > I've read a lot of things on the Internet. Some of them might have > been true. Unqualified claims of "speed" are usually bogus. Such > claims are especially difficult to establish in the realm of DNS, > because your apparent speed is largely dependent upon random third > parties' servers and the speed of their Internet connections. > > Do you have a link to these speed studies? I'd like to see them. > >> Unbound is the new standard dns caching server in FreeBSD 10 and >> replaces bind. > > IIUC that's only partly true. BIND is a complete DNS implementation, > whereas unbound is only a caching resolver. Those who are serving > authoritative DNS to the world also need an authoritative DNS server > such as BIND named or NLNetLabs' NSD. > > Note, best practice usually demands separation of authoritative DNS > service from recursive service. Unbound/NSD were began with this > understanding, whereas BIND has roots going back to the very > beginnings of DNS. > > (The fact that named can do it all in one notwithstanding, this is > not what ISC recommends. But it is a convenience for some small, > internal-only sites, where that might override security concerns.) > >> Just for interest. > -- > 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 -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq, NetworkManager and VPNs
Simon just added support for dynamically adding/removing an upstream dns server and reverse resolver in the upcoming release which I think will handle your use case. On Thu, Mar 6, 2014 at 1:39 AM, Tony Breeds wrote: > Hi All, > I'm a new user of dnsmasq and I can't see an easy way to do what > I want to do. > > My situation is (probably not that uncommon) I need to connect to a work > VPN and while I'm connected to said VPN I need to query work's DNS > servers for company.com addresses but all other queries should go > through my normal (as supplied by DHCP) DNS servers. > > I tried adding a config file like: > server=/company.com/DNS_SERVER_1@interface > server=/company.com/DNS_SERVER_2@interface > server=/I.P.ADDR.in-addr.arpa/DNS_SERVER_1@interface > server=/I.P.ADDR.in-addr.arpa/DNS_SERVER_2@interface > > Now my problem is that if that file exists when dnsmasq starts and my > VPN interface isn't up, dnsmasq prints an error and exits. This is > especially painful as I'm starting dnsmasq from NetworkManager (by > setting dns=dnsmasq in the NetworkManager config file) > > I can run a script that adds and removes the config file on VPN up/down > events but I can't find a way to re-read all the config files for a > running dnsmasq process. > > My next thought was to use the dbus interface to "inject" the above > configuration to the running dnsmasq server, but I don't see a syntax > that will remove the configuration when I take down my VPN. > > So any advice? this must be possible, perhaps I just need to be more > creative. > > Tony. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Setting dns domain name through dhcpv6
I'd like to note that we are trying to get away from resolve.conf.auto in a couple cases, notably when you have multiple upstreams and you want reverse queries to go to the right place. A search list doesn't cut it in that case. BUT supplying a search list makes sense to clients. On Mar 8, 2014 1:29 AM, "Roy Marples" wrote: > On 08/03/2014 8:36, Simon Kelley wrote: > >> On 07/03/14 21:42, Tom Hendrikx wrote: >> >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA256 >>> >>> Hi, >>> >>> I'm using dnsmasq 2.66 to provide my local network with ipv4 dhcp, and >>> ipv6 information requests (ip addressing is handled by my router). >>> >>> I'm able to to provide clients with a dns-server and such through >>> dhcpv6, but I'm failing to find the dhcp option that sets 'domain >>> lan.example.org' in /etc/resolv.conf, i.e. the v6 equivalent of >>> dhcp-option=option:domain-name,lan.example.org >>> >>> Can anyone enlighten me? I've searching through >>> https://www.iana.org/assignments/dhcpv6-parameters/ >>> dhcpv6-parameters.xhtml >>> but I'm failing to find something useful... >>> >> >> What you want is option 39, OPTION_CLIENT_FQDN >> > > domain in resolv.conf(5) isn't normally used. I wouldn't expect any DHCP > clients to put it there based on the FQDN. > dhcpcd(8) does :) > > What you probably want is option 24, OPTION_DOMAIN_LIST which I would > expect every DHCP client to fill out the search entry instead of the domain > entry. > If you read resolv.conf(5) you'll find that both pretty much do the same > thing, but search allows >1 entry. > > Roy > > ___ > 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] Announce: dnsmasq-2.69rc1
ATIC' >> >> which bloats the dnsmasq binary to over a megabyte, but >> saves the size of the shared libraries which are five >> times that size. >> To enable, DNSSEC, you will need a set of >> trust-anchors. Now that the TLDs are signed, this can be >> the keys for the root zone, and for convenience they are >> included in trust-anchors.conf in the dnsmasq >> distribution. You should of course check that these are >> legitimate and up-to-date. So, adding >> >> conf-file=/path/to/trust-anchors.conf >> dnssec >> >> to your config is all thats needed to get things >> working. The upstream nameservers have to be DNSSEC-capable >> too, of course. Many ISP nameservers aren't, but the >> Google public nameservers (8.8.8.8 and 8.8.4.4) are. >> When DNSSEC is configured, dnsmasq validates any queries >> for domains which are signed. Query results which are >> bogus are replaced with SERVFAIL replies, and results >> which are correctly signed have the AD bit set. In >> addition, and just as importantly, dnsmasq supplies >> correct DNSSEC information to clients which are doing >> their own validation, and caches DNSKEY, DS and RRSIG >> records, which significantly improve the performance of >> downstream validators. Setting --log-queries will show >> DNSSEC in action. >> >> The development of DNSSEC in dnsmasq was started by >> Giovanni Bajo, to whom huge thanks are owed. It has been >> supported by Comcast, whose techfund grant has allowed for >> an invaluable period of full-time work to get it to >> a workable state. >> >> Add --rev-server. Thanks to Dave Taht for suggesting this. >> >> Add --servers-file. Allows dynamic update of upstream >> servers full access to configuration. >> >> Add --local-service. Accept DNS queries only from hosts >> whose address is on a local subnet, ie a subnet for which >> an interface exists on the server. This option >> only has effect if there are no --interface --except- >> interface, --listen-address or --auth-server options. It is >> intended to be set as a default on installation, to allow >> unconfigured installations to be useful but also safe from >> being used for DNS amplification attacks. >> >> Fix crashes in cache_get_cname_target() when dangling CNAMEs >> encountered. Thanks to Andy and the rt-n56u project for >> find this and helping to chase it down. >> >> >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > -- > - > () ascii ribbon campaign - against html e-mail > /\ > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Stats improvement
I would certainly like to have a standard way of getting these statistics, through the dns, perhaps one unified with whatever bind and unbound use (or don't use.) Not a lot of people seem to be aware of why dns caching forwarders are so great, although benchmarks like namebench against your chrome or firefox cache are quite revealing, parsing huge network captures as I am presently to try to get a grip on timings for dns/response pairing is a pita and not router centric. However: Do check out namebench, it's pretty cool. It does bug me that in tests against the alexa top 2000 that it invariably selects some other dns server besides your local one as being the "best", because it has the best average - as if you regularly go to websites in timbuktu and care about the response time more than, say, google. Example against alexa top 2000 with a fresh cache: http://snapon.lab.bufferbloat.net/~d/namebench/namebench_2014-03-20_1255.html It is much better to test against your more common query set, which I don't have a snapshot of on that site presently - usually 40% or more of queries are resolved in a ms, 30% or so via your ISP in under 20ms. I'd love to see people posting namebench results from against their firefox/chrome caches... it's in apt on ubuntu at least the version I have is buggy, you have to hit control-C at least once for the gui to come up. On Mon, Mar 24, 2014 at 2:55 PM, Simon Kelley wrote: > On 24/03/14 11:25, Olivier Mauras wrote: >> >> >> Hello, >> >> I was wondering what would be the effort, and if there'd >> actually be any interest for some dnsmasq statistics improvements. (Yes >> i'm splitting dicussions ^^) >> For monitoring/graph purposes, actual >> dnsmasq stats are a bit difficult to use and completely unusable if >> using "log_queries" as it takes too long to retrieve them inside >> logs. >> >> I'd love to see a stats "interface" that would output >> total_queries, cache_hits, cache_misses, memory used by cache, >> etc >> >> Thanks, >> Olivier >> > > There's an idea to make this available as a DNS query, in the same way that > > > dig chaos txt version.bind > > returns the version number. > > Comments? > > Cheers, > > Simon. > > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Stats improvement
On Mon, Mar 24, 2014 at 3:21 PM, Dave Taht wrote: > I would certainly like to have a standard way of getting these > statistics, through the dns, perhaps one unified with whatever bind > and unbound use (or don't use.) > > Not a lot of people seem to be aware of why dns caching forwarders are > so great, although benchmarks like namebench against your chrome or > firefox cache are quite revealing, parsing huge network captures as > I am presently to try to get a grip on timings for dns/response > pairing is a pita and not router centric. > > However: > > Do check out namebench, it's pretty cool. It does bug me that in tests > against the alexa top 2000 that it invariably selects some other dns > server besides your local one as being the "best", because it has > the best average - as if you regularly go to websites in timbuktu and > care about the response time more than, say, google. > > Example against alexa top 2000 with a fresh cache: > > http://snapon.lab.bufferbloat.net/~d/namebench/namebench_2014-03-20_1255.html > > It is much better to test against your more common query set, which I > don't have a snapshot of on that site presently - usually 40% or more > of queries are resolved in a ms, 30% or so via your ISP in under 20ms. > > I'd love to see people posting namebench results from against their > firefox/chrome caches... it's in apt on ubuntu at least > > the version I have is buggy, you have to hit control-C at least once > for the gui to come up. I just did a namebench test against my local firefox cache (without clearing dnsmasq's caches) http://snapon.lab.bufferbloat.net/~d/namebench/namebench_2014-03-24_1541.html note that I have three dns servers in place - one on my local machine, a dnsmasq locally that is sending stuff over ipv6 to another dnsmasq which is then connected over ipv4 and ipv6 to comcasts forwarders. > > > On Mon, Mar 24, 2014 at 2:55 PM, Simon Kelley wrote: >> On 24/03/14 11:25, Olivier Mauras wrote: >>> >>> >>> Hello, >>> >>> I was wondering what would be the effort, and if there'd >>> actually be any interest for some dnsmasq statistics improvements. (Yes >>> i'm splitting dicussions ^^) >>> For monitoring/graph purposes, actual >>> dnsmasq stats are a bit difficult to use and completely unusable if >>> using "log_queries" as it takes too long to retrieve them inside >>> logs. >>> >>> I'd love to see a stats "interface" that would output >>> total_queries, cache_hits, cache_misses, memory used by cache, >>> etc >>> >>> Thanks, >>> Olivier >>> >> >> There's an idea to make this available as a DNS query, in the same way that >> >> >> dig chaos txt version.bind >> >> returns the version number. >> >> Comments? >> >> Cheers, >> >> Simon. >> >> >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] dnsmasq-2.68 vs. dnsmasq-2.69rc1 Coverity scan diff
did you also compile with dhcpv6 support enabled? On Tue, Mar 25, 2014 at 7:33 AM, Tomas Hozza wrote: > > > - Original Message - >> On 24/03/14 13:51, Tomas Hozza wrote: >> > Hi. >> > >> > I did a version diff scan between 2.68 and 2.69rc1 version. >> >>From my point of view there is one thing worth of fixing, >> > I'm attaching the patch. >> > >> > I'm also attaching the coverity scan log. >> > >> > Regards, >> > >> > Tomas Hozza >> > >> > >> >> Thanks, I agree there's a problem if recvfrom() fails and returns -1. >> The solution is to get the sanity checks right, since is already checks >> that n < sizeof(struct dns_header), just too late. I've committed a fix: >> >> >> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=490f90758dba741b10a2af6b70eb561777575e04 > > Looks reasonable, too. > >> Cheers, >> >> Simon. > > Hi Simon. > > Unfortunately I noticed, that I didn't enabled the new DNSSEC functionality > during the Coverity scan :) I did the scan again and found more issues worth > of fixing. > > Please see the attached log and patches. > > Regards, > > Tomas > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq doesn't send RA
On Thu, Mar 27, 2014 at 8:12 AM, Stéphane Guedon wrote: > Le jeudi 27 mars 2014, 10:30:30 John Gorkos a écrit : >> This sounds remarkably similar to the problem I described here: >> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q4/0078 >> 10.html Mine is on a Debian system, but the symptoms are the same. >> >> I never did find a solution. I simply run radvd in parallel with >> dnsmasq. John Gorkos >> > > the good thing with dnsmasq is that it can replace four softwares > (dhcp4 and 6, dns,ra) at once, with simple conf coordinated together. The ra-names feature worked for cerowrt for over a year. Is it possible you are having the problem with picking up addresses that had expiry times? (fixed in head, sorta) easy test: create a second static ipv6 address on the box and see if ra's work: for example, if your system has inet6 2001:db8::1/64 scope global valid_lft 544 preferred_lft 8321 do an ip -6 addr add 2001:db8::2/64 and see if that triggers dnsmasq to send ras. > But you don't have dnssec validation, nor nat64 (that's fine if > everything the rest works, you can waith for the function to be > mature). > > If you can't do ra again and serve the corresponding ipv6 names, that > begin to be really annoying... > > If I need to run radvd seperately, I think I am going to switch back > to dhcp and unbound (which are already setup). > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Stats improvement
On Fri, Mar 28, 2014 at 9:35 AM, Dave Taht wrote: > On Thu, Mar 27, 2014 at 1:57 PM, Simon Kelley wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> On 26/03/14 05:12, Olivier Mauras wrote: >>> Yes it should definitely be TXT records. Sounds really good to me. >>> >>> for upstream servers, why not having upstream.bind return total >>> queries forwarded + list of upstream servers that can then be check >>> individually with: dig TXT .upstream.bind >> >> OK. Code in git now. >> >> Try eg >> >> dig +short chaos txt misses.bind >> >> and >> >> dig +short chaos txt servers.bind > > I haven't looked at the code yet, but my take on this was originally that > I'd wanted a single dns reply for all the statistics (can live > without), 64 bit counters, and not only tracking misses but the > latency cost of a miss. Then there are misses that are never latency cost of a fill, I meant. This would end up giving stats that are comparable to namebench. > resolved... and (even harder), things like a 5 minute rolling > average... and a breakdown by query type (, A, DS, etc) > > gettimeofday() is very efficient on modern linuxes (it gets the time from a > shared page cache without even making a syscall), but I can see that > you might want to be able to compile that out. > > And I wasn't expecting you to get to it in this release! Just basic stats is > great > > >> >> >> Cheers, >> >> Simon. >> >>> >>> >>> Olivier >>> >>> On Tue, 2014-03-25 at 21:37 +, Simon Kelley wrote: >>>> My feeling it that this should use TXT records, then they can be >>>> extracted into any application using eg >>>> >>>> dig +short chaos txt stats.bind >>>> >>>> or the equivalent, which outputs the string to stdout. >>>> >>>> The current code has, >>>> >>>> >>>> cache-size, insertions which evicted unexpired cache entries, >>>> queries forwarded, queries answered locally, queries for auth >>>> zones. >>>> >>>> >>>> then for each upstream server, >>>> >>>> queries sent, and queries retried or failed. >>>> >>>> We could have >>>> >>>> size.bind and evictions.bind for cache size and evictions >>>> local.bind, upstream.bind and auth.bind for queries. >>>> >>>> But how to handle the variable number of upstream servers. Just >>>> free text? >>>> >>>> >>>> >>>> Simon. >>>> >>>> Enigmail On 24/03/14 22:53, Olivier Mauras wrote: >>>>> >>>>> >>>>> On Mon, 2014-03-24 at 21:55 +, Simon Kelley wrote: >>>>>> On 24/03/14 11:25, Olivier Mauras wrote: >>>>>>> >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I was wondering what would be the effort, and if there'd >>>>>>> actually be any interest for some dnsmasq statistics >>>>>>> improvements. (Yes i'm splitting dicussions ^^) For >>>>>>> monitoring/graph purposes, actual dnsmasq stats are a bit >>>>>>> difficult to use and completely unusable if using >>>>>>> "log_queries" as it takes too long to retrieve them inside >>>>>>> logs. >>>>>>> >>>>>>> I'd love to see a stats "interface" that would output >>>>>>> total_queries, cache_hits, cache_misses, memory used by >>>>>>> cache, etc >>>>>>> >>>>>>> Thanks, Olivier >>>>>>> >>>>>> >>>>>> There's an idea to make this available as a DNS query, in >>>>>> the same way that >>>>>> >>>>>> >>>>>> dig chaos txt version.bind >>>>>> >>>>>> returns the version number. >>>>>> >>>>>> Comments? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Simon. >>>>>> >>>>>> >>>>> >>>>> That would be a really good way of doing it! >>>>> >>>> >>> >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.11 (GNU/Linux) >> Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ >> >> iEYEARECAAYFAlM0kMsACgkQKPyGmiibgrcBGQCgh70G5hX6LqTdO+2z0ZEg0PYe >> 25EAnRvZ79kpqBVa4g9dGz7XXlKCOTR5 >> =85b/ >> -END PGP SIGNATURE- > > > > -- > Dave Täht > > Fixing bufferbloat with cerowrt: > http://www.teklibre.com/cerowrt/subscribe.html -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Stats improvement
On Thu, Mar 27, 2014 at 1:57 PM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 26/03/14 05:12, Olivier Mauras wrote: >> Yes it should definitely be TXT records. Sounds really good to me. >> >> for upstream servers, why not having upstream.bind return total >> queries forwarded + list of upstream servers that can then be check >> individually with: dig TXT .upstream.bind > > OK. Code in git now. > > Try eg > > dig +short chaos txt misses.bind > > and > > dig +short chaos txt servers.bind I haven't looked at the code yet, but my take on this was originally that I'd wanted a single dns reply for all the statistics (can live without), 64 bit counters, and not only tracking misses but the latency cost of a miss. Then there are misses that are never resolved... and (even harder), things like a 5 minute rolling average... and a breakdown by query type (, A, DS, etc) gettimeofday() is very efficient on modern linuxes (it gets the time from a shared page cache without even making a syscall), but I can see that you might want to be able to compile that out. And I wasn't expecting you to get to it in this release! Just basic stats is great > > > Cheers, > > Simon. > >> >> >> Olivier >> >> On Tue, 2014-03-25 at 21:37 +, Simon Kelley wrote: >>> My feeling it that this should use TXT records, then they can be >>> extracted into any application using eg >>> >>> dig +short chaos txt stats.bind >>> >>> or the equivalent, which outputs the string to stdout. >>> >>> The current code has, >>> >>> >>> cache-size, insertions which evicted unexpired cache entries, >>> queries forwarded, queries answered locally, queries for auth >>> zones. >>> >>> >>> then for each upstream server, >>> >>> queries sent, and queries retried or failed. >>> >>> We could have >>> >>> size.bind and evictions.bind for cache size and evictions >>> local.bind, upstream.bind and auth.bind for queries. >>> >>> But how to handle the variable number of upstream servers. Just >>> free text? >>> >>> >>> >>> Simon. >>> >>> Enigmail On 24/03/14 22:53, Olivier Mauras wrote: On Mon, 2014-03-24 at 21:55 +, Simon Kelley wrote: > On 24/03/14 11:25, Olivier Mauras wrote: >> >> >> Hello, >> >> I was wondering what would be the effort, and if there'd >> actually be any interest for some dnsmasq statistics >> improvements. (Yes i'm splitting dicussions ^^) For >> monitoring/graph purposes, actual dnsmasq stats are a bit >> difficult to use and completely unusable if using >> "log_queries" as it takes too long to retrieve them inside >> logs. >> >> I'd love to see a stats "interface" that would output >> total_queries, cache_hits, cache_misses, memory used by >> cache, etc >> >> Thanks, Olivier >> > > There's an idea to make this available as a DNS query, in > the same way that > > > dig chaos txt version.bind > > returns the version number. > > Comments? > > Cheers, > > Simon. > > That would be a really good way of doing it! >>> >> > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iEYEARECAAYFAlM0kMsACgkQKPyGmiibgrcBGQCgh70G5hX6LqTdO+2z0ZEg0PYe > 25EAnRvZ79kpqBVa4g9dGz7XXlKCOTR5 > =85b/ > -END PGP SIGNATURE- -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Does DNSSEC require nettle and gmp, or nettle with gmp?
On Tue, Apr 1, 2014 at 9:54 AM, /dev/rob0 wrote: > On Tue, Mar 25, 2014 at 07:08:44PM -0400, Alex Xu wrote: >> On 25/03/14 07:03 PM, sven falempin wrote: >> > my concern of nettle vs openssl is the amount of review and >> > testing nettle did get compared to something more widely(!) >> > used >> >> something being used a lot != something being good > > Absolutely true, but in the context of open source software, > especially cryptographic software, more use also tends to mean > more code review. > > I'm not really qualified to judge here what is best; I can only > point out what I, as a user, think about it. I'll trust Simon's > judgment, but I hope he has considered these concerns. I have not been tracking this conversation closely, but my own take on matters is that I'm opposed to a monoculture of anything... http://www.abc.net.au/news/2013-08-29/feature-banana/4922208 And thus I enthusiastically support other OSes than linux, other dns servers besides bind, and other crypto libraries besides openssl. > -- > 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 -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DHCPv6 hostname resolving
On Wed, Apr 2, 2014 at 8:59 AM, Albert ARIBAUD wrote: > Le 02/04/2014 17:26, Quintus a écrit : >> >> Hi there, > > > Hi Quintus, > > >> with DHPv4, dnsmasq properly converts the hostnames send to it to A >> records we can query for. It seems however that this is not the case >> with DHCPv6 and records; while I can perfectly query for the A >> record of "atlantis.cable.internal.xxx.eu" (and even the one of >> "atlantis" without any further qualification is found), querying for its >> record just returns NXDOMAIN, i.e. it's not found. >> >> Is this a bug, or do I have to enable that feature somehow so it works >> the same for DHCPv6 as it does for DHCPv4? > > > As per the manpage for dnsmasq, you should set 'ra-names' in the IPv6 > dhcp-range? e.g., instead of > > >> >> dhcp-range=set:wired6,2001:4dd0:ff00:8918:1::2,2001:4dd0:ff00:8918:1:::fffe,80,6h >> >> dhcp-range=set:wifi6,2001:4dd0:ff00:8918:2::2,2001:4dd0:ff00:8918:2:::fffe,80,6h > > > Use > > dhcp-range=set:wired6,2001:4dd0:ff00:8918:1::2,2001:4dd0:ff00:8918:1:::fffe,80,6h,ra-names > dhcp-range=set:wifi6,2001:4dd0:ff00:8918:2::2,2001:4dd0:ff00:8918:2:::fffe,80,6h,ra-names > > From the manpage: > > "ra-names enables a mode which gives DNS names to dual-stack > hosts which do SLAAC for IPv6. Dnsmasq uses the host's IPv4 > lease to derive the name, network segment and MAC address and > assumes that the host will also have an IPv6 address calculated > using the SLAAC algorithm, on the same network segment. The > address is pinged, and if a reply is received, an record is > added to the DNS for this IPv6 address. Note that this is only > happens for directly-connected networks, (not one doing DHCP via > a relay) and it will not work if a host is using privacy exten- > sions. ra-names can be combined with ra-stateless and slaac." There is even an internet draft on this... not that it's found a home within any working groups: http://tools.ietf.org/html/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00 > Amicalement, > -- > Albert. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnssec on android?
It looks like there will be some issues getting dnssec on on android by switching to dnsmasq: https://code.google.com/p/android/issues/detail?id=65510 What is dnsmasq's behavior on how/when to switch to tcp? -- Dave Täht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.html ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Does DNSSEC require nettle and gmp, or nettle with gmp?
On Wed, Apr 9, 2014 at 6:24 AM, /dev/rob0 wrote: > On Tue, Apr 01, 2014 at 11:54:28AM -0500, I wrote: > ^^ >> On Tue, Mar 25, 2014 at 07:08:44PM -0400, Alex Xu wrote: >> > On 25/03/14 07:03 PM, sven falempin wrote: >> > > my concern of nettle vs openssl is the amount of review and >> > > testing nettle did get compared to something more widely(!) >> > > used openssl >> > >> > something being used a lot != something being good >> >> Absolutely true, but in the context of open source software, >> especially cryptographic software, more use also tends to mean >> more code review. > > April Fools! > > ;) My heart bleeds for the openssl folk and openssl derived application users right now. More investment into creating, maintaining and improving core crypto libraries is desperately needed to hold our civilization together. >> I'm not really qualified to judge here what is best; I can only >> point out what I, as a user, think about it. I'll trust Simon's >> judgment, but I hope he has considered these concerns. > -- > 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 -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Does DNSSEC require nettle and gmp, or nettle with gmp?
On Wed, Apr 9, 2014 at 10:29 AM, Simon Kelley wrote: > On 09/04/14 15:51, Dave Taht wrote: > >> >> My heart bleeds for the openssl folk and openssl derived application users >> right now. More investment into creating, maintaining and improving >> core crypto libraries is desperately needed to hold our civilization >> together. >> > > +1 > > Don't underestimate the contribution of all the people who take > responsibility for the software that runs as root, or exposed to the > net, on your machines. It's something I have nightmares about. +10. :empathy waves: In my case I merely have thousands of users dependent on the OS I create. I can't push an update to them, and can only update the most current version of the code to include support (which I did about 2 hours after the disclosure), and hope people on my mailing list are paying attention. millions or billions of users would suck harder. and I still have several internet facing machines left to fix, and certs to recreate and redistribute. I would have preferred the have spent my week doing something else. The financial cost in patching this hole is nearly incalculatable, and the cost of having had it, or leaving it unpatched, is nearly infinite. https://www.youtube.com/watch?v=_y36fG2Oba0 The cost of prevention is slight, in comparison. > > Simon. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Does DNSSEC require nettle and gmp, or nettle with gmp?
On Wed, Apr 9, 2014 at 11:11 AM, Olaf Westrik wrote: > Simon, > > >> Don't underestimate the contribution of all the people who take >> responsibility for the software that runs as root, or exposed to the >> net, on your machines. It's something I have nightmares about. > > > I do hope that is not true and that you sleep well. > So much better to be rested and clear headed when coding :-) I sleep more soundly knowing simon works on dnsmasq full time these days. > > Olaf > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] byte swapping test in coverity
wonder if this would have picked up one of the earlier dnssec bugs... http://blog.regehr.org/archives/1128 -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnssec and local caching dns in fedora and network manager
interesting long thread over at the fedora project this weekend: https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html -- Forwarded message -- From: Chuck Anderson Date: Sun, Apr 13, 2014 at 10:59 AM Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default? To: cerowrt-de...@lists.bufferbloat.net On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote: > > > Is there a "D"? > > Running a full resolver in cerowrt? I've been running a dnssec-enabled bind > for some time on my boxes (prior to dnssec support in dnsmasq). How do these proposals compare with unbound+dnssec-trigger in the Fedora world? I stirred up a rats nest: https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html I realize these are slightly different use cases, but it may be helpful to learn from the different implementations, if for no other reason than to be sure they interoperate. I'm going to turn on unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC turned on to see what happens... ___ Cerowrt-devel mailing list cerowrt-de...@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnssec and local caching dns in fedora and network manager
On Mon, Apr 14, 2014 at 8:38 AM, Dan Williams wrote: > On Mon, 2014-04-14 at 09:31 +0100, Simon Kelley wrote: >> On 13/04/14 21:24, Dave Taht wrote: >> > interesting long thread over at the fedora project this weekend: >> > >> > https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html >> > >> >> I'm quite a long way through it already. The main takehome seems to be >> that captive portals are even more broken in the era of DNSSEC than >> before. It's amazing that's even possible.. > > They are quite awful. They were always awful. But with 10+ years of > captive portal hackage, it's pretty much on the DNSSEC implementors to > either (a) change every captive portal to work, or (b) figure out how to > work around the problem. A combination of the two is the right path, > but nobody is going to get all captive portals to follow a spec. Or c) make the legal and social environment such that the perceived need for captive portals go away entirely. https://www.openwireless.org/ > There is Hotspot 2.0 (and the older WISPR) that at least automates the > process so that you *know* you're connected to a captive portal and > sometimes you can automatically log in using the SIM card in your device > or other cached credentials. Usually used by phones and providers to > automatically roam to WiFi networks your provider has affiliations with. > > This is where the standardization work is going on for hotspot stuff. > > Dan > >> Maybe the IETF should create a sane spec for such things >> >> >> >> Simon. >> >> > >> > >> > -- Forwarded message -- >> > From: Chuck Anderson >> > Date: Sun, Apr 13, 2014 at 10:59 AM >> > Subject: Re: [Cerowrt-devel] Full blown DNSSEC by default? >> > To: cerowrt-de...@lists.bufferbloat.net >> > >> > >> > On Sun, Apr 13, 2014 at 12:05:19PM +0200, Toke Høiland-Jørgensen wrote: >> >> >> >>> Is there a "D"? >> >> >> >> Running a full resolver in cerowrt? I've been running a dnssec-enabled >> >> bind for some time on my boxes (prior to dnssec support in dnsmasq). >> > >> > How do these proposals compare with unbound+dnssec-trigger in the >> > Fedora world? I stirred up a rats nest: >> > >> > https://lists.fedoraproject.org/pipermail/devel/2014-April/197755.html >> > >> > I realize these are slightly different use cases, but it may be >> > helpful to learn from the different implementations, if for no other >> > reason than to be sure they interoperate. I'm going to turn on >> > unbound+dnssec-trigger on my laptop and try it behind Cerowrt w/DNSSEC >> > turned on to see what happens... >> > ___ >> > Cerowrt-devel mailing list >> > cerowrt-de...@lists.bufferbloat.net >> > https://lists.bufferbloat.net/listinfo/cerowrt-devel >> > >> > >> >> >> ___ >> 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 -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Stable releases v. development releases.
I think a lot of distro makers would be comforted by the idea of a stable branch and feel more comfortable in upgrading to the latest "stable" for distribution into their embedded products... ... regardless of your success in dealing the backward compatability issues. You could periodically obsolete a given stable branch, much like other systems, like linux do, every year or two. it's also an opportunity to charge for support, if you like. On Thu, Apr 17, 2014 at 2:14 PM, Simon Kelley wrote: > Thus far, dnsmasq has not maintained separate stable and development > branches. One reason for this is that there's been a pretty strong > policy of backwards-compatibility, so the penalty for upgrading to the > latest release is low: we've almost certainly not broken your config, or > changed behaviour. On the other hand, sometimes fixes for bugs have been > delayed by work on features. > > It looks like there are a couple of regressions in 2.69 which need early > correction. The dnsmasq way of this would be to release 2.70 rapidly > with fixes, but once serious development starts on the next set of > features, the ability to do that is lost. The alternative would be to > open stable and development branches, and make a 2.69.1 bugfix release. > There's some cost in doing that, of course. More repo complexity and > work in moving fixes into the development as well as stable releases. > Git makes that much easier than before, of course. > > I'm interested in opinions for and against the status-quo or a new > stable/devel split. > > Cheers, > > > Simon. > > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
I will argue that a better place to report dnssec validation errors is the dnsmasq list. On Wed, Apr 23, 2014 at 8:31 AM, Aaron Wood wrote: > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: query[A] > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net from 172.30.42.99 > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: dnssec-query[DS] > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.4.4 > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: forwarded > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net to 8.8.8.8 > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is BOGUS DS > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: validation result is > BOGUS > Wed Apr 23 15:13:05 2014 daemon.info dnsmasq[29719]: reply > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net is 2.20.28.186 > > This one validates via verisign, however. > > -Aaron > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
On Wed, Apr 23, 2014 at 10:18 AM, Aaron Wood wrote: > On Wed, Apr 23, 2014 at 6:44 PM, Robert Bradley > wrote: >> >> >> > ; <<>> DiG 9.8.1-P1 <<>> +cd @8.8.8.8 a >> > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net >> >> > >> > But a query for DS on the same domain, which is what dnsmasq does next, >> > returns SERVFAIL, _even_with_ checking disabled. >> > >> > ; <<>> DiG 9.8.1-P1 <<>> +cd @8.8.8.8 ds >> > e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net >> >> >> This looks identical to the *.cloudflare.com issue I had last week. In >> both cases, using Level 3's 4.2.2.2 instead of Google DNS works fine, >> and 8.8.8.8 returns SERVFAIL for DS lookups. This looks like a bug in >> Google's DNS servers as opposed to dnsmasq... > > > A question about dnsmasq and multiple servers. If I listed both 4.2.2.2 and > 8.8.8.8 in my dnsmasq configuration, how would dnsmasq behave in this case? > would it query both for the DS? or just "stick" with the first server to > start responding with an A-record? By default dnsmasq probes for a "best" upstream dns server periodically and uses that. > > (I confess that I don't know the details of DNS very well) > > -Aaron > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] more dnssec failures
What does unbound or bind do?
On Thu, Apr 24, 2014 at 5:35 AM, Aaron Wood wrote:
> And if I use Free.fr's servers, the DS resolves (I'm running CeroWRT
> double-NAT behind a Freebox v6):
>
> dig @192.168.1.254 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
>
> ; <<>> DiG 9.8.5-P1 <<>> @192.168.1.254 DS
> e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 11369
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
>
> ;; QUESTION SECTION:
> ;e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net. IN DS
>
> ;; AUTHORITY SECTION:
> cn.akamaiedge.net. 1800 IN SOA n0cn.akamaiedge.net. hostmaster.akamai.com.
> 1398342840 1000 1000 1000 1800
>
> ;; Query time: 39 msec
> ;; SERVER: 192.168.1.254#53(192.168.1.254)
> ;; WHEN: Thu Apr 24 14:34:00 CEST 2014
> ;; MSG SIZE rcvd: 127
>
> -Aaron
>
>
> On Thu, Apr 24, 2014 at 2:33 PM, Aaron Wood wrote:
>>
>> Well, I'm seeing the same results as you are from here in Paris (using
>> Free.fr).
>>
>> -Aaron
>>
>>
>> On Thu, Apr 24, 2014 at 1:27 PM, Simon Kelley
>> wrote:
>>>
>>> On 24/04/14 11:49, Aaron Wood wrote:
>>>
>>> >
>>> >> Dnsmasq does the DS query next because the answer to the A query comes
>>> >> back unsigned, so dnsmasq is looking for a DS record that proves this
>>> >> is
>>> >> OK. It's likely that Verisign does that top-down (starting from the
>>> >> root) whilst dnsmasq does it bottom up. Hence Verisign never finds the
>>> >> broken DS, whilst dnsmasq does.
>>> >>
>>> >> That's as good an analysis as I can produce right now. Anyone who can
>>> >> shed more light, please do.
>>> >>
>>> >> (And yes, please report DNSSEC problems on the dnsmasq-discuss list
>>> >> for
>>> >> preference.)
>>> >>
>>> >
>>> > This is still persisting (and it appears to be blocking a bunch of
>>> > Apple
>>> > software update functions). From your comments, Simon, it sounds like
>>> > you
>>> > think this is an Akamai issue, and should be reported to them?
>>> >
>>>
>>> I'm not absolutely sure that this isn't also a dnsmasq problem, and
>>> DNSSEC is still capable of surprising me, but I can't see how a SERVFAIL
>>> answer to
>>>
>>> dig @8.8.8.8 DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
>>>
>>> can not be either a Google ('cause it's their recursive server) or
>>> Akamai problem.
>>>
>>> Poking further, it looks like the authoritative name servers for that
>>> zone are
>>>
>>> ; <<>> DiG 9.8.1-P1 <<>> @8.8.8.8 NS cn.akamaiedge.net
>>> ; (1 server found)
>>> ;; global options: +cmd
>>> ;; Got answer:
>>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43031
>>> ;; flags: qr rd ra; QUERY: 1, ANSWER: 9, AUTHORITY: 0, ADDITIONAL: 0
>>>
>>> ;; QUESTION SECTION:
>>> ;cn.akamaiedge.net. IN NS
>>>
>>> ;; ANSWER SECTION:
>>> cn.akamaiedge.net. 299 IN NS n7cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n6cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n0cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n2cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n5cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n4cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n3cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n1cn.akamaiedge.net.
>>> cn.akamaiedge.net. 299 IN NS n8cn.akamaiedge.net.
>>>
>>> and all of those give sensible answers for
>>>
>>> DS e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net
>>>
>>> except n8cn.akamaiedge.net, which isn't responding, so I rather think
>>> this may be a Google mess.
>>>
>>> Or maybe it's Great Firewall induced breakage?
>>>
>>> Cheers,
>>>
>>>
>>> Simon.
>>>
>>>
>>>
>>
>
--
Dave Täht
NSFW:
https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] local dns-sd requests being forwarded to upstream servers on CeroWRT?
On Thu, Apr 24, 2014 at 5:33 AM, Aaron Wood wrote: > Using CeroWRT 3.10.36-4, I'm seeing the following in the logs: > > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > b._dns-sd._udp.96.42.30.172.in-addr.arpa from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: forwarded > b._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 I don't think it should do that. Am curious if it happens from the ethernet interface. > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > db._dns-sd._udp.96.42.30.172.in-addr.arpa from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: forwarded > db._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > r._dns-sd._udp.96.42.30.172.in-addr.arpa from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: forwarded > r._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > dr._dns-sd._udp.96.42.30.172.in-addr.arpa from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: forwarded > dr._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > lb._dns-sd._udp.96.42.30.172.in-addr.arpa from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: forwarded > lb._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > b._dns-sd._udp.home.lan from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: config > b._dns-sd._udp.home.lan is NXDOMAIN > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > db._dns-sd._udp.home.lan from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: config > db._dns-sd._udp.home.lan is NXDOMAIN The NXDOMAINS seem sane. > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > r._dns-sd._udp.home.lan from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: config > r._dns-sd._udp.home.lan is NXDOMAIN > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > dr._dns-sd._udp.home.lan from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: config > dr._dns-sd._udp.home.lan is NXDOMAIN > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: query[PTR] > lb._dns-sd._udp.home.lan from 172.30.42.99 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: config > lb._dns-sd._udp.home.lan is NXDOMAIN > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > b._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 Shouldn't do that either. > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > db._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > r._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > dr._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > lb._dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > 96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > 96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _dns-sd._udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > 96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > 42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > 42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnssec-query[DS] > _udp.96.42.30.172.in-addr.arpa to 8.8.8.8 > Thu Apr 24 14:15:14 2014 daemon.info dnsmasq[13365]: dnss
[Dnsmasq-discuss] test-ipv6.com vs dnssec
jg tells me the test-ipv6.com site fails with dnssec and enabled on native ipv6. disabling dnssec works. anyone can confirm? get a log/packet capture? -- Dave Täht ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Had to disable dnssec today
On Sat, Apr 26, 2014 at 12:44 PM, Simon Kelley wrote: > On 26/04/14 17:20, Aaron Wood wrote: >> David, >> >> With two of them (akamai and cloudflare), I _think_ it's a dnsmasq >> issue with the DS records for proving insecure domains are insecure. >> But Simon Kelley would know that better than I. >> > > > The result of the analysis of the akamai domain was that there's a > problem with the domain (ie it's an akamai problem) See the post in the > Cerowrt list by Evan Hunt for the origin of this conclusion. > > There's a dnsmasq issue to the extent that dnsmasq uses a different > strategy for proving that a name should not be signed than other > nameservers (dnsmasq works bottom-up, the others can work top-down, > since they are recursive servers, not forwarders.) This means that > dnsmasq sees the akamai problem, whilst eg unbound happens not to. I > plan to see if dnsmasq can be modified to improve this. If it's not a violation of the specification, the bottom-up method might be good to add to a dnssec validation tool. > > I'm not sure of cloudflare has been looked at in detail, but my > impression was that it's the same as akamai. > >> With BofA, I'm nearly certain it's them, or an issue with one of >> their partners (since the domain that fails isn't BofA, but >> something else): >> >> (with dnssec turned off): >> >> ;; QUESTION SECTION: ;sso-fi.bankofamerica.com. IN A >> >> ;; ANSWER SECTION: sso-fi.bankofamerica.com. 3599 IN CNAME >> saml-bac.onefiserv.com. saml-bac.onefiserv.com. 299 IN CNAME >> saml-bac.gslb.onefiserv.com. saml-bac.gslb.onefiserv.com. 119 IN A >> 208.235.248.157 >> >> And it's the saml-bac.gslb.onefiserv.com host that's failing (see >> here for debug info): >> >> http://dnssec-debugger.verisignlabs.com/sso-fi.bankofamerica.com >> >> -Aaron >> >> >> On Sat, Apr 26, 2014 at 6:00 PM, wrote: >> >>> Is this just a dnsmasq issue or is the DNSSEC mechanism broken at >>> these sites? If it is the latter, I can get attention from >>> executives at some of these companies (Heartbleed has sensitized >>> all kinds of companies to the need to strengthen security >>> infrastructure). >>> >>> >>> >>> If the former, the change process is going to be more tricky, >>> because dnsmasq is easily dismissed as too small a proportion of >>> the market to care. (wish it were not so). >>> > > > Given it's less than a month since the first DNSSEC-capable dnsmasq > release, anything other than small market share would be fairly miraculous! > > Cheers, > > Simon. > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Had to disable dnssec today
On Sat, Apr 26, 2014 at 4:38 AM, Aaron Wood wrote: > Just too many sites aren't working correctly with dnsmasq and using Google's > DNS servers. After 4 days of uptime, I too ended up with a wedged cerowrt 3.10.36-6 on wifi. The symptoms were dissimilar from what has been described here - I was seeing odhcpd trying to and failing to answer requests on the wifi interfaces, which I'd never seen in operation before (and could have been a self-induced failure by fiddling with hnetd) I have merged with openwrt head, which has some hostapd and routing fixes, as well as dnsmasq head which has some dnssec lookup fixes... and put out cerowrt-3.10.36-7. On first boot, it had problems getting anything on wifi to do dhcp. A reboot later (with multicast 9000 also disabled), a kindle that was failing to get online did. This box has also never got upstream dns servers right from the isp. I'll fiddle with the multicast thing later, to see if that or the reboot fixed it. With this dnssec with dnssec-check-unsigned, once time is correct: > - Bank of America (sso-fi.bankofamerica.com) still fails. It ain't our fault it's broke. > - Weather Underground (cdnjs.cloudflare.com) succeeds. > - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net) succeeds. > http://test-ipv6.com/ don't have ipv6 capability at this location, so this succeeds. I did see it fail once on the first boot but haven't repeated it. > > And I'm not getting any traction with reporting the errors to those sites, > so it's frustrating in getting it properly fixed. There needs to be constant network wide scanning service of some kind to detect dnssec configuration errors. > > While Akamai and cloudflare appear to be issues with their entries in google > dns, or with dnsmasq's validation of them being insecure domains, the BofA > issue appears to be an outright bad key. And BofA isn't being helpful (just > a continual "we use ssl" sort of quasi-automated response). Cluebats are needed. > So I'm disabling it for now, or rather, falling back to using my ISP's dns > servers, which don't support DNSSEC at this time. I'll be periodically > turning it back on, but too much is broken (mainly due to the cdns) to be > able to rely on it at this time. don't blame you, but if we weren't beating it up, nobody would be. > > -Aaron > > > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys wrote: > Comcast recently lit up IPv6 native dual stack in the Boston area. > > The http://test-ipv6.com/ web site complains about DNS problems unless > dnssec is disabled; if it is, I get various timeouts. > > > Test with IPv4 DNS record > ok (4.196s) > Test with IPv6 DNS record > ok (0.115s) using ipv6 > Test with Dual Stack DNS record > timeout (11.882s) > I don't know what this test does. try a local query over ipv6? Test for Dual Stack DNS and large packet > timeout (11.817s) > Test IPv4 without DNS > ok (0.214s) using ipv4 > Test IPv6 without DNS > ok (0.204s) using ipv6 > Test IPv6 large packet > ok (0.120s) using ipv6 > Test if your ISP's DNS server uses IPv6 > slow (8.752s) > Find IPv4 Service Provider > timeout (11.968s) > Find IPv6 Service Provider > ok (0.126s) using ipv6 ASN 7922 > Test for buggy DNS > undefined (5.003s) > > DNS server addresses look reasonable for Comcast. > DNS 1: 75.75.75.75 > DNS 2: 75.75.76.76 > To try to isolate things a little bit, you can turn off fetching ipv4 dns servers with option peerdns '0' in the wan (ge00) stanza of /etc/config/network and let the wan6 stanza fetch them. A packet capture of it working vs not working would be good. tcpdump -i ge00 -w cap1.cap port 53 Also capture on the local interface. DNS 1: 2001:558:feed::1 > DNS 2: 2001:558:feed::2 > > Today, the problem seems consistent with turning dnssec on and off on the > router. If enabled, I have problems; if disabled, I get a clean bill of > health out of test-ipv6.com. > - Jim > > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
I have put a link up to two of jim's captures going to test-ipv6 via cero, one with dnssec enabled, captured at the local laptop http://snapon.lab.bufferbloat.net/~cero2/baddns/ definately a lot of missing responses when captured at this end. the local laptop is using a local dnsmasq forwarder. It is falling back to trying a recursive lookup on the default domain ( ipv6.test-ipv6.com.home.lan ) - which it does do a nxdomain for immediately... On Mon, Apr 28, 2014 at 10:03 AM, Dave Taht wrote: > > > > On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys wrote: > >> Comcast recently lit up IPv6 native dual stack in the Boston area. >> >> The http://test-ipv6.com/ web site complains about DNS problems unless >> dnssec is disabled; if it is, I get various timeouts. >> >> >> > Test with IPv4 DNS record >> ok (4.196s) >> Test with IPv6 DNS record >> ok (0.115s) using ipv6 >> Test with Dual Stack DNS record >> timeout (11.882s) >> > > I don't know what this test does. try a local query over ipv6? > > Test for Dual Stack DNS and large packet >> timeout (11.817s) >> Test IPv4 without DNS >> ok (0.214s) using ipv4 >> Test IPv6 without DNS >> ok (0.204s) using ipv6 >> Test IPv6 large packet >> ok (0.120s) using ipv6 >> Test if your ISP's DNS server uses IPv6 >> slow (8.752s) >> Find IPv4 Service Provider >> timeout (11.968s) >> Find IPv6 Service Provider >> ok (0.126s) using ipv6 ASN 7922 >> Test for buggy DNS >> undefined (5.003s) >> >> DNS server addresses look reasonable for Comcast. >> DNS 1: 75.75.75.75 >> DNS 2: 75.75.76.76 >> > > To try to isolate things a little bit, you can turn off fetching ipv4 > dns servers > with > > option peerdns '0' > > in the wan (ge00) stanza of /etc/config/network > > and let the wan6 stanza fetch them. > > A packet capture of it working vs not working would be good. > > tcpdump -i ge00 -w cap1.cap port 53 > > Also capture on the local interface. > > DNS 1: 2001:558:feed::1 >> DNS 2: 2001:558:feed::2 >> >> Today, the problem seems consistent with turning dnssec on and off on the >> router. If enabled, I have problems; if disabled, I get a clean bill of >> health out of test-ipv6.com. >> - Jim >> >> >> ___ >> Cerowrt-devel mailing list >> cerowrt-de...@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/cerowrt-devel >> >> > > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
I see A and requests for for "ds.test-ipv6.com" that fail. On Mon, Apr 28, 2014 at 11:37 AM, Dave Taht wrote: > I have put a link up to two of jim's captures going to test-ipv6 via cero, > one with dnssec enabled, captured at the local laptop > > http://snapon.lab.bufferbloat.net/~cero2/baddns/ > > definately a lot of missing responses when captured at this end. the local > laptop is using a local dnsmasq forwarder. > > It is falling back to trying a recursive lookup on the default domain ( > ipv6.test-ipv6.com.home.lan ) - which it does do a nxdomain for > immediately... > > > > On Mon, Apr 28, 2014 at 10:03 AM, Dave Taht wrote: > >> >> >> >> On Mon, Apr 28, 2014 at 9:55 AM, Jim Gettys wrote: >> >>> Comcast recently lit up IPv6 native dual stack in the Boston area. >>> >>> The http://test-ipv6.com/ web site complains about DNS problems unless >>> dnssec is disabled; if it is, I get various timeouts. >>> >>> >>> >> Test with IPv4 DNS record >>> ok (4.196s) >>> Test with IPv6 DNS record >>> ok (0.115s) using ipv6 >>> Test with Dual Stack DNS record >>> timeout (11.882s) >>> >> >> I don't know what this test does. try a local query over ipv6? >> >> Test for Dual Stack DNS and large packet >>> timeout (11.817s) >>> Test IPv4 without DNS >>> ok (0.214s) using ipv4 >>> Test IPv6 without DNS >>> ok (0.204s) using ipv6 >>> Test IPv6 large packet >>> ok (0.120s) using ipv6 >>> Test if your ISP's DNS server uses IPv6 >>> slow (8.752s) >>> Find IPv4 Service Provider >>> timeout (11.968s) >>> Find IPv6 Service Provider >>> ok (0.126s) using ipv6 ASN 7922 >>> Test for buggy DNS >>> undefined (5.003s) >>> >>> DNS server addresses look reasonable for Comcast. >>> DNS 1: 75.75.75.75 >>> DNS 2: 75.75.76.76 >>> >> >> To try to isolate things a little bit, you can turn off fetching ipv4 >> dns servers >> with >> >> option peerdns '0' >> >> in the wan (ge00) stanza of /etc/config/network >> >> and let the wan6 stanza fetch them. >> >> A packet capture of it working vs not working would be good. >> >> tcpdump -i ge00 -w cap1.cap port 53 >> >> Also capture on the local interface. >> >> DNS 1: 2001:558:feed::1 >>> DNS 2: 2001:558:feed::2 >>> >>> Today, the problem seems consistent with turning dnssec on and off on >>> the router. If enabled, I have problems; if disabled, I get a clean bill >>> of health out of test-ipv6.com. >>> - Jim >>> >>> >>> ___ >>> Cerowrt-devel mailing list >>> cerowrt-de...@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >>> >> >> >> -- >> Dave Täht >> >> NSFW: >> https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article >> > > > > -- > Dave Täht > > NSFW: > https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] test-ipv6.com vs dnssec
On Fri, Apr 25, 2014 at 11:49 AM, Simon Kelley wrote: > On 25/04/14 19:01, Jim Gettys wrote: >> More specifically, after boot, most of the time test-ipv6.com reports lots >> of problems. >> >> Then I turned off both dnssec and dnssec-check-unsigned, and restarted >> dnsmasq; clean bill of health from test-ipv6.com. >> >> Then I turned on dnssec only, leaving dnssec-check-unsigned, and got a >> clean bill of health. >> >> Then I turned on both at the same time, and things are working. >> >> So we seem to have a boot time race of some sort. >> - Jim >> >> > > > test-ipv6.com is unsigned, so the important thing which is likely > failing is the query for the DS record of test-ipv6.com, which should > return NSEC records providing it doesn't exist, signed by .com As one example of a registrar not with the program, name.com (registrar for bufferbloat.net) does not allow for ds records to come from it, so that domain can't be fully signed. So it sounds to me as if negative proofs are not possible with registrars that lack this support? > > Simon. > > > >> >> On Fri, Apr 25, 2014 at 1:39 PM, Dave Taht wrote: >> >>> jg tells me the test-ipv6.com site fails with dnssec and enabled on >>> native ipv6. >>> >>> disabling dnssec works. >>> >>> anyone can confirm? get a log/packet capture? >>> >>> >>> -- >>> Dave Täht >>> ___ >>> Cerowrt-devel mailing list >>> cerowrt-de...@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>> >> >> >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss >> > -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock wrote: > On 2014-04-29 at 14:22 +0100, Simon Kelley wrote: >> secure no DS means that the original unsigned answer should be accepted, >> except that it shouldn't. There's no way to distinguish between secure >> lack of DS because we've reached an unsigned branch of the tree, and >> secure lack of DS because we're not at a zone cut, except if we know >> where the zone cuts are, and we don't. > > Fair point. > >> That's why dnsmasq works up from the bottom. The first secure no-DS >> answer we find marks the boundary between signed and unsigned tree. >> >> Dnsmasq is acting as a validating stub resolver here. That's a supported >> role for DNSSEC, so this must be possible. If it's not then we have a >> standards problem. > > You have a standards vs reality problem: lots of loadbalancer appliances > suck at DNS and are only just now managing to return errors, instead of > dropping the query (hanging), when queried for records instead of A > records. > > ( This has led to no end of pain in the IPv6 world; Happy Eyeballs, > expectations around improved _client_ behaviour, handle other parts of > the puzzle and tends to require the concurrency that a client also > needs to handle DNS problems, but it's still distinct. ) > > You're not going to get such loadbalancers responding sanely to a DS > query any time soon, and with the other DNS client software all being > recursors which work fine because they know where zone cuts are, you're > going to be fighting a long hard battle with vendors and sites to get > them to fix their brokenness when "it works for everyone else". > > So the standards 100% support what you're doing, but they don't match > common stupidity in deployed (high end, expensive) equipment. The only idea I have is to adopt some sort of whitelisting technology, and simultaneously nag the folk with busted implementations. > > To support DNSSEC in the real world without changing from being a > forwarder, you're going to need new insight. My only thoughts are > around whether or not this might provide impetus for TKEY-based TSIG for > forwarders to establish trust links to recursors elsewhere, in which > case once you have a TSIG key (whether TKEY-derived or OOB manual) then > you might delegate trust to the remote recursor. I see there have been a few commits to dnsmasq that address some stuff. > > Sorry to be the bearer of bad news, I'm delighted to have got this far. Is the consensus to not run with negative proofs on at this juncture? > -Phil -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
On Thu, May 1, 2014 at 1:26 PM, Rich Brown wrote: > > On May 1, 2014, at 2:37 PM, Simon Kelley wrote: > >> On 30/04/14 18:26, Dave Taht wrote: >>> On Tue, Apr 29, 2014 at 1:57 PM, Phil Pennock >>> wrote: > > snip, snip snip... > >>> Is the consensus to not run with negative proofs on at this juncture? >> >> If you want stuff to just work, turn off negative proofs, if you want to >> push the envelope, leave them on and complain to domain-admins. >> >> I had some feeling that something like this might be a problem, hence >> the discrete controls. > > I apologize that I haven't been following this closely, but so I'm going to > ask a TL;DR question. > > Which places in the OpenWrt/CeroWrt GUI (or the config files) do I use to > wiggle these levers? There is no gui support as yet. enablement is via /etc/dnsmasq.conf I disabled (commented out) the negative proof checks in the 3.10.38-2 release. > Thanks! > > Rich -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq not working as DNS server for client machines
On May 22, 2014 3:37 PM, "Chris Green" wrote: > > On Thu, May 22, 2014 at 11:08:22PM +0100, Chris Green wrote: > > On Thu, May 22, 2014 at 10:46:46PM +0100, Chris Green wrote: > > > I seem to have spoken too soon with my transfer of dnsmasq to a > > > different machine. > > > > > > It's running on my desktop machine which is also an always on server. > > > DNS is working fine for the desktop machine itself but it's not > > > working for client machines. > > > > > > DHCP is working though, so clients get an IP address OK and can talk > > > to other machines on the LAN if I specify IP addresses rather than > > > names. > > > > > > So how do I diagnose this? It's on xubuntu 14.04 so it's made a > > > little opaque by not being able view 'real' DNS servers anywhere > > > > > Sorry about that abrupt end. Not much to add though. > > > > As a general comment it would be very useful to be able easily to see > > what DNS servers are being used. > > > ... a little more information. DHCP clients are getting all the right > information, e.g. the laptop I'm using at the moment has:- > > IP Address: 192.168.1.125 > Broadcast Address: 192.168.1.255 > Subnet Mask:255.255.255.0 > Default Route: 192.168.1.1 > Primary DNS:192.168.1.4 > > The default route is an ADSL router and the primary DNS is my desktop > server machine running dnsmasq. So it would appear that dnsmasq isn't > answering DNS queries rather than it's not doing DHCP correctly. > > It's almost certainly a trivial configuration problem but I can't see > it at the moment. Tcpdump is your friend. > > -- > Chris Green > > ___ > 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] mdns support
As an outgrowth of the ietf homenet working group, the homewrt folk are attempting to blend together mdns, an mdns proxy, and improved address allocation schemes with dnsmasq in openwrt. They could use some more testers, coders, and help in general. I have long planned to integrate their work in cerowrt, and ultimately, I hope their work lands in openwrt and other operating systems. I would certainly like it if everything hung together tighter than it does at the moment. Homwrt folk can be found on #hnet-hackers on irc. The website is: http://www.homewrt.org/ and the relevant drafts are on the dnssd and homenet wg pages. http://tools.ietf.org/wg/homenet/ http://datatracker.ietf.org/wg/dnssd/ I view (in the coming ipv6 era) getting addressing, naming, and resource discovery right as pretty darn important, and the present state of things is abominable... this appears to be a start towards re-integrating mdns with regular dns: http://tools.ietf.org/html/draft-cheshire-mdnsext-hybrid-02 On Thu, Jun 19, 2014 at 12:35 PM, Vasiliy Tolstov wrote: > 2014-06-19 14:25 GMT+04:00 Tomas Hozza : >> From what I remember there was some discussion [1] in the past, >> but not really any final decision... >> >> [1] >> http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/2013q4/007753.html > > > =(. I'm try to use avahi, but it dometimes not work, also i can't > publish some addresses (process hang). And i thinkg that nss module > not needed if normal dns server able to do mdns requests. > Also avahi hardcore timeout for request to 5000msec, and ping > xxx.local address that does not have ptr record need every time > timeout for 5 secods. As i see avahi not maintained (last release more > than year ago). > > -- > Vasiliy Tolstov, > e-mail: v.tols...@selfip.ru > jabber: v...@selfip.ru > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] OpenWRT, modem restarts and lost dhcp leases
The simplest thing to do is merely move the dhcp leases file to persistent storage, if you are willing to live with the long term failure mode of flash becoming less long term. I don't honestly know the cycle lifetime of low end flash chips anymore - it was very bad when they first came out but has improved dramatically in the last 10 years. On Fri, Aug 22, 2014 at 11:39 AM, Anatol Pomozov wrote: > Hi > > This is a follow-up for a discussion that I had in systemd maillist > [1]. Here is description of the problem: > > I have a router (Archer C7 V2) where I use patched version of OpenWRT. > It uses dnsmasq as a dhcp server for my local network. OpenWRT uses a > file on tmpfs to store the dhcp leases. When I reboot modem the files > on tmpfs are lost and dnsmasq needs to build the dhcp lease database > from anew. All the machines that are connected directly to the modem > (via cable or via wifi) work fine here - they notice that data link > went down and when it gets back they update DHCP information. > > The problem is when some machine is located in a different network > segment. In this case the data layer stays healthy, machine does not > notice anything wrong with the network and dhcp client does not update > DHCP lease at the router. So I cannot ping my machine by the name > anymore, pinging by ip works fine. To update the lease I need to power > cycle the ethernet switch that serves that network segment. But of > course it is not the best solution. > > So my question what is the solution for such problem? Should dnsmasq > ask on start all the machines to update their dhcp leases? Is it what > FORCERENEW option is? I see that FORCERENEW is not implemented in > dnsmasq. > > [1] > http://lists.freedesktop.org/archives/systemd-devel/2014-August/022363.html > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Suggested configuration best practices for home net with dynamic ipv6 prefix?
On Mon, Sep 22, 2014 at 5:49 AM, Stephen Riehm wrote: > Hi, > > I'm wondering if there are some 'typical' or 'best practice' > configuration norms for configuring dnsmasq to provide A and > DNS lookups for unqualified and qualified hostnames in an ipv6 home > network without a static ipv6 prefix? > > Some things which are causing me headaches are: > > My ISP gives me a new ipv4 address and ipv6 prefix whenever my router > re-connects (daily). > (6to4 dual stack, ipv6 prefix = 2002:/56) > > My router (fritzbox) provides DHCPv6 however it insists on using the domain > name > fritz.box. and the name resolution seems to be very flakey. I'm hoping to > replace > the router's DNS & DHCP services with dnsmasq on a separate server (freebsd). OpenWrt tackled a lot of these problems with barrier breaker. So has the homenet working group of the ietf. > I would like to access some of my servers via ipv6 from the internet, but not > others. > (idea: add an NS record to my ISP's configuration, specifying my dnsmasq > server as > the authoritative server for my sub-domain - arguments pro / contra? > I can access my network via dyndns & ipv4 just fine) > > There seems to be a plethora of components required to get all this right, > any insights would be greatly appreciated! (I've read through the man pages > and > they all seem to overlap - I'm a programmer but not a network expert, there's > lots of networking terms & acronyms in the man pages that I don't fully > understand) > > For example, assuming dnsmasq is running on a host in my local network: > > Router configuration (fritzbox provides the following options): > Define a Unique Local Address? (fd00::... - currently off) > Should the DHCPv6 in the router be on? > with IA_PD? (prefix delegation? That's a good thing for me, > right?) > with IA_PD and IA_NA? > or DHCPv6 turned off in the router and: > O-Flag? > O- and M-Flags? > > On the dnsmasq server: > should rtsold be running? > and rtadvd? > and radvd? > does 'enable-ra' cover these? > > can dnsmasq detect a (new) host's autoconfigured ipv6 address and add > the name to its DNS tables? if so, how? > I tried using all combinations of ra-names, ra-stateless, slaac with > dhcp-range=::,constructor:em0 > but none worked. > I figure this could have something to do with the following from the > dnsmasq manpage: > > "Note that just any address on eth0 will not do: it must not > be an autoconfigured or privacy address, or be deprecated." > > However, my global address *is* autoconfigured - what else could I > try? > Is there a way to substitute "today's ipv6 prefix" into the > dhcp-range somehow? > > I have domain=example.com., local=/example.com./ and > auth-zone=example.com.,em0 > Do I need all three? > > My hope was to continue using auto-configuration on all of the hosts > (mac,linux,bsd,mobile devices), > but having them all reference a single DNS server for their fully qualified > domain name and > NS lookups. > > Or am I missing something obvious? > > Thanks in advance, > > Steve > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH v2 0/1] Use nanosecond granularity when checking for file changes.
+1 on inotify and kevent On Sat, Oct 4, 2014 at 9:24 AM, Karl Vogel wrote: > On Sat, Oct 4, 2014 at 6:10 PM, Karl Vogel wrote: >> On Fri, Oct 3, 2014 at 10:08 PM, Simon Kelley >> wrote: >>> On 30/09/14 15:02, Karl Vogel wrote: First version of the patch generated a compiler warning due to improper initialization of a variable. Karl Vogel (1): Use nanosecond granularity when checking for file changes. src/dnsmasq.c | 20 +++- src/dnsmasq.h |7 ++- src/option.c |3 ++- 3 files changed, 19 insertions(+), 11 deletions(-) >>> >>> This looks fine, but I have a vague worry about breaking the build on >>> old C libraries that don't define the st_mtim field. Does anyone know >>> when this entered the standard? This Ubuntu 14.04 system has the >>> nanosecond fields in the headers, but not in the stat(3) manpage :( >> >> According to the linux man page, "nanosecond timestamps are nowadays >> standardized, starting with POSIX.1-2008". (supported since kernel 2.5.48) >> >> http://man7.org/linux/man-pages/man2/stat.2.html >> >> It is also present in uClibC (I actually needed the patch for my OpenWRT >> gateway, which uses uclibc). >> >> I'm not sure what the status is of the BSD's. > > Checked in FreeBSD: > > https://svnweb.freebsd.org/base?view=revision&revision=205792 > > Date: Sun Mar 28 13:13:22 2010 UTC (4 years, 6 months ago) > > " > Rename st_*timespec fields to st_*tim for POSIX 2008 compliance. > > A nice thing about POSIX 2008 is that it finally standardizes a way to > obtain file access/modification/change times in sub-second precision, > namely using struct timespec, which we already have for a very long > time. Unfortunately POSIX uses different names. > > This commit adds compatibility macros, so existing code should still > build properly. Also change all source code in the kernel to work > without any of the compatibility macros. This makes it all a less > ambiguous. > > I am also renaming st_birthtime to st_birthtim, even though it was a > local extension anyway. It seems Cygwin also has a st_birthtim. > " > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] dnsmasq deployed with dnssec
on cerowrt (ALONG with all the fq_codel, and ipv6 chocolately goodness) http://n1.netalyzr.icsi.berkeley.edu/summary/id=43ca253f-2477-6d1fcde4-650e-45fa-8551 dnssec. working. after 12 years. /me happy THANK YOU SIMON FOR THIS IMPORTANT WORK! (I am puzzled about the edns0 result, tho.) -- Dave Täht https://www.bufferbloat.net/projects/make-wifi-fast ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] rebind-protection vs servers-file
I have been fiddling with improving my internal dns, by creating a file that has all my internal dns servers in it that I can easily copy everywhere. Example serversfile. server=/rossow.r.lupinlodge.org/172.23.143.9 rev-server=172.23.8.0/23,172.23.143.9 server=/lodge.r.lupinlodge.org/172.23.143.7 rev-server=172.23.6.0/23,172.23.143.7 and Adding the one line of parsing needed in openwrts dnsmasq script... with rebind-protection enabled I get an error if trying to ping rossow.r.lupinlodge.org with it disabled, it does the right thing. Will fiddle some more -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Trying to get hnetd working, trying to get distributed dns better
I setup a bunch of picostations running openwrt barrier breaker to try and get hnetd working, some details here: https://plus.google.com/u/0/107942175615993706558/posts/jV9WJyEYGGP Ran into problems also with getting reverse dns to work right. I think I should switch to blogging this stuff rather than g+. It would let me draw pretty pictures of all this complexity. -- Dave Täht http://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Trying to get hnetd working, trying to get distributed dns better
On Mon, Nov 24, 2014 at 1:25 PM, Simon Kelley wrote: > On 23/11/14 17:16, Dave Taht wrote: >> I setup a bunch of picostations running openwrt barrier breaker to try >> and get hnetd working, some details here: >> >> https://plus.google.com/u/0/107942175615993706558/posts/jV9WJyEYGGP >> >> Ran into problems also with getting reverse dns to work right. >> > > > You're doing stuff like rev-server=172.23.2.0/23,172.23.2.1 > but the reverse zone isn't trivially representable as an in-addr.arpa > zone unless the prefix length is divisible by 8 > > 2.23.172.in-addr.arpa corresponds with 172.23.2.0/24, but what's the > equivalent for 172.23.2.0/23 172.23.2.0/24 172.23.3.0/24 But yes, I had forgotten how reverse dns lookups worked in the general case, and will try distributing a file with the /24s broken out. Thanks! > You can do nasties with cnames, but rev-server doesn't. It also doesn't > seem to error if size%8 != 0, which is bad. However, I would argue that the correct dnsmasq behavior should be to break it up into /24s internally, whenever possible, and to retain the expressive simplicity of being able to specify other prefix lengths. > > Cheers, > > Simon. > > > -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] rebind-protection vs servers-file
On Mon, Nov 24, 2014 at 1:02 PM, Simon Kelley wrote: > On 22/11/14 23:06, Dave Taht wrote: >> I have been fiddling with improving my internal dns, by creating a >> file that has all my internal dns servers in it that I can easily copy >> everywhere. >> >> Example serversfile. >> >> server=/rossow.r.lupinlodge.org/172.23.143.9 >> rev-server=172.23.8.0/23,172.23.143.9 >> >> server=/lodge.r.lupinlodge.org/172.23.143.7 >> rev-server=172.23.6.0/23,172.23.143.7 >> >> and Adding the one line of parsing needed in openwrts dnsmasq script... >> >> with rebind-protection enabled I get an error if trying to ping >> rossow.r.lupinlodge.org >> >> with it disabled, it does the right thing. >> >> Will fiddle some more >> > > So dnsmasq is forwarding the query for rossow.r.lupinlodge.org and > getting an RFC 1918 address back as the answer? That will trigger the > rebind protection, which does nothing more than disallow RFC1918 > addresses in answers from upstream servers; it's not very bright. As far > as I can see, rebind protection is fundamentally incompatible with the > network-of-dnsmasq instances you're experimenting with, since RFC1918 > addresses as answers from other dnsmasq instances are required. I had figured that specifying these in the serversfile would override the basic rebind protection for these ips. > > > Cheers, > > Simon. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] sorting out the right ipv6 addr to choose and name in a source specific world
I have been wrestling with prefix coloring, where choosing a "best" prefix would be of use in (for example) reducing the problems induced by happy eyeballs when more than one ipv6 prefix is present and several other scenarios. There are many parts to this - one is in addressing, the other in DNS, and this is not dnsmasq specific but kind of general. * gai.conf Does anyone have a "better" gai.conf file or getaddrinfo implemention "out there? This is the closest I've found to what I sort of think I want. http://biplane.com.au/blog/?p=122 * hints for addressing? I will start with the complex scenario - I have three primary connections to the internet (one is hardline, one is 5 hops away on a source specific gateway to elsewhere, the last LTE), with slaac, dhcp, and privacy addresses assigned for each, a ula for internal addressing (with possibly slaac, dhcp, and privacy addresses), and a vpn (also on a ula). What the heck, let's throw in a hip address, also. And... why not? A legacy ipv6 tunnel from hurricane, a 2002:address for 6to4 The ideal scenario is where the host app picks the "best" address for each connection type, and I am a little vague on what actually happens. What my backbrain (but not RFC 3484 - is there a later rfc for what gai.conf should do?) says should happen is that the host should pick the shortest prefix match between source and destination. Well, it turns out this breaks down - my tunnel is a 2001::address, and my native ipv6 connection is a 2600::address, and my destination (being on the "legacy" internet), is a 2001::address, so things tend to pick the tunnel rather than the native address. A differentiation between these is that I have a different MTU for each. Another is how these addresses are acquired - the main address comes from dhcpv6, tunnel from a he speciifc script, the source specific gateway comes from hnet, the lte address is pppoe And worse, the "best" address is dynamic and changes every week, and on reboots, (this just happened to me and I went nuts flushing old ipv6 addrs everywhere, since I lack hnetd) and caching it or using it internally is a bad idea when a static ULA or more static tunnel addr is available, The LTE connection costs money to use, and is definately "secondary" in intent, and I can see supplying that via ra as secondary. I can also see treating almost all the others as "secondary" also, but it probably would be nice to have the nearly equal cost hnetd supplied prefix have a chance at being used occasionally. and, sigh, the ip route command has no ability currently to set secondary on an address. * In terms of DNS spitting all these into a single DNS record strikes me as insane. However, having more than one visible address per dns entry strikes me as desirable. Certainly a dhcp supplied address should end up in dns, and dnsmasq also has a mechanism to put slaac assigned address into dns. putting the ULA in the local dns is actually desirable when you have split dns. Perhaps having a subdomain per address type? dave.lte.home.lan dave.slaac.home.lan dave.dhcp.home.lan? I am not offering any solutions here, just sharing a headache. There are some other basic problems like setting a default src address on a default route in this scenario that are giving me headaches in the source specific universe... * In terms of being a host and selecting the for example, I think linux presently choses the last assigned static address as it's default source, and that can be overridden with stuff like: ip -6 route add default via 2001:db8::1 dev ethic src 2001:db8::abcd but it is not done today, and is not always the correct thing. I add a vpn address last in my case. What I see happening now is distributing source specific routes to hosts doesn't work, if you merely have default from 2001:558:6045:bd:8dcc:5e18:dd54:b31c via fe80::6eb0:ceff:fe0b:e2ab dev eth0 proto babel metric 1024 default from 2601:9:3640::/60 via fe80::6eb0:ceff:fe0b:e2ab dev eth0 proto babel metric 1024 and no broader default, the right thing doesn't happen for source address selection on the host. You end up with no ipv6 connectivity at all until you add something like this default via fe80::6eb0:ceff:fe0b:e2ab dev eth0 metric 1024 or this default from :: via fe80::4a1:51ff:fea3:1304 dev eth0.2 proto babel metric 1024 (different machine) to get something that works. On Mon, Dec 1, 2014 at 2:17 PM, Simon Kelley wrote: > On 01/12/14 18:49, Michael Gorbach wrote: >> On Nov 30, 2014, at 11:17 AM, Simon Kelley >> wrote: >>> >>> On 29/11/14 19:18, Michael Gorbach wrote: Hi All, I've got a question and potential enhancement request. It looks like right now, the (very useful) interface-name feature pulls all (global) addresses from the interface. One of my machines uses IPv6 privacy extensions (known in Linux as use_tempaddr), which means that in addition to link-local and permanent global addresses, it has a rotating cas
Re: [Dnsmasq-discuss] [homenet] sorting out the right ipv6 addr to choose and name in a source specific world
On Thu, Dec 18, 2014 at 2:06 PM, Brian E Carpenter wrote: > On 19/12/2014 04:07, Michael Richardson wrote: I am way behind on my mail (this thread) and will be away for the holidays. Merry Christmas, everyone, and to all a happy new year! >> Dave, >> my take is that applications, and the entire gai.conf/getaddrinfo() library >> is broken. Applications can neither be updated nor be trusted to know enough >> about the system to be able to make a proper decision. I concur. Also other apis dating from the 70s, like sendmsg,getmsg, and the new sendmmsg,getmmsg are a real pita to use, but increasingly of interest to the webrtc, quic, and brave new post-tcp udp-only world. >> Somewhere, someone was working on a new connect(2) call that took FQDNs >> rather than sockaddr's, such that the kernel could take ownership of this >> problem. > > I suppose you are thinking of Name Based Sockets: > http://tools.ietf.org/html/draft-ubillos-name-based-sockets > > It's dead, as far as I know. It's not dead, it's resting! The kernel work is not that out of date (3 years). Why did progress stop? https://github.com/namebasedsockets I for one would really like names to get more closely tied to numbers... > >> (Of course, actually solving the problem in a kernel is probably the >> wrong answer). >> What is necessary is some new infrastructure inside the box which becomes >> standardized (like sockets API was), with some daemon that thinks about the >> best source addresses is, and possibly gets involved with routing protocols. >> (I'm told that OSX has a sophisticated state machine that combines DHCP and >> 1x, and wifi... it sounds like it could be the start of such a thing) Openwrt had to go to very tightly integrated internal messaging API in order to get all of the newly mandated dynamicsm in ipv6 sort of taken care of, and that still isn't quite working right. Yes, looking over OSX would be a good idea. >> >> I think that shim6 and mptcp are answers in this equation. >> >> shim6 has, I'm told, deployment issues which make me very very sad. > > Like, it cannot get through most firewalls. I would like to test it against modern firewalls. > >> mptcp, I'm told, is likely to show up in Apple and Google products and >> infrastructure, and my idea (and many others) is that you don't always have >> to pick the perfect address for the SYN, just one that works, but rather one >> can add better addresses as one discovers them. > > But bad luck if you need UDP. Meh. The world is seemingly moving to userspace networking anyway. > > Some form of intelligent probing does seem to be the answer, > but certainly that needs to be generic because we cannot expect > all apps developers to reinvent it. That's one reason we wrote > http://tools.ietf.org/html/draft-naderi-ipv6-probing recently. > >Brian > -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
Wow, this thread goes back a ways. Is ds.test-ipv6.com still configured wrong, and does it pass now? It passes for me (but I am behind a more modern openwrt box right now) Is there another site that demonstrates this problem? BTW: For a while there (on comcast), in production, I ran with pure ipv6 for dns (it reduced ipv4 nat pressure significantly!), but it hung after a few days and I never got back to it. Were any problems like this experienced and/or fixed for dnsmasq in the past 8 months or so? Anyway... enough incremental fixes have landed all across the board in openwrt, and the chaos calmer process seems to have settled down enough, to consider doing an entirely updated cerowrt based on 3.14 and pushing things like dnsmasq further forward... ... but I, personally, am still, not in the position to easily build and test a new dnsmasq package for cerowrt and have no funding or time for further development based on chaos calmer. Hopefully someone else in the openwrt or cerowrt world can take up the slack. I see that several bleeding edge sub-distros of openwrt have also emerged on their forums... (Yet I will still try to produce a test dnsmasq version from the cerowrt-3.10 tree but I doubt it would be safe to do an opkg update for it.) On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > OK, it's taken some time, but with this insight, I've recoded the > relevant stuff to look for the limits of the signed DNS tree from the > DNS root down. That's clearly the correct way to do it, and should > avoid the original problem here, caused by sending DNSSEC queries to > DNSSEC-unaware servers in the unsigned parts of the tree. > > This was quite a big change, and it could do with some serious > testing. Available now on the dnsmasq git repo, or as 2.73test3 in a > tarball. > > There are other DNSSEC fixes in there too, Check the changelog. > > > Cheers, > > Simon. > > > On 04/10/14 22:45, Anders Kaseorg wrote: >> On Fri, 3 Oct 2014, Anders Kaseorg wrote: secure no DS means that the original unsigned answer should be accepted, except that it shouldn't. There's no way to distinguish between secure lack of DS because we've reached an unsigned branch of the tree, and secure lack of DS because we're not at a zone cut, except if we know where the zone cuts are, and we don't. >>> >>> Having just looked through RFC 5155 for clues: isn’t that the >>> purpose of the NS type bit in the NSEC3 record? In this example, >>> DS university would give an NSEC3 record with the NS bit clear. >>> That signals that we should go down a level and query DS campus. >>> In this case we find a signed DS there. But if we were to find >>> an NSEC3 with the NS bit set, then we’d know that we’ve really >>> found an unsigned zone and can stop going down. >> >> Aha: and this is exactly the answer given at >> http://tools.ietf.org/html/rfc6840#section-4.4 . >> >> Anders >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > > iQIcBAEBCAAGBQJUrrGDAAoJEBXN2mrhkTWitZ0P/1T8AaAAlcgI6Z9oDXBGKR+Q > gw0E0bUcmMsvOf5YepR4jqNqonMYBDEv5aSx4EG13LEYBdEekVjUWlakcTSFGCCH > r4bx91XmxZBBSjBM2UNRd4B/dGY34YydbjPFnV/Mmzv5FdUzmVxG3PRQ3E0EyyLp > Eczm+s0Dxz4pGzEINhFHZ6T8sByDeSjAb3adBNidofKFSevwIv/iOMOQJ5moQfem > VkY+azpFzSmpdeNpIU+uboMfcg4jhFpVU3WRr7umTmLc0KOus1j7ao9GxSujPQHo > S7q+IwSwKHUPMEeEmQh+j7yJ2seweGuqGl0quWkHaqGUIOh2C2E756qZfXeenUcv > ia00dcKmpCYi0Ay3nXdgIq91aRwc78GsR93MEBTuvJwDmAUDupsbZMdlA/3D6tOd > ZTREvBmxkFz/QYOo731N/JzdaflQeLUrNPIwRJKpYFW9caotiJ3EiihRGrqrjHBk > a7h8QXy8bQKxc3G0LLKlJNIkxApnNzG6YGSmD6t9bzRPn/sSqar0Ws0IIYd5nYDv > hB4ggfpHvrnEbke4lkfoEBLbJmFFcnSngJh7oDCMT6XEpqeUH7HT0RmYEncnbH1C > 9ZRpzUlzxyhZawjBbXWQBNmxhT2Z/KFYkLUkKMPnb060CBtn8DwlkZ22b2dqOvH8 > TeRUKySnx6ieH+55fjG4 > =CehB > -END PGP SIGNATURE- -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
OK, I built this latest dnsmasq as a test for cerowrt-3.10-50 users: login to the router cd /tmp wget http://snapon.lab.bufferbloat.net/~cero2/dnsmasq/dnsmasq-full_2.73-3_ar71xx.ipk opkg install ./dnsmasq-full_2.73-3_ar71xx.ipk (ignore the warnings about not overwriting several files) I did a few tests on the former dnssec problematic sites and everything looked kosher. As for the variety of the dnssec testing web sites about half seem down or mis-behaving. Sigh. the ongoing costs of keeping core internet test tools going strikes again... In an orgy of self-flagellation, and *only because I have native ipv6* I also turned off dns queries over ipv4 entirely (this is option peerdns '0' in /etc/config/networks on cerowrt's ge00 config), and will pound on it a few days/weeks. I send this email prior to actually trying that, however On Thu, Jan 8, 2015 at 10:07 AM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > > > On 08/01/15 17:44, Dave Taht wrote: >> Wow, this thread goes back a ways. Is ds.test-ipv6.com still >> configured wrong, and does it pass now? It passes for me (but I am >> behind a more modern openwrt box right now) > > ds.test-ipv6.com is still showing the same behaviour it was back in > April (!) as far as I can see. My bad. The "modern openwrt" I am behind does not have the dnsmasq-full package installed. > Queries to test-ipv6.com (which is what > tripped up Jim in the first place) work fine on the latest dnsmasq, > code, forwarding to 8.8.8.8 > >> >> Is there another site that demonstrates this problem? > > There were three in Aaron Wood's original posting (subject: Had to > disable dnssec today) > > - - Bank of America (sso-fi.bankofamerica.com) > - - Weather Underground (cdnjs.cloudflare.com) > - - Akamai (e3191.dscc.akamaiedge.net.0.1.cn.akamaiedge.net) > > > All three work for me with the new code. I didn't try old dnsmasq, to > see if the repair was from that or the DNS configuration. > >> >> BTW: For a while there (on comcast), in production, I ran with >> pure ipv6 for dns (it reduced ipv4 nat pressure significantly!), >> but it hung after a few days and I never got back to it. Were any >> problems like this experienced and/or fixed for dnsmasq in the past >> 8 months or so? >> > > http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=5782649ad95382dd558df97b33b64e854d8789fb > > is a possible candidate. K. >> Anyway... enough incremental fixes have landed all across the board >> in openwrt, and the chaos calmer process seems to have settled >> down enough, to consider doing an entirely updated cerowrt based on >> 3.14 and pushing things like dnsmasq further forward... >> >> ... but I, personally, am still, not in the position to easily >> build and test a new dnsmasq package for cerowrt and have no >> funding or time for further development based on chaos calmer. >> Hopefully someone else in the openwrt or cerowrt world can take up >> the slack. I see that several bleeding edge sub-distros of openwrt >> have also emerged on their forums... >> >> (Yet I will still try to produce a test dnsmasq version from >> the cerowrt-3.10 tree but I doubt it would be safe to do an opkg >> update for it.) > > There shouldn't be any non backwards-compatible changes in dnsmasq to > bite you. Don't know about other stuff. So far so good. > > > Cheers, > > Simon. > > >> >> On Thu, Jan 8, 2015 at 8:34 AM, Simon Kelley >> wrote: OK, it's taken some time, but with >> this insight, I've recoded the relevant stuff to look for the >> limits of the signed DNS tree from the DNS root down. That's >> clearly the correct way to do it, and should avoid the original >> problem here, caused by sending DNSSEC queries to DNSSEC-unaware >> servers in the unsigned parts of the tree. >> >> This was quite a big change, and it could do with some serious >> testing. Available now on the dnsmasq git repo, or as 2.73test3 in >> a tarball. >> >> There are other DNSSEC fixes in there too, Check the changelog. >> >> >> Cheers, >> >> Simon. >> >> >> On 04/10/14 22:45, Anders Kaseorg wrote: >>>>> On Fri, 3 Oct 2014, Anders Kaseorg wrote: >>>>>>> secure no DS means that the original unsigned answer >>>>>>> should be accepted, except that it shouldn't. There's no >>>>>>> way to distinguish between secure lack of DS because >>>>>>> we've reached an unsigned branch of the tree, and secure >>>&g
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
I was able to lock up this version of dnsmasq twice: 100% cpu usage. No syscalls were visible from strace during the lockup. Lockups occurred once on nearly at boot, and the second time, after a few hours of casual usage, with only ipv6 upstreams, on cero-3.10.50-1. furthermore, the only thing that kills it is a kill -9. I will build a non-stripped version in the morning... (and I do note that I was testing two things - one ipv6 upstreams only, and two, dnssec. Prior to this version I was using both ipv4 and ipv6 upstreams, no issues, had dnssec on also, usually no issues) Other suggestions for debugging the causes of a lockup requested (log all queries?) ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] Problems with DNSsec on Comcast, with Cero 3.10.38-1/DNSmasq 4-26-2014
I strongly suspect an ipv6 fragmentation handling bug in the kernel version cerowrt uses. Have tons of evidence pointing to that now, starting with some tests run last year from iwl and also the tests that netalyzer was doing. And: I just locked up the box completely while doing some dnssec stuff. will go through kernel git logs and see what has happened there since 3.10.50. Turning on the edns-packet-max feature now, however, as I lack time to poke into this in more detail, and we're supposed to be testing dnssec as it is ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Ow-tech] DNSSEC
On Wed, Feb 11, 2015 at 2:11 PM, Seth wrote: > On Tue, 10 Feb 2015 16:57:07 -0800, Ranganathan Krishnan > wrote: > >> I am looking into ways to improve DNS on the openwireless router software. >> When I mentioned DNSSEC as one of the items to review, I received this >> response from one of the developers. >> >> http://sockpuppet.org/blog/2015/01/15/against-dnssec/ I lack time in my life for a point by point rebuttal. >> CeroWRT put in work to include DNSSEC so there must be folks on the >> CeroWRT >> list who don't see it that way. If you wish to engage the advocates it would help to ask the question of the relevant mailing lists. There are many, but I don't know them all, but cc'ing dan york who is big on dane. To clarify, in cerowrt, dnssec support was one of a dozen technologies we wanted to prove viable on home routers and e2e, that comcast viewed it as important enough to fund simon kelly to implement, and it's been up and working for about 3 years now. We didn't do any real development of it in cerowrt, we merely tested the results of that effort and helped file off the rough edges, to make it more generally deployable. Which it is. Benefits I see to dnssec end-2-end: 1) The big one, that I personally love, is having a working NXDOMAIN, where my upstream ISP cannot fill a dns miss with advertising domains. There are a lot of valuable fallouts from this. 2) It doesn't cost much in terms of cpu or latency 3) A huge percentage of the sites I regularly visit ARE signed. At least one criticism, now thoroughly eliminated by existence proof, is that you can't run dnssec on the edge, and the problems that it causes are mostly invisible - as are the benefits - as it should be. The author of that post is more than welcome to try it for himself, day in, day out, as we have. >> I would appreciate any pointers to >> discussions refuting >> the points made in the blog post above. If the points made in the blog >> post stand >> there would not be any reason to include DNSSEC in the openwireless >> router. So, >> I am looking for counterpoints that might establish that DNSSEC could have >> value. > > > This talk doesn't refute the problems with DNSSEC, but rather reinforces > them. > > Dan Bernstein: Authenticating The Whole Internet on Vimeo > http://vimeo.com/18417770 > > Worth a watch > > Dan Kaminsky's response - http://dankaminsky.com/2011/01/05/djb-ccc/ > > Personally I'm a fan of DNSChain over DNSSEC - https://okturtles.com/ The debate has gone on 15 years. Alternative proposals need to be viable enough to merit rollout... which, lacking consensus, would take another 15 years. Certainly I would like to see DNS replaced with something better, and I am willing to work towards that goal... but given a choice whether to deploy dnssec more fully or not, I'd choose deployment. > ___ > Ow-tech mailing list > ow-t...@lists.eff.org > https://lists.eff.org/mailman/listinfo/ow-tech -- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNAME or domain to domain transltion?
I had had a lot of hope for DNAMEs, but they were shot down in the ietf years ago. Vestiges survive in "bind", at least, but I suspect there is little application support. I would not mind an attempt to resurrect them. Naming in the face of being renumbered all the time by various ipv4 and ipv6 providers is a real PITA. On Mon, Mar 16, 2015 at 6:33 PM, Adrian Lewis wrote: > Would it be fair to assume that there is no trick to this and if so, is > there any interest in a feature request for supporting DNAME records? > Unfortunately I'm simply a (very grateful) freeloader with no programming > skills whatsoever. I have no idea whether implementing this would be > something really simple or the opposite. > > Many thanks, > > Adrian > > -Original Message- > From: Adrian Lewis [mailto:adr...@alsiconsulting.co.uk] > Sent: 11 March 2015 19:06 > To: 'dnsmasq-discuss@lists.thekelleys.org.uk' > Subject: DNAME or domain to domain transltion? > > Hi, > > I've tried to find this out through reading and googling and I can't find > any obvious solution so I was hoping someone might know a trick that would > help me. I'm trying to do some sort of domain to domain translation so > that when a query for the a record of host1.firstdomain.tld is received, > dnsmasq does a lookup for host1.seconddomain.tld and returns the IP as if > the client had asked for host1.seconddomain.tld. > > For an individual host this is much the same as a CNAME record but I need > to be able to specify the hostname dynamically so that > %anything%.firstdomain.tld is a CNAME for %anything%.seconddomain.tld. > Wildcards don't help either as this is not a case of > %anything%.firstdomain.tld being a CNAME for > specifichost.seconddomain.tld. > > From what I gather, this is what a DNAME record will do although support > for this type of record seems a little scarce and dnsmasq doesn't support > these directly. The purpose is not nefarious and it is all being done for > internal to internal translation. I've not gone into why I need this in > any great detail but it's nothing dodgy. > > The --synth-domain feature suggests that there is some sort of engine to > create dynamic replies based on the query but I need the equivalent of: > --synth-domain=firstdomain.tld,seconddomain.tld > > Can anyone help? > > TIA, > > Adrian > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNAME or domain to domain transltion?
On Mon, Mar 16, 2015 at 9:18 PM, Brad Smith wrote: > On 03/16/15 22:41, Dave Taht wrote: > >> I had had a lot of hope for DNAMEs, but they were shot down in the ietf >> years ago. Vestiges survive in "bind", at least, but I suspect there is >> little application support. >> >> I would not mind an attempt to resurrect them. Naming in the face of >> being renumbered all the time by various ipv4 and ipv6 providers is a >> real PITA. >> > > I don't get why you said they were "shot down". The DNAME record type > is standards track with 2 RFCs issued. Starting as RFC 2672 and updated > 3 years ago with RFC 6672. As far as I can see they're supported by > most of the open source authoritative name servers and recursive > resolvers (BIND, NSD / Unbound, Knot, Yadifa, MaraDNS), commercial > implementations such as Cisco, Nominum, Microsoft as well as OS > resolvers. > I stand corrected. Do any applications work with DNAME? > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] DNAME or domain to domain transltion?
I have renewed hope then. On Mon, Mar 16, 2015 at 11:09 PM, Paul Vixie wrote: > dname is not dead. it always included a synthesized cname. so a dname in > the zone file can create an unlimited number of cnames in cache. > > re: > > Dave Taht > Tuesday, March 17, 2015 11:41 AM > I had had a lot of hope for DNAMEs, but they were shot down in the ietf > years ago. Vestiges survive in "bind", at least, but I suspect there is > little application support. > > I would not mind an attempt to resurrect them. Naming in the face of being > renumbered all the time by various ipv4 and ipv6 providers is a real PITA. > > > > > -- > Dave Täht > Let's make wifi fast, less jittery and reliable again! > > https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb > > > -- > Paul Vixie > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] dnsmasq 2.55 failures
On Mon, Mar 23, 2015 at 3:31 PM, John Knight wrote: > Hi, > > > > We use dnsmasq 2.55 in our Linksys routers. We have generally had few > problems with dnsmasq, but recently one of our customers reported a failure > that did not recover. > I have seen a failure with dns for ipv6 on dnsmasq like this (2-3 days of uptime, then spiraling off into a unresponsive loop) as recently as 2.72. Since ipv6 has now been rolled out universally across comcast's services and this is (to my knowledge) the only crash bug dnsmasq has anymore, I have been meaning to get the 2.73rc1 release candidate up and running full time in an mixed ipv4/ipv6 environment and to pound it flat with queries for some time now. I hope to deploy that candidate in the lab in a week or so. More eyeballs would be helpful on finally tracking it down. What I typically do is pound through the alexa top 1 million, repeatedly, and also namebench, other tests are feasible. I have some hope that the edns0 bugfix in this release candidate actually fixes it. The five years of dnsmasq releases since 2.55 have had many bug fixes (see release notes) and upgrades (notably dnssec), also, and it is well worth upgrading your userbase even if this fix remains difficult to find. folk on your side of the firmware might also benefit from seeing jim gettys do his "insecurity in home embedded devices" talk, filmed here: http://cyber.law.harvard.edu/events/luncheon/2014/06/gettys and updated considerably since, with new data. https://gettys.wordpress.com/2014/10/06/bufferbloat-and-other-challenges/ > > > On the customer’s router, the maximum number of dhcp clients is 50. The > customer happens to be a hotel and experienced a high usage rate and > exceeded the 50 dhcp client limit. As expected, the 50 active clients > received their IP address and those over 50 did not. However, the customer > noticed that dns stopped working when this happened. The CPU usage went to > 50% (49.4% was logged to dnsmasq by top). This may be 100% of single CPU > as this is a dual CPU router. The environment is a mixed environment of > both IPv4 and IPv6… I believe we only use dnsmasq for IPv6 for the dns > capability; ipv4 uses dhcp and dns capability from dnsmasq. The customer > goes on to say that dhcp renewals were not being handled as well. Customer > has also added that sometimes they see issue with only 30 active dhcp users > or so. Apparently it requires a good number of users before it happens… > and it does not occur immediately…. Sometimes a few days or more before it > happens. > > > > I looked through some of your release notes and noticed some similarities > on some bug reports, but did not see an exact match. Does any of this make > sense to you? We tried reproducing this in our lab and were unsuccessful > simulating the scenario. We realize that our dnsmasq version is pretty old > and a lot of fixes may have been applied since version 2.55. If there is a > good chance that the issues seen have been fixed in a later release, we > will consider upgrading to a newer version. If you could comment on the > likelihood of a fix already being made, I would appreciate it. Since we > cannot reproduce the problem, we will likely have to apply a newer version > (hopefully very stable) and have customer try it… something we would prefer > to avoid unless we have some confidence that the problem may already be > fixed in the newer release. > > > > Thank you for your time. I look forward to hearing from you. > > > > Best Regards and thanks, > > > > John Knight > > > > *JOHN KNIGHT * > Senior Software Engineer > > *Belkin International * > > O +1 949 238 4543 > M +1 949 351 1020 > [image: Belkin-WeMo-Linksys] > > > > > __ > Confidential This e-mail and any files transmitted with it are the property > of Belkin International, Inc. and/or its affiliates, are confidential, and > are intended solely for the use of the individual or entity to whom this > e-mail is addressed. If you are not one of the named recipients or > otherwise have reason to believe that you have received this e-mail in > error, please notify the sender and delete this message immediately from > your computer. Any other use, retention, dissemination, forwarding, > printing or copying of this e-mail is strictly prohibited. Pour la version > française: http://www.belkin.com/email-notice/French.html Für die > deutsche Übersetzung: http://www.belkin.com/email-notice/German.html > __ > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss
Re: [Dnsmasq-discuss] [Babel-users] Looping in EAGAIN
I see this patch for EAGAIN on an interface going away did not make the
babel-ss-merge branch apparently. (for those new to this bug, see:
http://lists.alioth.debian.org/pipermail/babel-users/2014-October/001777.html
for more details. )
No, I haven't had time to test this patch, nor have I come up with a better
idea.
I am curious if there could be some other *more robust* means of detecting
when an interface has gone away, and/or how dnsmasq was coping with this
situation nowadays.
(I'd mentioned this problem on the endless homenet thread
http://www.ietf.org/mail-archive/web/homenet/current/msg05156.html
and, thought I'd check to see if it was mainlined!)
I certainly hate any possibility anywhere in routing code where a
possibility for infinite loop existed. are there any checkers for such
loops in the world?
On Wed, Oct 15, 2014 at 2:00 PM, Juliusz Chroboczek <
j...@pps.univ-paris-diderot.fr> wrote:
> Dave,
>
> I'm not going to have time to test this for a while. In the meantime,
> here's a proposed patch, please let me know if you find the time to test
> it.
>have
> -- Juliusz
>
> diff --git a/net.c b/net.c
> index 6f9728f..9b0b738 100644
> --- a/net.c
> +++ b/net.c
> @@ -141,7 +141,7 @@ babel_send(int s,
> {
> struct iovec iovec[2];
> struct msghdr msg;
> -int rc;
> +int rc, count = 0;
>
> iovec[0].iov_base = (void*)buf1;
> iovec[0].iov_len = buflen1;
> @@ -156,13 +156,18 @@ babel_send(int s,
> again:
> rc = sendmsg(s, &msg, 0);
> if(rc < 0) {
> -if(errno == EINTR)
> -goto again;
> -else if(errno == EAGAIN) {
> +if(errno == EINTR) {
> +count++;
> +if(count < 1000)
> +goto again;
> +} else if(errno == EAGAIN) {
> int rc2;
> rc2 = wait_for_fd(1, s, 5);
> -if(rc2 > 0)
> -goto again;
> +if(rc2 > 0) {
> +count++;
> +if(count < 1000)
> +goto again;
> +}
> errno = EAGAIN;
> }
> }
--
Dave Täht
Let's make wifi fast, less jittery and reliable again!
https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] High Availability: Part Deux
I too would like a more high availability form of DNS and dhcp in general. One thing that I do currently is use anycast in my (fairly complex, highly routed) campus network, so that the local dns servers are distributed via the babel routing protocol, and the closest one that is up responds. (anycast is widely used on the internet backbone as well) this introduces problems in monitoring what, exactly, is "up", and is not as effective as what I would like. Replicating the dhcp leases and dns entries remains a problem (what usually happens is users trying a non working AP, end up trying another). I still regard this distributed solution as it stands, as being superior to the alternative of hauling back all dns and dhcp to a set of central servers, which then would require perfect connectivity at all times, centralized management of everything, and result in worse caching. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] DNSSEC and www.ietf.org
I have trouble accessing ietf.org, also, with older versions of dnsmasq + dnssec, presently. On Mon, Mar 30, 2015 at 8:52 AM, Marc Petit-Huguenin wrote: > Am I the only one who cannot access www.ietf.org since Cloudflare enabled > DNSSEC? (with dnsmasq-full 2.73-3) > > Thanks. > > -- > Marc Petit-Huguenin > Email: m...@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > > > ___ > Cerowrt-devel mailing list > cerowrt-de...@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [Cerowrt-devel] DNSSEC and www.ietf.org
for cerowrt-3.10? Really wasn't planning on it. Didn't even know there was a problem til today... for my current openwrt builds - you betcha. thursday-ish. On Mon, Mar 30, 2015 at 11:17 AM, Marc Petit-Huguenin wrote: > On 03/30/2015 11:49 AM, Simon Kelley wrote: >> Dnsmasq bug, should be fixed in 2.73rc3 pls shout if not. >> >> (the problem is that the clouldflare.bet zone includes the domains >> /003.cloudflare.net (that's ctrl-c at the start) and that was >> confusing dnsmasq.) > > Thanks. > > Dave, any chance to get a build of 2.73rc3? > >> >> Simon. >> >> >> >> On 30/03/15 16:58, Dave Taht wrote: >>> I have trouble accessing ietf.org, also, with older versions of >>> dnsmasq + dnssec, presently. >> >>> On Mon, Mar 30, 2015 at 8:52 AM, Marc Petit-Huguenin >>> wrote: >>>> Am I the only one who cannot access www.ietf.org since Cloudflare >>>> enabled DNSSEC? (with dnsmasq-full 2.73-3) >>>> >>>> Thanks. >>>> >>>> -- Marc Petit-Huguenin Email: m...@petit-huguenin.org Blog: >>>> http://blog.marc.petit-huguenin.org Profile: >>>> http://www.linkedin.com/in/petithug >>>> >>>> >>>> ___ Cerowrt-devel >>>> mailing list cerowrt-de...@lists.bufferbloat.net >>>> https://lists.bufferbloat.net/listinfo/cerowrt-devel >>>> >> >> >> >> >> > > -- > Marc Petit-Huguenin > Email: m...@petit-huguenin.org > Blog: http://blog.marc.petit-huguenin.org > Profile: http://www.linkedin.com/in/petithug > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] a little feedback on the new dnssec startup method in openwrt
A) Not clear what happens if it tries to write it while the jffs filesystem is still being cleaned B) the dnssec_timestamp file needs to go somewhere that can be written by nobody. B1) trying to create it to /etc/ fails and fails to startup dnsmasq (see A) Thu Apr 2 18:31:52 2015 daemon.info dnsmasq[3705]: started, version 2.73rc3 cachesize 150 Thu Apr 2 18:31:52 2015 daemon.info dnsmasq[3705]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth DNSSEC loop-detect inotify Thu Apr 2 18:31:52 2015 daemon.info dnsmasq[3705]: DNS service limited to local subnets Thu Apr 2 18:31:52 2015 daemon.crit dnsmasq[3705]: cannot create timestamp file /etc/dnssec_timestamp: Permission denied Thu Apr 2 18:31:52 2015 daemon.crit dnsmasq[3705]: FAILED to start up Thu Apr 2 18:31:57 2015 daemon.info dnsmasq[3706]: started, version 2.73 B2) creating it as root, but not chowning it to nobody, fails. In this second case, failure to update mtime is ok and dnsmasq startup Thu Apr 2 18:32:07 2015 daemon.err dnsmasq[3751]: failed to update mtime on /etc/dnssec_timestamp: Permission denied Thu Apr 2 18:32:07 2015 daemon.info dnsmasq[3751]: DNSSEC validation enabled C) making it writable by nobody of course makes it vulnerable to other users running as nobody root@OpenWrt:/etc/config# ls -l /etc/dnssec_timestamp -rw-r--r--1 nobody root 0 Apr 2 18:32 /etc/dnssec_timestamp -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] losing RRSIGS in dnsmasq 2.73rc3
So I am testing with the latest 2.73 release candidate3. I do TWO dnssec queries on the same domain. The first, does the right thing. The second, does not give me the RRSIGs. d@nuc-client:~/public_html/archer_c7_O2$ dig www.bufferbloat.net +dnssec +multi ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> www.bufferbloat.net +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38038 ;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; QUESTION SECTION: ;www.bufferbloat.net.IN A ;; ANSWER SECTION: www.bufferbloat.net.86400 IN CNAME shipka.bufferbloat.net. www.bufferbloat.net.86400 IN RRSIG CNAME 7 3 86400 ( 20150430231644 20150331223348 6560 bufferbloat.net. qVWE6+j4ESNbRoulnJO9FoDdSCWCpghIE2Pe9f0wGaF5 lSdVv5S1A2S6P5YrZaWajp8BWPO/cliXjwStNQdoQ5Et YtHgrDZAMj1hW2CVR8TPWaa+I2R5jnmqbdTslBBCxkpG 2vFLB6SioH8oh4JYtujD3K0XxOY543MclW7FF60= ) shipka.bufferbloat.net.86400 IN A 149.20.54.81 shipka.bufferbloat.net.86400 IN RRSIG A 7 3 86400 ( 20150430184126 20150331182930 6560 bufferbloat.net. QPy1G/6ho5zIbPA8KUKFKjFYVCOvib454oRvaQ1cvfZZ vLyvd8zUmLw8nxAa3hcsU1MZlLAo1ELPEOac8/ND0FkZ Wp8wm/OTajoFM9/cOZqFNXkPBdsboqlSo0+EBJiROuzI u2S8PtoC0y7gJdjeRIXHhoYsv+TeZm9TtrCGBK4= ) ;; Query time: 34 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Apr 02 12:04:27 PDT 2015 ;; MSG SIZE rcvd: 435 d@nuc-client:~/public_html/archer_c7_O2$ dig www.bufferbloat.net +dnssec +multi ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> www.bufferbloat.net +dnssec +multi ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61475 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; QUESTION SECTION: ;www.bufferbloat.net.IN A ;; ANSWER SECTION: www.bufferbloat.net.86397 IN CNAME shipka.bufferbloat.net. shipka.bufferbloat.net.86397 IN A 149.20.54.81 ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; WHEN: Thu Apr 02 12:04:30 PDT 2015 ;; MSG SIZE rcvd: 100 -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] losing RRSIGS in dnsmasq 2.73rc3
On Thu, Apr 2, 2015 at 1:08 PM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > I get a BOGUS validation because there's no DS record for bufferbloat.ne > t > > bufferbloat.net uses dlv.isc.org, which dnsmasq doesn't support. I > think we went round this loop last year sometime. I have to admit that we have not looked at how we did dnssec 4+ years back. It does (now) just appear that we are misconfigured. Attempts to reach www.ietf.org always return the RRSIGS. > > What are you doing which allows this to validate? Maybe a configured > trust-anchor for bufferbloat.net? I guess the first answer is being > returned from upstream, and the second is coming from the dnsmasq > cache. It should have RRSIGs never-the-less, but I can't work out > what's happening until I understand how you're getting validation at all > . I have no idea. I used comcast´s upstream resolvers. (Next up for me is hammering dnssec via as many ways as I can come up with over ipv6, btw) > > > Cheers, > > > Simon. > > > > > > > On 02/04/15 20:10, Dave Taht wrote: >> So I am testing with the latest 2.73 release candidate3. >> >> I do TWO dnssec queries on the same domain. >> >> The first, does the right thing. The second, does not give me the >> RRSIGs. >> >> >> d@nuc-client:~/public_html/archer_c7_O2$ dig www.bufferbloat.net >> +dnssec +multi >> >> ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> www.bufferbloat.net >> +dnssec +multi ;; global options: +cmd ;; Got answer: ;; >> ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38038 ;; flags: qr >> rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4000 ;; >> QUESTION SECTION: ;www.bufferbloat.net.IN A >> >> ;; ANSWER SECTION: www.bufferbloat.net.86400 IN CNAME >> shipka.bufferbloat.net. www.bufferbloat.net.86400 IN RRSIG >> CNAME 7 3 86400 ( 20150430231644 20150331223348 6560 >> bufferbloat.net. qVWE6+j4ESNbRoulnJO9FoDdSCWCpghIE2Pe9f0wGaF5 >> lSdVv5S1A2S6P5YrZaWajp8BWPO/cliXjwStNQdoQ5Et >> YtHgrDZAMj1hW2CVR8TPWaa+I2R5jnmqbdTslBBCxkpG >> 2vFLB6SioH8oh4JYtujD3K0XxOY543MclW7FF60= ) shipka.bufferbloat.net. >> 86400 IN A 149.20.54.81 shipka.bufferbloat.net.86400 IN RRSIG >> A 7 3 86400 ( 20150430184126 20150331182930 6560 bufferbloat.net. >> QPy1G/6ho5zIbPA8KUKFKjFYVCOvib454oRvaQ1cvfZZ >> vLyvd8zUmLw8nxAa3hcsU1MZlLAo1ELPEOac8/ND0FkZ >> Wp8wm/OTajoFM9/cOZqFNXkPBdsboqlSo0+EBJiROuzI >> u2S8PtoC0y7gJdjeRIXHhoYsv+TeZm9TtrCGBK4= ) >> >> ;; Query time: 34 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; >> WHEN: Thu Apr 02 12:04:27 PDT 2015 ;; MSG SIZE rcvd: 435 >> >> d@nuc-client:~/public_html/archer_c7_O2$ dig www.bufferbloat.net >> +dnssec +multi >> >> ; <<>> DiG 9.9.5-3ubuntu0.1-Ubuntu <<>> www.bufferbloat.net >> +dnssec +multi ;; global options: +cmd ;; Got answer: ;; >> ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 61475 ;; flags: qr >> rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 4096 ;; >> QUESTION SECTION: ;www.bufferbloat.net.IN A >> >> ;; ANSWER SECTION: www.bufferbloat.net.86397 IN CNAME >> shipka.bufferbloat.net. shipka.bufferbloat.net.86397 IN A >> 149.20.54.81 >> >> ;; Query time: 0 msec ;; SERVER: 192.168.1.1#53(192.168.1.1) ;; >> WHEN: Thu Apr 02 12:04:30 PDT 2015 ;; MSG SIZE rcvd: 100 >> >> > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUdocsACgkQKPyGmiibgrfJ2wCdEFNDy+Pefl6OJ2TIFintaIs2 > 7c8An1JA7D0CpD+FxhOKU7o/bajnEmkL > =YJ6J > -END PGP SIGNATURE- > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] losing RRSIGS in dnsmasq 2.73rc3
On Thu, Apr 2, 2015 at 1:50 PM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/04/15 21:43, Dave Taht wrote: >> On Thu, Apr 2, 2015 at 1:08 PM, Simon Kelley >> wrote: I get a BOGUS validation because >> there's no DS record for bufferbloat.ne t >> >> bufferbloat.net uses dlv.isc.org, which dnsmasq doesn't support. I >> think we went round this loop last year sometime. >> >>> I have to admit that we have not looked at how we did dnssec 4+ >>> years back. It does (now) just appear that we are misconfigured. >>> Attempts to reach www.ietf.org always return the RRSIGS. >> >> >> What are you doing which allows this to validate? Maybe a >> configured trust-anchor for bufferbloat.net? I guess the first >> answer is being returned from upstream, and the second is coming >> from the dnsmasq cache. It should have RRSIGs never-the-less, but I >> can't work out what's happening until I understand how you're >> getting validation at all . >> >>> I have no idea. I used comcast´s upstream resolvers. > > Are you giving dnsmasq the --dnssec-debug flag? If so you'll still get > a reply (wo an "ad" flag) when the validation fails. That (combined > with the second reply coming from cache) would fit the data provided. > If you remove the dnssec-debug flag, you should get consistent > SERVFAIL replies. No dnssec-debug. # auto-generated config file from /etc/config/dhcp conf-file=/etc/dnsmasq.conf dhcp-authoritative domain-needed localise-queries read-ethers bogus-priv expand-hosts local-service dnssec-timestamp=/etc/dnssec_timestamp domain=lan server=/lan/ dhcp-leasefile=/tmp/dhcp.leases resolv-file=/tmp/resolv.conf.auto addn-hosts=/tmp/hosts conf-dir=/tmp/dnsmasq.d stop-dns-rebind rebind-localhost-ok conf-file=/usr/share/dnsmasq/trust-anchors.conf dnssec dnssec-check-unsigned dhcp-broadcast=tag:needs-broadcast dhcp-range=lan,192.168.1.100,192.168.1.249,255.255.255.0,12h no-dhcp-interface=eth0 >> >>> (Next up for me is hammering dnssec via as many ways as I can >>> come up with over ipv6, btw) >> >> > > I await developments.. Well, I wish I had a better test than namebench. > > S. > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUdq7IACgkQKPyGmiibgrdr7gCglfq0dC/oWCYtQJS5KRd1lErZ > NCAAoIkI5y98kMcDLJtfbx2hEGtfcaDm > =ceEu > -END PGP SIGNATURE- -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] a little feedback on the new dnssec startup method in openwrt
On Thu, Apr 2, 2015 at 1:20 PM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 02/04/15 19:41, Dave Taht wrote: >> A) Not clear what happens if it tries to write it while the jffs >> filesystem is still being cleaned > > Not sure I have anything sensible to add here. > >> >> B) the dnssec_timestamp file needs to go somewhere that can be >> written by nobody. > > This is documented in the manpage entry. > > nobody is the default, but you most systems have a "dnsmasq" user and > run with --user=dnsmasq I would not mind if this much more priv separation existed in openwrt also, yes. >> >> B1) trying to create it to /etc/ fails and fails to startup >> dnsmasq (see A) >> >> Thu Apr 2 18:31:52 2015 daemon.info dnsmasq[3705]: started, >> version 2.73rc3 cachesize 150 Thu Apr 2 18:31:52 2015 daemon.info >> dnsmasq[3705]: compile time options: IPv6 GNU-getopt no-DBus >> no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP no-conntrack ipset auth >> DNSSEC loop-detect inotify Thu Apr 2 18:31:52 2015 daemon.info >> dnsmasq[3705]: DNS service limited to local subnets Thu Apr 2 >> 18:31:52 2015 daemon.crit dnsmasq[3705]: cannot create timestamp >> file /etc/dnssec_timestamp: Permission denied Thu Apr 2 18:31:52 >> 2015 daemon.crit dnsmasq[3705]: FAILED to start up Thu Apr 2 >> 18:31:57 2015 daemon.info dnsmasq[3706]: started, version 2.73 >> >> B2) creating it as root, but not chowning it to nobody, fails. >> >> In this second case, failure to update mtime is ok and dnsmasq >> startup >> >> Thu Apr 2 18:32:07 2015 daemon.err dnsmasq[3751]: failed to update >> mtime on /etc/dnssec_timestamp: Permission denied Thu Apr 2 >> 18:32:07 2015 daemon.info dnsmasq[3751]: DNSSEC validation enabled >> >> C) making it writable by nobody of course makes it vulnerable to >> other users running as nobody > > Which is why a "dnsmasq" user is a good idea. I buy that. John? >> >> root@OpenWrt:/etc/config# ls -l /etc/dnssec_timestamp -rw-r--r-- 1 >> nobody root 0 Apr 2 18:32 /etc/dnssec_timestamp >> >> >> > > By the time the mtime update happens, dnsmasq has dropped root, so > having the timestamp file writable only by root won't work. The first > iteration of this code had the timestamp created whilst dnsmasq still > has root, and chowned to the dnsmasq no-priv user (eg nobody). I > couldn't convince myself that that couldn't be leveraged somehow, so > changed to this method. The idea is there should be some directory > writable by nobody for this file to live in. Well, if it is perpetually created in /tmp on boot, how does it detect the time slew? It seemed to me that writing it to flash closed a vulnerability during a quick reboot cycle. > > > > Cheers, > > Simon. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iEYEARECAAYFAlUdpHcACgkQKPyGmiibgrcEKwCfX1A5AFEru0uMwZRiE84mT/1A > F8cAnR7gnt7tBfuqECc7InKfCsBpCNUF > =i7iB > -END PGP SIGNATURE- -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] High Availability: Part Deux
Well the most elegant and simple solution we came up with was: https://tools.ietf.org/html/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00 But the world did not go that way, preferring nothing that worked at all. On Fri, Apr 3, 2015 at 12:20 PM, Jonathan Fisher wrote: > Absolutely :) That setup works quite nicely right now actually! The problem > then is DNS... with ipv6 coming down the pipe, it's time to stop addressing > everyone with IPs and start using memorizable DNS names. Any ideas on that? > > Email Confidentiality Notice: The information contained in this transmission > is confidential, proprietary or privileged and may be subject to protection > under the law, including the Health Insurance Portability and Accountability > Act (HIPAA). The message is intended for the sole use of the individual or > entity to whom it is addressed. If you are not the intended recipient, you > are notified that any use, distribution or copying of the message is > strictly prohibited and may subject you to criminal or civil penalties. If > you received this transmission in error, please contact the sender > immediately by replying to this email and delete the material from any > computer. > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss > -- Dave Täht Let's make wifi fast, less jittery and reliable again! https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
nslookup www.ietf.org fails again... it did not fail a few days ago. chrome returns nxdomain -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
Suspecting edns0 (I am also using ipv6 only as my upstream forwarder), i dropped edns_packet_max dair-833:babeld d$ dig +dnssec www.ietf.org ;; Truncated, retrying in TCP mode. ; <<>> DiG 9.8.3-P1 <<>> +dnssec www.ietf.org ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4614 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags: do; udp: 1200 ;; QUESTION SECTION: ;www.ietf.org. IN A ;; ANSWER SECTION: www.ietf.org. 1292 IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net. www.ietf.org. 1292 IN RRSIG CNAME 5 3 1800 20160426153432 20150427143650 40452 ietf.org. P/M2NpsObZhTLqxxkQqDnKCkIqhgcBQcSRidfikEAFDrNUKJDeah8z4S 8/QRGqsn4OtmZHHhm0LwfxtUrqQkB/sbQzoUVgAdPQHQRxmUpZ58BQ4O P8jcThPIWnlauBBNusbTuq/iEo2L73P+eBBesGq+rCiUDmKHAfbo2aF4 fKh9q8NjmJbfAoD6ihjq5aNigzPErwv7mZ6jLg/eS1xh12pox5EYAUnO lPXIj5puSgizSkr7oOZv41kIiqxyvxGdu37ti7zc73p5NGI5qng+eSOE JcvK0VQc1Rn18nlwnq3yM+o6VldGDfMX6WY+zywKwyI3tFnpqAtKC+CJ /JxtIw== www.ietf.org.cdn.cloudflare-dnssec.net. 64 IN A 104.20.0.85 www.ietf.org.cdn.cloudflare-dnssec.net. 64 IN A 104.20.1.85 www.ietf.org.cdn.cloudflare-dnssec.net. 64 IN RRSIG A 13 6 300 20150507200525 20150505180525 35273 cloudflare-dnssec.net. jcky3oJ2x1ZUfEQJCSLEqjCWA9ifxAArUb2ZVsnHbhBngBq0IvER4KCU mrdAy7+5vHduGsaMg/y4mHLfJohcRA== ;; Query time: 222 msec ;; SERVER: 172.26.16.1#53(172.26.16.1) ;; WHEN: Wed May 6 12:08:13 2015 ;; MSG SIZE rcvd: 538 On Wed, May 6, 2015 at 11:22 AM, Dave Taht wrote: > nslookup www.ietf.org fails again... it did not fail a few days ago. > > chrome returns nxdomain > > > -- > Dave Täht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
I retried it with edns0 set to 1500 bytes, and it worked (falling back to tcp). 1800 bytes did not. an osx box was the client. I did capture the transaction(s) this time, the failing queries and a working one are at: http://snapon.lab.bufferbloat.net/~d/dnsmasq/ One of my concerns has always been what fq_codel's algorithm does to fragmented packets in general... but I have not looked at this captures... The testing I was doing earlier (where ietf.org worked) was with a linux box as the client a few days ago. I will resume testing that later today, and also continue slamming dnsmasq with queries over ipv6 from the alexa top 1m On Wed, May 6, 2015 at 12:30 PM, Kevin Darbyshire-Bryant wrote: > Continues to work here on my iPhone hiding behind openwrt cc trunk > dnsmasq2.73rc7 > > Were I not on the iPhone I could do some dig'age :-) > > -- > Cheers, > > ke...@darbyshire-bryant.me.uk > Sent from my phone, apologies for brevity, spelling & top posting > >> On 6 May 2015, at 20:21, Dave Taht wrote: >> >> nslookup www.ietf.org fails again... it did not fail a few days ago. >> >> chrome returns nxdomain >> >> >> -- >> Dave Täht >> Open Networking needs **Open Source Hardware** >> >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >> >> ___ >> Dnsmasq-discuss mailing list >> Dnsmasq-discuss@lists.thekelleys.org.uk >> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
prematurely sent that email. setting edns_packet_max to 1200 made it drop to tcp and work. I am going to argue that edns0 should be set to the bare minimum, by default, in dnsmasq, whatever it is, for it to fall back to tcp correctly. On Wed, May 6, 2015 at 12:09 PM, Dave Taht wrote: > Suspecting edns0 (I am also using ipv6 only as my upstream forwarder), > i dropped edns_packet_max > > > dair-833:babeld d$ dig +dnssec www.ietf.org > > ;; Truncated, retrying in TCP mode. > > > ; <<>> DiG 9.8.3-P1 <<>> +dnssec www.ietf.org > > ;; global options: +cmd > > ;; Got answer: > > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4614 > > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1 > > > ;; OPT PSEUDOSECTION: > > ; EDNS: version: 0, flags: do; udp: 1200 > > ;; QUESTION SECTION: > > ;www.ietf.org. IN A > > > ;; ANSWER SECTION: > > www.ietf.org. 1292 IN CNAME www.ietf.org.cdn.cloudflare-dnssec.net. > > www.ietf.org. 1292 IN RRSIG CNAME 5 3 1800 20160426153432 > 20150427143650 40452 ietf.org. > P/M2NpsObZhTLqxxkQqDnKCkIqhgcBQcSRidfikEAFDrNUKJDeah8z4S > 8/QRGqsn4OtmZHHhm0LwfxtUrqQkB/sbQzoUVgAdPQHQRxmUpZ58BQ4O > P8jcThPIWnlauBBNusbTuq/iEo2L73P+eBBesGq+rCiUDmKHAfbo2aF4 > fKh9q8NjmJbfAoD6ihjq5aNigzPErwv7mZ6jLg/eS1xh12pox5EYAUnO > lPXIj5puSgizSkr7oOZv41kIiqxyvxGdu37ti7zc73p5NGI5qng+eSOE > JcvK0VQc1Rn18nlwnq3yM+o6VldGDfMX6WY+zywKwyI3tFnpqAtKC+CJ /JxtIw== > > www.ietf.org.cdn.cloudflare-dnssec.net. 64 IN A 104.20.0.85 > > www.ietf.org.cdn.cloudflare-dnssec.net. 64 IN A 104.20.1.85 > > www.ietf.org.cdn.cloudflare-dnssec.net. 64 IN RRSIG A 13 6 300 > 20150507200525 20150505180525 35273 cloudflare-dnssec.net. > jcky3oJ2x1ZUfEQJCSLEqjCWA9ifxAArUb2ZVsnHbhBngBq0IvER4KCU > mrdAy7+5vHduGsaMg/y4mHLfJohcRA== > > > ;; Query time: 222 msec > > ;; SERVER: 172.26.16.1#53(172.26.16.1) > > ;; WHEN: Wed May 6 12:08:13 2015 > > ;; MSG SIZE rcvd: 538 > > > On Wed, May 6, 2015 at 11:22 AM, Dave Taht wrote: >> nslookup www.ietf.org fails again... it did not fail a few days ago. >> >> chrome returns nxdomain >> >> >> -- >> Dave Täht >> Open Networking needs **Open Source Hardware** >> >> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 > > > > -- > Dave Täht > Open Networking needs **Open Source Hardware** > > https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
Yes, I was using comcast native ipv6. On Wed, May 6, 2015 at 1:49 PM, Simon Kelley wrote: > This stuff does worry me. It's a big source of brittleness. > > One thing that's worth pointing out is that it's not necessarily the > answer to the original query that's too big, it might be the answer to > one of the DS or DNSKEY queries needed to validate it. If the answer to > one of those comes back with the TrunCated bit set, then dnsmasq > abandons the whole thing and returns a TC answer to the original > question so that the requestor tries again in TCP mode. Now the DS or > DNSKEY query gets done in TCP mode too, and the answer isn't truncated. > Dnsmasq doesn't mix TCP and UDP queries in one validation, and always > does the upstream queries in the same mode as the query it's answering. > > That explains why it's falling back to TCP even though the final > (signed) answer is 538 bytes. > > Doing a quick binary chop. I see fallback to TCP if edns-packet-max is > less then 1625, which is bigger than a ethernet packet. Looking at the > packet capture, I see that it's actually the answer to > > DNSKEY org > > which is 1625 bytes and fragmented (and reassembled) across my wireless > LAN. Actually, it's probably fragmented somewhere on the other end of > the 3G connection or before. It gets reassembled at this end. > > There are four DNSKEYS and the corresponding RRSIGS in that answer. I > wonder if that's intended? > > All the above is on IPv4. Dave are you using IPv6? I'll try that next. > > Cheers, > > Simon. > > > > > On 06/05/15 20:42, Dave Taht wrote: >> I retried it with edns0 set to 1500 bytes, and it worked (falling back >> to tcp). 1800 bytes did not. >> >> an osx box was the client. >> >> I did capture the transaction(s) this time, the failing queries and a >> working one are at: http://snapon.lab.bufferbloat.net/~d/dnsmasq/ >> >> One of my concerns has always been what fq_codel's algorithm does to >> fragmented packets in general... but I have not looked at this >> captures... >> >> The testing I was doing earlier (where ietf.org worked) was with a >> linux box as the client a few days ago. I will resume testing that >> later today, and also continue slamming dnsmasq with queries over ipv6 >> from the alexa top 1m >> >> >> >> On Wed, May 6, 2015 at 12:30 PM, Kevin Darbyshire-Bryant >> wrote: >>> Continues to work here on my iPhone hiding behind openwrt cc trunk >>> dnsmasq2.73rc7 >>> >>> Were I not on the iPhone I could do some dig'age :-) >>> >>> -- >>> Cheers, >>> >>> ke...@darbyshire-bryant.me.uk >>> Sent from my phone, apologies for brevity, spelling & top posting >>> >>>> On 6 May 2015, at 20:21, Dave Taht wrote: >>>> >>>> nslookup www.ietf.org fails again... it did not fail a few days ago. >>>> >>>> chrome returns nxdomain >>>> >>>> >>>> -- >>>> Dave Täht >>>> Open Networking needs **Open Source Hardware** >>>> >>>> https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 >>>> >>>> ___ >>>> 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 -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] seeing www.ietf.org fail dnssec with dnsmasq rc7
on a comcast native ipv6 connection, 1232 from OSX (ping6 -s 1232 2001:4860:4860::) On the router *itself* I can't even ping6 -s 80 2001:4860:4860:: PING 2001:4860:4860:: (2001:4860:4860::): 80 data bytes ^C --- 2001:4860:4860:: ping statistics --- 1 packets transmitted, 0 packets received, 100% packet loss So i kind of suspected the -s calculation includes headers on one OS or the other, or, I thought briefly, have a firewall rule in the way, but weirdly I can ping6 -s 4000 to snapon.lab.bufferbloat.net from the router also. This makes no sense whatsoever. sigh. We have a tool (isoburst) we keep meaning to polish up that tests udp extensively, I guess we're going to have to add fragmentation checks to it. On Thu, May 7, 2015 at 6:32 AM, Toke Høiland-Jørgensen wrote: > Simon Kelley writes: > >> Using ping6 2001:4860:4860:: -s >> >> (that's the Google public DNS server) >> >> I see answers up to packet size 1344. > > I get answers up to -s 1432. This is on an he.net tunnel. > > -Toke > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Mirror the git repository to github.com
I like the idea of github as a bug tracker also. On Mon, May 11, 2015 at 9:51 AM, Thiago Farina wrote: > On Sat, May 9, 2015 at 5:38 PM, Karl-Philipp Richter > wrote: >> Hi, >> Mirroring the git repository git://thekelleys.org.uk/dnsmasq.git to >> github.com would facilitate contributions by providing the pull request >> feature. >> > Is Simon fine with pull requests? > > -- > Thiago Farina > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Open Networking needs **Open Source Hardware** https://plus.google.com/u/0/+EricRaymond/posts/JqxCe2pFr67 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Fwd: Important Info for signers of the FCC Letter from Dave Täht and CeroWrt
If anyone here is as tired as I am of vendors shipping obsolete versions of dnsmasq in "new" routers, please consider signing the upcoming letter to the FCC. Details and links below. -- Forwarded message -- From: Rich Brown Date: Wed, Oct 7, 2015 at 7:16 PM Subject: Important Info for signers of the FCC Letter from Dave Täht and CeroWrt To: Dave Taht Thank you for endorsing our comments to the FCC about locking down Wi-Fi routers and other devices. Your signature is one of over 140 names at this time. I am working with Dave Täht to complete the submission. We have prepared a near-final draft of the letter which we will submit on Friday, 9 October. We welcome you to review the current version at: https://docs.google.com/document/d/1E1D1vWP9uA97Yj5UuBPZXuQEPHARp-AhRqUOeQB2WPk/edit# Important points: 1) If you still agree with the letter, you do not do need to do anything. We received all the information we need from the form at http://goo.gl/forms/WCF7kPcFl9 IF you have not signed yet, please do so soon. 2) THE FCC REQUIRES WE INCLUDE YOUR NAME AND POSTAL ADDRESS. That information *will* be published on the open web. If you do not wish to be included, please let me know. 3) IF YOU DO NOT AGREE (or no longer agree) with the letter, please respond to this note and let me know. In either case, I will ensure that your name is not included in our response. 4) The window for updating/adding/removing your name will close tomorrow, Thursday 8 October at 11:59pm ET. 5) If you included a "Personal Comment" on the web form, or have further thoughts, please consider filing a separate note with the FCC containing that comment. It will have greater impact. It's easy to do this at http://apps.fcc.gov/ecfs/hotdocket/list - find the "15-170" item (first in the list, with more than 340 other filers) If you didn't keep a copy of your comment, send me a note and I will look it up. Thanks again! Rich Brown -- Dave Täht Do you want faster, better, wifi? https://www.patreon.com/dtaht ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Last call for signatures to the FCC on the wifi lockdown issue
The CeroWrt project's letter to the FCC on how to better manage the software on wifi and home routers vs some proposed regulations is now in last call for signatures. The final draft of our FCC submittal is here: https://docs.google.com/document/d/15QhugvMlIOjH7iCxFdqJFhhwT6_nmYT2j8xAscCImX0/edit?usp=sharing The principal signers (Dave Taht and Vint Cerf), are joined by many network researchers, open source developers, and dozens of developers of aftermarket firmware projects like OpenWrt. Prominent signers currently include: Jonathan Corbet, David P. Reed, Dan Geer, Jim Gettys, Phil Karn, Felix nFietkau, Corinna "Elektra" Aichele, Randell Jesup, Eric S. Raymond, Simon Kelly, Andreas Petlund, Sascha Meinrath, Joe Touch, Dave Farber, Nick Feamster, Paul Vixie, Bob Frankston, Eric Schultz, Brahm Cohen, Jeff Osborn, Harald Alvestrand, and James Woodyatt. If you would like to join our call for substituting sane software engineering practices over misguided regulations, the window for adding your signature to the letter closes at 11:59AM ET, today, Friday, 2015-10-08. Sign via webform here: http://goo.gl/forms/WCF7kPcFl9 We are at approximately 170 signatures as I write. For more details on the controversy we are attempting to address, or to submit your own filing to the FCC see: https://libreplanet.org/wiki/Save_WiFi https://www.dearfcc.org/ Sincerely, Dave Täht CeroWrt Project Architect Tel: +46547001161 ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Fwd: strategies to mitigate DNS amplification attacks in ISP network
DNS cookies look kind of interesting... -- Forwarded message -- From: Mark Andrews Date: Wed, Dec 2, 2015 at 1:39 AM Subject: Re: strategies to mitigate DNS amplification attacks in ISP network To: Michael Hare Cc: "na...@nanog.org" Deploy DNS COOKIES. This allows legitimate UDP traffic to be identified and treated differently to spoofed traffic by providing the equivalent to a TCP handshake but over UDP. This is currently in IETF last call but the code points are assigned and implementations are available. Ask your nameserver vendor for this today. Ask your OS vendor for support. https://tools.ietf.org/html/draft-ietf-dnsop-cookies-07 Mark In message , Michael Hare writes: > Martin- > > I represent a statewide educational network running Juniper gear that is a qu > asi-enterprise. I think efforts depend on size and type of network. We are > testing an approach that involves; > > 1) whitelisting known local resolvers, well behaved cloud DNS resolvers. > 2) on ingress, policing non-conforming traffic that matches UDP src port 53 d > st port unreserved bytes > 1400 > 3) on ingress, queuing fragments to high packet loss priority [you better und > erstand how fragments are used in your network before doing this] > 4) If you have Juniper gear look into prefix-action > 5) RTBH if required > > This obviously doesn't work on the core of the internet. > > Other good tips: > * strengthen [anycast] your local DNS resolvers and consider a scheme that al > lows you to change their outgoing address on the fly. > * push [some] of your external authoritative DNS to the cloud. > > -Michael > > > > -Original Message- > > > From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Martin T > > > Sent: Tuesday, December 01, 2015 11:00 AM > > > To: na...@nanog.org > > > Subject: strategies to mitigate DNS amplification attacks in ISP network > > > > > > Hi, > > > > > > as around 40% of ASNs allow at least partial IPv4 address spoofing in > > > their network(http://spoofer.csail.mit.edu/summary.php) and there are > > > around 30 million open-resolvers(http://openresolverproject.org/) in > > > the Internet, then DNS amplification traffic is daily occasion for > > > ISPs. This in probably mainly because RPF checks and DNS > > > RRL(https://kb.isc.org/article/AA-01000/0/A-Quick-Introduction-to-Respons > e- > > > Rate-Limiting.html) > > > are not ubiquitously implemented, recursive requests without any ACLs > > > in DNS servers are often allowed, it requires little effort from > > > attackers point of view and is effective attack method. Unfortunately, > > > there seems to be very limited number of countermeasures for ISPs. Few > > > which I can think of: > > > > > > 1) higher capacity backbone links - I'm not sure if this can be > > > considered a mitigation method, but at least it can help to affect > > > smaller amount of customers if traffic volumes are not very high > > > > > > > > > 2) rate-limit incoming DNS traffic flows on peering and uplink ports - > > > here I mean something similar to iptables "recent" > > > module(http://www.netfilter.org/documentation/HOWTO/netfilter- > > extensions- > > > HOWTO-3.html#ss3.16) > > > which allows certain number of certain type of packets in a configured > > > time-slot per IP. However, such functionality is probably not common > > > on edge or backbone routers. > > > > > > > > > Tracking the packet state does definitely not work because state table > > > should be synchronized between all the routers in the network and > > > again, this requires Internet-routers to have stateful firewall > > > functionality. In addition, one also needs to allow new DNS > > > connections from Internet to its network. > > > If one simply polices incoming DNS traffic on uplink and peering > > > ports(for example if baseline DNS traffic is 5Mbps, then policer is > > > set to 50Mbps), then legitimate customers DNS traffic is also affected > > > in case of actual attack occurs and policer starts to drop DNS > > > traffic, i.e. policer has no way to distinguish between the legitimate > > > and non-legitimate incoming DNS traffic. > > > > > > > > > Am I wrong in some points? What are the common practices to mitigate > > > DNS amplification attacks in ISP network? > > > > > > > > > thanks, > > > Martin -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] Got bad packet: bad compression pointer
I am testing the dnsmasq-full build on current lede-project head, and enabled dnssec. Then : root@dancer:/# host flent-fremont.bufferbloat.net flent-fremont.bufferbloat.net has address 23.239.20.41 flent-fremont.bufferbloat.net has IPv6 address 2600:3c01::f03c:91ff:fe50:48d4 ;; Got bad packet: bad compression pointer 111 bytes 40 41 81 80 00 01 00 00 00 01 00 00 0d 66 6c 65 @A...fle 6e 74 2d 66 72 65 6d 6f 6e 74 0b 62 75 66 66 65 nt-fremont.buffe 72 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 c0 rbloat.net.. 1a 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e 6f ..4.arno 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 65 ld.ns.cloudflare 03 63 6f 6d 00 03 64 6e 73 c0 f0 78 9d d7 47 00 .com..dns..x..G. 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 .'`..:. Filed the bug here: https://bugs.lede-project.org/index.php?do=details&task_id=392 I see a few other references to this phrase elsewhere on the net but did not find a resolution. In this case I've seen this with osx sierra, and "dancer" is a pretty recent ubuntu box. The dnssec tests on the web seem to all pass, it just shows up with host - and not consistently. I just had it happen one time in 4, on a recent test. -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
On Mon, Jan 16, 2017 at 1:11 PM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Host makes A, and MX queries and it's the reply to the MX that's > failing. This all works fine here (dnsmasq and host both running on > the same x86_64 host. The reply to the MX query looks like this. > > > ; (1 server found) > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19992 > ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 512 > ;; QUESTION SECTION: > ;flent-fremont.bufferbloat.net. IN MX > > ;; AUTHORITY SECTION: > bufferbloat.net.1798IN SOA arnold.ns.cloudflare.com. > dns.cloudflare.com. 2023610183 1 2400 604800 3600 > > ;; Query time: 50 msec > ;; SERVER: 127.0.0.1#53(127.0.0.1) > ;; WHEN: Mon Jan 16 20:27:43 GMT 2017 > ;; MSG SIZE rcvd: 122 > > > Comparing the packet dump you have with the correct answer I'm seeing, > there are a few not-important differences (transaction-id, > time-to-live and SOA serial), the only other difference is the second > domain name in the SOA record, dns.cloudflare.com. That's represented > as the label "dns" and then a compression pointer pointing back to > previous instance of "cloudflare.com" in arnold.ns.cloudflare.com. The > correct pointer is c0 45, the pointer in your dump is c0 f0. (the c0 > is flags, the 45 (or f0) is an offset from the start of the packet). > > This packet has been through some hairy code in dnsmasq which elides > DNSSEC records (RRSIGs etc) and has to fix up the pointers thus > affected. My guess is that that's the problem, somehow, but I'm at a > loss to say why it works for me and breaks for you. It's a mips box supplying dns here. Different rules for alignment? > > Note that if my hypothesis is correct, you'll only see the effect when > the answer comes from upstream, and not when the answer comes from the > dnsmasq cache. > > If you want to try and debug this, first check that you can see the > same error just doing the MX query with a cold cache, then look at > what's happening in rrfilter() in src/rrfilter.c > > The other thing that would be useful is to capture the answer from > usptream complete with the NSEC and RRSIG records that need to be > removed. When I do that, the NSEC and RRSIG records come _after_ the > SOA record, so that the compression pointer in the SOA record doesn't > need to be touched at all, if the order of the records varied, that > could expose bugs in this code. > > Not an answer, but some good clues.. Don't even know if it's over ipv4 or ipv6 at the moment. will check harder. Great clues, thx, I'll get on it after I resolv https://bugs.lede-project.org/index.php?do=details&task_id=388 > > Cheers, > > Simon. > > > > > > > On 16/01/17 18:56, Dave Taht wrote: >> I am testing the dnsmasq-full build on current lede-project head, >> and enabled dnssec. Then : >> >> root@dancer:/# host flent-fremont.bufferbloat.net >> flent-fremont.bufferbloat.net has address 23.239.20.41 >> flent-fremont.bufferbloat.net has IPv6 address >> 2600:3c01::f03c:91ff:fe50:48d4 ;; Got bad packet: bad compression >> pointer 111 bytes 40 41 81 80 00 01 00 00 00 01 00 00 0d 66 6c 65 >> @A...fle 6e 74 2d 66 72 65 6d 6f 6e 74 0b 62 75 66 66 65 >> nt-fremont.buffe 72 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 c0 >> rbloat.net.. 1a 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e 6f >> ..4.arno 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 65 >> ld.ns.cloudflare 03 63 6f 6d 00 03 64 6e 73 c0 f0 78 9d d7 47 00 >> .com..dns..x..G. 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 >> .'`..:. >> >> >> Filed the bug here: >> https://bugs.lede-project.org/index.php?do=details&task_id=392 >> >> I see a few other references to this phrase elsewhere on the net >> but did not find a resolution. >> >> In this case I've seen this with osx sierra, and "dancer" is a >> pretty recent ubuntu box. The dnssec tests on the web seem to all >> pass, it just shows up with host - and not consistently. I just had >> it happen one time in 4, on a recent test. >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJYfTb0AAoJEBXN2mrhkTWiffYP/Ariw/tDKjfy8pd6/Z2Nixc/ > MW5zcQAh421uxrSIA4NNhJeymiXdiwQNC8CAbvtSPNvwE87Ed8GlnfExnYSzWpig > UvjJS1fXRF+y57e8UcqQmZEXTNtE/wdc5Rs0nqv+TpLaBMXF4nVjABmSsNOzymrw > VQdMOHIrq
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
so far I can only make it happen on mips. Doesn't happen on arm. Haven't tried harder yet. ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > I won't have access to a MIPS system 'till the weekend. > > I assume you're using the git head code? No. Lede-project head. package claims to be dnsmasq-2.76-6. libc is musl. Box under test was an archer c7v2. Can go try a few other mips boxes like the wndr3800, but I've seen it there too. The arm box (that is working) is an linksys-1200ac. (overall it's looking like a fine release of lede) > Did you manage to see a dump of the upstream reply? Not yet. I'll touch bases with you later in the week. > > > Simon. > > > > On 18/01/17 07:31, Dave Taht wrote: >> so far I can only make it happen on mips. Doesn't happen on arm. >> Haven't tried harder yet. >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJYf8aDAAoJEBXN2mrhkTWiN9UP/2E9D6j/nd3RsubzHgZSvzB/ > CJPNyk32jnAqZdIa9D3DOH2L9gN5GyBiAtv4iCz5KuzDnB9twBtQWOdzde5sZWWd > 4t8tSsvJkr0pRZhhRQKelF2oW0k7Y0UM4mD90ZoabX9ytQG4ceTFkHKlwwPLvvTc > Osh9RmCpX1tsJoE/y+lMpEdT+GlhOe4z2Z9FZlTN7ke/uO9nIarekSIvnxgOnyac > vrHvgnjyyEHbfr0BNaupdwZz9d/dVABYkFTDUk4dg4tn6MW99AsbD2DaL9alx8U/ > MsvbFarQe/w8fJkmBJOThWkLMvpO1854XAysc8/m5ldIEwcV4Yge29nYrmDhn9kH > Evo7wbKSH4AYGskYTiWnssczu1RhQOX9jCD31gv5CVOeTY4Dt7NR3WFCsAH2RYpR > jcstckC5R1fqfKtQt9B0l2SWmmLukRcMbGM1hiJbqGrZcb++gZ2RYl80AD0iQhkD > GjLNQAUKwlDwzB7JYXX+Fn0AVvP/G4qrmYBFlcxloddtrCiNqu4icTYIAb1zv0Lo > opM+0fFcfg1PPPobTQ7FLJQR/uAO93MWZJ43Ht90YEdk6aaBCf7Ego1fU0G6TjCV > iphmOqvhs96GFfhaBMYwFxvHb1tHNDT+Xzlsvkvk+S8SKyhNOg5GJOL2Dz78vlB/ > fcImILW4vRf4rIkMDZKL > =kPYg > -END PGP SIGNATURE- -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Got bad packet: bad compression pointer
The offputting part of your outline of what to check for was "some hairy pointer code". :) I'm in the middle of some crash bugs elsewhere, and I didn't realize how fast I could get you data without thinking about the "hairy" parts. dnssec and dnssec-check-unsigned are enabled, and I'm using cachesize (what's the limit nowadays?) I put packet captures of the external interface on the router (comcast upstream) and captures taken at the client, a log, and conf file, here: http://www.taht.net/~d/dnssecbug/ Basically hammering on nslookup for the two internal and internal captures there. Hammering on "dig" later, I was unable to trigger it on A, or requests. Was able to easily trigger it on a MX request. flent-freemont does not exist, btw. Flent-fremont, does. It will go boom on both. root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ;; Got bad packet: bad compression pointer 123 bytes a5 c9 81 a0 00 01 00 00 00 01 00 01 0e 66 6c 65 .fle 6e 74 2d 66 72 65 65 6d 6f 6e 74 0b 62 75 66 66 nt-freemont.buff 65 72 62 6c 6f 61 74 03 6e 65 74 00 00 0f 00 01 erbloat.net. c0 1b 00 06 00 01 00 00 0e 10 00 34 06 61 72 6e ...4.arn 6f 6c 64 02 6e 73 0a 63 6c 6f 75 64 66 6c 61 72 old.ns.cloudflar 65 03 63 6f 6d 00 03 64 6e 73 c0 eb 78 9d d7 47 e.com..dns..x..G 00 00 27 10 00 00 09 60 00 09 3a 80 00 00 0e 10 ..'`..:. 00 00 29 02 00 00 00 00 00 00 00 ..) root@dancer:~/dnssecbug# dig flent-freemont.bufferbloat.net MX ; <<>> DiG 9.10.3-P4-Ubuntu <<>> flent-freemont.bufferbloat.net MX ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 34631 ;; flags: qr rd ra ad; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 512 ;; QUESTION SECTION: ;flent-freemont.bufferbloat.net.INMX ;; AUTHORITY SECTION: bufferbloat.net.3600INSOAarnold.ns.cloudflare.com. dns.cloudflare.com. 2023610183 1 2400 604800 3600 ;; Query time: 72 msec ;; SERVER: 172.26.16.1#53(172.26.16.1) ;; WHEN: Wed Jan 18 12:42:02 PST 2017 ;; MSG SIZE rcvd: 123 On Wed, Jan 18, 2017 at 12:01 PM, Dave Taht wrote: > On Wed, Jan 18, 2017 at 11:48 AM, Simon Kelley > wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> I won't have access to a MIPS system 'till the weekend. >> >> I assume you're using the git head code? > > No. Lede-project head. package claims to be dnsmasq-2.76-6. libc is musl. > > Box under test was an archer c7v2. Can go try a few other mips boxes > like the wndr3800, but I've seen it there too. The arm box (that is > working) is an linksys-1200ac. (overall it's looking like a fine > release of lede) > >> Did you manage to see a dump of the upstream reply? > > Not yet. I'll touch bases with you later in the week. > >> >> >> Simon. >> >> >> >> On 18/01/17 07:31, Dave Taht wrote: >>> so far I can only make it happen on mips. Doesn't happen on arm. >>> Haven't tried harder yet. >>> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v2.0.22 (GNU/Linux) >> >> iQIcBAEBCAAGBQJYf8aDAAoJEBXN2mrhkTWiN9UP/2E9D6j/nd3RsubzHgZSvzB/ >> CJPNyk32jnAqZdIa9D3DOH2L9gN5GyBiAtv4iCz5KuzDnB9twBtQWOdzde5sZWWd >> 4t8tSsvJkr0pRZhhRQKelF2oW0k7Y0UM4mD90ZoabX9ytQG4ceTFkHKlwwPLvvTc >> Osh9RmCpX1tsJoE/y+lMpEdT+GlhOe4z2Z9FZlTN7ke/uO9nIarekSIvnxgOnyac >> vrHvgnjyyEHbfr0BNaupdwZz9d/dVABYkFTDUk4dg4tn6MW99AsbD2DaL9alx8U/ >> MsvbFarQe/w8fJkmBJOThWkLMvpO1854XAysc8/m5ldIEwcV4Yge29nYrmDhn9kH >> Evo7wbKSH4AYGskYTiWnssczu1RhQOX9jCD31gv5CVOeTY4Dt7NR3WFCsAH2RYpR >> jcstckC5R1fqfKtQt9B0l2SWmmLukRcMbGM1hiJbqGrZcb++gZ2RYl80AD0iQhkD >> GjLNQAUKwlDwzB7JYXX+Fn0AVvP/G4qrmYBFlcxloddtrCiNqu4icTYIAb1zv0Lo >> opM+0fFcfg1PPPobTQ7FLJQR/uAO93MWZJ43Ht90YEdk6aaBCf7Ego1fU0G6TjCV >> iphmOqvhs96GFfhaBMYwFxvHb1tHNDT+Xzlsvkvk+S8SKyhNOg5GJOL2Dz78vlB/ >> fcImILW4vRf4rIkMDZKL >> =kPYg >> -END PGP SIGNATURE- > > > > -- > Dave Täht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] will there be a 2.77 release anytime soon?
just checkin -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] Bug forward upstream SERVFAIL
From a brief conversation with the bind9 maintainer: D: if bind gets a servfail, and has two forwarders, will it try the other forwarder? E: Yes. D: Even in the case of a dnssec query? E: Bind9 retries an authoritative answer because it might have been spoofed or one of the servers might be out of date or misconfigured. It uses the function fctx_nextaddress() to get the next address to try when a query fails. fctx_nextaddress() searches through both forwarders and auth servers, depending on what kind of query it is. D: So I believe it is correct for dnsmasq to try all upstreams on a servfail response, which restores the prior dnsmasq behavior, and is more robust. E: Yes. D: This seems to look like the right thing: https://github.com/MartinWetterwald/dnsmasq/pull/1/files -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
[Dnsmasq-discuss] IDN (internationalized domain name) support
I am curious as to the deployment status of IDN in the field? and to how often others are building it into their default distro of dnsmasq, and any issues that may exist (other than improving the ease of domain name phishing) -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] IDN (internationalized domain name) support
On Tue, Jan 31, 2017 at 8:57 AM, Simon Kelley wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > It's included in the Debian, (and therefore Ubuntu) packaging. > > Of course the only difference it makes is to the interpretation of > domain names in /etc/hosts and friends and config files. - IDNs get > cached and forwarded by dnsmasq fine without the support being included. Good to know. Perhaps now I can have my umlaut in my last name back on some domain name somewhere. > OK, it also affects logging, I think. göögle.com appears in the logs > göögle.com and not as xn--ggle-5qaa.com That jumps to a very interesting site, btw... And I guess a couple loggers and logger utilities need to be checked if they are 8 bit clean. > > Cheers, > > Simon. > > > > On 28/01/17 21:09, Dave Taht wrote: >> I am curious as to the deployment status of IDN in the field? >> >> and to how often others are building it into their default distro >> of dnsmasq, and any issues that may exist (other than improving the >> ease of domain name phishing) >> > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.22 (GNU/Linux) > > iQIcBAEBCAAGBQJYkMHnAAoJEBXN2mrhkTWi2vUP/iX/Z/tnB/Skw6yGWxlIu28W > bcajXnUjCfph8xixJXGKDJNWzLSxPgPpEGhJfzZQvtDOrC7rr4MAKxBSuhpfciVV > PWQm9t6JAwwIfaW9u4gLw9dTifiHJovbgNsR1KMwcqNARy3S6WSTjERpmm9h2Tp2 > pI4n1Bg+IAEG/f5b9QxjPTFlbGrZbiVpsp+hVUftUGykQjugtP6lo4UpeLXjPrjJ > a2ZVi4Qpz/G9ujRkStq9PcLy4NOjc8ZHc85QBmUowCiGv5FJYJFUKRnEU2ChmFnY > tztFXgDjXHMaGV/Am44w+HpCTWHDyENEd2iKFhm+hSfnD89P5N02mRUxstQJdKrE > yEBv22/U2mAW6o4XJWWVIB31h4gMNAFQPiAlSlLVquFx40kcWRswoqZKrCCIvYsy > tJm8FjawA/Yt9kIdM71ymJ6NkwYPr0rfgZE95p/5L5q+nidOVVbDN/eGNyY4yylM > tcsKo22D+GyRFLmc/NqnuCbq9PaXbHY88s5lJQf1mSKdYKckMYmPgVXnq45M2AaO > auUpTEdhsXsfzOULzOQmXwv2dSfo2IHfRZRFJeSpMf7JwAMjgxiK3tEidPL75LUt > vM6xkVNBCD8LlFj5BK94EhSw+3QDCZmQUBU4FImF8aOCxsdq+Vk+/D4nGJW1SgGC > 9aMz4z1pFq3IM44GP+fN > =X8Ni > -END PGP SIGNATURE- > > ___ > Dnsmasq-discuss mailing list > Dnsmasq-discuss@lists.thekelleys.org.uk > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Dnsmasq-discuss mailing list Dnsmasq-discuss@lists.thekelleys.org.uk http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
Re: [Dnsmasq-discuss] [PATCH] Accept /32 and /0 as valid CIDR prefixes for rev-server directive
On Tue, Feb 14, 2017 at 7:17 AM, Simon Kelley wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> That's an improvement, but I tend to agree that /0 doesn't make much
> sense. If we're going to patch this, it seems to make more sense to
> reject anything other that /32 /24 /16 or /8.
>
> The ideal solution would be to accept any prefix length and generate
> the (up to) 256 --server equivalents that it corresponds to. If
> you're going to have syntactic sugar, it may as well work for you.
+1 on accepting any size netmask universally. I am perpetually getting
/48s... or /56s... or /60s or /61s, /62s or /63 and prefix splitting
in shell to generate the appropriate things for rev-server, etc, is a
PITA. I'm sitting here trying to remember which one of these two broke
with different sized netmasks
synth-domain=ula.taht.net,fd32:7d58:8d63::/64,ula-
rev-server=fd32:7d58:8d63::/48,fd32:7d58:8d63::1
And I did look at the code for both and was too dumb to figure out how
to apply the technique universally.
>
> Cheers,
>
> Simon.
>
>
>
> On 13/02/17 23:31, olivier.ga...@sigexec.com wrote:
>> From: Olivier Gayot
>>
>> [ excerpt from the man page ] The rev-server directive provides a
>> syntactic sugar to make specifying address-to-name queries easier.
>> For example --rev-server=1.2.3.0/24,192.168.0.1 is exactly
>> equivalent to --server=/3.2.1.in-addr.arpa/192.168.0.1
>>
>> It is not mentioned in the man page but specifying anything but /8
>> or /24 as the CIDR prefix has the same effect as specifying /16.
>>
>> It is not a big deal for subnets on non-octet boundaries since
>> they cannot be represented using a single in-addr.arpa address.
>> However, it is unconvenient for /32 and /0 prefixes while their
>> analogous server directives behave as expected. E.g. the following
>> server directives work as expected:
>>
>> server=/42.10.168.192.in-addr.arpa/1.2.3.4
>> server=/in-addr.arpa/1.2.3.4
>>
>> but the following do not:
>>
>> rev-server=192.168.10.42/32,1.2.3.4
>> rev-server=192.168.10.42/0,1.2.3.4
>>
>> and, in practice, they behave the same as:
>>
>> server=/168.192.in-addr.arpa/1.2.3.4
>> server=/168.192.in-addr.arpa/1.2.3.4
>>
>> This strange behaviour is fixed by accepting /32 and /0 CIDR
>> prefixes as valid values. Any other value will still be considered
>> the same as /16.
>>
>> Signed-off-by: Olivier Gayot ---
>> src/option.c | 31 +-- 1 file changed,
>> 21 insertions(+), 10 deletions(-)
>>
>> diff --git a/src/option.c b/src/option.c index 4a5ef5f..eeca3d6
>> 100644 --- a/src/option.c +++ b/src/option.c @@ -850,19 +850,30 @@
>> char *parse_server(char *arg, union mysockaddr *addr, union
>> mysockaddr *source_a static struct server *add_rev4(struct in_addr
>> addr, int msize) { struct server *serv = opt_malloc(sizeof(struct
>> server)); - in_addr_t a = ntohl(addr.s_addr) >> 8; + in_addr_t
>> a = ntohl(addr.s_addr); char *p;
>>
>> memset(serv, 0, sizeof(struct server)); - p = serv->domain =
>> opt_malloc(25); /* strlen("xxx.yyy.zzz.in-addr.arpa")+1 */ - - if
>> (msize == 24) -p += sprintf(p, "%d.", a & 0xff); - a = a >>
>> 8; - if (msize != 8) -p += sprintf(p, "%d.", a & 0xff); - a =
>> a >> 8; - p += sprintf(p, "%d.in-addr.arpa", a & 0xff); + p =
>> serv->domain = opt_malloc(29); /*
>> strlen("xxx.yyy.zzz.ttt.in-addr.arpa")+1 */ + + switch (msize) +
>> { +case 32: + p += sprintf(p, "%d.", a & 0xff); + /*
>> fall through */ +case 24: + p += sprintf(p, "%d.", (a >>
>> 8) & 0xff); + /* fall through */ +default: +case 16: +
>> p += sprintf(p, "%d.", (a >> 16) & 0xff); + /* fall through
>> */ +case 8: + p += sprintf(p, "%d.in-addr.arpa", (a >> 24)
>> & 0xff); + break; +case 0: + p += sprintf(p,
>> "in-addr.arpa"); +}
>>
>> serv->flags = SERV_HAS_DOMAIN; serv->next = daemon->servers;
>>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v2.0.22 (GNU/Linux)
>
> iQIcBAEBCAAGBQJYox+hAAoJEBXN2mrhkTWiBSUQAJQxq6yD3Tcw/39On0QcLcfy
> aZTerALrzgrwlpyH4yVWeztrA3pFK1uVLIhnQP161zR+NJRI5Bo0J7tAOElETm3k
> QQ0HEu16skPHdmzlmbR1MMLoVKn4myh6hDm5iFSAf+jsCpItAzYo5Cy9/oAz3PNU
> Hp1SKxYNwrcSTw5FQrLpNuhZxbqvkA5KiU3URcnzv3mW2YbMzcjrULL7hF7xfN0t
> 2iwI8shObm/3FMDux7jX1wuRPQALWokaXFhAyOTDUVBONavA4W/PxS+8VvV4noi4
> dFh6FMhJYPggUh7v02PTOoPtSuvaLNGt1vgWeHt1sqTXEo6rVsft085fKwH1uONw
> SGWrGhnFaVDewHeEoB46K6qg7LYSoLa1cgv8li8QJ9ZTSiFC7ZqIWsXBQ5oqlGzr
> 0iR6jo1yqISvwyek8nogsgNWI4zx/mmC1AXhR/OjE8Y/3MA87rhpY+t/U2ZJug5e
> f611DvKCl4iQuL/EyWY7hCIK7XCHi4ACx7sosN21zgL2/ToLshaF7i3rcYC6F/Bx
> 5GGgv6x6WiXWRMk82YiqcEphnOdphsWen4ZMHTdlBIzZ1EXpD5XwhDHTzzmD3SlT
> oNjwPR1Gmkt1yXxLSvvr6mp7XFRDQOJMWDHvmfroH4p2hcxyB/2dSbhLjrfri0nL
> WsjDDAhdIM1aHokLmLqi
> =mtD9
> -END PGP SIGNATURE-
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
--
Dave Täht
Let's go make home routers and wi
