I am just about to get this installed and I wonder if anyone has any exprience of setting this up. The ISP concerned uses PPPOE, would the standard debian install using the ISP's given login name and password be all that is required. I assume nameserver setup would be transparent similiar to using "usepeerdns" in a PPP set up. Also, this is Lindsay from NE Victoria, I am already on the luv list, for some reason though I I can no longer post anything from my original account, this has been on going for quite along time, ALL other email works OK from my original account. Using Linux since 1993, Lindsay
On 12/09/2016 9:19 AM, zlinew9@virginbroadband.com.au wrote:
I am just about to get this installed and I wonder if anyone has any exprience of setting this up. The ISP concerned uses PPPOE, would the standard debian install using the ISP's given login name and password be all that is required. I assume nameserver setup would be transparent similiar to using "usepeerdns" in a PPP set up.
Also, this is Lindsay from NE Victoria, I am already on the luv list, for some reason though I I can no longer post anything from my original account, this has been on going for quite along time, ALL other email works OK from my original account.
Using Linux since 1993, Lindsay _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
PPPOE for a sat connection, that's just bad design. Mike
On 12/09/16 9:49 AM, Ray via luv-main wrote:
I am just about to get this installed and I wonder if anyone has any exprience of setting this up. The ISP concerned uses PPPOE, would the standard debian install using the ISP's given login name and password be all that is required. I assume nameserver setup would be transparent similiar to using "usepeerdns" in a PPP set up.
any bandwidth-limited connection would be better with a local caching dns server, forwarding to the peer dns. I don't know how that translates to debian. Douglas
Also, this is Lindsay from NE Victoria, I am already on the luv list, for some reason though I I can no longer post anything from my original account, this has been on going for quite along time, ALL other email works OK from my original account.
Using Linux since 1993, Lindsay _______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
On 14.09.2016 00:37, Douglas Ray via luv-main wrote:
On 12/09/16 9:49 AM, Ray via luv-main wrote:
I am just about to get this installed and I wonder if anyone has any exprience of setting this up. The ISP concerned uses PPPOE, would the standard debian install using the ISP's given login name and password be all that is required. I assume nameserver setup would be transparent similiar to using "usepeerdns" in a PPP set up.
any bandwidth-limited connection would be better with a local caching dns server, forwarding to the peer dns.
I don't know how that translates to debian.
Douglas
I am using pdnsd as a local cacheing from a sugestion from Russel Coker, this turned out to be a real excellent sugestion as it sped up page loading no end (this was on dialup). I will keep this setup as it will almost certainly be a good step forward on satelite given its latency issues. Note: The satelite dish and modem was installed last monday, ie more than a week ago and I have as yet not done anything as I still have plenty of data left on my current account. Also the modem was installed a good distance from my current firewall (access was far easier) and I did not have a long enough cat 6 cable.
_______________________________________________ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Lindsay
Quoting zlinew9@virginbroadband.com.au (zlinew9@virginbroadband.com.au):
I am using pdnsd as a local cacheing from a sugestion from Russell Coker, this turned out to be a real excellent sugestion as it sped up page loading no end (this was on dialup).
I'm sure it would -- just from the caching. However, FWIW, you can do better still, by running a recursive nameserver such as Unbound. pdnsd is terrific for what it is, but it's ultimately just a small caching forwarder with no intelligence of its own. http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdnsd http://linuxmafia.com/faq/Network_Other/dns-servers.html#unbound To explain and disambiguate the type of DNS software: http://linuxmafia.com/pipermail/sf-lug/2008q3/006880.html http://linuxmafia.com/pipermail/sf-lug/2008q3/005293.html
On Wed, Sep 14, 2016 at 07:10:43AM +1000, zlinew9@virginbroadband.com.au wrote:
I am using pdnsd
FYI, I saw this DSA come in a few days ago: https://www.debian.org/security/2016/dsa-3664 Debian Security Advisory DSA-3664-1 pdns -- security update Date Reported: 10 Sep 2016 Affected Packages: pdns Vulnerable: Yes Security database references: In the Debian bugtracking system: Bug 830808. In Mitre's CVE dictionary: CVE-2016-5426, CVE-2016-5427, CVE-2016-6172. More information: Multiple vulnerabilities have been discovered in pdns, an authoritative DNS server. The Common Vulnerabilities and Exposures project identifies the following problems: CVE-2016-5426 / CVE-2016-5427 Florian Heinz and Martin Kluge reported that the PowerDNS Authoritative Server accepts queries with a qname's length larger than 255 bytes and does not properly handle dot inside labels. A remote, unauthenticated attacker can take advantage of these flaws to cause abnormal load on the PowerDNS backend by sending specially crafted DNS queries, potentially leading to a denial of service. CVE-2016-6172 It was reported that a malicious primary DNS server can crash a secondary PowerDNS server due to improper restriction of zone size limits. This update adds a feature to limit AXFR sizes in response to this flaw. For the stable distribution (jessie), these problems have been fixed in version 3.4.1-4+deb8u6. We recommend that you upgrade your pdns packages. craig -- craig sanders <cas@taz.net.au>
Quoting Craig Sanders (cas@taz.net.au):
On Wed, Sep 14, 2016 at 07:10:43AM +1000, zlinew9@virginbroadband.com.au wrote:
I am using pdnsd
FYI, I saw this DSA come in a few days ago:
https://www.debian.org/security/2016/dsa-3664
Debian Security Advisory DSA-3664-1 pdns -- security update
Craig, PowerDNS Authoritative Server is sometimes called 'pdns', and that is the name of the related Debian package. (Complementary codebase PowerDNS Recursor has Debian package pdns-recursor.) _But_ that is completely unrelated to pdnsd. http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdnsd http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdns http://linuxmafia.com/faq/Network_Other/dns-servers.html#pdns-recursor
On Fri, Sep 16, 2016 at 01:12:07AM -0700, Rick Moen wrote:
_But_ that is completely unrelated to pdnsd.
ah, my mistake. i assumed he was talking about powerdns.
good page that, i've read it before but not for some time. IMO a useful addition to it would be a list of authoritative servers that use bind9 RFC-1034 zonefiles. apart from "it aint broke, why fix it?" laziness, one of the reasons i'm still using bind9 is because I don't want to rewrite my zone files in a new format (or even have to learn a new format), and I haven't been overly happy with the few alternatives I've tried that could use bind zonefiles. - powerdns is serious overkill for my needs (home server with only a few domains). - last time i looked at it (years ago, not long after it was released), there were some incompatibilities between NSD's interpretation of bind zonefiles and bind9's interpretation. Also, I didn't want to have to run two name servers (internet-facing authoritative and private LAN recursive) - although dnsproxy or similar could solve that problem now. it's probably worth another look. - maradns provides a conversion tool for bind zonefiles, but doesn't use them natively. otherwise, i'd probably switch to it. I've used it several times on gateway boxes i've built for other people. craig -- craig sanders <cas@taz.net.au>
Quoting Craig Sanders (cas@taz.net.au):
On Fri, Sep 16, 2016 at 01:12:07AM -0700, Rick Moen wrote:
_But_ that is completely unrelated to pdnsd.
ah, my mistake. i assumed he was talking about powerdns.
No worries. ;->
good page that, i've read it before but not for some time. IMO a useful addition to it would be a list of authoritative servers that use bind9 RFC-1034 zonefiles.
You know, they kind of _could_ have called that format the RFC-1034 file format, as some RRs are described/defined there, but because all the key ones are described/defined in accompanying RFC-1035, it's generally called 'RFC-1035 format'. Anyway, yes, good idea -- and I actually do document RFC 1035 support where I know about it.
apart from "it aint broke, why fix it?" laziness, one of the reasons i'm still using bind9 is because I don't want to rewrite my zone files in a new format (or even have to learn a new format), and I haven't been overly happy with the few alternatives I've tried that could use bind zonefiles.
- powerdns is serious overkill for my needs (home server with only a few domains).
Yeah. $WORK did a massive conversion of hundreds of domains from BIND9 to PowerDNS Authoritative Server, and there were various problems along the way. I'm not convinced it was a good idea, even for a large Internet firm that does that many domains. Probably on balance (gains in performance and security), but with some reservations.
- last time i looked at it (years ago, not long after it was released), there were some incompatibilities between NSD's interpretation of bind zonefiles and bind9's interpretation.
I believe you, but haven't seen this. I've administered NSD on ns1.svlug.org from NSD 2.x days onwards, and it's been really good. I've not encountered any zonefile-parsing weirdness. (I still run BIND9 on ns1.linuxmafia.com .) Searching for data on this, I find some docs in their initial public release candidate: https://www.nlnetlabs.nl/downloads/nsd/OLD/nsd-1.0.0-rc2/REQUIREMENTS 'Section C. Technical Specifications has C.1. Zone file format and RR records.' It basically _claimed_ NSD would parse any valid RFC 1035 file containing only IN-class RRs. FWIW, I've not seen NSE 2.x and later's parser reject or get wrong anything from my own zones.
Also, I didn't want to have to run two name servers (internet-facing authoritative and private LAN recursive) - although dnsproxy or similar could solve that problem now. it's probably worth another look.
I found about a year ago what struck me at the time as the ideal solution to that problem but failed to add it to my linuxmafia.com knowledgebase. Maybe it was dnsproxy. Here's a creative solution from one of the NLnet Labs guys: https://www.nlnetlabs.nl/pipermail/nsd-users/2014-August/001998.html It is possible, but not using the same address+port of course. One solution is to have NSD only listen on localhost while unbound listens on the external adress. You can then use stub-zone configuration in unbound to make it use the localhost adress for lookups in any zone you are serving from NSD. This is what i do for my home network, for a production setup I would rather keep authorative and caching DNS services fully separated. However, followup from a different poster stresses that this is appropriate only for serving a private zone from NSD, as it wouldn't have the AA bit set. This is similar: https://www.nlnetlabs.nl/pipermail/nsd-users/2014-August/002000.html The ArchLinux wiki proposes a different soution: Bind NSD to 127.0.0.1:53530, and bind Unbound to *:53 with the auhtoritative zones declared as ones to refer to NSD using the 'local-zone' and 'stub-zone' features: https://wiki.archlinux.org/index.php/Nsd The 'Dnsspoof' examples on https://web.archive.org/web/20160329083109/https://calomel.org/unbound_dns.h... show some ways to leverage the DNS host being dual-homed (if it is). Other solutions might beckon if the host is multihomed, e.g., bind NSD to the public-facing real IP, and bind Unbound to the private RFC1918 address. Personally, when I do my next server rebuild on ns1.linuxmafia.com (which is a totally public-facing 'bastion host', not dual-homed), what I'll probably do is IP-alias a second public IP address onto the public network port (its sole network port other than loopback), and bind NSD to one and Unbound to the other -- which has the benefit of simplicity, letting me easily ACL the daemons individually, and keeping their configurations totally separate. Fortunately, I have spare IPs. None of this tested by your present correspondent. Yet. ;->
- maradns provides a conversion tool for bind zonefiles, but doesn't use them natively. otherwise, i'd probably switch to it. I've used it several times on gateway boxes i've built for other people.
I like author Sam Trenholme quite a bit, and have corresponded with him frequently on nameservice matters. Some of the details on that page, notably the very thorough information in the entry for Deadwood (his modern recursive server, intended to replace the old one in Maradns), comes directly from Sam. I get the impression that Deadwood is really, really excellent, on a par with Unbound, PowerDNS Recursive Server, and dnscache. As to Sam's authoritative-only daemon from Maradns, I honestly don't know, and have to admit I haven't tried it out. Many people are quite happy with it. Proper competition include NSD, Knot DNS (newest), tinydns, and PowerDNS Authoritative Server (overlarge, over-complex). Differentiators include which ones fully support: IPv6, DNSSEC/EDNS0. Personally, I'm getting a bit cynical about the standards churn for the latter, e.g., EDNS0 got rewritten via RFC 6891 in 2013. I'm tempted to react 'Fine, let us know when you're done playing standards gods, and I'll start paying attention.'
Oh, meant to add:
- powerdns is serious overkill for my needs (home server with only a few domains).
Yeah. $WORK did a massive conversion of hundreds of domains from BIND9 to PowerDNS Authoritative Server, and there were various problems along the way. I'm not convinced it was a good idea, even for a large Internet firm that does that many domains. Probably on balance (gains in performance and security), but with some reservations.
I recently stumbled upon a (new?) feature of BIND9's 'rndc' control utility that reduces the relative attraction of PowerDNS: ability to add/remove zones without restarting BIND: Problem You want to add a new zone or delete an existing zone without restarting or reloading a name server. Solution Add a new zone statement to named.conf or delete an existing one, then run rndc reconfig (for BIND 9) or ndc reconfig (for BIND 8). https://www.safaribooksonline.com/library/view/dns-bind/0596004109/ch05s07.h... At $WORK prior to the changeover to PowerDNS, we had greatly reduced the risk inherent in restarting BIND9 by building into our rollout process what they flattered me by naming the 'Rick test' using BIND9's named-checkconf utility: #Double-check BIND conffile: /usr/sbin/named-checkconf -z -t /var/named/chroot/ /etc/named.conf | \ egrep 'missing|not allowed|unknown|not at top of zone|\ appears to be an address|no current owner name|MAXTTL|file not found|\ may not be used with|outside epoch|in future|invalid|unsupported|no TTL|\ ignoring| TTL set to prior TTL' | sort -u #Should return null. This 'lints' the conffiles and all referenced zonefiles (-z), giving you advance warning of problems that might either prevent BIND9 startup or invalidate individual zones at load time. This alone prevented a lot of downtime. And 'rndc relaod [zone]' eliminated most restarts. _However_, ability to add/remove zones without restarting BIND is huge, and should eliminate almost all restarts.
On Fri, Sep 16, 2016 at 03:27:38PM -0700, Rick Moen wrote:
good page that, i've read it before but not for some time. IMO a useful addition to it would be a list of authoritative servers that use bind9 RFC-1034 zonefiles.
You know, they kind of _could_ have called that format the RFC-1034 file
typo. i actually meant to type 1035 there, and thought i did.
Anyway, yes, good idea -- and I actually do document RFC 1035 support where I know about it.
yep, saw that which is what gave me the idea for a summary list.
Here's a creative solution from one of the NLnet Labs guys: https://www.nlnetlabs.nl/pipermail/nsd-users/2014-August/001998.html
I saw that last night. It made me realise that probably the best option for me would be to have NSD listen on 203.16.167.1 while Unbound listens on 192.168.10.1 (I run both private and public subnets on my LAN so I can have both private and public hosts and VMs). Then all I'd have to do is configure my LAN hosts and VMs to use 192.168.10.1 as the resolver. Easy. Unbound seems to have all the features I need, including being able to forward requests for specific domains to specific servers (useful, e.g., for resolving private DNS views over a VPN).
Other solutions might beckon if the host is multihomed, e.g., bind NSD to the public-facing real IP, and bind Unbound to the private RFC1918 address.
err, yes. exactly that.
I'm tempted to react 'Fine, let us know when you're done playing standards gods, and I'll start paying attention.'
I mostly just leave things alone and then every 2 or 5 years or so go on a binge of updating everything to the latest standards. Unless I'm bored, or have a particular reason to make changes. craig -- craig sanders <cas@taz.net.au>
participants (5)
-
Craig Sanders -
Douglas Ray -
Mike O'Connor -
Rick Moen -
zlinew9＠virginbroadband.com.au