RE: PTR zone / VLSM issue

2009-03-16 Thread Chris Thompson

[Top-posting de-swizzled]

On Mar 15 2009, Ben Bridges wrote:


From: bind-users-boun...@lists.isc.org on behalf of Alan Clegg

[...]

Charles Lee wrote:


I believe its format should be:  96-127.51.212.195.in-addr.arpa

The problem I seem to be having is what order the 96-127 should be in,
because in normal format the network is 195.212.51.96-127 (we basically
run address .96 to address .127)

Can anyone help out with the proper format of the zone and what a PTR
record would look like?


It matters not a bit nor a twiddle, as it is just a label that needs to
be "pointed to" by the actual in-addr label elsewhere.

96.fred.51.212.195.in-addr.arpa.IN PTR  mymachine.foo.com.

would work fine as long as you had:

fred.51.212.195.in-addr.arpa. IN NSdelegated.foo.com.
96.51.212.195.in-addr.arpa.   IN CNAME 96.fred.51.212.195.in-addr.arpa.

on the nameserver that was actually delegated 51.212.195.in-addr.arpa.

(feel free to use $GENERATE to create the above CNAMEs)


I agree, it's arbitrary.  If you are wanting to format the name 
of your zone similarly to the RFC, I believe the format would be

96/27.51.212.195.in-addr.arpa (for the subnet 195.212.51.96/27).


Except, of course, that RFC 2317 also says

| The examples here use "/" because it was felt to be more visible and
| pedantic reviewers felt that the 'these are not hostnames' argument
| needed to be repeated.  We advise you not to be so pedantic, and to
| not precisely copy the above examples, e.g.  substitute a more
| conservative character, such as hyphen, for "/".

Half-recommending the use of / was an abomination IMO, not because
it is a non-hostname character in the RFC 1123 sense, but because 
it makes it very awkward to use zone names as file name components.


The real point for the OP is: whatever the naming convention used,
you have to agree it with the delegating authority (unless you are
in the happy position of *being* the delegating authority as well).
All too likely, they will not offer you any choice in the matter.

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

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


how bind supports multi-processors?

2009-03-16 Thread Ralf Peng
Hello,

I'm using a linux box with 4 core CPUs.
How can I make the new downloaded bind-9.6 support multi-processors?

Thanks.

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


Re: how bind supports multi-processors?

2009-03-16 Thread JINMEI Tatuya / 神明達哉
At Tue, 17 Mar 2009 10:25:57 +0800,
Ralf Peng  wrote:

> I'm using a linux box with 4 core CPUs.
> How can I make the new downloaded bind-9.6 support multi-processors?

Build it with threads:

% ./configure --enable-threads [and other config options if necessary]
% make

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Re: how bind supports multi-processors?

2009-03-16 Thread Ralf Peng
Thanks.
Is threads stable enough in product use of Bind?

2009/3/17 JINMEI Tatuya / 神明達哉 :
> At Tue, 17 Mar 2009 10:25:57 +0800,
> Ralf Peng  wrote:
>
>> I'm using a linux box with 4 core CPUs.
>> How can I make the new downloaded bind-9.6 support multi-processors?
>
> Build it with threads:
>
> % ./configure --enable-threads [and other config options if necessary]
> % make
>
> ---
> JINMEI, Tatuya
> Internet Systems Consortium, Inc.
>
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: how bind supports multi-processors?

2009-03-16 Thread JINMEI Tatuya / 神明達哉
At Tue, 17 Mar 2009 10:47:10 +0800,
Ralf Peng  wrote:

> Is threads stable enough in product use of Bind?

It would depend on the definition of stability and of product use:-)

As far as I know, many people happily use BIND9 with threads in an
environment which would normally be called 'in product'.  On the other
hand, I have to admit we still sometimes see strange behavior only
happening with threads.

If you're a conservative operator and don't see a performance problem
without threads, you may just want to go for it.  If you hit a
performance problem with a non-thread build, enable threads and give
it a try.

---
JINMEI, Tatuya
Internet Systems Consortium, Inc.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users


Intermittent name resolution for spmonline.petronas.com.my

2009-03-16 Thread Elias

Hello all,

We're seing intermittent name resolution for spmonline.lb2.petronas.com.my 
but can't seem to pin the issue down. While troubleshooting I noticed that 
their nameserver will return an NXDOMAIN answer whenever a TCP query is sent 
and thought I'd bingo'ed the issue down.


# dig @lb2jr.petronas.com.my spmonline.lb2.petronas.com.my +tcp

; <<>> DiG 9.6.0rc2 <<>> @lb2jr.petronas.com.my 
spmonline.lb2.petronas.com.my +tcp

