Re: bindvrs Vulnerability

[Yohann LEPAGE]

Balanagaraju Munukutla a écrit :


Hi

Hi,


How to Disable the BIND version query feature in BIND 9.2.1.

in named.conf :
options {
 version"what you want";
};

Or just : http://www.google.com/search?q=disable+version+bind

--
Yohann LEPAGE


Post-scriptum La Poste

Ce message est confidentiel. Sous réserve de tout accord conclu par
écrit entre vous et La Poste, son contenu ne représente en aucun cas un
engagement de la part de La Poste. Toute publication, utilisation ou
diffusion, même partielle, doit être autorisée préalablement. Si vous
n'êtes pas destinataire de ce message, merci d'en avertir immédiatement
l'expéditeur.


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

bindvrs Vulnerability

[Balanagaraju Munukutla]

Hi

How to Disable the BIND version query feature in BIND 9.2.1.

This is a bindvrs Vulnerability.

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

Bug in Bind 9.6.1-P2

[Radu Banabic]

Hello,

An abort is triggered when dst_lib_destroy is called from the error handler
in dst_lib_init (dst_api.c). If memory allocation
fails in one of the methods called by dst_lib_init, dst_lib_destroy will be
called without having dst_initialized set, thus triggering
an assert and therefore an abort.

Best regards,

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

Re: Question from an absolute rookie

[Kevin Darcy]

Rij wrote:

Hello,

I am trying to understand the behavior of bind resolver regarding a
particular issue. Let us say a resolver A sends a query to a server B.
If the response is too big, B will set the TC flag.  Let's assume that
the truncated portion was NOT part of the additional section since I
believe in that case A is free to ignore.

Will A now definitely open a TCP connection with B to get the full response?

Or will A ignore that and try a different server?
  
I believe all resolvers which are based on BIND's resolver library will 
retry the same nameserver via TCP before going to the next nameserver in 
the list.


In "classical" DNS, this behavior only made sense: the only reason for 
truncating is because the response is too big, but ideally you should 
get the same-sized response from *any* of the nameservers you query 
(disregarding "optional" contents such as certain records in the 
Additional Section, as you noted) so they'll *all* presumably be 
truncated. It would be rather rare for one nameserver to truncate a 
response and then another nameserver in the same resolver list to give 
an un-truncated response to the same query [*].


I will point out, however, that RFC 2181 only says "query again, using a 
mechanism, such as a TCP connection, that will permit larger replies" 
when getting a truncated response. It doesn't specify any particular 
nameserver-selection algorithm. So this behavior might vary from 
implementation to implementation.


- Kevin

[*] The introduction of the EDNS0 extension (see RFC 2671), which allows 
clients and servers to negotiate a buffer size, deviates from the 
"classical" model and raises some new hypothetical scenarios, where the 
same response might be truncated from some resolvers but not others. As 
a practical matter it shouldn't really change the resolver behavior; 
I'll defer discussion of that unless you're really interested.

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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Mathew J. Newton]

On Mon, January 11, 2010 8:33 pm, Matthew Pounsett wrote:

> The problem may be at Kloth.. but at least one of the many possible
> problems they might be having could be corrected by a slightly different
> configuration at your end.

Thanks Matt for your (and others) continued help with this - it is much
appreciated.

