clarification on AXFR

[rams]

Hi,
During AXFR of a zone, the zone.dbfile is not created till the AXFR
completes. Till AXFR completes, the file name will be some value as
456eefwfc. Is it correct behavior?

Thanks & Regards,
Ramesh
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: multiple PTR RRs [dnsviz]

[Joseph S D Yao]

On Wed, Jun 02, 2010 at 03:40:31PM +, Paul Vixie wrote:
> Chris Thompson  writes:
> 
> > Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> > records in an RRset, as your first case has? (On the other hand it
> > handles multiple A records in forward zones OK.)
> 
> to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr()
> in more or less direct contravention to RFC 1034. if dnsviz doesn't handle
> it (and i don't know if it doesn't) then it's not dnsviz's fault at all
> since the DNS RFC's say that there will only be one PTR RR at an in-addr.


Vixie, not to presume to argue with you about what Paul M meant by that,
but in RFC 2181 Elz and Bush say:

10.2. PTR records

   Confusion about canonical names has lead to a belief that a PTR
   record should have exactly one RR in its RRSet.  This is incorrect,
   the relevant section of RFC1034 (section 3.6.2) indicates that the
   value of a PTR record should be a canonical name.  That is, it should
   not be an alias.  There is no implication in that section that only
   one PTR record is permitted for a name.  No such restriction should
   be inferred.

That having been said, I always feel better, myself, when there is a
1-to-1 mapping.


--
/*\
**
** Joe Yao  j...@tux.org - Joseph S. D. Yao
**
\*/
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: max-cache-size query

[Doug Barton]

On 06/02/10 01:31, Techi wrote:

but, my question is still not answered.
Why on earth such huge defference in the number of connections on the firewall
with the max-cache-size on and off? I still don't get it.


Imagine the cache as a bucket. With a large bucket the chances of the 
answer that any given client needs being in the bucket already are 
higher, which means they can connect, get their answer, and disconnect 
quickly, without the resolver having to make any additional connections 
to the outside world.


With a small bucket if the answer the client needs isn't there already 
it has to wait while the resolver makes anywhere from 1-4 _additional_ 
connections to the outside world before it can finally get its answer 
and go away. I'm seriously twisting things here to make a good story, 
but hopefully it gives you more of an idea of what is happening.


When it comes to the size of the cache on a name server you should set 
it to about 80% of the available ram on the system. If that turns out 
not to be enough, add more ram, or get a bigger system.



hth,

Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

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

Re: DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Matthew Seaman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 02/06/2010 18:49:44, Casey Deccio wrote:
> This has been fixed.  The problem had to do with establishing a canonical
> ordering of RRs within an RRset for the purposes of verifying an RRSIG.
> dnspython's default comparison operators don't follow canonical ordering
> from RFC 4034, so I had to make some provisions to order properly.  This
> didn't affect A RRsets with multiple RRs because the order of A-type rdata
> was the same using both orderings.
> 
> Thanks for bringing this to my attention.

Excellent. Thank you very much indeed -- I'm glad to have been of service.

Cheers,

Matthew

- -- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwGoNIACgkQ8Mjk52CukIzVVwCfTOVmg0meReYFd389TP1D+D96
25EAnRFSXO7JIcaGic1ME49upIkPq+lR
=VZlY
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Casey Deccio]

On Wed, Jun 2, 2010 at 7:44 AM, Chris Thompson  wrote:

