Re: libbind error

[Stacey Jonathan Marshall]

On 12/11/2010 22:46, Jack Tavares wrote:


I believe I found a bug in the libbind code.

Is this the correct place to report that?

Thanks


Jack,

According to http://www.isc.org/software/libbind (found via search):

   Bug reports may be sent to libbind-b...@isc.org
   . The public mailing list for
   discussing libbind development is bind-workers
   .

I've not seen much happen in the libbind space mind so you may want to 
cross post here as well.


Stace
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: error (broken trust chain) resolving

[Brian J . Murrell]

Brian J. Murrell  interlinx.bc.ca> writes:
> 
> Casey Deccio  deccio.net> writes:
> >  
> > Do you get a NOERROR response with the AD bit set?
> 
> Yup:
> ...

Was any of that information I posted in the previous message useful?  If not,
I'd be happy to gather some more.


___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC with 9.7.2-P2

[David Forrest]

On Fri, 12 Nov 2010, Phil Mayers wrote:


On 12/11/10 12:49, David Forrest wrote:


and, on checking named.conf, I found the entry for br. as:
trusted-keys {
"br." 257 3 5
"AwEAAdDoVnG9CyHbPUL2rTnE22uN66gQCrUW5W0NTXJBNmpZXP27w7PMNpyw3XCFQWP/XsT0pdzeEGJ400kdbbPqXr2lnmEtWMjj3Z/ejR8mZbJ/6OWJQ0k/2YOyo6Tiab1NGbGfs513y6dy1hOFpz+peZzGsCmcaCsTAv+DP/wmm+hNx94QqhVx0bmFUiCVUFKU3TS1GP415eykXvYDjNpy6AM=";
};



This key is invalid for "br".

Since you're running 9.7.2, don't do this. "br" is signed by the root; 
instead, defined a "managed-keys" statement for "." and let the root DNSSEC 
take care of it.


See:

http://www.isc.org/community/blog/201007/using-root-dnssec-key-bind-9-resolvers


That fixed it! Thanks, Phil.

Upon restarting I got a starting log message:
reading built-in trusted keys from file '/etc/bind.keys'

and stopped it with rndc to rename that file as it seemed to be a 
lookaside key for dlv.  After a restart of named I got only a 
named[25911]: set up managed keys zone for view external, file 
'3c4623849a49a53911c4a3e48d8cead8a1858960bccdea7a1b978d73ec2f06d7.mkeys' 
message and it seems to be working fine now.


Although I am using Fedora 11, I did disable the inits for the 
distribution scripts and start named from a root cron crontab