> According to RFC you must have at least two name servers on different
> networks for each delegation.  I interpret this as two name servers *per
> address protocol* that you want to support.  So, if you want to support
> queries from the v4 Internet (there may be reasons you don't) then you
> should have at least two name servers responding to queries over v4.

I will do eventually. Given this is just for personal use/experimentation
I may get one of the free DNS providers to act as a secondary.

> Koth may be having network trouble on v4 which prevents them from getting
> at 77.103.161.0/24.  If that is the problem, a second v4 name server in a
> different subnet (at a different site) might present them with a path to a
> name server that can answer their query.  This is the reason why there is
> a redundancy requirement in the RFC.

I did think that, but then I can force them to use my server (using the @
option) and they resolve quite happily. It seems to be somewhere between
the .org and server and mine that they have trouble with!

> That said.. there is nothing wrong with a name server that only answers
> using one address protocol or the other.  And there is functional
> precedent in infrastructure for name servers that are only on v6.
> j.gtld.biz, which is authoritative for the us. zone only has a v6 address.
>  While this occasionally confuses an operator here and there, the DNS
> likes it just fine.

That's good to know - I thought I was trying to do something that was
fundamentally forbidden!

Mathew


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 15:16, Matthew Pounsett wrote:

> By contrast, Verisign's servers have long included glue in the ANSWER 
> section.  This is widely considered to be at best suboptimal, and by many (or 
> most) to be a bug.  Verisign has indicated that this behaviour is coming to 
> an end, although I don't recall off the top of my head if they've announced a 
> date.

Following up my own email.. someone pointed me to the specific reference to the 
vague memory I had floating around in my head:



To summarize, the behaviour I mentioned above is scheduled to go away on March 
1st, 2010.. at which point the com/net servers should start answering with glue 
in the ADDITIONAL section.

Matt



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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 14:48, Mathew J. Newton wrote:

>> FWIW, at least one of the afilias hosts had the same IPv4 address for
>> ns[12].v6ns.org.
> 
>>> ns1.v6ns.org.   86400   IN  A   77.103.161.36
>>> ns1.v6ns.org.   86400   IN  2a01:348:133::a1
>>> ns2.v6ns.org.   86400   IN  A   77.103.161.36
>>> ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2
> 
> Hmm.. That's interesting. I know for a fact that my registrar wouldn't
> allow me to enter two servers with the same address, however within my
> zone I may have had ns[12] set with IPv4 records set for a period (a few
> days ago). This makes me wonder where .org is getting its records from - a
> combination of glue provided by the registrar and cached results from my
> zone?

The org. name servers are authoritative-only.. no caching takes place.

Also, the registry is contractually prevented from modifying zone data supplied 
by the registrars, which would preclude it from cloning the v4 address from one 
name server to the other.  Besides, as database objects, the relationship 
between one name server and the other would be pretty loose, and there'd be no 
reasonable way to assume that ns2.v6ns.org is authoritative for everything that 
ns1.v6ns.org is authoritative for.

I suspect that, even though they threw an error, your registrar went ahead and 
passed on the same IPv4 address for both name servers to the registry.

Matt



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

Re: Interoperability issues using TSIG with HMAC-SHA224

[Evan Hunt]

> Just to clarify, does this also apply to HMAC-MD5 (block size = 64 bytes,
> digest size = 16 bytes) ?

MD5 is not affected.

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

Re: Interoperability issues using TSIG with HMAC-SHA224

[Chris Thompson]

On Jan 9 2010, Evan Hunt wrote:


We've recently found out about an interoperability flaw affecting all the
HMAC-SHA* algorithms; it affects any key with a secret longer than the
digest length of the algorithm (which is 28 bytes, for HMAC-SHA224).  If
your secret is longer than that, try a shorter key and see if that works.


Just to clarify, does this also apply to HMAC-MD5 (block size = 64 bytes,
digest size = 16 bytes) ?

--
Chris Thompson
Email: c...@cam.ac.uk
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 12:29, Mathew J. Newton wrote:

> Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems
> unable to resolve my records and I can't help but feel it's a problem at
> my end rather than theirs!

The problem may be at Kloth.. but at least one of the many possible problems 
they might be having could be corrected by a slightly different configuration 
at your end.

According to RFC you must have at least two name servers on different networks 
for each delegation.  I interpret this as two name servers *per address 
protocol* that you want to support.  So, if you want to support queries from 
the v4 Internet (there may be reasons you don't) then you should have at least 
two name servers responding to queries over v4.

Koth may be having network trouble on v4 which prevents them from getting at 
77.103.161.0/24.  If that is the problem, a second v4 name server in a 
different subnet (at a different site) might present them with a path to a name 
server that can answer their query.  This is the reason why there is a 
redundancy requirement in the RFC.


That said.. there is nothing wrong with a name server that only answers using 
one address protocol or the other.  And there is functional precedent in 
infrastructure for name servers that are only on v6.  j.gtld.biz, which is 
authoritative for the us. zone only has a v6 address.  While this occasionally 
confuses an operator here and there, the DNS likes it just fine.

Matt


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Matthew Pounsett]

On 2010/01/11, at 12:57, Rick Dicaire wrote:

> If I understand this correctly, the lack of an ANSWER section for 
> query would denote there is no ipv6 glue at the TLD?

No, that would indicate that the name server you queried is not authoritative 
for the record you queried about.  Glue, by definition, is non-authoritative 
data, and so appears in the ADDITIONAL section, as in the example you pasted.

By contrast, Verisign's servers have long included glue in the ANSWER section.  
This is widely considered to be at best suboptimal, and by many (or most) to be 
a bug.  Verisign has indicated that this behaviour is coming to an end, 
although I don't recall off the top of my head if they've announced a date.

Matt


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Mathew J. Newton]

On Mon, January 11, 2010 6:27 pm, Miles Mccredie wrote:

> FWIW, this is what I'm seeing from an IPv4 only host.  Not sure if the
> unexpected source is the problem that kloth.net is seeing or whether
> it's the result of putting

>> *;; reply from unexpected source: 77.103.161.36#60741, expected
>> 77.103.161.36#53
>> ;; reply from unexpected source: 77.103.161.36#60741, expected
>> 77.103.161.36#53
>> ;; connection timed out; no servers could be reached

It never rains but it pours?!

I too have seen that on occasion. I think it's down to my crappy D-Link
router, or rather its implementation of NAT. I've got a Cisco router sat
here waiting to take its place when I can find time to get round to it.

> FWIW, at least one of the afilias hosts had the same IPv4 address for
> ns[12].v6ns.org.