> On Jun 2 2010, Matthew Seaman wrote:
>
>  I'm DNSSEC enabling the .ip6.arpa zone for my IPv6 allocation and
>> registering it with dlv.isc.org.  Using bind-9.7.0-p2 dnssec tools.
>>
>> Everything seems to be working well, but when I test using the Sandia
>> Labs dnsviz.net tool I get inconsistent results.
>>
>> My mail, etc. server on 2001:8b0:151:1:e2cb:4eff:fe26:6481 appears as
>> 'bogus'
>>
>>
>> http://dnsviz.net/d/1.8.4.6.6.2.e.f.f.f.e.4.b.c.2.e.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
>>
>> Yet my personal laptop on 2001:8b0:151:1:fa1e:dfff:feda:c0bb is all good:
>>
>>
>> http://dnsviz.net/d/b.b.0.c.a.d.e.f.f.f.f.d.e.1.a.f.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/
>>
>> What am I doing wrong?
>>
>
> Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> records in an RRset, as your first case has? (On the other hand it
> handles multiple A records in forward zones OK.)
>
>
This has been fixed.  The problem had to do with establishing a canonical
ordering of RRs within an RRset for the purposes of verifying an RRSIG.
dnspython's default comparison operators don't follow canonical ordering
from RFC 4034, so I had to make some provisions to order properly.  This
didn't affect A RRsets with multiple RRs because the order of A-type rdata
was the same using both orderings.

Thanks for bringing this to my attention.

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

Re: Clarification on bind result

[Kevin Darcy]

What exactly are you expecting to see there? NS records for the root 
zone? Is this *non-recursive* nameserver obligated to give out NS and/or 
SOA records for the root zone in the Authority Section? I think not.



- Kevin


On 6/1/2010 4:45 AM, rams wrote:

Is there any update on the following issue.

On Mon, May 31, 2010 at 2:16 PM, rams > wrote:


Hi ,
I have the following zone file:

$ORIGIN td3497.com .

@ IN SOA udns1.ultradns.net .
ppk.yahoo.com . (

2010052610 ; serial

10800 ; refresh

3600 ; retry

2592000 ; expire

86400 ; minimum

)

cname.chain.td3497.com . 86400 IN
CNAME mx.chain.td3497.com .

mx.chain.td3497.com . 86400 IN MX 34
mx1.chain.td3497.com .

mx1.chain.td3497.com . 86400 IN MX
34 mx2.chain.td3497.com .

mx2.chain.td3497.com . 86400 IN MX
34 mx3.chain.td3497.com .

mx3.chain.td3497.com . 86400 IN A
1.2.3.4

ramesh.td3497.com . 86400 MX 20 .

ramesh.td3497.com . 86400 MX 20 mx1.

*cname.td3497.com . 86400 CNAME .*

td3497.com . 86400 IN NS udns2.ultradns.net
.

td3497.com . 86400 IN NS udns1.ultradns.net
.

;End

I queried for cname domain against bind 9.6.X and got the
following response

C:\Documents and Settings\rameshb>dig @localhost cname.td3497.com
 mx

; <<>> DiG 9.6.1-P1 <<>> @localhost cname.td3497.com
 mx
; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 681
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;cname.td3497.com .  IN  MX

;; ANSWER SECTION:
cname.td3497.com .   86400   IN 
CNAME   .


;; Query time: 15 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon May 31 14:10:32 2010
;; MSG SIZE  rcvd: 47

Here why authority section is not returned? Actually authority
section should be returned with SOA right?

Thanks & Regards,

Ramesh



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


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

Re: DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Casey Deccio]

On Wed, Jun 2, 2010 at 8:40 AM, Paul Vixie  wrote:

> Chris Thompson  writes:
>
> > Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> > records in an RRset, as your first case has? (On the other hand it
> > handles multiple A records in forward zones OK.)
>
> to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr()
> in more or less direct contravention to RFC 1034. if dnsviz doesn't handle
> it (and i don't know if it doesn't) then it's not dnsviz's fault at all
> since the DNS RFC's say that there will only be one PTR RR at an in-addr.
>

Not to take this off topic, but RFC 2181 (sec 10.2) clarifies that a PTR
RRset *may* have multiple RRs, but each must point to a canonical name, as
opposed to an alias.

That being said, DNSViz is intended to consider multiple RRs in the PTR
RRset, but I'm still trying to track down the issue that is causing it to
report a bogus signature.  I'll report back when I have an answer.

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

[no subject]

[Paul Vixie]

Chris Thompson  writes:

> Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
> records in an RRset, as your first case has? (On the other hand it
> handles multiple A records in forward zones OK.)

