Re: Bind > 9.12 Will Not Start On FreeBSD

2019-04-28 Thread Doug Barton

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

2019-01-01 Thread Doug Barton
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"

2018-08-26 Thread Doug Barton

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

2018-08-21 Thread Doug Barton

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)

2018-08-20 Thread Doug Barton

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

2018-08-20 Thread Doug Barton

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)

2018-08-19 Thread Doug Barton
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)

2018-08-19 Thread Doug Barton

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

2018-08-18 Thread Doug Barton

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

2018-08-18 Thread Doug Barton

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

2018-08-15 Thread Doug Barton

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

2016-01-28 Thread Doug Barton

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

2016-01-22 Thread Doug Barton

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

2016-01-15 Thread Doug Barton

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?

2015-06-03 Thread Doug Barton

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

2014-10-24 Thread Doug Barton
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

2014-10-24 Thread Doug Barton

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

2014-10-24 Thread Doug Barton

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

2014-10-20 Thread Doug Barton

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

2014-10-07 Thread Doug Barton

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

2014-10-01 Thread Doug Barton

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

2014-09-27 Thread Doug Barton

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

2014-09-15 Thread Doug Barton

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?

2014-09-12 Thread Doug Barton

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'

2014-08-28 Thread Doug Barton

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'

2014-08-27 Thread Doug Barton

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'

2014-08-27 Thread Doug Barton

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'

2014-08-26 Thread Doug Barton

-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

2014-08-23 Thread Doug Barton
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?

2014-08-04 Thread Doug Barton

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?

2014-07-31 Thread Doug Barton
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: Public facing authoritative NS all masters

2014-07-12 Thread Doug Barton
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: Using a DynDNS hostname in master-statement for a bind slave?

2014-06-27 Thread Doug Barton

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

2014-06-10 Thread Doug Barton

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

2014-06-06 Thread Doug Barton
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

2014-06-03 Thread Doug Barton
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

2014-06-01 Thread Doug Barton

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?

2014-06-01 Thread Doug Barton

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

2014-05-11 Thread Doug Barton

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)

2014-04-30 Thread Doug Barton

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)

2014-04-25 Thread Doug Barton

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

2014-04-11 Thread Doug Barton

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

2014-04-07 Thread Doug Barton

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

2014-04-07 Thread Doug Barton

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

2014-03-17 Thread Doug Barton

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

2014-03-17 Thread Doug Barton

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

2014-03-09 Thread Doug Barton

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

2014-02-23 Thread Doug Barton

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

2014-02-18 Thread Doug Barton

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

2014-02-17 Thread Doug Barton

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

2014-02-12 Thread Doug Barton

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

2014-02-12 Thread Doug Barton

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

2014-02-06 Thread Doug Barton

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

2014-02-06 Thread Doug Barton

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

2014-01-20 Thread Doug Barton

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

2014-01-14 Thread Doug Barton

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?

2014-01-12 Thread Doug Barton

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?

2014-01-12 Thread Doug Barton
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?

2014-01-12 Thread Doug Barton
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?

2014-01-12 Thread Doug Barton

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

2013-07-30 Thread Doug Barton

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

2013-07-23 Thread Doug Barton

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?

2013-07-14 Thread Doug Barton

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

2013-07-09 Thread Doug Barton
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

2013-07-09 Thread Doug Barton
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

2013-07-03 Thread Doug Barton

-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

2013-07-02 Thread Doug Barton

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

2013-06-26 Thread Doug Barton

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

2013-06-26 Thread Doug Barton

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

2013-06-26 Thread Doug Barton
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...

2013-06-26 Thread Doug Barton
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

2013-06-17 Thread Doug Barton

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

2013-06-16 Thread Doug Barton
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

2013-06-14 Thread Doug Barton

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

2013-06-14 Thread Doug Barton

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

2013-06-14 Thread Doug Barton

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

2013-06-13 Thread Doug Barton

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

2013-06-13 Thread Doug Barton

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

2013-06-11 Thread Doug Barton

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

2013-06-05 Thread Doug Barton

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

2013-05-21 Thread Doug Barton

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)

2013-05-17 Thread Doug Barton
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

2013-05-09 Thread Doug Barton

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

2013-05-07 Thread Doug Barton

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

2013-05-03 Thread Doug Barton

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

2013-04-26 Thread Doug Barton
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.

2013-04-12 Thread Doug Barton

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

2013-04-08 Thread Doug Barton

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

2013-04-08 Thread Doug Barton

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)

2013-04-03 Thread Doug Barton

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?

2013-04-03 Thread Doug Barton

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)

2013-04-03 Thread Doug Barton

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)

2013-03-28 Thread Doug Barton

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

2013-03-25 Thread Doug Barton
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

2013-03-05 Thread Doug Barton

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

2013-02-28 Thread Doug Barton

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

2013-02-28 Thread Doug Barton

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

2013-02-26 Thread Doug Barton
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

2013-02-26 Thread Doug Barton

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

2013-02-22 Thread Doug Barton

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


  1   2   3   4   >