>> ns1.v6ns.org.   86400   IN  A   77.103.161.36
>> ns1.v6ns.org.   86400   IN  2a01:348:133::a1
>> ns2.v6ns.org.   86400   IN  A   77.103.161.36
>> ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2

Hmm.. That's interesting. I know for a fact that my registrar wouldn't
allow me to enter two servers with the same address, however within my
zone I may have had ns[12] set with IPv4 records set for a period (a few
days ago). This makes me wonder where .org is getting its records from - a
combination of glue provided by the registrar and cached results from my
zone?

Mathew


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Mathew J. Newton]

On Mon, January 11, 2010 5:57 pm, Rick Dicaire wrote:

> While this is not in response to your original question, I am curious.
> I'm not sure if you were part of the discussion we just had on IRC
> freenode #ipv6, but querying a .org TLD NS for  records for ns1
> and ns2.v6ns.org return no actual  records, no errors reported,
> but there seem to be  records shown in the ADDITIONAL section of
> the query response.

Hi Rick,

Thanks for that. I wasn't in that discussion, were you discussing this
sort of issue? (for the .org zones in particular?)

I could be wrong, but would I be right in saying that glue records being
served up under the ADDITIONAL section is perfectly valid, not least
because by definition they are no authoritative for those records and
hence can be ignored (and/or not cached)? I'm guessing here...

> If I understand this correctly, the lack of an ANSWER section for 
> query would denote there is no ipv6 glue at the TLD?

Just to clarify, I'm seeing these weird results for the A records too - I
don't know if that matters either way.

However, surely there must be some glue otherwise where are they getting
the results from?

Mathew


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Niobos]

On 11 Jan 2010, at 18:29, Mathew J. Newton wrote:
Specifically, the Dig tool at http://www.kloth.net/services/dig.php  
seems
unable to resolve my records and I can't help but feel it's a  
problem at

my end rather than theirs!

It's their end


The domain is v6ns.org, and the record I am attempting to query for is
ns1.v6ns.org - here's what the Kloth Dig tool gets:



v6ns.org.   86400   IN  NS  ns1.v6ns.org.
v6ns.org.   86400   IN  NS  ns2.v6ns.org.
;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO)  
in 4 ms

If I retry this DNS-query, I get:

; <<>> DiG 9.4.3-P3 <<>> @A2.ORG.AFILIAS-NST.INFO ns1.v6ns.org.
; (2 servers found)
;; global options:  printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 52072
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns1.v6ns.org.  IN  A

;; AUTHORITY SECTION:
v6ns.org.   86400   IN  NS  ns1.v6ns.org.
v6ns.org.   86400   IN  NS  ns2.v6ns.org.

;; ADDITIONAL SECTION:
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2

;; Query time: 28 msec
;; SERVER: 2001:500:40::1#53(2001:500:40::1)
;; WHEN: Mon Jan 11 20:26:17 2010
;; MSG SIZE  rcvd: 150

Which seems perfectly valid for a v4&v6 delegation.


I set the domain up to experiment with IPv6, which could be why I've  
got a

problem...
Shouldn't, but might... I'm running a v4-v6 DNS right now and I've  
been through some trouble to get it working...


I have a single DNS server with a IPv4 address and two IPv6  
addresses. The

zone file is as follows:

$ORIGIN v6ns.org.
$TTL300
@   IN  SOA ns1.v6ns.org. dns.newtonnet.co.uk. (
   2010012000  ; Serial
   14400   ; Refresh
   7200; Retry
   950400  ; Expire
   300 )   ; Negative Cache TTL

   IN  NS  ns1.v6ns.org.
   IN  NS  ns2.v6ns.org.

ns1 IN  2a01:348:133::a1
ns1 IN  A   77.103.161.36
ns2 IN  2a01:348:6:a1::2

This is NOT how it's configured in the Glue:
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2


Local lookups for ns1.v6ns.org (A and  records) work fine, as they
also do from Men&Mice's online Dig tool. So why not Kloth's?
Possibly because it's broken. It works fine here; results conform to  
the zone you listed above.



I can't help but feel it is given the lack of an IPv4 A record for
ns2.v6ns.org - either as glue in .org or within my own v6ns.org  
zone. But

should this matter? In the absence of an IPv4 A-record for the
ns2.v6ns.org delegation in .org shouldn't their Dig attempt to  
connect to
ns1.v6ns.org instead (yes, they are the same machine but noone else  
knows

this but me... and you!)?
I'm not a DNS expert, but I think it should. However, currently there  
IS a A-glue for ns2


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

Re: Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Rick Dicaire]

On Mon, Jan 11, 2010 at 12:29 PM, Mathew J. Newton
 wrote:
> The same delegation records are present as glue in the .org nameservers.

While this is not in response to your original question, I am curious.
I'm not sure if you were part of the discussion we just had on IRC
freenode #ipv6, but querying a .org TLD NS for  records for ns1
and ns2.v6ns.org return no actual  records, no errors reported,
but there seem to be  records shown in the ADDITIONAL section of
the query response.