to be fair, multiple PTR RRs is something we added in BIND gethostbyaddr()
in more or less direct contravention to RFC 1034. if dnsviz doesn't handle
it (and i don't know if it doesn't) then it's not dnsviz's fault at all
since the DNS RFC's say that there will only be one PTR RR at an in-addr.
-- 
Paul Vixie
KI6YSY
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

About NAT-PT

[Lingfeng Xiong]

hi all,
I am trying to build a pure IPv6 network for my university. Now I wanna to
build a Bind-based DNS server. Because I am using NAT-PT for IPv4 accessing,
I must get the A record from my ISP's DNS server and add a special prefix to
it. Could you tell me how to config my bind to do this? thx!
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Chris Thompson]

On Jun 2 2010, Matthew Seaman wrote:


I'm DNSSEC enabling the .ip6.arpa zone for my IPv6 allocation and
registering it with dlv.isc.org.  Using bind-9.7.0-p2 dnssec tools.

Everything seems to be working well, but when I test using the Sandia
Labs dnsviz.net tool I get inconsistent results.

My mail, etc. server on 2001:8b0:151:1:e2cb:4eff:fe26:6481 appears as
'bogus'

http://dnsviz.net/d/1.8.4.6.6.2.e.f.f.f.e.4.b.c.2.e.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/

Yet my personal laptop on 2001:8b0:151:1:fa1e:dfff:feda:c0bb is all good:

http://dnsviz.net/d/b.b.0.c.a.d.e.f.f.f.f.d.e.1.a.f.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/

What am I doing wrong?


Nothing that I can see. Maybe dnsviz can't cope with multiple PTR
records in an RRset, as your first case has? (On the other hand it
handles multiple A records in forward zones OK.)

--
Chris Thompson
Email: c...@cam.ac.uk

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

DNSSEC / DLV for 2001:8b0:151:1:e2cb:4eff:fe26:6481