; (1 server found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1050
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;spmonline.lb2.petronas.com.my. IN  A

;; AUTHORITY SECTION:
lb2.petronas.com.my.3600IN  SOA lb2jr.petronas.com.my. 
dnsadmin.pttcdc.com.my. 2008081601 1200 900 86400 3600


The admin reacted quickly by saying that they don't allow zone transfers (I 
don't see how that relates to the issue), and have since completely blocked 
of TCP/53. So I'm back to square one again.



This is the cache dump whenever the query fails (BIND 9.6.0rc2) :


; authauthority
petronas.com.my.20296   NS  ns2.petronas.com.my.
 20296   NS  gateway.petronas.com.my.
; authanswer
gateway.petronas.com.my. 20296  A   170.38.99.99
; glue
lb2.petronas.com.my.19493   NS  lb2jr.petronas.com.my.
   19493   NS  lb2tt.petronas.com.my.
; authauthority
spmonline.lb2.petronas.com.my. 2269 \-ANY ;-$NXDOMAIN
; authanswer
lb2jr.petronas.com.my.  20417   A   170.38.17.251
; authanswer
lb2tt.petronas.com.my.  20411   A   211.25.204.251
; authanswer
ns2.petronas.com.my.20320   A   170.38.22.200
; answer
spmonline.petronas.com.my. 19493 CNAME  spmonline.lb2.petronas.com.my.


Another question is, when do queries normally switch to TCP? I know that 
when the answer is to big to fit in a single UDP packet, it is switched to 
TCP, but are there any other reasons? RFC 5452 has a mention that certain 
resolvers may re-issue the query over TCP when they detects spoofing 
attempts (can anyone explain in detail how this is achieved, greatly 
appreciated :D)


Thx!


- Elias - 


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


Re: Intermittent name resolution for spmonline.petronas.com.my

2009-03-16 Thread Mark Andrews

It's a load balancer which intercepts A queries and passes
everything else to the nameserver behind it which knows
nothing about spmonline.lb2.petronas.com.my so it returns
NXDOMAIN.   As you have IPv6 aware applications they make
 queries which results in NXDOMAIN being returned which
is then cached.

Tell the administrator of the load balancer to correctly
configure the backing nameserver to add a A record for
spmonline.lb2.petronas.com on the backing zone.  That way
the answers that the backing server returns will be consistant
with those returned from the load balancer.

; <<>> DiG 9.3.6-P1 <<>>  @lb2jr.petronas.com.my 
spmonline.lb2.petronas.com.my
; (1 server found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 16217
;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;spmonline.lb2.petronas.com.my. IN  

;; AUTHORITY SECTION:
lb2.petronas.com.my.3600IN  SOA lb2jr.petronas.com.my. 
dnsadmin.pttcdc.com.my. 2008081601 1200 900 86400 3600

;; Query time: 386 msec
;; SERVER: 170.38.17.251#53(170.38.17.251)
;; WHEN: Tue Mar 17 14:44:01 2009
;; MSG SIZE  rcvd: 105

Mark

In message <3bddbe8cfba149818ce53daa53631...@eliaslaptop>, "Elias" writes:
> Hello all,
> 
> We're seing intermittent name resolution for spmonline.lb2.petronas.com.my 
> but can't seem to pin the issue down. While troubleshooting I noticed that 
> their nameserver will return an NXDOMAIN answer whenever a TCP query is sent 
> and thought I'd bingo'ed the issue down.
> 
> # dig @lb2jr.petronas.com.my spmonline.lb2.petronas.com.my +tcp
> 
> ; <<>> DiG 9.6.0rc2 <<>> @lb2jr.petronas.com.my 
> spmonline.lb2.petronas.com.my +tcp
> ; (1 server found)
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 1050
> ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
> ;; WARNING: recursion requested but not available
> 
> ;; QUESTION SECTION:
> ;spmonline.lb2.petronas.com.my. IN  A
> 
> ;; AUTHORITY SECTION:
> lb2.petronas.com.my.3600IN  SOA lb2jr.petronas.com.my. 
> dnsadmin.pttcdc.com.my. 2008081601 1200 900 86400 3600
> 
> The admin reacted quickly by saying that they don't allow zone transfers (I 
> don't see how that relates to the issue), and have since completely blocked 
> of TCP/53. So I'm back to square one again.
> 
> 
> This is the cache dump whenever the query fails (BIND 9.6.0rc2) :
> 
> 
> ; authauthority
> petronas.com.my.20296   NS  ns2.petronas.com.my.
>   20296   NS  gateway.petronas.com.my.
> ; authanswer
> gateway.petronas.com.my. 20296  A   170.38.99.99
> ; glue
> lb2.petronas.com.my.19493   NS  lb2jr.petronas.com.my.
> 19493   NS  lb2tt.petronas.com.my.
> ; authauthority
> spmonline.lb2.petronas.com.my. 2269 \-ANY ;-$NXDOMAIN
> ; authanswer
> lb2jr.petronas.com.my.  20417   A   170.38.17.251
> ; authanswer
> lb2tt.petronas.com.my.  20411   A   211.25.204.251
> ; authanswer
> ns2.petronas.com.my.20320   A   170.38.22.200
> ; answer
> spmonline.petronas.com.my. 19493 CNAME  spmonline.lb2.petronas.com.my.
> 
> 
> Another question is, when do queries normally switch to TCP? I know that 
> when the answer is to big to fit in a single UDP packet, it is switched to 
> TCP, but are there any other reasons? RFC 5452 has a mention that certain 
> resolvers may re-issue the query over TCP when they detects spoofing 
> attempts (can anyone explain in detail how this is achieved, greatly 
> appreciated :D)
> 
> Thx!
> 
> 
> - Elias - 
> 
> ___
> bind-users mailing list
> bind-users@lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users