If I understand this correctly, the lack of an ANSWER section for 
query would denote there is no ipv6 glue at the TLD?

2001:500:e::1 being a0.org.afilias-nst.info, a .org TLD NS

; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>>  ns1.v6ns.org
@2001:500:e::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 38080
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns1.v6ns.org.  IN  

;; AUTHORITY SECTION:
v6ns.org.   86400   IN  NS  ns1.v6ns.org.
v6ns.org.   86400   IN  NS  ns2.v6ns.org.

;; ADDITIONAL SECTION:
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2

;; Query time: 102 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Mon Jan 11 12:44:13 2010
;; MSG SIZE  rcvd: 150



; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>>  ns2.v6ns.org
@2001:500:e::1
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 377
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 4
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns2.v6ns.org.  IN  

;; AUTHORITY SECTION:
v6ns.org.   86400   IN  NS  ns2.v6ns.org.
v6ns.org.   86400   IN  NS  ns1.v6ns.org.

;; ADDITIONAL SECTION:
ns2.v6ns.org.   86400   IN  2a01:348:6:a1::2
ns2.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  A   77.103.161.36
ns1.v6ns.org.   86400   IN  2a01:348:133::a1

;; Query time: 719 msec
;; SERVER: 2001:500:e::1#53(2001:500:e::1)
;; WHEN: Mon Jan 11 12:44:23 2010
;; MSG SIZE  rcvd: 150

An example showing glue in .com/.net:

; <<>> DiG 9.6.1-P2-RedHat-9.6.1-13.P2.fc12 <<>>  ns2.he.net
@G.GTLD-SERVERS.net
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 25892
;; flags: qr rd; QUERY: 1, ANSWER: 1, AUTHORITY: 5, ADDITIONAL: 9
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;ns2.he.net.IN  

;; ANSWER SECTION:
ns2.he.net. 172800  IN  2001:470:200::2

;; AUTHORITY SECTION:
he.net. 172800  IN  NS  ns1.he.net.
he.net. 172800  IN  NS  ns2.he.net.
he.net. 172800  IN  NS  ns3.he.net.
he.net. 172800  IN  NS  ns4.he.net.
he.net. 172800  IN  NS  ns5.he.net.

;; ADDITIONAL SECTION:
ns1.he.net. 172800  IN  A   216.218.130.2
ns2.he.net. 172800  IN  A   216.218.131.2
ns2.he.net. 172800  IN  2001:470:200::2
ns3.he.net. 172800  IN  A   216.218.132.2
ns3.he.net. 172800  IN  2001:470:300::2
ns4.he.net. 172800  IN  A   216.66.1.2
ns4.he.net. 172800  IN  2001:470:400::2
ns5.he.net. 172800  IN  A   216.66.80.18
ns5.he.net. 172800  IN  2001:470:500::2

;; Query time: 100 msec
;; SERVER: 192.42.93.30#53(192.42.93.30)
;; WHEN: Mon Jan 11 12:54:02 2010
;; MSG SIZE  rcvd: 334


-- 
aRDy Music and Rick Dicaire present:
http://www.ardynet.com
http://www.ardynet.com:9000/ardymusic.ogg.m3u
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Best way to run Bind on public DNS servers??

[Kaya Saman]

Kaya Saman wrote:

Hi all,

this is the first time I'm going to be playing around with a setup 
like this so I'd like to get some advice:


I would like to run a master/slave configuration of Bind servers but 
am confused about how to implement such a setup and the underlying 
network fabric involved!!


First up, currently in my lab I am running an authoritative DNS server 
through NAT so when people make queries it goes through port 53 on my 
Cisco 857's ADSL interface then reaches the server with an internal 
private IP address.


I know that I can use 2 different public IP addresses and implement 
this via NAT opening up static NAT definitions from both WAN IP's to 
internal private IP's of the servers; however. is this the best 
practice or should I give the servers public addresses on one of their 
NICs then run the named service from their???


I plan to upgrade to a Cisco 1800 series which has two routable ports 
in either Ethernet or ADSL and Ethernet configurations and has a 
managed 8 port switch which I am sure can be included to be outside 
the NAT making it easy to tie the servers in to the network.


I've never dealt with a setup like this before as everything I've done 
so far has been behind NAT so I'm a little confused about how to go 
about it. I know this is probably more of a thing for the Cisco 
Netpro forum but since I am going to be dealing with Bind there maybe 
a way I can get around with NAT depending on what the experts or more 
experienced people say!


Many thanks for any responses!

Best regards,

Kaya


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


Hi, since I got no responses for this question could I rephrase it to 
asking if Bind will do a zone transfer over public internet if the 
servers have private IP addresses and are behind NAT with static port 
definitions?


Regards,

Kaya

P.s. as an extra what or how is the best way to learn about DNS? Of 
course on this mailing list there are many pros and knowledgeable people 
but for someone like me who is keen and enthusiastic but hasn't had the 
opportunity to work for a company that deals in DNS, network design or 
data centers I find myself with more questions then answers! Basically 
no professional experience is what's holding me back I feel - Thanks

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