[Matthew Seaman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


I'm DNSSEC enabling the .ip6.arpa zone for my IPv6 allocation and
registering it with dlv.isc.org.  Using bind-9.7.0-p2 dnssec tools.

Everything seems to be working well, but when I test using the Sandia
Labs dnsviz.net tool I get inconsistent results.

My mail, etc. server on 2001:8b0:151:1:e2cb:4eff:fe26:6481 appears as
'bogus'

http://dnsviz.net/d/1.8.4.6.6.2.e.f.f.f.e.4.b.c.2.e.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/

Yet my personal laptop on 2001:8b0:151:1:fa1e:dfff:feda:c0bb is all good:

http://dnsviz.net/d/b.b.0.c.a.d.e.f.f.f.f.d.e.1.a.f.1.0.0.0.1.5.1.0.0.b.8.0.1.0.0.2.ip6.arpa/dnssec/

What am I doing wrong?

Cheers,

Matthew

- -- 
Dr Matthew J Seaman MA, D.Phil.   7 Priory Courtyard
  Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: matt...@infracaninophile.co.uk   Kent, CT11 9PW
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkwGWkEACgkQ8Mjk52CukIyFlwCgiaFHI4yzaZBNreBCo3RUCh93
0pUAn0nzjDwmNv+c4OKNoQmHD1ueQS7v
=Ncbf
-END PGP SIGNATURE-
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Choosing authoritative nameservers

[Matus UHLAR - fantomas]

On 02.06.10 16:20, Elias wrote:
> Does anyone know how BIND chooses which authoritative server to refer to? 
> When a referal returns ns1.abc.com, ns2.abc.com and ns3.abc.com, will the 
> recursive server randomly send out a request to either ns1, ns2 or ns3 or 
> is there a selection algorithm?

there's algorithm preferring the server with fastest responses but
ocasionally tryiong other servers.

> I've got a problem resolving www.klse.com.my and its probably caused by a 
> broken server along the path. But the problem is I keep hitting the same  
> server everytime no matter how many times I flush my caches.

it's most probably not caused by server selection in BIND but in broken
delegation.

this is provided by com.my. sevrers:

> klse.com.my.86400   IN  NS  ens1.klse.com.my.
> klse.com.my.86400   IN  NS  ens2.klse.com.my.
> ;; Received 103 bytes from 61.6.38.139#53(ns5.jaring.my) in 6 ms

ens1.klse.com.my.   86400   IN  A   211.25.178.3
ens2.klse.com.my.   86400   IN  A   121.123.146.80

This is provided by delegated servers:

;; ANSWER SECTION:
klse.com.my.28800   IN  NS  ens1.bursamalaysia.com.
klse.com.my.28800   IN  NS  ens2.bursamalaysia.com.

;; SERVER: 211.25.178.3#53(211.25.178.3)

klse.com.my.28800   IN  NS  ens1.bursamalaysia.com.
klse.com.my.28800   IN  NS  ens2.bursamalaysia.com.

;; SERVER: 121.123.146.80#53(121.123.146.80)


- we can safely say STOP here, the delegation is broken, fix it.


However, looking at bursamalaysia.com domain... Delegation:

;; AUTHORITY SECTION:
bursamalaysia.com.  172800  IN  NS  ens1.bursamalaysia.com.
bursamalaysia.com.  172800  IN  NS  ens2.bursamalaysia.com.

;; ADDITIONAL SECTION:
ens1.bursamalaysia.com. 172800  IN  A   211.25.178.3
ens2.bursamalaysia.com. 172800  IN  A   121.123.146.80


while ens1.bursamalaysia.com. returns same list of namservers, but does not
return glue records for them, the ens2.bursamalaysia.com. returns SERVFAIL
for bursamalaysia.com.

It's even more broken. 


-- 
Matus UHLAR - fantomas, uh...@fantomas.sk ; http://www.fantomas.sk/
Warning: I wish NOT to receive e-mail advertising to this address.
Varovanie: na tuto adresu chcem NEDOSTAVAT akukolvek reklamnu postu.
Fighting for peace is like fucking for virginity...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: max-cache-size query

[Techi]

On Wed 02 of Jun 2010 00:45:42 you wrote:
> One obvious solution to keeping  the firewall guys happy would just be
> to make them not burn state entries for the nameserver at all
> Firewalls in front of nameservers cause an ungodly amount of issues
> for no real benefit...
I will transfer that to our vendors, but, my question is still not answered. 
Why on earth such huge defference in the number of connections on the firewall 
with the max-cache-size on and off? I still don't get it. 
P.
 
> 
> Just sayin'...
> 
> W
> 
> On Jun 1, 2010, at 8:35 AM, Techi wrote:
> > Hallo,
> > Recently, I faced huge problems with my DNS servers (bind crashed
> > with no
> > apparent reason). Some of the symptons were:
> > * Huge number of connections on our firewalls (>15).
> > * A lot of errors in syslog about max file descriptors limits reached
> > (currently on system, the FD limit is 4096, the default of centos)
> >
> > Anyway, after the proposal of a friend of mine, I removed the the
> > max-cache-
> > size limit (that was set to 256MB.
> > After a restart of bind, the FW guys reported a huge drop on
> > connections
> > (<1)!
> > Additionally, I have no crashes so far (in contract with 1-2 per
> > week).
> > So, why:
> > a. bind generated so much traffic?
> > b. Is it possible to have bind crash because I could not handle the
> > cache
> > clean-up and on the same time to serve requests?
> >
> > Thank you
> > ___
> > bind-users mailing list
> > bind-users@lists.isc.org
> > https://lists.isc.org/mailman/listinfo/bind-users
> 
> ---
> Schizophrenia beats being alone.
> 
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Choosing authoritative nameservers

[Elias]

Hi guys,

Does anyone know how BIND chooses which authoritative server to refer to? 
When a referal returns ns1.abc.com, ns2.abc.com and ns3.abc.com, will the 
recursive server randomly send out a request to either ns1, ns2 or ns3 or is 
there a selection algorithm?


I've got a problem resolving www.klse.com.my and its probably caused by a 
broken server along the path. But the problem is I keep hitting the same 
server everytime no matter how many times I flush my caches.


# /usr/local/bin/dig www.klse.com.my +trace

; <<>> DiG 9.7.0 <<>> www.klse.com.my +trace
;; global options: +cmd
.   491578  IN  NS  c.root-servers.net.
.   491578  IN  NS  f.root-servers.net.
.   491578  IN  NS  m.root-servers.net.
.   491578  IN  NS  j.root-servers.net.
.   491578  IN  NS  i.root-servers.net.
.   491578  IN  NS  k.root-servers.net.
.   491578  IN  NS  d.root-servers.net.
.   491578  IN  NS  g.root-servers.net.
.   491578  IN  NS  h.root-servers.net.
.   491578  IN  NS  a.root-servers.net.
.   491578  IN  NS  l.root-servers.net.
.   491578  IN  NS  b.root-servers.net.
.   491578  IN  NS  e.root-servers.net.
;; Received 504 bytes from 192.168.10.209#53(192.168.10.209) in 13 ms

my. 172800  IN  NS  dns2.mynic.net.my.
my. 172800  IN  NS  ns.uu.net.
my. 172800  IN  NS  ns5.jaring.my.
my. 172800  IN  NS  ns2.cuhk.edu.hk.
my. 172800  IN  NS  ns6.jaring.my.
my. 172800  IN  NS  ns-my.nic.fr.
my. 172800  IN  NS  dns.mynic.net.my.
my. 172800  IN  NS  ns20.iij.ad.jp.
;; Received 441 bytes from 192.36.148.17#53(i.root-servers.net) in 182 ms

klse.com.my.86400   IN  NS  ens1.klse.com.my.
klse.com.my.86400   IN  NS  ens2.klse.com.my.
;; Received 103 bytes from 61.6.38.139#53(ns5.jaring.my) in 6 ms

www.klse.com.my.28800   IN  NS  sens2.bursamalaysia.com.
www.klse.com.my.28800   IN  NS  sens1.bursamalaysia.com.
;; Received 90 bytes from 121.123.146.80#53(ens2.klse.com.my) in 5 ms

www.klse.com.my.20  IN  A   121.123.146.114
;; Received 49 bytes from 211.25.178.1#53(sens1.bursamalaysia.com) in 7 ms

A dig +trace gives a successful resolution, but the query fails when I try 
to lookup either sens1.bursamalaysia.com or sens2.bursamalaysia.com (the 
query will ALWAYS hits ens2.bursamalaysia.com which is the broken server)


# /usr/local/bin/dig sens1.bursamalaysia.com +trace

; <<>> DiG 9.7.0 <<>> sens1.bursamalaysia.com +trace
;; global options: +cmd
.   491534  IN  NS  f.root-servers.net.
.   491534  IN  NS  c.root-servers.net.
.   491534  IN  NS  b.root-servers.net.
.   491534  IN  NS  j.root-servers.net.
.   491534  IN  NS  d.root-servers.net.
.   491534  IN  NS  a.root-servers.net.
.   491534  IN  NS  m.root-servers.net.
.   491534  IN  NS  g.root-servers.net.
.   491534  IN  NS  l.root-servers.net.
.   491534  IN  NS  h.root-servers.net.
.   491534  IN  NS  e.root-servers.net.
.   491534  IN  NS  i.root-servers.net.
.   491534  IN  NS  k.root-servers.net.
;; Received 492 bytes from 192.168.10.209#53(192.168.10.209) in 30 ms

com.172800  IN  NS  d.gtld-servers.net.
com.172800  IN  NS  a.gtld-servers.net.
com.172800  IN  NS  c.gtld-servers.net.
com.172800  IN  NS  b.gtld-servers.net.
com.172800  IN  NS  m.gtld-servers.net.
com.172800  IN  NS  f.gtld-servers.net.
com.172800  IN  NS  g.gtld-servers.net.
com.172800  IN  NS  l.gtld-servers.net.
com.172800  IN  NS  h.gtld-servers.net.
com.172800  IN  NS  e.gtld-servers.net.
com.172800  IN  NS  i.gtld-servers.net.
com.172800  IN  NS  k.gtld-servers.net.
com.172800  IN  NS  j.gtld-servers.net.
;; Received 497 bytes from 192.33.4.12#53(c.root-servers.net) in 428 ms

bursamalaysia.com.  172800  IN  N