(* * * * * /usr/bin/pgrep named >/dev/null ||  (ulimit -u 4096; 
/usr/local/sbin/named -u named)
as I have all the 9.7.2-P2 stuff in /usr/local/sbin while F11 used 
/usr/sbin.  My troubles were of my own making, not F11's, although I do 
not remember creating the '/etc/bind.keys' file.


Thanks again, this is a very helpful list.

Dave


--
David Forrest   e-mail   drf @ maplepark.com
Maple Park Development Corporation  http://xen.maplepark.com
St. Louis, Missouri(Sent by ALPINE 2.01 FEDORA 11 LINUX)
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC with 9.7.2-P2

[Adam Tkac]

On Sat, Nov 13, 2010 at 11:35:57AM +1100, Mark Andrews wrote:
> 
> In message <4cdd6467.9050...@imperial.ac.uk>, Phil Mayers writes:
> > On 12/11/10 15:45, Lightner, Jeff wrote:
> > 
> > > For Production (RPM based system) you should use RHEL or CentOS which
> > > has a much longer life cycle.  (Speaking of which, RHEL6 was just put in
> > 
> > I don't agree with your line of reasoning. RHEL may have longer update 
> > cycles, but there's no guarantee a particular RHEL install will be 
> > applying updates in real-time, so the keys in the dnssec-conf package 
> > may still get out of date, or a RHEL install may run after it's 5-year 
> > update cycle ends.
> > 
> > I think the dnssec-conf package should have had a nightly cron job to 
> > refresh these keys, and it was a mistake to deploy without such.
> > 
> > Just my opinion of course.
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> I use the following scripts (update-trusted-keys and commit-trusted-keys)
> to manage my trust anchors.  I run update-trusted-keys nightly from cron
> and manually update when I get email that there has been a change.
> 
> update-trusted-keys replaces the trust anchor when the tld gets a DS
> record added to the root zone.  With no arguements it just updates the
> current list of zones listed is /etc/trusted-keys.

Isn't sufficient to configure the root trust anchor inside "managed-keys {};"
statement? If I understand correctly the key should be automatically
updated, shouldn't it?

Regards, Adam

-- 
Adam Tkac, Red Hat, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 15, 2010 at 3:36 AM, Brian J. Murrell  wrote:
>
> Was any of that information I posted in the previous message useful?  If not,
> I'd be happy to gather some more.
>

Well, I'm curious as to why you're not getting the AD bit set for the
negative proof of existence for bondedsender.org/DS.  What happens if
you disable DLV and run the DS query again?

Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 15, 2010 at 6:31 AM, Casey Deccio  wrote:
> On Mon, Nov 15, 2010 at 3:36 AM, Brian J. Murrell  
> wrote:
>>
>> Was any of that information I posted in the previous message useful?  If not,
>> I'd be happy to gather some more.
>>
>
> Well, I'm curious as to why you're not getting the AD bit set for the
> negative proof of existence for bondedsender.org/DS.  What happens if
> you disable DLV and run the DS query again?

I just realized that your debugging output involving DLV lookups is
related to a different query and shouldn't affect the result of
bondedsender.org/DS.  However, querying the original TXT RR with DLV
disabled might also give more insight.

Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: one remaining error message in named log startup messages

[Tony Finch]

On Fri, 12 Nov 2010, Stewart Dean wrote:

>   "adjusted limit on open files from 1024 to 1048576"

> The named service works just fine.

> which says to add a line:
>   named soft nofile 4096
> to /etc/security/limits.conf
>
> Did that, then tried both restarting named and rebooting the machine, but it
> doesn't make a difference.

Try upping it from 4096 to 1048576, since that is what BIND wants the
limit to be.

Tony.
-- 
f.anthony.n.finchhttp://dotat.at/
HUMBER THAMES DOVER WIGHT PORTLAND: NORTH BACKING WEST OR NORTHWEST, 5 TO 7,
DECREASING 4 OR 5, OCCASIONALLY 6 LATER IN HUMBER AND THAMES. MODERATE OR
ROUGH. RAIN THEN FAIR. GOOD.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

RE: how to see ALL NS records in a zone file with dig

[M. Meadows]

Jay,
 
 I see what you're saying. I was missing the difference in the feedback 
from the recurse / no recurse options. Makes sense. Thanks very much for the 
excellent help!
 
Marty

 
> Date: Mon, 15 Nov 2010 10:57:40 -0600
> From: jay-f...@uiowa.edu
> To: sun-g...@live.com
> Subject: RE: how to see ALL NS records in a zone file with dig
> 
> On Mon, 15 Nov 2010, M. Meadows wrote:
> > Thanks for the reply Jay. Does that work for you? It doesn't work for me.
> 
> Yep, it works for me. Here's an example for zone healthcare.uiowa.edu with
> the query answered by an authoritative server for the parent (uiowa.edu).
> 
> The query with recursion disabled shows dns-cb returning its view as the
> parent above the uiowa.edu -> healthcare.uiowa.edu delegation cut:
> 
> jnf...@seatpost: dig +norec +nostats -t ns healthcare.uiowa.edu 
> @dns-cb.uiowa.edu
> 
> ; <<>> DiG 9.7.1-P2 <<>> +norec +nostats -t ns healthcare.uiowa.edu 
> @dns-cb.uiowa.edu
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31651
> ;; flags: qr ra; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
> 
> ;; QUESTION SECTION:
> ;healthcare.uiowa.edu. IN NS
> 
> ;; AUTHORITY SECTION:
> healthcare.uiowa.edu. 86400 IN NS dns1.uihealthcare.com.
> healthcare.uiowa.edu. 86400 IN NS dns2.uihealthcare.com.
> 
> ;; ADDITIONAL SECTION:
> dns1.uihealthcare.com. 2305 IN A 129.255.116.10
> dns2.uihealthcare.com. 1178 IN A 129.255.116.11
> 
> It returns no answers, just a referral to what it's been told the servers are
> for healthcare.uiowa.edu.
> 
> 
> The query with recursion enabled shows dns-cb returning the information it
> has cached for healthcare.uiowa.edu:
> 
> jnf...@seatpost: dig +nostats -t ns healthcare.uiowa.edu @dns-cb.uiowa.edu
> 
> ; <<>> DiG 9.7.1-P2 <<>> +nostats -t ns healthcare.uiowa.edu @dns-cb.uiowa.edu
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 29488
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 0
> 
> ;; QUESTION SECTION:
> ;healthcare.uiowa.edu. IN NS
> 
> ;; ANSWER SECTION:
> healthcare.uiowa.edu. 3283 IN NS hc-dc3.healthcare.uiowa.edu.
> healthcare.uiowa.edu. 3283 IN NS hc-dc4.healthcare.uiowa.edu.
> healthcare.uiowa.edu. 3283 IN NS hc-dc5.healthcare.uiowa.edu.
> healthcare.uiowa.edu. 3283 IN NS hc-dc1.healthcare.uiowa.edu.
> healthcare.uiowa.edu. 3283 IN NS hc-dc2.healthcare.uiowa.edu.
> 
> It returns answers rather than a referral.
> 
> Note that in neither cases is the response authoritative, because dns-cb
> doesn't hold authority over the healthcare.uiowa.edu zone. It has the
> configured hints about how to get to the authoritative servers, & it will
> cache the server list from the authoritative servers.
> 
> Is that not the type of behavior you're getting with your servers?
> 
> 
> Jay Ford, Network Engineering Group, Information Technology Services
> University of Iowa, Iowa City, IA 52242
> email: jay-f...@uiowa.edu, phone: 319-335-, fax: 319-335-2951
  ___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: error (broken trust chain) resolving

[Casey Deccio]

On Mon, Nov 15, 2010 at 6:31 AM, Casey Deccio  wrote:
>
> Well, I'm curious as to why you're not getting the AD bit set for the
> negative proof of existence for bondedsender.org/DS.

After a review of NSEC3 showed that this particular behavior is
expected because org has been signed using NSEC3 with the opt-out bit
set.  RFC 5155, section 9.2:

http://tools.ietf.org/html/rfc5155#section-9.2

Casey
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC with 9.7.2-P2

[Mark Andrews]

In message <20101115140938.ga17...@evileye.atkac.brq.redhat.com>, Adam Tkac wri
tes:
> On Sat, Nov 13, 2010 at 11:35:57AM +1100, Mark Andrews wrote:
> > 
> > In message <4cdd6467.9050...@imperial.ac.uk>, Phil Mayers writes:
> > > On 12/11/10 15:45, Lightner, Jeff wrote:
> > > 
> > > > For Production (RPM based system) you should use RHEL or CentOS which
> > > > has a much longer life cycle.  (Speaking of which, RHEL6 was just put i
> n
> > > 
> > > I don't agree with your line of reasoning. RHEL may have longer update 
> > > cycles, but there's no guarantee a particular RHEL install will be 
> > > applying updates in real-time, so the keys in the dnssec-conf package 
> > > may still get out of date, or a RHEL install may run after it's 5-year 
> > > update cycle ends.
> > > 
> > > I think the dnssec-conf package should have had a nightly cron job to 
> > > refresh these keys, and it was a mistake to deploy without such.
> > > 
> > > Just my opinion of course.
> > > ___
> > > bind-users mailing list
> > > bind-users@lists.isc.org
> > > https://lists.isc.org/mailman/listinfo/bind-users
> > 
> > I use the following scripts (update-trusted-keys and commit-trusted-keys)
> > to manage my trust anchors.  I run update-trusted-keys nightly from cron
> > and manually update when I get email that there has been a change.
> > 
> > update-trusted-keys replaces the trust anchor when the tld gets a DS
> > record added to the root zone.  With no arguements it just updates the
> > current list of zones listed is /etc/trusted-keys.
> 
> Isn't sufficient to configure the root trust anchor inside "managed-keys {};"
> statement? If I understand correctly the key should be automatically
> updated, shouldn't it?

For 9.7 yes.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

MySQL BIND SDB

[Tech W.]

Hello,

Is mysql Bind SDB suitable for a production application?
We have many dozens of domains in the bind servers, what's the best way to 
maintain the zones and records?

Thanks.


  
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

got "BAD (HORIZONTAL) REFERRAL" error

[jeff]

hi all, i have setup a bind server,  host the zone faisco.com, and 
work fine several daysbut one of my new client said that they can't resolve my 
domain, meanwhile they can resolve other web site without any problem.i run 
'dig' on their machine, this is the result:; <<>> DiG 9.4.0 
<<>> www.faisco.com +trace;; global options: printcmd. 
3600 IN NS m.root-servers.net.. 3600 IN NS l.root-servers.net.. 3600 IN NS 
k.root-servers.net.. 3600 IN NS j.root-servers.net.. 3600 IN NS 
i.root-servers.net.. 3600 IN NS h.root-servers.net.. 3600 IN NS 
g.root-servers.net.. 3600 IN NS f.root-servers.net.. 3600 IN NS 
e.root-servers.net.. 3600 IN NS d.root-servers.net.. 3600 IN NS 
c.root-servers.net.. 3600 IN NS b.root-servers.net.. 3600 IN NS 
a.root-servers.net.;; Received 417 bytes from 192.168.0.10#53(192.168.0.10) in 
0 mscom. 165333 IN NS g.gtld-servers.net.com. 165333 IN NS 
h.gtld-servers.net.com. 165333 IN NS i.gtld-servers.net.com. 165333 IN NS 
j.gtld-servers.net.com. 165333 IN NS k.gtld-servers.net.com. 165333 IN NS 
l.gtld-servers.net.com. 165333 IN NS m.gtld-servers.net.com. 165333 IN NS 
a.gtld-servers.net.com. 165333 IN NS b.gtld-servers.net.com. 165333 IN NS 
c.gtld-servers.net.com. 165333 IN NS d.gtld-servers.net.com. 165333 IN NS 
e.gtld-servers.net.com. 165333 IN NS f.gtld-servers.net.;; Received 464 bytes 
from 192.203.230.10#53(e.root-servers.net) in 284 mscom. 165333 IN NS 
g.gtld-servers.net.com. 165333 IN NS h.gtld-servers.net.com. 165333 IN NS 
i.gtld-servers.net.com. 165333 IN NS j.gtld-servers.net.com. 165333 IN NS 
k.gtld-servers.net.com. 165333 IN NS l.gtld-servers.net.com. 165333 IN NS 
m.gtld-servers.net.com. 165333 IN NS a.gtld-servers.net.com. 165333 IN NS 
b.gtld-servers.net.com. 165333 IN NS c.gtld-servers.net.com. 165333 IN NS 
d.gtld-servers.net.com. 165333 IN NS e.gtld-servers.net.com. 165333 IN NS 
f.gtld-servers.net.;; BAD (HORIZONTAL) REFERRAL;; Received 464 bytes from 
192.41.162.30#53(l.gtld-servers.net) in 383 mscom. 165333 IN NS 
g.gtld-servers.net.com. 165333 IN NS h.gtld-servers.net.com. 165333 IN NS 
i.gtld-servers.net.com. 165333 IN NS j.gtld-servers.net.com. 165333 IN NS 
k.gtld-servers.net.com. 165333 IN NS l.gtld-servers.net.com. 165333 IN NS 
m.gtld-servers.net.com. 165333 IN NS a.gtld-servers.net.com. 165333 IN NS 
b.gtld-servers.net.com. 165333 IN NS c.gtld-servers.net.com. 165333 IN NS 
d.gtld-servers.net.com. 165333 IN NS e.gtld-servers.net.com. 165333 IN NS 
f.gtld-servers.net.;; BAD (HORIZONTAL) REFERRAL;; Received 464 bytes from 
192.26.92.30#53(c.gtld-servers.net) in 329 mscom. 165333 IN NS 
g.gtld-servers.net.com. 165333 IN NS h.gtld-servers.net.com. 165333 IN NS 
i.gtld-servers.net.com. 165333 IN NS j.gtld-servers.net.com. 165333 IN NS 
k.gtld-servers.net.com. 165333 IN NS l.gtld-servers.net.com. 165333 IN NS 
m.gtld-servers.net.com. 165333 IN NS a.gtld-servers.net.com. 165333 IN NS 
b.gtld-servers.net.com. 165333 IN NS c.gtld-servers.net.com. 165333 IN NS 
d.gtld-servers.net.com. 165333 IN NS e.gtld-servers.net.com. 165333 IN NS 
f.gtld-servers.net.;; BAD (HORIZONTAL) REFERRAL;; Received 464 bytes from 
192.5.6.30#53(a.gtld-servers.net) in 466 mscom. 165333 IN NS 
g.gtld-servers.net.com. 165333 IN NS h.gtld-servers.net.com. 165333 IN NS 
i.gtld-servers.net.com. 165333 IN NS j.gtld-servers.net.com. 165333 IN NS 
k.gtld-servers.net.com. 165333 IN NS l.gtld-servers.net.com. 165333 IN NS 
m.gtld-servers.net.com. 165333 IN NS a.gtld-servers.net.com. 165333 IN NS 
b.gtld-servers.net.com. 165333 IN NS c.gtld-servers.net.com. 165333 IN NS 
d.gtld-servers.net.com. 165333 IN NS e.gtld-servers.net.com. 165333 IN NS 
f.gtld-servers.net.;; BAD (HORIZONTAL) REFERRAL;; Received 464 bytes from 
192.12.94.30#53(e.gtld-servers.net) in 383 mslots of 'BAD (HORIZONTAL) 
REFERRAL'???and the correct result should be like this:; <<>> DiG 
9.4.0 <<>> www.faisco.com +trace;; global options: 
printcmd. 43757 IN NS a.root-servers.net.. 43757 IN NS b.root-servers.net.. 
43757 IN NS c.root-servers.net.. 43757 IN NS d.root-servers.net.. 43757 IN NS 
e.root-servers.net.. 43757 IN NS f.root-servers.net.. 43757 IN NS 
g.root-servers.net.. 43757 IN NS h.root-servers.net.. 43757 IN NS 
i.root-servers.net.. 43757 IN NS j.root-servers.net.. 43757 IN NS 
k.root-servers.net.. 43757 IN NS l.root-servers.net.. 43757 IN NS 
m.root-servers.net.;; Received 228 bytes from 192.168.1.254#53(192.168.1.254) 
in 156 mscom. 172800 IN NS g.gtld-servers.net.com. 172800 IN NS 
l.gtld-servers.net.com. 172800 IN NS k.gtld-servers.net.com. 172800 IN NS 
f.gtld-servers.net.com. 172800 IN NS d.gtld-servers.net.com. 172800 IN NS 
c.gtld-servers.net.com. 172800 IN NS a.gtld-servers.net.com. 172800 IN NS 
e.gtld-servers.net.com. 172800 IN NS h.gtld-servers.net.com. 172800 IN NS 
j.gtld-servers.net.com. 172800 IN NS i.gtld-servers.net.com. 172800 IN NS 
m.gtld-servers.net.com. 172800 IN NS b.gtld-servers.net.;; Received 504 bytes 
from 192.203.230.10#53(e.root-servers.net) in 531 msfaisco.com. 172800 IN NS 
dns1.fais