Re: 9.4.3 oddities

[Cathy Almond]

The problem reported below proves to have been resolved by this change:

2797. [bug] Don't decrement the dispatch manager's maxbuffers.
[RT #20613]

When randomized query ports was implemented, the increase in the number
concurrently-used sockets had an equivalent increased usage need of
another resource - the dispatch manager buffer pool.  This was of course
enlarged too, but an oversight meant that it could be reduced again in
some circumstances.

The reason that the rndc reconfig buys temporary relief is that it runs
through the configuration file again and revisits and reapplies the
initial large pool size decision.

The fix is currently available in 9.7.0rc1 and 9.6.2b1 will be included
in the upcoming BIND Extended Support Versions (ESVs).

Imri Zvik wrote:
> Hi,
> 
> We've recently upgraded our caching servers to 9.4.3-P4/P3 (2 of them running 
> 9.4.3-P4 and 2 running 9.4.3-P3). Few days ago I've noticed something 
> strange - When the server is loaded, some queries randomly fails (SERVFAIL). 
> It seems that only queries for which the answer is NOT cached are affected.
> I've verified with host/dig and tcpdump that there is no network issue (no 
> unanswered packets). Digging deeper into the issue, I've found that the issue 
> appears when the number of sockets used by named approach 1024~ (checked with 
> netstat/lsof). The weirdest part, is that if I run "rndc reconfig", suddenly 
> named is able to use more than 1024 sockets (I've seen it using 4000-5000~ 
> sockets), and the problem goes away for about an hour.
> 
> If I downgrade to 3.4.2-P2 the problems goes away.
> 
> I used the following command to reproduce the problem:
> for i in {1..10}; do dig mx www.cnn.com @localhost |grep status |grep -v 
> NOERROR; done
> 
> My servers are running RHEL 5.4 (2.6.18-164.9.1.el5) and FreeBSD 7.0 (the 
> problem is seen on both), and they are splitted into two, unrelated, 
> networks, and on two separate physical locations.
> 
> I've compiled bind from the vanilla ISC sources using the following configure 
> command:
> 
> ./configure --enable-threads --enable-largefile --prefix=/usr/local
> 
> I've also tried the following (I've also raised the OS limits, of course):
> STD_CDEFINES="-DISC_SOCKET_FDSETSIZE=1048576" ./configure --enable-threads 
> --enable-largefile --prefix=/usr/local
> 
> As I was seeing the "general: error: socket: file descriptor exceeds limit 
> (4096/4096)" error a couple of days ago.
> 
> My best guess is that the problem is related to the recent move to epoll...
> 
> Any ideas on how I should proceed from here? 
> ___
> 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

Is an IPv6-only glue/delegation record a problem in a world of IPv4?

[Mathew J. Newton]

I would be grateful if someone might be able to shed some light on an
apparent problem I've got with an experimental DNS I have setup.

Specifically, the Dig tool at http://www.kloth.net/services/dig.php seems
unable to resolve my records and I can't help but feel it's a problem at
my end rather than theirs!

The domain is v6ns.org, and the record I am attempting to query for is
ns1.v6ns.org - here's what the Kloth Dig tool gets:

[dig 'ns1.v6ns.org' 'A' +trace]

 dig: couldn't get address for 'ns1.v6ns.org': failure

 ; <<>> DiG 9.3.2 <<>> ns1.v6ns.org A +trace
 ;; global options:  printcmd
 .  301721  IN  NS  I.ROOT-SERVERS.NET.
 .  301721  IN  NS  J.ROOT-SERVERS.NET.
 .  301721  IN  NS  K.ROOT-SERVERS.NET.
 .  301721  IN  NS  L.ROOT-SERVERS.NET.
 .  301721  IN  NS  M.ROOT-SERVERS.NET.
 .  301721  IN  NS  A.ROOT-SERVERS.NET.
 .  301721  IN  NS  B.ROOT-SERVERS.NET.
 .  301721  IN  NS  C.ROOT-SERVERS.NET.
 .  301721  IN  NS  D.ROOT-SERVERS.NET.
 .  301721  IN  NS  E.ROOT-SERVERS.NET.
 .  301721  IN  NS  F.ROOT-SERVERS.NET.
 .  301721  IN  NS  G.ROOT-SERVERS.NET.
 .  301721  IN  NS  H.ROOT-SERVERS.NET.
 ;; Received 228 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

 org.   172800  IN  NS  A2.ORG.AFILIAS-NST.INFO.
 org.   172800  IN  NS  A0.ORG.AFILIAS-NST.INFO.
 org.   172800  IN  NS  D0.ORG.AFILIAS-NST.org.
 org.   172800  IN  NS  C0.ORG.AFILIAS-NST.INFO.
 org.   172800  IN  NS  B0.ORG.AFILIAS-NST.org.
 org.   172800  IN  NS  B2.ORG.AFILIAS-NST.org.
 ;; Received 432 bytes from 192.36.148.17#53(I.ROOT-SERVERS.NET) in 8 ms

 v6ns.org.  86400   IN  NS  ns1.v6ns.org.
 v6ns.org.  86400   IN  NS  ns2.v6ns.org.
 ;; Received 150 bytes from 199.249.112.1#53(A2.ORG.AFILIAS-NST.INFO) in 4 ms

