Re: Bind > 9.12 Will Not Start On FreeBSD
On 4/27/19 9:22 PM, Tim Daneliuk wrote:
On 4/27/19 5:33 PM, @lbutlr wrote:
On 27 Apr 2019, at 16:21, Tim Daneliuk wrote:
Why is 9.12+ now suddenly so grumpy about who owns the files? Is this a recent
fix to reduce the attack surface on files owned by root?
Pretty sure. I thought it was mentioned in the 9.12 release notes, but now I
can't find it.
Possibly relevant:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223842
Yes, that's almost certainly it. Sad to see that the FreeBSD ports team
is still doing their usual stellar job of "It's not our problem."
You need to make the directory you define as the working directory
("directory" in named.conf) writable to the named process.
I vaguely recall that I might have had code to make sure that got set
correctly in the rc.conf file back when I was maintaining the BIND
ports, but I can't figure out what they've done to the repo, and I can't
find my old stuff in there.
You're probably better off making your working directory something
that's not named in the mtree file, so that your permissions don't get
"fixed" by it.
hope this helps,
Doug
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: SSL cert for lists.isc.org expired on Saturday, December 29, 2018
I've had LE fail after a cerbot upgrade because it grew a dependency that didn't automatically get installed with the upgrade. So yes, automation good, but not perfect. On 2018-12-31 6:54 PM, John W. Blue wrote: nuff said, eh? I thought that Let's Encrypt wanted to roll / revalidate SSL certs every 90 days. IIRC they have automation for apache and DNS tools when it comes to revalidation. Good hunting! ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: about the effect of installing with "--without-openssl"
On 08/26/2018 07:30 PM, takahiro wrote: That's why I want to know the effect of installing with "without-openssl". What specifically are you trying to accomplish by compiling without openssl? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/21/2018 08:53 AM, Grant Taylor via bind-users wrote: On 08/20/2018 11:06 PM, Doug Barton wrote: But that doesn't mean that slaving a zone, any zone, including the root, is "dangerous." If slaving zones is dangerous, the DNS is way more fragile than it already is. Sorry, poor chose of words. The last time I read the RFC discussing slaving the root zone stressed that it should only be done for localhost and / or a special config that could only impact the single host if (implying when) there was a problem, thus limiting the scope of negative impact. I combined that and the potential unvalidated zone transfer allowing ""corruption and called it "dangerous". I don't think there is anything dangerous about slave zone transfers at all. I've been doing them for the better part of 20 years. I think the ""danger, if any, is the fact that the discussion was around the root zone and the potential impact of the blast radius if things went wrong. Namely all client machines that used the DNS server in question. The DNSSEC validation errors that Tony references are self-healing, in that if the validating resolver stops validating things, the operator is hopefully going to notice that, and take steps to fix it. Sadly, the small user base that I've had, has been more likely to not tell me about problems and live with things or change things to use other servers without providing that desired ~> needed feedback loop. I am certainly open to the new mirror zone software doing awesome things, don't get me wrong. But don't call something "dangerous" that lots of people have already been using successfully for over 15 years. Sorry for the poor choice of words. Fair enough, no harm in challenging assumptions, etc. I have never said that slaving the root is for everyone, and you've illustrated some good reasons why. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nslookup oddities (Was: SRV record not working)
On 08/20/2018 10:14 AM, Lee wrote: On 8/19/18, Mark Andrews wrote: nslookup applies the search list by default and doesn’t stop on a NODATA response. Some versions of nslookup have been modified by OS vendors to use /etc/hosts for address lookups. nslookup doesn’t display the entire response by default. I learned something :) Thank you Not that I know the implications of "doesn’t stop on a NODATA response" but hopefully that can be remedied. wrt the search list, that's why I got in the habit of always typing the trailing dot. I've never seen that fail, but 'set nosearch' is supposed to do the same thing. 'set debug' and 'set d2' displays lots, but I never checked to see if it was the entire response or no So... it seems like the bottom line is that dig is better but nslookup ain't all that bad Lee, Messages like this, and the one you sent me privately, are the reason that I usually don't even bother replying to messages on this list. I don't say that to denigrate you. I say it in the hopes that someone, maybe even you, will learn from your mistake. Your "bottom line" completely misses basically everything that's been said in this thread. No one has made any statement about nslookup being "bad," or "worse" than any other tool. I have clearly stated the contexts in which the two tools are more or less suited for a given situation, and given reasons why. Others have expanded on those reasons. If you still don't understand why, at least try to understand the when and how. Go back and re-read the thread. Look up the terms that you don't understand. You can even ask reasonable, specific questions to the effect of, "I looked up term XYZ but didn't understand how the zig interacts with the zag, can someone explain that to me?" In other words, do SOMETHING to help yourself. Don't complain that no one worked hard enough to make you understand something that you seem to be working so hard to misunderstand. Good luck, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/20/2018 09:00 AM, Grant Taylor via bind-users wrote: On 08/20/2018 05:23 AM, Tony Finch wrote: If the local root zone gets corrupted somehow (maliciously or otherwise) the usual setup cannot detect a problem, but it'll cause DNSSEC validation failures downstream. The normal resolver / validator algorithm is more robust. The new mirror zone code validates the root zone before installing it, which at least allows it to detect a problem; I have not examined it closely enough to see how hard it tries to recover by xfering the zone from a different root server, or if it just falls back to normal resolution. Thank you for that explanation. It explains why it's potentially dangerous to blindly slave the root zone for general use by clients on a local recursive resolver. No, it doesn't do that at all. It may be true that the new mirror zone code does awesome things to make sure that the slaved zone is identical to the master's, I don't know, I haven't seen it. But that doesn't mean that slaving a zone, any zone, including the root, is "dangerous." If slaving zones is dangerous, the DNS is way more fragile than it already is. The DNSSEC validation errors that Tony references are self-healing, in that if the validating resolver stops validating things, the operator is hopefully going to notice that, and take steps to fix it. And I have always said that you should not be slaving the root unless you already have a good mechanism for making sure that said slaving isn't failing. (In other words, don't go into this, or any other configuration blind.) I am certainly open to the new mirror zone software doing awesome things, don't get me wrong. But don't call something "dangerous" that lots of people have already been using successfully for over 15 years. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nslookup oddities (Was: SRV record not working)
And don't forget NIS, and NSSwitch. And don't get me started on the tricks that the windows resolver plays. On 08/19/2018 07:59 PM, Mark Andrews wrote: nslookup applies the search list by default and doesn’t stop on a NODATA response. Some versions of nslookup have been modified by OS vendors to use /etc/hosts for address lookups. nslookup doesn’t display the entire response by default. On 20 Aug 2018, at 12:28 pm, Lee wrote: On 8/19/18, Doug Barton wrote: On 08/19/2018 12:11 PM, Lee wrote: On 8/18/18, Doug Barton wrote: nslookup uses the local resolver stub. That's fine, if that's what you want/need to test. If you want to test specific servers, or what is visible from the Internet, etc. dig is the right tool, as the answers you get from nslookup cannot be guaranteed to be directly related to the question you asked. Could you expand on that a bit please? I thought nslookup was pretty much equivalent to dig @ the exception being that nslookup looks for a & records and dig just looks for a records Nope. Depending on what operating system you're on, what version of nslookup you have, how you format your query, and how the system is configured; even telling nslookup to query a specific server may not get you the answer you're looking for. That's still awfully vague. Do you have any examples of nslookup returning bad information? If you want to know what answer your stub resolver is going to return for a given query, nslookup is a great tool. Although, if you just need to know what address record you'll get back, ping works just as well. ping just shows one address; "nslookup www.yahoo.com" shows all of them If you want to really debug DNS you need to learn to use dig, and understand the output. Agreed. If you're serious about debugging DNS you needs to learn dig. But the assertion is ... the answers you get from nslookup cannot be guaranteed to be directly related to the question you asked. so I'm wondering how, or under what circumstances, nslookup returns invalid information. Thanks Lee ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nslookup oddities (Was: SRV record not working)
On 08/19/2018 12:11 PM, Lee wrote: On 8/18/18, Doug Barton wrote: nslookup uses the local resolver stub. That's fine, if that's what you want/need to test. If you want to test specific servers, or what is visible from the Internet, etc. dig is the right tool, as the answers you get from nslookup cannot be guaranteed to be directly related to the question you asked. Could you expand on that a bit please? I thought nslookup was pretty much equivalent to dig @ the exception being that nslookup looks for a & records and dig just looks for a records Nope. Depending on what operating system you're on, what version of nslookup you have, how you format your query, and how the system is configured; even telling nslookup to query a specific server may not get you the answer you're looking for. If you want to know what answer your stub resolver is going to return for a given query, nslookup is a great tool. Although, if you just need to know what address record you'll get back, ping works just as well. If you want to really debug DNS you need to learn to use dig, and understand the output. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SRV record not working
On 08/18/2018 04:53 PM, Barry Margolin wrote: In article , Grant Taylor wrote: On 08/18/2018 07:25 AM, Bob McDonald wrote: I don't think anyone hates nslookup (well maybe a few do ) I suppose the immense dislike stems from the fact that it's the default utility under Windows. Folks who use dig as their default realize that when used properly, dig provides much more functionality than nslookup. For example, try using TSIG with nslookup or getting a NSID response. These are only a couple of examples. There's other reasons to change. The output from dig is much more comprehensive. And, yes, if you install the bind tools from ISC under Windows, dig works quite well. I've been told that nslookup will lie and provide incorrect information in some situations. I have no idea what situations that is. I would love to learn what they are. If you know of such an example, please enlighten me. As such, I tend to use nslookup on platforms without dig when or until I have reason to not do so. I don't think it "lies" much, but the output isn't as clear and unambiguous as dig's. When it reports errors, it can be difficult to tell specifically what the actual error was. One example I can think of is that for some reason it expects the nameserver to be able to reverse-resolve its own IP. If it can't, it reports this as an error, and you might think that it's reporting an error about the name you're actually trying to look up. nslookup uses the local resolver stub. That's fine, if that's what you want/need to test. If you want to test specific servers, or what is visible from the Internet, etc. dig is the right tool, as the answers you get from nslookup cannot be guaranteed to be directly related to the question you asked. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 2018-08-15 10:43, Tony Finch wrote: Doug Barton wrote: Slaving the root and ARPA zones is a small benefit to performance for a busy resolver, [...] This technique is particularly useful for folks in bad/expensive network conditions. While the current anycast networks of root servers is much better than it was "in the old days," the more data you have locally the more resilient you are to DDOS against those targets. I should probably have said that it isn't just RFC 8198: * synth-from-dnssec (RFC 8198) synthesizes negative answers, so in most cases you don't need to talk to the authorities to find out that the answer is no; this is on by default If you're slaving the zone on the resolver, that resolver is authoritative for the zone, so it doesn't need to query another server to prove that the answer is no. * prefetch (https://tools.ietf.org/html/draft-wkumari-dnsop-hammer [1]) means your users won't suffer the latency of talking to the authorities when a popular name expires from the cache; this is on by default If you're slaving the zone, there is no cache to expire. * stale-answer-enable / max-stale-ttl (https://tools.ietf.org/html/draft-ietf-dnsop-serve-stale) means you can still function for a while if you can't reach the authorities This is a terrible idea, so not having it is a good thing. :) These are all general-purpose features, not at all specific to the root. I think a local root was clearly a good idea before DNSSEC; since 2010 I have been less comfortable with it. How, specifically, is DNSSEC affected by the validating resolver having a local copy of the root zone? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Local Slave copy of root zone
On 08/15/2018 09:11 AM, Bob McDonald wrote: I've recently been investigating having a local slave copy of the root zone on a caching/forwarder type server. I've even put the local slave copy of the root zone into a separate view accessed via a different loopback address. (An limited example of this exists on the ISC site) My question is this. Is there any benefit to also hosting local slave copies of arpa., in-addr.arpa., and ip6.arpa.? Although FreeBSD now comes with unbound as it's default DNS software, installing bind yields an example named.conf which floats the concept of the local slave copies of the above zones. (That is what led me down this path...) I'm responsible for the slave zone configuration in the FreeBSD named.conf. At least, I wrote the original version of it, and maintained it for many years. The version located here looks essentially as I left it: https://svnweb.freebsd.org/ports/head/dns/bind913/files/named.conf.in?revision=470832=markup Slaving the root and ARPA zones is a small benefit to performance for a busy resolver, and as long as you maintain a watch on your logs to make sure that slaving the zone does not fail, you're golden. I understand the reasoning behind maintaining these zones in a separate view, accessible only locally, but don't see any value in it. A resolver is going to cache the answers it gets anyway. This technique is particularly useful for folks in bad/expensive network conditions. While the current anycast networks of root servers is much better than it was "in the old days," the more data you have locally the more resilient you are to DDOS against those targets. In regards to production readiness, I've used it in heavy production at numerous sites, as have thousands of FreeBSD users. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Modification in dhcpd.conf does not update ddns
On 01/28/2016 10:23 AM, Bernard Fay wrote: Hi, I have DDNS and DHCPD setup and it works ok so far. But, while testing the integration of dhcpd and dns, I found that if I change the IP address in dhcpd.conf for a previously configured client the change is not reflected in DNS once the client receive the new IP. When you say "configured client" are you referring to a DHCP reservation? If so, do you have update-static-leases enabled in your dhcpd.conf? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: RPZ in dns views
On 01/22/2016 05:30 PM, Rama Krishna Prasad Chunduru wrote:
Hi All,
I am trying to use RPZ ( Response Policy Zone) in DNS views (BIND
9.8.2) but i am getting the below error
service named restart
Stopping named:[ OK ]
Starting named:
Error in named configuration:
/etc/named.conf:92: when using 'view' statements, all zones must be in views
[FAILED]
That error message is pretty clear. :)
Whenever you edit named.conf, especially if you're doing it by hand, you
should run named-checkconf and make sure you don't get any errors.
That's what the service script is doing for you, and it's even telling
you exactly which line to look at (92).
view "second-key-view" {
match-clients{
second-key-acl;
//key secret-key;
};
zone "bbc.com "
{
type master;
file "views/firstkey";
allow-query {none;};
};
response-policy {
zone "youtube.com ";
};
};
You ended the view with the close-curly-bracket immediately above. You
probably want to comment out (or completely remove) the zone declaration
below.
zone "youtube.com "
{
type master;
file "dummy-block";
allow-query {none;};
};
view ...
hope this helps,
Doug
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind9 on VMWare
On 01/13/2016 04:34 AM, Philippe Maechler wrote: My idea for the new setup is: --- caching servers - Setup new caching servers - Configure the ipv4 addresses of both (old) servers on the new servers as a /32 and setup an anycast network. This way the stupid clients, who won't switch to the secondary ns server when the primary is not available, are happy when there is some problem with one server. If we're having issues with the load in the future we can setup a new server and put it into the anycast network Assuming you can manage the anycast effectively that's a good architecture that works well. Many of my customers have used it. auth. servers - Setup a hidden master on the vmware - Setup two physical servers which are slaves of the hidden master That way we have one box which is (anytime in the future) doing the dnssec stuff, gets the update that we're doing over the webinterface and deploys the ready-to-serve zones to his slaves. I would not hesitate to make the authoritative servers virtual as well. I'm not sure if it is a good thing to have physical serves, although we have a vmware cluster in both nodes which has enough capacity (ram, cpu, disk)? I once read that the vmware boxes have a performance issue with heavy udp based services. Did anyone of you face such an issue? Are your dns servers all running on physical or virtual boxes? When I was at BlueCat we recommended to customers that they put their resolving name servers on physical boxes in order to avoid chicken and egg problems after a catastrophic failure. Resolvers are core infrastructure, as are Virtualization clusters. It's better to avoid interdependencies between critical infrastructure wherever possible. Since you already have the physical boxes, I would continue to use them. The same argument can be made for DHCP as well, BTW. That said, a non-zero number of our customers had all of their stuff virtualized, and were quite happy with it. Modern VMware has little or no penalty, and certainly nothing that would slow you down at 15k qps. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
GSS-TSIG updates with multiple KSPs on the same BIND server?
Folks,
Reading through manuals, HOWTOs, etc. on line it SEEMS possible that
BIND 9.8+ could be configured to use multiple KSPs. The traditional way
of configuring GSS-TSIG is the following in options{}:
tkey-domain FOO.BAR;
tkey-gssapi-credential DNS/dns1.foo.bar;
However that configuration restricts the server to use only that one
KSP. What I'd like to do instead is to use the tkey-gssapi-keytab option
to specify just the keytab file. According to the 9.9.5 ARM:
tkey-gssapi-keytab The KRB5 keytab file to use for GSS-TSIG updates. If
this option is set and tkey-gssapi-credential is not set, then updates
will be allowed with any key matching a principal in the specified keytab.
I'm assuming that if I get the [realms] and [domain_realms] configured
correctly in my krb5.conf file that I would be good to go, but I am far
from an expert on Kerberos, and while using a single KSP works fine, I
haven't yet created a test environment for using multiple KSPs. So
before I do that I thought I would ask if what I want to do is even
possible, and if so where the landmines are.
In case it's not clear, the use case here is to be able to use the same
BIND instance as master for multiple AD realms that do not have an
existing trust relationship.
Thanks,
Doug
--
I am conducting an experiment in the efficacy of PGP/MIME signatures.
This message should be signed. If it is not, or the signature does not
validate, please let me know how you received this message (direct, or
to a list) and the mail software you use. Thanks!
signature.asc
Description: OpenPGP digital signature
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Digging to the final IP
It's interesting to see the discussion about trying to turn dig into something it isn't. :) It's a really good DNS diagnostic tool, but if you just want to get the answer for a query, host does the job quite well, with a lot less fuss. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DLV verify issue
On 10/23/14 4:34 AM, Péter-Zoltán Keresztes wrote: Hello I am trying to add a dnssec signed tomain to DLV isc. Is there a DNSSEC path from this domain up to the root zone? (It would be helpful to list what domain it is.) If so, why are you adding it to DLV? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Digging to the final IP
On 10/21/14 8:31 PM, Frank Bulk wrote: Dave, Thanks for the input, but what I was looking for was a dig command that returns the IP(s) or a fail. It looks like the host command is the right solution in this case, not dig. Yep. :) You can check the return value of the call to get your fail as well. For example: $ host ajklasdfjklasd.com ; echo $? Host ajklasdfjklasd.com not found: 3(NXDOMAIN) 1 hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND resource requirements
On 10/20/14 11:50 AM, Mike Bernhardt wrote: Anyone have some input on this? No one has commented so far. -Original Message- From: Mike Bernhardt [mailto:bernha...@bart.gov] Sent: Tuesday, October 14, 2014 11:59 AM To: bind-users@lists.isc.org Subject: BIND resource requirements We are currently using 9.8. We have had it on the radar to move to 9.9 but it's been low priority since 9.8 is still supported for now. But in reading about all of the alleged issues with 9.10.x as well as possible increased resource use starting with 9.9.5, I would like to ask a question: We have 2 views and maybe 6 static zones. Is there any significant change in resource requirements I need to be aware of in moving to 9.9? And are there any known and intended increased requirements for 9.10 (i.e. not bug-related)? Are you talking authoritative-only data? If so, what's preventing you from loading up a BIND 9.9.5 instance in the lab, loading up your data, and answering your own question? :) If your response is, I don't have a lab, then you know your next step. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Inline-signing feature request: Directly set the signed zone's serial number
On 10/7/14 11:03 AM, Terry Burton wrote: With inline signing you have a hidden serial number in the unsigned zone and an exposed serial number in the signed versions which your slaves track. After redeployment (following DR, emergency relocation, elastic capacity expansion, etc.) I want to be able to bump the exposed serial number (once) back to an appropriate value without having to modify the unsigned zones. (For context, the unsigned zone serial number matches the revision number in a VCS to which the DNS infrastructure hosts and administrators have read-only access, i.e. mandatory separation of infrastructure and data access rights.) * Check out the unmodified version of the unsigned zone * Increase the serial number in the checked out copy to be past the one in the signed zone * rndc reload * Delete the modified version of the zone file, and revert to the master copy ... all of which is not to say that your request is not reasonable, just letting you know that a solution exists. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Diagnostic help part 2
On 10/1/14 8:17 AM, Barry Margolin wrote: In article mailman.1035.1412133286.26362.bind-us...@lists.isc.org, Eli Heady eli.he...@gmail.com wrote: With response sizes growing (dnssec, ipv6), answers are more likely to be too large for UDP. That's unlikely. That's why EDNS was created, so that these large answers wouldn't require TCP. ... and more than a decade later EDNS still fails very often due to misconfigured and/or ancient firewalls that don't understand it. 53/TCP is part of the spec, and should not be blocked. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Two domains reporting errors
On 9/25/14 4:49 PM, LuKreme wrote: Wait a second, so the zone name comes from the named.conf? Not quite. When named loads the zone file it does it in the context of the zone stanza from named.conf. If the zone name in the SOA is listed literally then named will check to make sure that it matches, and generate an error if it does not. However, if you use the @ sign in that spot in the SOA record then named will fill in the zone name for you. The subsequent uses of the @ sign will inherit their labels from the context of the previous label. I could have, for all my hosted domains, a single file named something like hosted.conf and then simply link to it with `ln hosted.conf dw.tld` or ln -s, perhaps? Don't do that ... Just use the same file name in the zone stanzas in named.conf. Also, the SOA line contains ns? The MNAME field theoretically lists the master name server for the zone. In practice however it isn't used for anything except occasionally for dynamic DNS. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Change in behaviour regarding ndots and searchlist
On 9/15/14 7:04 AM, Lightner, Jeff wrote: While the final dot has been required within zone files to prevent unwanted appendages to records it has NOT been required by tools such as host and nslookup on either Windows or Linux/UNIX which routinely use search domains. On Windows the behavior you're seeing has been the default for a long time. (I spend a lot of time looking at BIND query logs helping customers to debug wacky holes they've dug for themselves with Windows search strings.) Further, Windows has a feature usually referred to as domain search devolution which means that if you have a domain name option (NOT a search string) such as foo.example.com and query.foo.example.com doesn't return an answer, it will also try for query.example.com and query.com. So short names are awesome ... except where they're not. :) And even more awesome in the Windows world when you have applications that can ONLY work with short names, you can't even type a FQDN into the config. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.10.0-P2 memory leak?
On 9/12/14 11:07 AM, Mike Hoskins (michoski) wrote: I do have a lot of interest in the community getting to the bottom of this, as we are just planning a large upgrade in one of our environments which will move caching clusters serving 6-8k clients over to 9.10.1. Given all of the problems that have been reported with 9.10 you may wish to reconsider that plan. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/28/14 10:55 AM, Timothe Litt wrote: Aside from the use of the word 'absurdity', I'm not offended. I am trying to educate. And while I recognize that I'm arguing pragmatism with a market purist, It's nice to be called pure, in some context anyway. :) However as I pointed out I'm not simply arguing market forces, I'm also arguing the morality of rewarding those providers who do the right thing; and I'm quite specifically arguing the anti-pragmatist perspective that voting with your feet is important. Chris, I purposely did not invoke the spectre of Jim Reid because I did not agree with his violent opposition to the DLV when it was created. But now that we're in the signed root phase of DNSSEC deployment I think that argument has a lot more validity. hopefully the OP (and others) will learn why some of us have a slightly different view of how to get to the end goal. I agree that illuminating the different points of view is valuable, and I am happy to agree to disagree with you (and Chris Thompson) on this topic. And why my advice for resolvers is 'check DLV', while my advice for domain owners is 'take reasonable steps to stay/get out of DLV, but use it if you *must*'. We're actually not that far apart... ... I'm sorry to say that we are still quite far apart on specifics though. You continue to use the word impossible when what you mean is outside of the constraints I have created for myself. I was trying not to devolve into a discussion of your specific situation, but one really simple solution to your particular use case would be to move your stuff to a colo facility where they provide proper reverse DNS, signed delegations, etc. There are a world of other options, but you have designated a set of parameters within which you wish to operate, and a provider that does DNSSEC is outside of your parameters. That doesn't make it impossible, that makes it something you're not willing to do. Chris' message was an excellent example of his particular value of really, really hard, but even he points out that it's not the same as impossible. His organization has done the cost/benefit analysis and determined that having a DNSSEC chain from the root for their reverse delegations is not worth the cost of moving away from JANET. I don't know the politics anywhere near as well as Chris does, but I know them well enough to know that his organization is probably correct in their analysis. In any case, their network, their rules. I have no problem with that. And I want to reiterate one last time that I'm NOT saying that no one should use the DLV, or that no one should put new entries into it. If you or Chris have people that need to validate your reverse DNS, they should be given the information they need about using the DLV to do that. What I AM saying is that people should not be routinely advised to use the DLV, and that resolver operators should only use it if they have a good reason to. And with that, I'll let others chime in, as I don't think I'm saying anything new here. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/26/14 10:35 AM, Timothe Litt wrote: I think this is misleading, or at least poorly worded and subject to misinterpretation. I chose my words carefully, and I stand by them. I did not say that the DLV has no value, and I specifically mentioned that there are circumstances when it is valuable and should be used. You clearly have a different view, which is fine. When it comes to gTLDs, I completely reject the notion that users cannot change registrars. It can be hard, no doubt, but it's a cost/benefit analysis. If the benefit of DNSSEC outweighs the difficulty of moving, then it's worth it. If not, it's not. The fact that it's hard doesn't mean it's impossible. That said, I do recognize that there are situations where a chain of trust to the root is not possible (such as some reverse zones). Again, this becomes a cost/benefit analysis. For reverse zones if DNSSEC is important it may be worth the effort of changing providers, or even getting a PI assignment. For TLDs where DNSSEC is not yet available, a change may be in order. If enough people vote with their feet in this way those providers and TLDs that lose customers may reconsider their offerings. No one said it would be easy. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
On 8/27/14 3:03 PM, Timothe Litt wrote: So you really meant that validating resolvers should only consult DLV if their administrator knows that users are looking-up names that are in the DLV? That's how I read your advice. You're correct. I don't see how that can work; hence we'll disagree. I think the only viable strategy for*resolvers* is to consult the DLV - as long as it exists. So that leads to a Catch-22, as ISC has stated that they will continue to provide the DLV as long as it is used. You're saying that people should continue to consult it as long as it exists. Now that the root is signed the traditional argument against continued indiscriminate use of the DLV is that it makes it easier for registries, service providers, etc. to give DNSSEC a low priority. You don't need me to provide DNSSEC for you, you can use the DLV. Based on my experience I think there is a lot of validity to that argument, although I personally don't think it's persuasive on its own. While I appreciate the tone of reasoned discourse in the message I'm responding to, what you have done is provide additional details to support your thesis that changing providers is hard. I'm not arguing the contrary position, so we can agree to agree on that. What you haven't done is provide any evidence to refute my thesis that It's hard != It's impossible. I'll even go so far as to agree with you that in some cases it's really, really hard. What that leaves us with is your position (which I will state in an admittedly uncharitable way), Some of us would like to have the benefits of protecting our authoritative data with DNSSEC without having to endure the cost and inconvenience of migrating our resources to providers that support it. Therefore the entire Internet should use the DLV. In contrast, my position is that people and/or organizations which need the protection of DNSSEC should vote with their feet. In this way providers that offer DNSSEC will be rewarded, and those that do not will be punished. Completely aside from what I believe to be the absurdity of your argument, the position I suggest will almost certainly result in market forces which encourage the deployment of DNSSEC. At bare minimum it has the moral value of rewarding providers who have done the right thing. I realize that it's unpopular to state some of these ideas in such a direct way, and I hope no one is offended by one person's opinion. I also realize that those who wish to receive the benefits of DNSSEC without enduring the aforementioned costs will not like my argument. I can't help you there. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: recursive lookups for UNSECURE names fail if dlv.isc.org is unreachable and dnssec-lookaside is 'auto'
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 8/26/14 5:50 AM, Tomas Hozza wrote: | On 08/26/2014 02:27 PM, Mark Andrews wrote: | Why would you expect them to succeed? | | Because validation using root servers and authoritative servers | proved that the domain is intentionally unsecure. Tomas, It seems that Mark straightened you out a bit. :) I think it's worthwhile to discuss a little more of the theory for those watching the thread, and for the archives. The point of DLV initially was to provide a mechanism for sharing trust anchors for those that did not have a path through the root (which in the early days of course was everyone). Thus Mark's point that the lack of a path through the root not being conclusive is quite important. The other thing worth pointing out is that while it's certainly fine to test the DLV, and understand how it works, at this point in the evolution of DNSSEC the commonly accepted wisdom is that it should not be used routinely; and in fact should only be used when the admin knows that there is a TA in it that she needs, and that is not available with a path through the root. FWIW, Doug -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) iQEcBAEBCAAGBQJT/LtLAAoJEFzGhvEaGryE8KcH/0V5YLHU5qDKp0zlaqt6TRlH Yt9taFQuQZhn3tdbYb/Y3L7HLkRhQGGHXvsCjbaF91tnaCtHKY7Jmrd0KQLszgkJ aXNocB8vG8nk8HNOVc3WQr0SNlGxTgX5zBzxTaonGW1RpxRjOoo2wFrZnRbYCR+G aHlvkRnjuzggtHHjMHNuMmnt54fraW62waDNgJrb7GDZjaiCmfg14o/VsH4h2J7U 5B0/kF0fHGjJ8QKafxNQfjlYe/25hqDae0NwxCAg3SQWHfxXHzOpf7Hi/mR7DbbS x1yOSOPdg7pgbJV+JpsMPaz4s0hOTWGnD9ykYM096dsjh6Jh3ztDNAyZ6Vqt2GY= =uQ3S -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind RPZ dnsfirewall howto's version 2 are here
Please don't reply to a message on the list and change the subject line. Doing so causes your new topic to show under the previous one for those using mail readers that thread properly, and may cause your message to be missed altogether if someone has blocked that thread. Instead, save the list address and start a completely new message. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Metazones or Something Else?
On 08/04/2014 09:33 AM, John Anderson wrote: I've recently inherited a project that is going to require some method of automatically disseminating zone information to slave DNS servers running BIND. The traditional solution to this problem is rsync, although I realize that's not very sexy. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: OT: Authoritative Server returning RR's with decrementing TTL's?
Almost certainly not running BIND. Almost certainly is running a creative load balancing solution. hth, Doug On 07/31/2014 12:56 PM, Ray Van Dolson wrote: Not BIND-related specifically... (though the server below could be running BIND I suppose). This seems weird. Why is this authoritative server returning *some* answers with decrementing TTL's? $ dig @ns1.dtra.mil dtra.mil NS ; DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 @ns1.dtra.mil dtra.mil NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 34658 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dtra.mil. IN NS ;; ANSWER SECTION: dtra.mil. 2002IN NS ns1.dtra.mil. dtra.mil. 3359IN NS ns2.dtra.mil. ;; Query time: 92 msec ;; SERVER: 214.27.180.254#53(214.27.180.254) ;; WHEN: Thu Jul 31 12:47:33 2014 ;; MSG SIZE rcvd: 62 $ dig @ns1.dtra.mil dtra.mil NS ; DiG 9.7.4-P1-RedHat-9.7.4-2.P1.fc14 @ns1.dtra.mil dtra.mil NS ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 22108 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;dtra.mil. IN NS ;; ANSWER SECTION: dtra.mil. 1999IN NS ns1.dtra.mil. dtra.mil. 3359IN NS ns2.dtra.mil. ;; Query time: 90 msec ;; SERVER: 214.27.180.254#53(214.27.180.254) ;; WHEN: Thu Jul 31 12:47:35 2014 ;; MSG SIZE rcvd: 62 Server behaves the same way even if I do the queries without recursion desired... Odd. Ray ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Using a DynDNS hostname in master-statement for a bind slave?
On 06/27/2014 08:27 AM, Johannes Kastl wrote: The slave server (HOST B) is reachable from the internet via a dynDNS hostname. Now I want to setup another bind as slave on a server hosted at my provider. It should use HOST B as its master, to transfer the zone and act as a slave. BUT I found nothing in the documentation on how to deal with a master server that has no fixed IP and is reachable via a dynamic hostname. That's because it cannot be done. You need a master with a fixed address. If your zone content and IP address don't change often you could set a very long expire time on the zone, and fix the master definition on your provider's slave whenever it breaks, but that's pretty fragile. Good luck, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: tsig-key
On 06/10/2014 08:56 AM, Mohammed Ejaz wrote: Any help would be highly appreciated. Switch to BlueCat which does all communication with TSIG by default? :) Sorry, couldn't resist ... Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: SPF RR type
Please don't reply to a message on the list and change the subject line. Doing so causes your new topic to show under the previous one for those using mail readers that thread properly, and may cause your message to be missed altogether if someone has blocked that thread. Instead, save the list address and start a completely new message. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem dlz_mysql_driver
Please don't reply to a message on the list and change the subject line. Doing so causes your new topic to show under the previous one for those using mail readers that thread properly, and may cause your message to be missed altogether if someone has blocked that thread. Instead, save the list address and start a completely new message. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Architecture Questions
On 05/28/2014 07:39 AM, Mark Andrews wrote: In message d6c04ec67151214dad5e55e7ebf5207e425e3...@wrxxentexmb01.na.follett.l an, Baird, Josh writes: Hi, I have historically hosted authoritative slave zones on my internal caching/r ecursive servers to override recursion for internal zones. These servers are not directly reachable from the internet. Generally speaking, I realize tha t it is considered a bad practice for any authoritative servers to perform re cursion. Is it a common practice in this particular scenario though? The other option would be to have 'X' number of authoritative servers with re cursion disabled, and then spin up another dedicated caching/recursive tier w hich used stub zones to communicate with the authoritative servers. Clients would point directly to the caching tier for name resolution. This scenari o sounds like it would be more cumbersome to maintain. It would also require additional servers. I'm not sure the additional hardware and complexity is worth trouble in this scenario, but I am looking for opinions. Furthermore, I was recently told by one of the larger managed IPAM/DNS vendor s that it was on ISC's roadmap to no longer allow authoritative servers to pe rform recursion (ie, the 'recusion yes' option would be disabled if the serve r contained authoritative zones). Is this actually true? No. There are good reasons to allow a server to perform both roles. What isn't advisable is for a listed server offering authoritative service to the world to also be recursive. This risks leaking cached data to the world. It can also result in answers being returned when referrals are expected. Sharing rolls is very bad if you serve not leaf zones to the world. If there are only leaf zones being served it is not such a issue. A internal server or a recursive server having copies of zones isn't generally issue though you do need to be careful about the type of response you generate depending upon RD state. This is a much more complex issue that is generally acknowledged. +1 to everything that Mark said. I always recommend to customers that they do this on their INTERNAL servers for just the reasons that Josh outlined. And as Mark said, EXTERNAL authoritative servers should never have a recursive role. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Book recomendations?
On 05/27/2014 03:51 PM, Baird, Josh wrote: Hi, Can someone recommend a modern/new-ish book on DNS (specifically BIND)? I know there have been several O'Reily books throughout the years, but haven't kept up on anything in the past few years. I'm looking for architecture design, best practices in designing enterprise and service provider DNS architectures, etc. For DNSSEC specifically: https://www.michaelwlucas.com/nonfiction/dnssec-mastery ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Slave zone intermittently not refreshing
On 05/08/2014 05:53 AM, Mart van de Wege wrote: I have a couple, all of them 'retry limit for master $foo exceeded'. Only 2 hits for the master that's giving trouble though, and none of those around the time we had trouble. If you're seeing any of these errors the problem is worse than you think. Also, you haven't mentioned anything about the logs on the master. Are you seeing any errors about the number of simultaneous transfers exceeded? IME if things work on the command line but the servers are not performing as expected this is usually the culprit. Also IME the default limits for simultaneous transfers and SOA queries are quite conservative. On a busy master I usually at least double them. You'll want to watch performance on the master to make sure it's not actually getting swamped of course. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: a note on 9.10.0rc2: eleven, twelve; dig and delv(e)
Evan, I mulled over your response and considered not pursuing this further, but apparently I can't help myself. :) On 04/27/2014 12:00 PM, Evan Hunt wrote: On Sun, Apr 27, 2014 at 07:36:22PM +0100, Chris Thompson wrote: I rather liked delve, but the truncation to delv does indeed seem suboptimal in those respects, and quite ugly as well. I found that my initial ugh, ugly reaction wore off after I'd typed it the new way a couple of times. Human beings' ability to adapt is remarkable. That doesn't mean that every thing we adapt to is a good thing. But, indeed, if I'd known this was going to be a problem a month ago, I would have happily put it to discussion and a vote. Unfortunately the bug report came in only a couple of days before the originally- scheduled publication of 9.10.0, and I decided it would be better to live with an imperfect name than deal with the fallout of changing it after it was officially released. I'm not seeing any official releases for 9.10, only release candidates. Apologies if I've missed something obvious here. If I'm right about this not being released yet, it means you still have plenty of time to come up with another name. As much as the thing may seem to be settled from your perspective (dealing with it day to day) the exposure that 9.10 has received to date is only a tiny fraction of what it will be after the official release. I encourage you(pl.) to reconsider your decision to actually release as is. Anyway, now it can hang around and comiserate with resolv.conf. Evidence of prior bad decisions does not provide justification for future bad decisions. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: a note on 9.10.0rc2: eleven, twelve; dig and delv(e)
On 04/25/2014 02:25 PM, Evan Hunt wrote: So, after consultation with the bottoms of one or two bottles, and consideration of several alternative names (including dredge, bore, shovel and -- taking it in a slightly different direction -- groove) we decided to simply send the second 'e' in delve off to wherever the one from creat() went. The tool will now be called delv. (I plan to continue pronouncing it the same way.) First, thanks for being considerate to the Xapian folks. However IMO that's not a good solution. To start with, the delve name was a bit silly, and didn't really trip off the tongue. Your proposed solution is suboptimal from both a product differentiation and a tab completion perspective. If you(collectively) really cannot come up with a better name, why not crowd-source it on the ISC home page? I'm not terribly good at clever names for things like this, but I would vote for 'dq' (as in, DNS query) which has the virtue of not matching anything in the Ubuntu did you mean? database. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Clients Matching Multiple Views
On 04/11/2014 10:59 AM, John Wobus wrote: My understanding has been that two views that are masters for a zone can safely share a zone file if the zone isn't dynamic (e.g. dnsupdate, dnssec auto signing, etc), but that two views of a slave zone shouldn't do that: you could have two different views independently rewriting the same file, a bad thing even if the files are known to be identical. Furthermore, allowing that could conceivably show no problems very much of the time, masking the actual risk. You are correct. Include statements that reference the common data between the zones on the master has been the canonical way to handle this situation since day 1. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Example of classless reverse-lookup zone
On 04/07/2014 02:46 PM, Dimitar Georgievski wrote: Hi, I am trying to configure a subnet (example: 10.1.16.32/27 http://10.1.26.96/27) zone files for internal domains, and have hard times with setting up the reverse lookup zone file. The couple examples I found on the internet didn't help much. Did you find this in your search? https://dougbarton.us/DNS/2317.html If it falls in the category of Didn't help much I'd love to hear suggestions for improvement. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Example of classless reverse-lookup zone
On 04/07/2014 08:14 PM, Dimitar Georgievski wrote: Hi Doug, Thanks, your article really cleared my confusion with the naming and delegation of zones. I did read initially RFC 2317 https://tools.ietf.org/html/rfc2317 when I started working on this task, but I was lost with the use of the / character, and, I realize now, I wasn't using the CNAME records correctly. This time I took your advice and used the first and last octets of the range to create the CNAMEs as well as the name for the reverse zones. It worked from the first attempt. Great news! Glad I could help. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.10.0b1 is now available
On 03/17/2014 12:29 PM, Mathieu Arnold wrote: Hum, so, it will also use pkcs11 for dnssec validation too ? (Sorry if this seems a silly question.) HSMs are typically an auth-only tool, although I suppose that in a super-high-security environment that they could be justified for validation ... it would be interesting to see a requirements doc on what the HSM would need to provide to do that. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.10.0b1 is now available
On 03/17/2014 01:06 PM, Evan Hunt wrote: On Mon, Mar 17, 2014 at 08:41:13PM +0100, Mathieu Arnold wrote: Yes, it was my understanding of how HSM worked. That's why I was trying to build with OpenSSL *and* native PKCS11, to get the DNSSEC validation on one side, and PKCS11 interface for zone signing on the other. I'd advise doing that with two separate BIND instances -- sign using pkcs11 (possibly on a hidden master) and keep that separate from your recursion/validation. Evan, I think that Mathieu understands that from a proper DNS functionality perspective. What he's struggling with is that the way FreeBSD ports are set up they don't really have a flag for This configuration of options will give you an authoritative-only server that you cannot use for general purpose recursion/validation within a specific set of options for the general purpose port. Mathieu, if I may, what I would do in this situation is create a slave port for the HSM compile options, and put some sort of warning (pre-compile, pkg-message, or both) that clearly indicates to the user that this configuration is limited to auth-only. That's the least painful way I can think of to deal with it off hand. You may come up with a more creative solution. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Sporadic but noticable SERVFAILs in specific nodes of an anycast resolving farm running BIND
On 3/8/2014 1:30 PM, sth...@nethelp.no wrote: One mitigation approach is to blackhole the domains using local zones. That�s not much of a mitigation. Not having open resolvers would be mitigation. Not having open resolvers is good - but unfortunately doesn't help against misbehaving clients (e.g. small home routers with DNS proxies open to queries from the WAN side). There is a fairly long list of things that closing open resolvers won't fix, but one wonders how that is relevant? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
On 02/12/2014 10:16 PM, Christoph Moench-Tegeder wrote: ## Doug Barton (do...@dougbarton.us): If you don't have enough random bits on your system to run these simple tests, your /dev/random is seriously underpopulated, and likely a security risk. You should definitely not put BIND in production compiled with the option you mention above. Our build/test environment is not our production environment. Then what's the point of running the tests? If your test environment isn't closely mirroring your production environment you're mostly just wasting time. Further, the ideas about random numbers for practical purposes have shifted a bit. In short, you don't really need high real entropy, but a stream of numbers *unpredictable to the adversary*. Yes, I'm quite familiar with those thoughts, and have some degree of sympathy with them. You will hopefully have noted that I didn't recommend hooking up a hardware based source of high-quality entropy to every name server. What I actually recommended was that Linux systems run a low-impact, freely available piece of software that helps to stir the entropy pool so that /dev/random can produce sufficient PRNG bits without blocking. That's more than adequate for nearly all uses, unless you're actually doing work which requires a high-quality RNG. See: http://www.metzdowd.com/pipermail/cryptography/2014-February/019920.html http://blog.cr.yp.to/20140205-entropy.html http://iang.org/ssl/hard_truths_hard_random_numbers.html Yes, these are all decent posts, and I have no real argument with them based on a casual reading. However none of them contradict the actual advice I gave. In fact, on systems like FreeBSD you never get to see the entropy directly, you only get the output of a PRNG (yarrow in this case), which is periodically reseeded with real entropy. Funny you should mention FreeBSD's Yarrow, as I was peripherally involved in its initial implementation. :) I'm not sure what point you're trying to make by mentioning that you never get to see the 'entropy' directly though. That's not only a feature, it's a fundamental part of the design. Even linux ranodm(4) suggests to use /dev/urandom in most cases, as frequent reads on /dev/random will deplete the entropy pool and make /dev/random unusuable for those who really need it. Yes, that's one of the weaknesses of the Linux model vs. Yarrow (and its successors). It's also why I suggested running haveged. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Monitoring Zonefiletransfer
On 02/18/2014 04:39 PM, Mark Andrews wrote: Only transfer from one AD master. Microsoft AD doesn't maintain consistent serials across the servers. The serials should be monotonically increasing from a individual server. Also try to determine what the primary master is for the zone. Windows DNS does have this concept, but they don't emphasize it since they like people to believe in the fantasy that is lazy replication. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: how to modify the cache
On 02/17/2014 11:37 AM, Kevin Darcy wrote: Ugh, that mixes apples (recursive resolution) and oranges (iterative resolution). Out of curiosity, what bad thing do you think will happen if you mix these two functions? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: bind-9.9.5 regression test error
On 02/12/2014 11:16 AM, Christoph Moench-Tegeder wrote: ## Bruce Dubbs (bruce.du...@gmail.com): I've been trying to run the regression tests for bind-9.9.5 and keep getting lots of timeouts and errors in the system/inline test. I saw the same symptoms when packaging/testing bind-9.9.5. I traced the issue to processes blocking in read() from /dev/random - so adding --with-randomdev=/dev/urandom to configure's arguments made all tests pass. If you don't have enough random bits on your system to run these simple tests, your /dev/random is seriously underpopulated, and likely a security risk. You should definitely not put BIND in production compiled with the option you mention above. For Linux systems haveged is a fairly painless way to populate your entropy pool, which should be fine for BIND. There are of course other more complicated methods as well for higher-security requirements. Doug PS for Mark, When I was maintaining BIND for FreeBSD I always ran the unit tests before I put a new version live. :) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: changing NSEC3 salt
On 02/12/2014 05:17 AM, Chris Thompson wrote: On Feb 11 2014, David Newman wrote: [...] That's interesting. It seems to contradict Lucas' advice to always use '1 0 10' for these [NSEC3] flags, as fewer aren't secure enough and more aren't any more secure. It's difficult to see how that can make sense. Increasing the number of iterations simply gives a linear increase in the computational cost of testing names against NSEC3s (and the same factor in the overheads in authoritative and validating nameservers, of course). I can't speak directly for Michael, but I was the lead technical reviewer for DNSSEC Mastery, so I can tell you from my perspective that the intent was not to provide a thorough treatise on all of the possible ramifications of every possible combination of flags. The intent was to help people get up and running with DNSSEC; with reasonable defaults, and a minimum of fuss. Personally, I am hard pressed to justify setting iterations at a value higher than 10. As many others have pointed out, some quite recently, NSEC3 is not going to save you from zone walking by a determined attacker. Changing the salt often'ish will help, as will doing more than 1 or 2 iterations. But at the end of the day someone who really wants to calculate a rainbow table on your zone can and will do so. Moore's law wipes out a factor of 10 before very long ... Exactly which is IMO another reason that values higher than 10 are not likely to do anything other than increase the costs on validators, and for no good reason. It's not often mentioned, incidentally, that using more iterations increases the probability of a collision. Of course, it's pretty damn small to begin with, so that doesn't really matter. But the algorithm, described in RFC 5155 section 5, could have been better designed from that point of view. Honestly that wasn't a factor in my thinking, but it's interesting info to store away for future use, thanks. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Disabling RPZ for a few clients / views sharing zones
On 02/06/2014 06:27 AM, Chuck Anderson wrote: I was kinda hoping that newer versions of BIND could share zones (with identical zone contents) between views without requiring the messy multiple IP alias setup. You have always been able to do this with include files. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: missing NOTIFY after rndc signing -clear all zone
On 02/06/2014 04:27 AM, Klaus Darilion wrote: Hi! I just noticed that on rndc signing -clear all zone, Bind removes the private RRs, updates the NSEC3 RR, and increases the serial, but it does not send NOTIFYs. I guess this is a bug. I tested bind 9.9.5, with inline-signing of a zone. Does the notify get sent when you reload the zone? ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: classless ptr setup
On 01/20/2014 11:21 AM, Jim Pazarena wrote: Thank you for this. I am familiar with the setup; I suppose that my question was unclear. Can the SAME named.conf handle BOTH the /24 cname assignments AND the /25 in-addr.arpa records. Which sounds like a dumb question, but I thought named may not like it. But I'll set it up and see if named complains (if at all). There's no reason named cannot do it, but the question is why would you want to? It would make sense to split the zone into /25s if you were going to delegate them to your customers, but if you're going to host it all on the same server you get a lot of extra complexity for no real benefit. You may get some useful information at https://dougbarton.us/DNS/2317.html in any case. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: dumping master file: tmp-xxx: open: permission denied
On 01/14/2014 08:14 AM, LuKreme wrote:
so I should change
zone kreme.com { type slave; masters { 75.148.37.67; }; file
slave/kreme.com; };
to
zone kreme.com { type slave; masters { 75.148.37.67; }; file
“/var/named/etc/namedb/slave/kreme.com; };
and that will eliminate the errors?
No. All path names in your configuration file should be relative to the
chroot directory. So /etc/namedb/slave/kreme.com.
You seem to be using FreeBSD. The default named.conf has the
configuration you should start with if you're using the default rc.d
script to start named. Start with that, follow the examples, and only
change things in the default if you're certain you know what the
implications of those changes will be.
Doug
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Generic reasons for recursive performance not to peg CPU?
Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
Thanks for the response, but that's not it. The auth-only responses are generating a lot more traffic than the recursive. Doug On 01/12/2014 05:21 PM, Sten Carlsen wrote: Wild guess: network bandwidth runs out before CPU? Why the difference, I have no clue. On 13/01/14 02.16, Doug Barton wrote: Howdy, Without going into too much detail, doing some performance testing and am seeing a weird result. On the same systems authoritative queries will happily peg the CPU. However when running recursive queries (with a small zone, all data cached before testing) the CPU never gets above 80%. The disk is nearly inactive on both systems, and there is no swapping. Using BIND 9.9.4. Is there perhaps something obvious I'm overlooking here? Any suggestions are welcome. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. Doug On 01/12/2014 06:07 PM, Leonard Mills wrote: Are you allowing long answers when authoritative? Performance measurements with and without additional data in responses is measurable (imo around 12% more network traffic from the replies on auth-only servers). ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Generic reasons for recursive performance not to peg CPU?
On 01/12/2014 07:30 PM, Barry Margolin wrote: In article mailman.2014.1389579103.20661.bind-us...@lists.isc.org, Doug Barton do...@dougbarton.us wrote: Thanks for the response, but you're answering a different question than I asked. :) The question I'm interested in is, Why is the recursive server not pegging the CPU? I'm aware that there will be a difference in qps between auth-only and recursive, but the recursive server seems to be working a lot less hard than the auth server, and I can't figure out why. If the answer isn't already in cache, The answers are all in cache. We're pre-loading the data, and only running queries for data that we're pre-loading. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Updated to bind 9.9.3-P2
On 07/30/2013 02:49 PM, Lawrence K. Chen, P.Eng. wrote: From 9.9.2-P2...I had build 9.9.3, but just as I was about to deploy came the announcement to either go to 9.9.3-P1 or stay with 9.9.2-P2. All the picky messages of this version You had a lot of issues in your message. IMO they make it clear that you can benefit from the better testing provided by the latest version (which is 9.9.3-P2, btw). You will definitely be better off fixing those errors. You can compile the latest version before installing it, and use the named-compilezone and named-checkzone from the newer version before you complete the upgrade process. Regarding your DNSSEC problems, you should really consider the auto-dnssec maintain option, which will prevent the need for your homegrown automated system (which apparently has issues), and is one of the chief benefits of the 9.9 branch. hope this helps, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: permissions for DNSSEC zone signing
On 07/23/2013 04:48 PM, David Newman wrote:
On 7/23/13 3:44 PM, Mark Andrews wrote:
In message 51ef00af.4090...@networktest.com, David Newman writes:
FreeBSD 9.1-RELEASE-p4, BIND 9.9.3-P1 ESV installed from ports
[...]
zone example.org {
type master;
file master/example.org.db;
allow-query { any; };
allow-transfer { xfer; };
key-directory /etc/namedb/managed-keys;
inline-signing yes;
auto-dnssec maintain;
};
There is a valid KSK and ZSK for this zone in managed-keys.
Changing ownership of the master directory results in a complaint when
restarting named that master wants to be owned by root.
Rename the file to dynamic/example.org.db and update named.conf.
The directory dynamic has permissions set up for dynamic master files
which this zone is.
Thanks, Mark!
This is a *static* zone file but signing works as expected if:
1. the zone file is set up in a directory which bind can write to (e.g.,
/var/named/etc/namedb/dynamic, even for static zones); and
2. the zone file's serial number increments. (named did not create a
filename.jnl file until I incremented the zone file's serial number.)
The zone may be static but the auto-dnssec maintain process is
equivalent to the dynamic updates process, so that is the correct
directory.
Doug (who set up the permissions for named in FreeBSD ages ago)
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: bind classless slave from microsoft dns classful SOA?
On 07/12/2013 09:09 AM, Michael Hare wrote: Bind-users; I have been asked to slave a /24 from a microsoft SOA, however, their authority for the /24 is false in that they really only have authority to 192/26. Am I correct in that there is no way to slave said zone [x.y.z.in-addr.arpa] but serve it as a different zone [192/26.x.y.z.in-addr.arpa] without relying on some outside scripts to do the translation? You should probably confer with the admin of the auth server to determine precisely what their version of the zone is (if you haven't already queried the master server to determine it for yourself). Miscommunication about the zone names for 2317 zones are rather common. Unless you've been told by the parent admin that the zone is precisely 192/26.* do not assume that is the case. There are a number of ways to represent 2317 zones. Good luck, Doug https://dougbarton.us/DNS/2317.html ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse Lookups with Forwarders
It's not at all clear from your description what you're trying to accomplish. Particularly it's not clear what you seem to be trying to accomplish with the 2317 delegation for a /24 zone. Can you describe what you're trying to do, and why? It may be easier to help you that way. Please use the actual zone(s) you're working with, as that will also make it easier. Doug https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse Lookups with Forwarders
Ok, simple. The zone you want to forward is 110.252.173.in-addr.arpa.
There is no need to make it more complicated than that.
Good luck,
Doug
On 07/09/2013 12:18 AM, sumsum 2000 wrote:
What I am trying to achieve is this:
I am using BIND9 only for forwarding DNS requests to other DNS Servers.
I want the entire hosts in the
network : 173.252.110.0
with the host range: 173.252.110.1 - 173.252.110.254
with a total 254 addresses to be sent for reverse lookup say to DNS :
8.8.8.8, using a single zone configuration as shown below.
Instead of having a zone file for each and every IP in the network, i
want to use one zone file to have all the hosts in the network
173.252.110.0 to be forwarded to 8.8.8.8.
So when i do a dig -x 173.252.110.27 which is in the range of the
specified network, i want it be forwarded to only 8.8.8.8
When i do dig on a specific address, it gets resolved, but not through
the configured DNS 8.8.8.8, but through default DNS 8.8.4.4. I hope
this explains the situation which i am trying to solve with a zone file
delegation.
I am not sure if the zone file configuration is correct.
==
dig -x 173.252.110.27,
; DiG 9.8.2rc1-RedHat-9.8.2-14.mlos2.mwg -x 173.252.110.27
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 16896
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;27.110.252.173.in-addr.arpa.INPTR
;; ANSWER SECTION:
27.110.252.173.in-addr.arpa. 39INPTR
edge-star-shv-13-frc1.facebook.com
http://edge-star-shv-13-frc1.facebook.com.
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 9 07:11:49 2013
;; MSG SIZE rcvd: 93
named.conf
==
# named.conf
options {
listen-on port 53 { 127.0.0.1; };
listen-on-v6 port 53 { ::1; };
allow-query {localhost;};
recursion yes;
dump-file /var/named/data/cache_dump.db;
statistics-file /var/named/data/named_stats.txt;
memstatistics-file
/var/named/data/named_mem_stats.txt;
directory /var/named;
version none;
max-cache-size 134217728;
forward only;
};
include /etc/rndc.key;
include /etc/named.conf.test;
named.conf.test:
==
view default IN {
max-cache-ttl 600;
max-ncache-ttl 600;
zone . IN {
type forward;
forwarders {8.8.4.4;};
forward only;
};
zone 0/24.110.252.173.in-addr.arpa IN {
type forward;
forwarders {8.8.8.8;};
forward only;
};
};
~
On Tue, Jul 9, 2013 at 12:23 PM, Doug Barton do...@dougbarton.us
mailto:do...@dougbarton.us wrote:
It's not at all clear from your description what you're trying to
accomplish. Particularly it's not clear what you seem to be trying
to accomplish with the 2317 delegation for a /24 zone.
Can you describe what you're trying to do, and why? It may be easier
to help you that way. Please use the actual zone(s) you're working
with, as that will also make it easier.
Doug
https://dougbarton.us/DNS/__bind-users-FAQ.html#RealNames
https://dougbarton.us/DNS/bind-users-FAQ.html#RealNames
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Reverse address entries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/03/2013 07:52 PM, Novosielski, Ryan wrote: | On 07/03/2013 04:39 AM, Matus UHLAR - fantomas wrote: | On 02.07.13 08:53, Daniel McDonald wrote: | I've had trouble with OSI-Soft PI historian without reverse | entries. If there is no reverse, then the PI software would | spend about 30 seconds looking in vain for a DNS answer before | sending a SYN-ACK packet. | | If there is no reverse, the software should get NXDOMAIN answer. in | such case there's nothing to wait for any longer. Are you sure that | was not a case of unreachable servers? | | Something I just stumbled over today (funny that it was during this | topic) is that there is a Cisco ASA issue that makes reverse queries | against anything but in-addr.arpa fail with a timeout. Unfortunately, | some things check IN-ADDR.ARPA (why on earth?) and the lack of that | entry is apparently causing mail delivery problems. It's not clear what distinction you're making. DNS should not be case sensitive, or is that what you're saying the problem is? -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQEcBAEBCAAGBQJR1O0LAAoJEFzGhvEaGryEY2IH/0KZLIRqq9OW7VnALaQmUZoZ OXFsDx3z44KgQtmRve2TJdDWmJXj7gSqnufdti1Ah4fi+ay1nfNBt2Zp4IHvQAKq +/Eatorenr0nEUaRDwG/WEJrx4+2Hj8nvEQUbm1NdCP24d1zKI4Vhb0y01xx2JoN +r80HJXu4AYIA4IU65jAgBZpMMvLtHcWYawqs/f+YKvchoK/Hqw9ELGisHLaAB5k UnXyRPmo4bNP2eisH0CsY8rgVdRcY38rSM11O924cwupFxwTk6Ex7mnPaTUL3iOf 7diG4sAVSZxVJ1NCC+0Am3ATDXjDBnAACEE/XakEAGKOqYcBuUUR9ndzoFvFQXM= =wuuQ -END PGP SIGNATURE- ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: configure syslog prefix
On 07/02/2013 06:34 AM, Sam Wilson wrote: In article mailman.731.1372769988.20661.bind-us...@lists.isc.org, Tony Finch d...@dotat.at wrote: Klaus Darilion klaus.mailingli...@pernau.at wrote: Some software allows to configure the syslog prefix, but I couldn't find that for bind. Rename the named executable. Assuming a Unix-like OS would having multiple links (hard or soft) have the correct effect? Yeah, hard links work of course, but symlinks are slightly preferable here because they make upgrades transparent. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Secondary DNS question...
On 06/26/2013 07:54 AM, Matus UHLAR - fantomas wrote: All very interesting, but I'm afraid at my level of expertise on DNS, I'm not following. If I'm broken, how do I attempt to fix? Someone mentioned that our ns1.starionhost.net was not authoritative. How does one even decide that? As far as I know I haven't had any issues until now... On Jun 26, 2013, at 12:38 AM, Frank Bulk frnk...@iname.com wrote: Do you have a box such as a firewall or load-balancer sitting in front of ns1? On 26.06.13 01:46, SH Development wrote: No, the box is hanging right off the internet on a static IP. there's apparently something wrong about your server or its firewall. The DNS responses (at least for the SOA) come out broken (at least they get invalid here), however I have no idea in which way they are broken. Maybe someone with better DNS knowledge could look at output I have posted before. Available at https://lists.isc.org/pipermail/bind-users/2013-June/090970.html or pcap format at http://test.fantomas.sk/74.87.108.83.dns.pcap Matus, Your previous post definitely seems to indicate a network problem, but I'm not sure what it might be. Meanwhile, I can't seem to find an address record for ns2.starionhost.net in the starionhost.net zone. That's likely at least part of the reliability problem with the starionline.com zone. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Secondary DNS question...
On 06/26/2013 06:50 PM, SH Development wrote: Okay, so I got to it sooner than I thought. So, could you take a look at: starionhost.net stariontech.com starionline.com Any one of those, but they should all be identical now and on some new secondary DNS. The delegations are now identical, and the buddydns servers work fine. However I'm seeing very odd behavior with ns1.starionhost.net. I have a Perl script which uses Net::DNS to check delegations. It almost always times out when attempting to query ns1.starionhost.net, however I can query the same server with dig repeatedly and it doesn't have any problems. But that's not even the weirdest bit. When running the Perl script it sometimes works for starionhost.net, but never works for the other 2. It seems to me that you have something very odd going on with your network. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Secondary DNS question...
Yes, seems fine now. Can you share more information about what it was you turned off? Sounds odd, but the results speak for themselves. Doug On 06/26/2013 09:39 PM, SH Development wrote: Sure could use some direction about where to start looking. I thought I had everything working for the last few years, but now I'm beginning to question how long I've had a problem. The setup is OSX running BIND 9.9.3-P1 on a static IP, no firewall, no router, just straight to the internet. I am also serving Apache and ProFTP on the same box. As a thought, I have had some strange errors in the console log, I think they are coming from a spam solution I am running. I'm shutting it down temporarily. Wonder if it could be corrupting the network. @Doug, could you try your test again now, now that I've shut off the potentially offending program? Jeff ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Secondary DNS question...
Interesting, the pcap that was posted previously showed some odd errors around udp checksums, some showed valid, some showed invalid. With modern NICs it's not uncommon to see them all invalid due to checksum offloading, but the mix of valid and invalid was odd. Doug On 06/26/2013 09:58 PM, SH Development wrote: I am running a demo of the Canit anti-spam software from Roaring Penguin Software as an appliance (ISO) inside of Virtual Box for OSX. I was getting a lot of these errors in the system logs: 6/26/13 11:38:37 PM kernel in_delayed_cksum_offset: ip_len 48640 (190) doesn't match actual length 204 Shutting down Virtual Box stops the erros. So, until I figure out why that is happening, I'll just let everything fail over to my secondary MX spam solution. Very interesting. Now will have to do some research on the error as it pertains to Virtual Box. Jeff On Jun 26, 2013, at 11:53 PM, Doug Barton do...@dougbarton.us wrote: Yes, seems fine now. Can you share more information about what it was you turned off? Sounds odd, but the results speak for themselves. Doug On 06/26/2013 09:39 PM, SH Development wrote: Sure could use some direction about where to start looking. I thought I had everything working for the last few years, but now I'm beginning to question how long I've had a problem. The setup is OSX running BIND 9.9.3-P1 on a static IP, no firewall, no router, just straight to the internet. I am also serving Apache and ProFTP on the same box. As a thought, I have had some strange errors in the console log, I think they are coming from a spam solution I am running. I'm shutting it down temporarily. Wonder if it could be corrupting the network. @Doug, could you try your test again now, now that I've shut off the potentially offending program? Jeff ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: PTR files
Norman, It's virtually certain that the error you're seeing is not related to BIND. You would almost certainly get your problem solved faster by posting on a list related to the web server software that you are using and walking through your complete configuration with them. Good luck, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Thank you Warren!!! - WAS::Re: This list's prefix
Great! Now step 2 is to remove the tag from the subject line before sending mail back to the list. :) On 06/16/2013 02:50 PM, Jerry K wrote: Hello Warren, Thank you so much for this post. Long time procmail user here. I'm only sad I didn't think of this myself first. Its been working great for me on this list, and a couple of others. Jerry On 06/ 5/13 12:46 PM, Warren Kumari wrote: On Jun 5, 2013, at 11:43 AM, Narcis Garcia informat...@actiu.net wrote: It's not the only mailing list where I'm subscribed. Could please the administrator setup a prefix for messages' subject? You have unwittingly walked into a religious argument. If, like me, you really like list prefixes, *and* you use procmial, you can add them yourself: # Add an [6MAN] to messages to the IPv6 Maintenance Working Group \(6man\) ipv6.ietf.org :0 fw * ^List-Id:[ ].*\ipv6\.ietf\.org\ |/bin/sed -e 's/^Subject:[ ]*/Subject: [6MAN] /' Nice to meet another member of the Church of Prefixes. We meet on Saturdays, and wear tricorn hats. Sure, folk laugh at the hats, but at least it draws attention away from our list prefix kink. Warren For example: [bind-u] Thanks. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Rate-Limit Question
On 06/14/2013 09:08 AM, Evan Hunt wrote: (Our usual policy is not to add substantial new features in maintenance releases like 9.9.4; making it a compile-time option that defaults to off is our way of tiptoeing around the rule.) Quite reasonable, and much appreciated. :) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
Ronald, You started this thread a bit off topic, but now you've wandered pretty far off into the rhetorical weeds. So I'm going to respond to you here so that the archives have a little more utility, then I'm going to let you have the last word. On 06/14/2013 02:04 PM, Ronald F. Guilmette wrote: In message 51baa714.9020...@dougbarton.us, Doug Barton do...@dougbarton.us wrote: It's obvious you're frustrated (understandable), and enthusiastic (commendable), but you might want to consider dialing down your rhetoric a bit. Great idea! I have only one small question... Would you be willing to provide me an example to follow? If so, please proceed. So let me be a little more clear. You're engaging in frivolous arguments and borderline ad hominem attacks. Neither is particularly useful, and have only served to obscure whatever utility your proposals may have had. You've had responses from people here who have been working on this problem for years, Yes. On the order of 13 years it appears. Regarding BCP 38, longer than that actually. And yes, progress has been made, but it's still an active problem (for reasons already discussed). Based on recent reports, I am forced to conclude that the people of whom you speak have not actually managed to solve the problem, even given all that time. Your conclusion is correct, even though your premise is faulty. In addition to the aforementioned problem of the costs associated with BCP 38, there is also the problem of new operators coming on to the scene that need education. It's not a problem that can be solved, it requires an ongoing effort under the best of circumstances. and have a deep understanding of it.* Yes. And that deep understanding has apparently not been successful in resolving the problem, I think. Again, false premise, this time with a bonus false conclusion. Understanding what causes a problem is different from being able to wave a magic wand and solve it. Especially with DNS which has a very long tail of deployed software that does not get upgraded. On the other hand, maybe you think that it _has_ been successful in solving the problem. If so, all I can say is that I would hate to see what failure looks like. Nice rhetorical flourish, but again, totally unhelpful. Trying to understand what they're telling you, and its implications, would really help your situation. I understand that you hold the view that it is self-evident that I must not understand something, simply because I do not accept without question the prevailing conventional view of this problem and its possible solutions. I do wonder however if the possibility, however unlikely, ever crossed your mind that perhaps I _do_ actually understand both the problem and the issues, and that I just happen to disagree with the conventional wisdom with respect to these matters, a con- ventional wisdom that, from where I am sitting at least, appears to have so far succeeded in producing absolutely nothing in the way of either a solution or even observable progress over all of the past thirteen years. Pardon my being blunt, but you have a fundamental lack of understanding about the basic facts at hand, therefore it would be hard for me to conclude that you do understand the problem. Regarding your proposed solution, you yourself dramatically revised it within a very short period after your first post, thus it would be reasonable to conclude that the best case scenario is that your understanding of the solution is evolving. Please note, these observations are not meant to be pejorative. As Vernon pointed out you have parachuted in with the one true solution, and you're berating anyone who dares to disagree with you. It would be helpful for you to look at the situation from our perspective. No. You can still get pretty good amplification with 512 byte responses. That is an interesting contention. Is there any evidence of, or even any reasonably reliable report of any DDoS actually being perpetrated IN PRACTIC E using strictly 512 byte packets? You're asking the wrong question. Attackers don't go out of their way to find open resolvers that they are sure will return 4k packets. That also is an interesting contention. May I ask what the factual basis was for your conclusion here? The overwhelming collected evidence of how botnets work, and how the attackers use them would be a good start. I don't follow the topic in depth, but I do try to keep up to speed on the highlights. You should probably spend some time learning about the details yourself. It's not my job to do your homework for you. :) And yes, I understand that you feel (erroneously) that this is an appeal to authority fallacy. However there is a vast difference between it's true because I say so, and, Go do your own homework, because the facts exist to support that what I'm saying is true. It's probably also worth noting that if your attitude was a little
Re: DNS Amplification Attacks... and a trivial proposal
On 06/14/2013 05:13 PM, Vernon Schryver wrote: From: Doug Barton do...@dougbarton.us is that (like RRL) your proposal relies on people updating their software. RRL needs only authority and open recursive servers to be updated. The vast majority of DNS installations are closed recursive and stubb servers that do not need RRL. (A case could be made for RRL on a minority of private recursive servers.) You're right of course, but unfortunately at least where open resolvers are concerned the same people who operate open resolvers are also those least likely to know what RRL is, or why it's needed; and are also least likely to actually upgrade old software. So a statistically significant percentage of the long tail problem is going to apply to those who would provide the most benefit from making the change. I could therefore make a pretty strong case that RRL should be on by default, but I realize that's incredibly unlikely to fly. :) Other ideas that I like such as DNS cookies would need more widespread changes, which makes enthusiasm for them taxing. Yeah, that's unfortunate since if it's a good idea it's worth implementing no matter how long it takes to be beneficial. The time will pass either way. RRL is actually useful for DDOS attacks against the authoritative server itself. There are likely other reasons, but those are the most obvious (to me anyway). That's in the RRL sales story that I've been flogging since before the first version of the RRL patch, but so far it has been only incidentally true. Some DNS server operators have reported drastic reductions in network and CPU load during attacks thanks to RRL, but they were not the intended victims of the attacks. Personally I've never understood why RRL wasn't already baked in. The only way a legitimate client could send the same query over and over in a short period of time (intentionally being vague on both terms) is that it is broken. We did the smart thing to solve that problem on the iterative side 10 years ago, I don't know why it's taken so long to solve the auth side. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
On 06/13/2013 02:01 PM, Ronald F. Guilmette wrote: The entire problem is fundamentally a result of the introduction of EDNS0. Wwouldn't you agree? No. You can still get pretty good amplification with 512 byte responses. There are 2 causes of this problem, lack of BCP 38, and improperly secured (read, open) resolvers. The first requires operator education, and in a non-trivial number of cases requires operators to act against their own interests. Thus, the problem remains unsolved 13 years later. The latter problem also requires operator education, but is more likely to be solvable. There is no quick fix. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DNS Amplification Attacks... and a trivial proposal
Ronald, It's obvious you're frustrated (understandable), and enthusiastic (commendable), but you might want to consider dialing down your rhetoric a bit. You've had responses from people here who have been working on this problem for years, and have a deep understanding of it.* Trying to understand what they're telling you, and its implications, would really help your situation. More below. * Note, I'm not including myself in that category. I know a bit more than the average person, but I'm not an expert. On 06/13/2013 06:57 PM, Ronald F. Guilmette wrote: In message 51ba355b.10...@dougbarton.us, Doug Barton do...@dougbarton.us wrote: No. You can still get pretty good amplification with 512 byte responses. That is an interesting contention. Is there any evidence of, or even any reasonably reliable report of any DDoS actually being perpetrated IN PRACTICE using strictly 512 byte packets? You're asking the wrong question. Attackers don't go out of their way to find open resolvers that they are sure will return 4k packets. They blast out to all the ones that they know, and take the amplification that they can get. 50 - 500 is still a pretty good amplification rate. The important point being (as others have made to you) that this is not an EDNS0 issue. It's also worth noting that I realize this wasn't the main point you were trying to make, but it will probably be helpful for you to get your facts straight. If that's actually a real problem, then I am forced to assume that there must have been numerous reliable reports of successful and devastating DNS reflection DDoS attacks which pre-dated the widespread adoption of EDNS0. Again, you're making the wrong argument. As others have pointed out to you, DNS amplification is just the attack du jour. There is evidence at the moment that the kiddies are already moving to chargen since we seem to be making some progress on open resolvers, and they want to keep their options open. There is no quick fix. I will settle for a slow one. Then you really want to learn more about response rate limiting, which already exists, and is in the process of being adopted into the major flavors of authoritative DNS software. That will help a lot with DNS amplification, but the real answer is still going to be BCP 38, with all of its attendant thorns. I am not persuaded that we have even really begun in ernest a process that is likely to lead to that result. Almost everybody, even 13 years later, is still hoping for, and praying for, some utterly cost-free and pain-free solution to drop down out of the sky like mana from heaven. Again, you need to become more familiar with the efforts that have been ongoing for years. Mark also made an excellent point about legislation for BCP 38 being an unfortunate necessity at this point. For a variety of reasons there are costs associated with implementing BCP 38, costs which a non-zero number of operators have chosen not to pay. Adding legislative penalties/incentives that will make implementing it less costly than not is pretty much the only untried tool we have left. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Serving up two domains
Jason, What you're saying here doesn't make sense, so some more details are needed. On 06/11/2013 08:54 PM, Jason Hellenthal wrote: I have a domain or two that I'm serving up and have traffic from some mobile devices and a few pieces of software that also try to resolve to the hostname.tld instead of what normally would be expected to be hostname.domain.tld. Is what you wrote above what you meant to write? If so that's very surprising. Can you give some more details? Are these private zones, or are you seeing this traffic from the Internet? Is there a search list involved? If so, and tld is listed before domain.tld that would make sense, and it should be fixed there. Not really concerned with why but rather would just like to allow them to resolve to the same address as the .domain.tld. If you really are seeing traffic trying to resolve hostname.tld, you probably need to fix the root problem rather than trying to support the bad behavior. hth, Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: any requests
On 06/05/2013 11:33 AM, Tony Finch wrote: I believe the ANY hack on mail servers was a Sendmailism 20ish years ago. s/Send/q/ ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Negative zones; NXDOMAIN responses
On 05/21/2013 12:39 AM, Phil Mayers wrote:
On 05/21/2013 08:23 AM, Matus UHLAR - fantomas wrote:
On 21.05.13 11:03, Mark Andrews wrote:
The simplest solution is to slave the root zone and
turn off notify to so you don't spam the official
root servers. 192.5.5.241 is f.root-servers.net.
zone . IN {
type slave;
file slave/root;
masters { 192.5.5.241; };
notify no;
};
I thought this is not oficially recommended for ordinary users to prevent
root servers from being overloaded (transfers use much more resources
than
ordinary lookups). Has this changed?
ICANN run a specifc AXFR service for various infrastructure zones:
http://dns.icann.org/services/axfr/
...which IIRC some configs for root-slaving (FreeBSD?) use by default.
It's not used by default, but it is in the config, commented out.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Problem query (SERVFAIL)
No problem here from 2 different sites. Seems to be a problem between your resolving name server and their authorities: ;; AUTHORITY SECTION: pointhq.com.3190IN NS dns6.pointhq.com. pointhq.com.3190IN NS dns7.pointhq.com. ;; ADDITIONAL SECTION: dns6.pointhq.com. 235 IN A 91.109.245.139 dns7.pointhq.com. 235 IN A 37.123.115.172 hope this helps, Doug On 05/17/2013 04:02 PM, budsz wrote: Hi folks, I've some problem with query serveral site, I use BIND 9.6.-ESV-R7-P2 $ host dns1.pointhq.com http://dns1.pointhq.com ;; connection timed out; no servers could be reached $ tail /var/log/named.log 18-May-2013 05:58:09.490 client 127.0.0.1#55351: view internal: query failed (SERVFAIL) for dns1.pointhq.com/IN/A http://dns1.pointhq.com/IN/A at /usr/src/usr.sbin/named/../../contrib/bind9/bin/named/query.c:4655 But if i use Google DNS: $ host dns1.pointhq.com http://dns1.pointhq.com ;; connection timed out; no servers could be reached budsz:~$ host dns1.pointhq.com http://dns1.pointhq.com 8.8.8.8 Using domain server: Name: 8.8.8.8 Address: 8.8.8.8#53 Aliases: dns1.pointhq.com http://dns1.pointhq.com has address 109.233.112.63 Can you give me some clue to fix this problem - Thank you. -- budsz ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Mailing list reply-to setting
Seriously, can we stop discussing this now? If you need subject line tags, or your mail client doesn't properly know how to respond only to the list, or whatever -- please go work that out on your own. The majority of users on the list don't want or need these things, and many of us find things like subject line tags a repulsive waste of screen real estate. I normally stay out of these discussions, but this message, I use mail a certain way, so everyone else should have to put up with the things I need to accommodate my way of working was just too much. TRY filtering your mail into proper folders ... do it for a week, a month, whatever. If your mail client doesn't notify you when mail gets put into a folder, get a better mail client. Once you try doing it that way for a while chances are near 100% that you will like it much better. Doug PS, you kids get off my lawn! On 05/09/2013 03:43 PM, Sten Carlsen wrote: This is also the way I use mail, so +1. On 09/05/13 23:02, Carlos M. martinez wrote: My mail setup is as limited as my eyesight. As I mentioned, I have emails in my inbox and filter afterwards in order to keep mbox size at reasonable levels. In this way I don't forget to check this or that folder. While on inbox I filter by looking at the tags. Works really well and I know quite a few people who do the same. I counted and I'm subscribed to over 50 mailing lists and this is the only one which does not tag the subject. Probably you've discussed this in the past (I'm a rather new subscriber), so I apologize for bringing up a dead horse. regards, Carlos On 5/8/13 10:53 PM, Michael McNally wrote: On 5/8/13 9:43 AM, Carlos M. martinez wrote: Agreed, but, subject tagging is very useful for those who prefer to have things hit your inbox first, before archiving. And there seems to be a lot more agreement on the tagging issue than on the reply to. Unless your mail setup is extremely restricted in what it can filter on, you have several choices of header which can be used by an automated filter to detect and classify appropriately according to list. Personally I have procmail file bind-users traffic based on the List-Id: header, but I realize you may be in a different environment with different tools available.) List-Id: BIND Users Mailing List bind-users.lists.isc.org Michael McNally ISC Support ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Classless PTR query issue
On 05/07/2013 01:50 PM, Matus UHLAR - fantomas wrote: On 07.05.13 11:06, Michael Varre wrote: So interestingly they did give me their setup and this is their response, and my warm and fuzzy feeling continues to go out the window: They use SimpleDNS Record Name: 65.246.59.108.in-addr.arpa DNS Server (FQDN): dns1.kishmish.com. TTL: 1 Hour I'd imagine this is wrong since 65 is my starting IP rather than my network IP, which is 64. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. https://dougbarton.us/DNS/2317.html ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: DDOS attack Bind 9.9 - P2
On 05/03/2013 11:44 AM, rohan.he...@cwjamaica.com wrote: What if both authoritative and recursive are running on the same server That's a simple answer, don't do that. Doug (ever) ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ISC Courses
Ted made some really good points. It's also worth pointing out that overhead, like renting the facility to teach the classes in, food, travel expenses for the trainers to get to the site, course materials, insurance, etc. often run into the 'many hundreds' of dollars per student before the first word is spoken in class. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: ANNOUNCEMENT: New BIND versions are available.
Michael, Thanks for this announcement, and a welcome change. Given the following: 1. bind-announce is very low volume, and carries only critical information that the community needs to know 2. Currently all posts to bind-announce are duplicated to the other lists Wouldn't it make sense to 'sort -u' the membership of the 3 lists, call that the new bind-announce, and give people a 1-time message about how to unsubscribe if they don't want to be there? I applaud ISC's desire to not subscribe people to lists willy-nilly without their permission, but given the specific circumstances here you may have over-engineered the solution a bit. :) Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Simple question about zone and CNAME
On 04/08/2013 06:54 AM, Sam Wilson wrote: In article mailman.61.1365232319.20661.bind-us...@lists.isc.org, Doug Barton do...@dougbarton.us wrote: On 04/05/2013 11:53 PM, Novosielski, Ryan wrote: | It is funny you should mention that... my questions about using views | to create a situation where one single record is different happens to | be exactly for this reason. The Active Directory administrators were | saying that not having umdnj.edu point to an Active Directory server | was bothering the AD servers in some fashion. The solution we're going | to test is telling the AD servers that umdnj.edu are them, but telling | everyone else on the planet that it's www. We think this will do it, | but haven't tested yet. Much better to put the AD stuff in its own subdomain, like ad.umdnj.edu. AD DNS is only really happy when it runs the whole show for its home domain. It's possible to do otherwise, but really painful and fragile. We've been running our main domain with the underscore domains delegated to AD for well over a decade and it's been neither painful nor fragile, You apparently missed the context of the response. :) I didn't say impossible, and I've set it up the way you describe in the past. But it assumes both an initial and ongoing level of clue that is not always available. Whereas, put all the AD stuff in its own subdomain is both pain-less, and has other advantages. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Simple question about zone and CNAME
On 04/08/2013 06:42 AM, Sam Wilson wrote: In article mailman.49.1365191296.20661.bind-us...@lists.isc.org, wbr...@e1b.org wrote: Incidentally, we have just been asked for an A record for cam.ac.uk to duplicate www.cam.ac.uk because, and I quote, all the publicity material sent out by the nominator [for an award for the web site] gave the URL as http://cam.ac.uk/ and this has been retweeted around. Yes, sadly I've lost that technical battle with marketing several places now. And then there's theses folks: http://no-www.org/ Is co-opting high-level name space for a single protocol a modern-day landgrab? Is holding on to the antiquated notion that every protocol needs a unique hostname charmingly anachronistic, or just plain obstructionist? (See what I did there?) For bonus points, list the number of services running on your typical server configuration, and then tell us how many of them have their own hostnames. Start with dns, ssh, and ntp. Then describe how you differentiate your SSL web service from your plain text version. Bonus points if you're running ipp, nfs, or kerberos with their own unique hostnames on the same system. The point being that the world moved on, and putting websites on hostnames that don't start with www. is the common case now. Can we save our energy for something more productive? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward First on Master Zone (bypass SOA)
On 04/01/2013 11:46 AM, Kevin Darcy wrote: On 3/29/2013 12:09 AM, Doug Barton wrote: On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote: My organization is evaluating the use of split-view DNS in our environment. Simple ... don't do it. It's almost never the right answer, and as you're learning carries with it more administrative overhead than the problems it's designed to solve. Much better to spend the time carefully considering what your goals are, and finding other ways to reach them. And your alternative is what? Run the external version of the namespace on a completely separate infrastructure from the internal version? No, my point was don't do 2 versions. Somewhere in the last 10 years (roughly corresponding to the popularity of NAT) it became baked in to a large segment of the DNS operator community that having internal and external views of the same zones was not only necessary, it was the only right way to do things. In my experience the number of times that this is the right answer are very few and far between. Looking at the actual problems that need solving without the prejudice that multiple views are necessary (or even correct) often leads to better solutions. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations?
On 04/02/2013 12:47 AM, Martin T wrote: Is NS record pointing to some other name server needed in case of classless IN-ADDR.ARPA delegations? What happens if one does not specify this? It's very common for the parent name server(s) to slave the 2317 zone so that it can answer directly. It's also common for the child to slave the parent zone so that it can answer internal queries directly. And of course as Mark pointed out name servers 1 is basic DNS. You may find this useful as well: https://dougbarton.us/DNS/2317.html Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward First on Master Zone (bypass SOA)
On 04/03/2013 05:30 PM, Kevin Darcy wrote: It's still not clear to me what you think is the right way to do it. I'm not saying that there is only one right way. I'm saying you first have to answer the question, What might we want to achieve by having different answers internally vs. externally for the same label? Sometimes multiple views are actually necessary to accomplish business goals. IME however it's become so baked in that we need multiple views that the right questions are never asked. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Forward First on Master Zone (bypass SOA)
On 03/28/2013 12:28 PM, Ben-Eliezer, Tal (ITS) wrote: My organization is evaluating the use of split-view DNS in our environment. Simple ... don't do it. It's almost never the right answer, and as you're learning carries with it more administrative overhead than the problems it's designed to solve. Much better to spend the time carefully considering what your goals are, and finding other ways to reach them. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: querying TLD nameservers - limitations
There is no need to post to both the mailing list and the news group. You can safely post only to the list, and it will be sent to the group for you. Rather than us guessing what it is you're trying to accomplish, can you say a little more about it? I can think of some legitimate reasons why a monitoring system may need to query TLD name servers, but before we can answer your question properly we really need to know a bit more information. Doug On 03/24/2013 04:55 PM, blrmaani wrote: I am developing a monitoring script for internal use and this requires extensive querying of TLD nameservers (a .. m).tld servers. Questions: 1. Are there any rate limitations imposed by TLD servers i.e these servers allows only certain number of DNS queries per IP per second? 2. Are there other limitations I should be aware of while developing my script? Any experience among this group members in developing these kind of scripts using Net::DNS::Resolver perl module? Thanks! Blr ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Overriding Included Zone File Entries
On 03/05/2013 11:08 AM, Pat Suwalski wrote: Hello everyone, I have a question about using the $INCLUDE directive in my zone files. We run DNS for a moderately large number of domains, largely pointing at the same servers. So, I'd really like to have the following setup: db.common.inc: mail IN A n.n.n.n mail2 IN A n.n.n.n www IN A n.n.n.n @ IN TXT v=spf1... And then have individual zone files be able to override the various values: db.special.domain.com: $INCLUDE db.common.inc www IN A x.x.x.x You already have the answer that you can't do that. What you could do is create separate $INCLUDE files that contain the different elements that may need to be overridden. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND roadmap
On 02/28/2013 02:37 AM, Shane Kerr wrote: Note though that as far as I can tell, few people actually use the ESV software. Please let us know if the ESV policy works for you! You probably want to have some discussions with OS vendors that embed BIND to familiarize yourself with how many people are using ESV versions from that channel. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Problems with resolving a local tld
On 02/28/2013 09:34 AM, Robert Moskowitz wrote: Only for my internal tld does the lookup fail. Are you distributing the trust anchor for htt to all of the servers that are doing validation? Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling lame server logging
You want to set up your resolver on your mail server to forward to your main resolver, using the forward only option. This will allow your mail server resolver to benefit from the cache already populated on your main resolver, while still maintaining the value of caching the answers itself locally. Your goal of reducing the number of error messages in your main resolver's logs so that you can better chase down real problems is a good one. However you eventually reach a point of diminishing return where further reducing the errors ends up in you missing actual new problems. Or, put another way, slogging through noisy logs is part of the job, given the horrific state of most DNS out there. Welcome to the club. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: disabling lame server logging
On 02/26/2013 10:38 AM, Robert Moskowitz wrote: I would like a scalpel for lame logging, but probably would not discover any actionable data. There is a logging category for lame-servers. It's in the ARM. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Most specific match on PTR records
On 02/22/2013 01:26 AM, Nikita Koshikov wrote: On Thu, Feb 21, 2013 at 10:47 PM, Doug Barton do...@dougbarton.us mailto:do...@dougbarton.us wrote: Can you slave the 11.2.10.in-addr.arpa zone instead of forwarding? That would be easier, and avoid the pitfalls already described by others. I can't, 10.2.11.0/24 http://10.2.11.0/24 network - is windows dhcp with dynamic dns registers. I'm not sure why that would mean that you cannot slave the zone. Are you concerned about too-frequent updates? Mark was right, a delegation in the zone file is the simplest solution. I suggested slaving the zone because it gives you better performance locally, but if it isn't possible, Mark's solution is just fine. Doug ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Most specific match on PTR records
On 02/21/2013 10:20 AM, Nikita Koshikov wrote:
Hello list,
I'm trying to cut /24 network from the scope of /8 network, here is
example:
zone 11.2.10.in-addr.arpa {
type forward;
forwarders { 192.168.1.23; 192.168.1.24; };
};
zone 10.in-addr.arpa {
type master;
file master/int/10.in-addr.arpa;
};
10.in-addr.arpa is just a file that returns NXDOMAIN for any 10.0.0.0/8
http://10.0.0.0/8 ip address. But I need to forward requests for
10.2.11.0/24 http://10.2.11.0/24 net to other dns servers and the
above config not working.
Can you slave the 11.2.10.in-addr.arpa zone instead of forwarding? That
would be easier, and avoid the pitfalls already described by others.
Doug
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