I set the domain up to experiment with IPv6, which could be why I've got a
problem...

I have a single DNS server with a IPv4 address and two IPv6 addresses. The
zone file is as follows:

$ORIGIN v6ns.org.
$TTL300
@   IN  SOA ns1.v6ns.org. dns.newtonnet.co.uk. (
2010012000  ; Serial
14400   ; Refresh
7200; Retry
950400  ; Expire
300 )   ; Negative Cache TTL

IN  NS  ns1.v6ns.org.
IN  NS  ns2.v6ns.org.

ns1 IN  2a01:348:133::a1
ns1 IN  A   77.103.161.36
ns2 IN  2a01:348:6:a1::2

The same delegation records are present as glue in the .org nameservers.

Local lookups for ns1.v6ns.org (A and  records) work fine, as they
also do from Men&Mice's online Dig tool. So why not Kloth's?

I can't help but feel it is given the lack of an IPv4 A record for
ns2.v6ns.org - either as glue in .org or within my own v6ns.org zone. But
should this matter? In the absence of an IPv4 A-record for the
ns2.v6ns.org delegation in .org shouldn't their Dig attempt to connect to
ns1.v6ns.org instead (yes, they are the same machine but noone else knows
this but me... and you!)?

I would be grateful for any assistance, and would be more than happy to
provide further details if the above is insufficient.

Mathew




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

R: Logging problems on Bind9

[Autuori Gianluigi]

 I moved my query.log to /var/log/named/ and I correct named.local.conf to log 
there

-Messaggio originale-
Da: bind-users-bounces+autuori.gianluigi.wintime=ansaldobreda...@lists.isc.org 
[mailto:bind-users-bounces+autuori.gianluigi.wintime=ansaldobreda...@lists.isc.org]
 Per conto di Autuori Gianluigi
Inviato: lunedì 11 gennaio 2010 13.36
A: Hauke Lampe
Cc: bind-users@lists.isc.org
Oggetto: R: Logging problems on Bind9

Thanks, now it works fine 

-Messaggio originale-
Da: Hauke Lampe [mailto:list+bindus...@hauke-lampe.de]
Inviato: lunedì 11 gennaio 2010 13.15
A: Autuori Gianluigi
Cc: bind-users@lists.isc.org
Oggetto: Re: Logging problems on Bind9

Autuori Gianluigi wrote:

> I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
> Named runs as bind user and in my named.conf.local I wrote:

Ubuntu uses AppArmor (http://en.wikipedia.org/wiki/AppArmor)

You need to edit the profile for usr.sbin.named in /etc/apparmor.d/ if you want 
named to write files outside the allowed directories.

The easier way would be to move your query.log to /var/log/named/ as this 
directory is allowed by default.

/etc/apparmor.d/usr.sbin.named:

/usr/sbin/named {
[...]
  # some people like to put logs in /var/log/named/ instead of having
  # syslog do the heavy lifting.
  /var/log/named/** rw,
  /var/log/named/ rw,
}


HTH,
Hauke.




Questo messaggio e-mail e ogni documento ad esso eventualmente allegato puo' 
avere carattere riservato ed essere tutelato da segreto. Esso,comunque, e'
ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il 
destinatario del messaggio vi preghiamo di volerci avvertire immediatamente per 
e-mail o telefono e di cancellare il presente messaggio e ogni eventuale 
allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per 
qualunque fine del messaggio e di ogni allegato, nonche' la loro divulgazione, 
distribuzione o inoltro a terzi senza l'espressa autorizzazione del mittente. 
In ragione del mezzo di trasmissione utilizzato, il mittente non assume alcuna 
responsabilita' sulla segretezza/riservatezza delle informazioni contenute nel 
messaggio e nei relativi allegati. 

This e-mail and any file transmitted with it may contain material that is 
confidential, privileged and/or attorney work product for the sole use of the 
intended recipient. If you are not the intended recipient of this e-mail, 
please do not read it, notify us immediately by e-mail or by telephone and then 
delete this message and any file attached from your system. You should not copy 
or use it for any purpose, disclose the contents of the same to any other 
person or forward it without express permission.
Considering the means of transmission, we do not undertake any liability with 
respect to the secrecy and confidentiality of the information contained in this 
e-mail and its attachments.

___
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

R: Logging problems on Bind9

[Autuori Gianluigi]

Thanks, now it works fine 

-Messaggio originale-
Da: Hauke Lampe [mailto:list+bindus...@hauke-lampe.de] 
Inviato: lunedì 11 gennaio 2010 13.15
A: Autuori Gianluigi
Cc: bind-users@lists.isc.org
Oggetto: Re: Logging problems on Bind9

Autuori Gianluigi wrote:

> I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
> Named runs as bind user and in my named.conf.local I wrote:

Ubuntu uses AppArmor (http://en.wikipedia.org/wiki/AppArmor)

You need to edit the profile for usr.sbin.named in /etc/apparmor.d/ if you want 
named to write files outside the allowed directories.

The easier way would be to move your query.log to /var/log/named/ as this 
directory is allowed by default.

/etc/apparmor.d/usr.sbin.named:

/usr/sbin/named {
[...]
  # some people like to put logs in /var/log/named/ instead of having
  # syslog do the heavy lifting.
  /var/log/named/** rw,
  /var/log/named/ rw,
}


HTH,
Hauke.




Questo messaggio e-mail e ogni documento ad esso eventualmente allegato puo' 
avere carattere riservato ed essere tutelato da segreto. Esso,comunque, e'
ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il 
destinatario del messaggio vi preghiamo di volerci avvertire immediatamente per 
e-mail o telefono e di cancellare il presente messaggio e ogni eventuale 
allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per 
qualunque fine del messaggio e di ogni allegato, nonche' la loro divulgazione, 
distribuzione o inoltro a terzi senza l'espressa autorizzazione del mittente. 
In ragione del mezzo di trasmissione utilizzato, il mittente non assume alcuna 
responsabilita' sulla segretezza/riservatezza delle informazioni contenute nel 
messaggio e nei relativi allegati. 

This e-mail and any file transmitted with it may contain material that is 
confidential, privileged and/or attorney work product for the sole use of the 
intended recipient. If you are not the intended recipient of this e-mail, 
please do not read it, notify us immediately by e-mail or by telephone and then 
delete this message and any file attached from your system. You should not copy 
or use it for any purpose, disclose the contents of the same to any other 
person or forward it without express permission.
Considering the means of transmission, we do not undertake any liability with 
respect to the secrecy and confidentiality of the information contained in this 
e-mail and its attachments.

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

R: Logging problems on Bind9

[Autuori Gianluigi]

Tahnks...
I check it but selinux is not installed 

-Messaggio originale-
Da: Chris Buxton [mailto:chris.p.bux...@gmail.com] 
Inviato: lunedì 11 gennaio 2010 12.47
A: Autuori Gianluigi
Cc: bind-users@lists.isc.org
Oggetto: Re: Logging problems on Bind9

You're seeing a message from SELinux. Turn it off, or set it to permissive 
mode, to allow this to work. Or you can try to add the necessary permission to 
the profile for named; this is not something I've ever done, so I can't give 
guidance.

Chris Buxton

On Jan 11, 2010, at 3:24 AM, Autuori Gianluigi wrote:

> I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
> Named runs as bind user and in my named.conf.local I wrote:
> 
> logging {
>   channel query.log {
>   file "/var/log/query.log";
>   severity dynamic;
>   };
>   category queries { query.log; };
> };
> 
> but in /var/log/messages:
> 
> Jan 11 09:16:24 vmcm3-01 kernel: [  983.091894]
> audit(1263197784.510:10): type=1503 operation="inode_permission"
> requested_mask="a::" denied_mask="a::" name="/var/log/query.log"
> pid=4156 profile="/usr/sbin/named" namespace="default"
> 
> The user ov /var/log/query.log is bind and the group is bind with mask
> 664
> 
> Where is the problem?
> 
> --
> -- Questo messaggio e-mail e ogni documento ad esso 
> eventualmente allegato puo' avere carattere riservato ed essere tutelato da 
> segreto. Esso,comunque, e'
> ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il 
> destinatario del messaggio vi preghiamo di volerci avvertire immediatamente 
> per e-mail o telefono e di cancellare il presente messaggio e ogni eventuale 
> allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per 
> qualunque fine del messaggio e di ogni allegato, nonche' la loro 
> divulgazione, distribuzione o inoltro a terzi senza l'espressa autorizzazione 
> del mittente. In ragione del mezzo di trasmissione utilizzato, il mittente 
> non assume alcuna responsabilita' sulla segretezza/riservatezza delle 
> informazioni contenute nel messaggio e nei relativi allegati. 
> 
> This e-mail and any file transmitted with it may contain material that is 
> confidential, privileged and/or attorney work product for the sole use of the 
> intended recipient. If you are not the intended recipient of this e-mail, 
> please do not read it, notify us immediately by e-mail or by telephone and 
> then delete this message and any file attached from your system. You should 
> not copy or use it for any purpose, disclose the contents of the same to any 
> other person or forward it without express permission.
> Considering the means of transmission, we do not undertake any liability with 
> respect to the secrecy and confidentiality of the information contained in 
> this e-mail and its attachments.
> 
> ___
> 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: Logging problems on Bind9

[Hauke Lampe]

Autuori Gianluigi wrote:

> I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
> Named runs as bind user and in my named.conf.local I wrote:

Ubuntu uses AppArmor (http://en.wikipedia.org/wiki/AppArmor)

You need to edit the profile for usr.sbin.named in /etc/apparmor.d/ if
you want named to write files outside the allowed directories.

The easier way would be to move your query.log to /var/log/named/ as
this directory is allowed by default.

/etc/apparmor.d/usr.sbin.named:

/usr/sbin/named {
[...]
  # some people like to put logs in /var/log/named/ instead of having
  # syslog do the heavy lifting.
  /var/log/named/** rw,
  /var/log/named/ rw,
}


HTH,
Hauke.



signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Logging problems on Bind9

[Chris Buxton]

You're seeing a message from SELinux. Turn it off, or set it to permissive 
mode, to allow this to work. Or you can try to add the necessary permission to 
the profile for named; this is not something I've ever done, so I can't give 
guidance.

Chris Buxton

On Jan 11, 2010, at 3:24 AM, Autuori Gianluigi wrote:

> I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
> Named runs as bind user and in my named.conf.local I wrote:
> 
> logging {
>   channel query.log {
>   file "/var/log/query.log";
>   severity dynamic;
>   };
>   category queries { query.log; };
> };
> 
> but in /var/log/messages:
> 
> Jan 11 09:16:24 vmcm3-01 kernel: [  983.091894]
> audit(1263197784.510:10): type=1503 operation="inode_permission"
> requested_mask="a::" denied_mask="a::" name="/var/log/query.log"
> pid=4156 profile="/usr/sbin/named" namespace="default"
> 
> The user ov /var/log/query.log is bind and the group is bind with mask
> 664
> 
> Where is the problem?
> 
> 
> Questo messaggio e-mail e ogni documento ad esso eventualmente allegato puo' 
> avere carattere riservato ed essere tutelato da segreto. Esso,comunque, e'
> ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il 
> destinatario del messaggio vi preghiamo di volerci avvertire immediatamente 
> per e-mail o telefono e di cancellare il presente messaggio e ogni eventuale 
> allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per 
> qualunque fine del messaggio e di ogni allegato, nonche' la loro 
> divulgazione, distribuzione o inoltro a terzi senza l'espressa autorizzazione 
> del mittente. In ragione del mezzo di trasmissione utilizzato, il mittente 
> non assume alcuna responsabilita' sulla segretezza/riservatezza delle 
> informazioni contenute nel messaggio e nei relativi allegati. 
> 
> This e-mail and any file transmitted with it may contain material that is 
> confidential, privileged and/or attorney work product for the sole use of the 
> intended recipient. If you are not the intended recipient of this e-mail, 
> please do not read it, notify us immediately by e-mail or by telephone and 
> then delete this message and any file attached from your system. You should 
> not copy or use it for any purpose, disclose the contents of the same to any 
> other person or forward it without express permission.
> Considering the means of transmission, we do not undertake any liability with 
> respect to the secrecy and confidentiality of the information contained in 
> this e-mail and its attachments.
> 
> ___
> 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

Logging problems on Bind9

[Autuori Gianluigi]

I'm using Bind9 and Ubuntu 8.04 kernel 2.6.24.
Named runs as bind user and in my named.conf.local I wrote:

logging {
channel query.log {
file "/var/log/query.log";
severity dynamic;
};
category queries { query.log; };
};

but in /var/log/messages:

Jan 11 09:16:24 vmcm3-01 kernel: [  983.091894]
audit(1263197784.510:10): type=1503 operation="inode_permission"
requested_mask="a::" denied_mask="a::" name="/var/log/query.log"
pid=4156 profile="/usr/sbin/named" namespace="default"

The user ov /var/log/query.log is bind and the group is bind with mask
664

Where is the problem?


Questo messaggio e-mail e ogni documento ad esso eventualmente allegato puo' 
avere carattere riservato ed essere tutelato da segreto. Esso,comunque, e'
ad esclusivo utilizzo del destinatario in indirizzo. Qualora non foste il 
destinatario del messaggio vi preghiamo di volerci avvertire immediatamente per 
e-mail o telefono e di cancellare il presente messaggio e ogni eventuale 
allegato dal vostro sistema. E' vietata la duplicazione o l'utilizzo per 
qualunque fine del messaggio e di ogni allegato, nonche' la loro divulgazione, 
distribuzione o inoltro a terzi senza l'espressa autorizzazione del mittente. 
In ragione del mezzo di trasmissione utilizzato, il mittente non assume alcuna 
responsabilita' sulla segretezza/riservatezza delle informazioni contenute nel 
messaggio e nei relativi allegati. 

This e-mail and any file transmitted with it may contain material that is 
confidential, privileged and/or attorney work product for the sole use of the 
intended recipient. If you are not the intended recipient of this e-mail, 
please do not read it, notify us immediately by e-mail or by telephone and then 
delete this message and any file attached from your system. You should not copy 
or use it for any purpose, disclose the contents of the same to any other 
person or forward it without express permission.
Considering the means of transmission, we do not undertake any liability with 
respect to the secrecy and confidentiality of the information contained in this 
e-mail and its attachments.

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