nxdomain not caching for configured reverse lookup
Hi,
I have the following zone configuration for forwarding DNS query
view default IN {
max-cache-ttl 604800;
max-ncache-ttl 10800;
zone . IN {
type forward;
forwarders {161.69.96.5;};
forward only;
};
zone 7.7.7.7.in-addr.arpa IN {
type forward;
forwarders {10.212.24.11;};
forward only;
};
};
when I do dig -x 9.9.9.9, which is not in the configured zone for DNS
which falls to the default DNS server 161.69.96.5, i get the resonses cached
and when i do dig -x 7.7.7.7, which is in the configured zone for DNS
10.212.24.11, i am not able to get the responses cached.
When i reverse the DNS entries for the default and the configured zones, i
get the same answer.
I would like to get the configured zones NXDOMAIN also cached, so that the
next time, the request comes, it should be served from the cache.
What am I missing?
Thanks
S
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nxdomain not caching for configured reverse lookup
On 20.08.13 15:42, sumsum 2000 wrote:
zone 7.7.7.7.in-addr.arpa IN {
type forward;
forwarders {10.212.24.11;};
forward only;
};
and when i do dig -x 7.7.7.7, which is in the configured zone for DNS
10.212.24.11, i am not able to get the responses cached.
what is the TTL of those NXDOMAIN answers?
--
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.
Remember half the people you know are below average.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
bind-users Digest, Vol 1603, Issue 1
Je suis absent jusqu'au 23 Août 2013 inclus. En cas d'urgence, vous pouvez contacter RASOAMANANA Ranto (Mob: +261320701232, e-mail: ranto.rasoaman...@orange.com). Confidentiality: This email is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Confidentialité: Ce message et les documents joints sont protégés et confidentiels. Ils sont exclusivement destinés aux personnes nommément visées ci-dessus. Toutes opinions exprimées dans cette communication ne sont pas nécessairement celles de la Société. Si celui-ci arrive chez vous par erreur, ne prenez aucune action, n'en faites pas de copie merci de bien vouloir le supprimer et en informer l'expéditeur immédiatement. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nxdomain not caching for configured reverse lookup
[root@FF15763 var]# dig -x 7.7.7.7
; DiG 9.8.2rc1-RedHat-9.8.2-16.mlos2 -x 7.7.7.7
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 62698
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;7.7.7.7.in-addr.arpa.INPTR
;; Query time: 295 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 20 15:49:24 2013
;; MSG SIZE rcvd: 38
[root@FF15763 var]# dig -x 9.9.9.9
; DiG 9.8.2rc1-RedHat-9.8.2-16.mlos2 -x 9.9.9.9
;; global options: +cmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 56762
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;9.9.9.9.in-addr.arpa.INPTR
;; AUTHORITY SECTION:
in-addr.arpa.900INSOAb.in-addr-servers.arpa.
nstld.iana.org. 2011029209 1800 900 604800 3600
;; Query time: 326 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Aug 20 15:49:29 2013
;; MSG SIZE rcvd: 106
On Tue, Aug 20, 2013 at 3:49 PM, Matus UHLAR - fantomas
uh...@fantomas.skwrote:
On 20.08.13 15:42, sumsum 2000 wrote:
zone 7.7.7.7.in-addr.arpa IN {
type forward;
forwarders {10.212.24.11;};
forward only;
};
and when i do dig -x 7.7.7.7, which is in the configured zone for DNS
10.212.24.11, i am not able to get the responses cached.
what is the TTL of those NXDOMAIN answers?
--
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.
Remember half the people you know are below average.
__**_
Please visit
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nxdomain not caching for configured reverse lookup
The forward zone is not for a zone cut in the DNS tree. As a result the SOA record is above the zone and the SOA record gets ignored. In practice almost all forwarded zones match a actual zone so the returned SOA record is accepted. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.1-P1: 'make test' fails
On 22 Nov 2011, at 11:24, Niall O'Reilly wrote: Since quite a few years, I habitually run 'make test' after building BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether anyone else is also. [By way of putting this to bed, at last ...] Updating the Perl module Net::DNS to a recent version seems to be what is needed to make the test which was failing (labelled 'xfer') run successfully. I don't know the cut-off point between 'old' and 'recent' version of Net::DNS. I've had success with 0.65 and 0.66; current is 0.72. An 'old' version will cause the 'xfer' test to fail in BIND releases subsequent to 9.8.1-P1, including current releases. Best regards, /Niall ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: nxdomain not caching for configured reverse lookup
On 20.08.13 15:42, sumsum 2000 wrote:
zone 7.7.7.7.in-addr.arpa IN {
type forward;
forwarders {10.212.24.11;};
forward only;
};
On 20.08.13 21:19, Mark Andrews wrote:
The forward zone is not for a zone cut in the DNS tree. As a result
the SOA record is above the zone and the SOA record gets ignored.
In practice almost all forwarded zones match a actual zone so the
returned SOA record is accepted.
which means you need to forward 7.7.7.in-addr.arpa, 7.7.in-addr.arpa or
7.in-addr.arpa, depending on what is configured on 10.212.24.11.
BTW, are you aware that 7.7.7.7 is used by DoD and 9.9.9.9 by IBM?
--
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.
Depression is merely anger without enthusiasm.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: nxdomain not caching for configured reverse lookup
The use of 7.7.7.7 and 9.9.9.9 was used for testing purpose. This test is
to cover the scenario, if I have a reverse lookup which is not configured
on 10.212.24.11, i was expecting it to return NXDOMAIN and have it cached.
This is not the ideal scenario of usage, but to check the condition, if it
is not configured correctly.
On Tue, Aug 20, 2013 at 6:07 PM, Matus UHLAR - fantomas
uh...@fantomas.skwrote:
On 20.08.13 15:42, sumsum 2000 wrote:
zone 7.7.7.7.in-addr.arpa IN {
type forward;
forwarders {10.212.24.11;};
forward only;
};
On 20.08.13 21:19, Mark Andrews wrote:
The forward zone is not for a zone cut in the DNS tree. As a result
the SOA record is above the zone and the SOA record gets ignored.
In practice almost all forwarded zones match a actual zone so the
returned SOA record is accepted.
which means you need to forward 7.7.7.in-addr.arpa, 7.7.in-addr.arpa or
7.in-addr.arpa, depending on what is configured on 10.212.24.11.
BTW, are you aware that 7.7.7.7 is used by DoD and 9.9.9.9 by IBM?
--
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.
Depression is merely anger without enthusiasm.
__**_
Please visit
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-usersto
unsubscribe from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/**listinfo/bind-usershttps://lists.isc.org/mailman/listinfo/bind-users
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.1-P1: 'make test' fails
On Aug 20, 2013, at 5:11 AM, Niall O'Reilly niall.orei...@ucd.ie wrote: On 22 Nov 2011, at 11:24, Niall O'Reilly wrote: Since quite a few years, I habitually run 'make test' after building BIND from sources. I'me seiing a failure with 9.8.1-P1, and wonder whether anyone else is also. [By way of putting this to bed, at last ...] Updating the Perl module Net::DNS to a recent version seems to be what is needed to make the test which was failing (labelled 'xfer') run successfully. I don't know the cut-off point between 'old' and 'recent' version of Net::DNS. I've had success with 0.65 and 0.66; current is 0.72. An 'old' version will cause the 'xfer' test to fail in BIND releases subsequent to 9.8.1-P1, including current releases. There is a mailing list for Net::DNS. List-Subscribe: https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users, mailto:net-dns-users-requ...@nlnetlabs.nl?subject=subscribe That said, there was a discussion last December about what has changed since Net::DNS was taken over by a new maintainer, meaning post-0.68. A small number of quite disruptive changes were made in 0.69. Regards, Chris Buxton ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: BIND 9.8.1-P1: 'make test' fails
On 20 Aug 2013, at 15:08, Chris Buxton wrote: There is a mailing list for Net::DNS. List-Subscribe: https://www.nlnetlabs.nl/mailman/listinfo/net-dns-users, mailto:net-dns-users-requ...@nlnetlabs.nl?subject=subscribe That said, there was a discussion last December about what has changed since Net::DNS was taken over by a new maintainer, meaning post-0.68. A small number of quite disruptive changes were made in 0.69. Thanks, Chris. For problem at hand, the break-point of interest is somewhere between 0.31 and 0.65. 8-) Niall ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-users Digest, Vol 1603, Issue 3
Je suis absent jusqu'au 23 Août 2013 inclus. En cas d'urgence, vous pouvez contacter RASOAMANANA Ranto (Mob: +261320701232, e-mail: ranto.rasoaman...@orange.com). Confidentiality: This email is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Confidentialité: Ce message et les documents joints sont protégés et confidentiels. Ils sont exclusivement destinés aux personnes nommément visées ci-dessus. Toutes opinions exprimées dans cette communication ne sont pas nécessairement celles de la Société. Si celui-ci arrive chez vous par erreur, ne prenez aucune action, n'en faites pas de copie merci de bien vouloir le supprimer et en informer l'expéditeur immédiatement. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
d root server
Hello, Why do I still get the following in my logs even after downloading the latest version root hint file. checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: d root server
Thanks Edward, I didn't think I needed to edit the downloaded root hint file. In fact the d.root-server.net server is assigned the IP address in the dig output below. I do not know where 128.8.10.90 comes from. dig d.root-servers.net ; DiG 9.7.2-P3 d.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;d.root-servers.net.IN A ;; ANSWER SECTION: d.root-servers.net. 156446 IN A 199.7.91.13 Regards, Rohan On Tue, 20 Aug 2013 14:20:23 -0400 Edward DeLargy eddela...@gmail.com wrote: Ah..I also just thought of thisensure that you have two seperate IPs for the server in the hints..you may have two entries with the same IP. Regards, Ed On Tue, Aug 20, 2013 at 2:12 PM, rohan.he...@cwjamaica.com wrote: Hello, Why do I still get the following in my logs even after downloading the latest version root hint file. checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind99 and a slave named server
On 18 Aug 2013, at 19:20 , Noel Butler noel.but...@ausics.net wrote: As has been said already, there is really very little to it, and unless you sent it to Alan off-list, you still have _NOT_ provided the error logs after being asked by more than one person. Thanks, I thought I was clear. I am *not* getting any errors, so there are no error logs. However, I am currently running each server as a master. What I am looking for is something (docs, a writeup, a how-to, anything) on converting a master bind 9.9 server to a slave bind 9.9 server. I see a lot on converting a slave to a master. Things that I know are issues I want to cover before I make changes. 1. RAW versus TEXT 2. allow transfer 3. notify 4. key files1 5. dnssec-enable 6. managed-keys and any changes in how root servers are setup since I am pretty sure that has changed since I first setup bind 9.1 many eons ago (2002?). 1 For example, right now, since server 2 is an exact copy of server 1 with IPs changed, the two machines have identical rndc-key files. -- A clear conscience is usually the sign of a bad memory. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
rrset-order code
HI
I'm working on a DNS project, which is weighted load balancing DNS which
depends on weight of a serveres that have the page we want to lookup to order
the returned list of the IP.
My question is:
we know in bind that we use rrset-order{ order random;}//where is the piece of
code that implement the random function in BIND9
so i can edit it to reach my goal
Nidal
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
duplicate records
we know that BIND eleminate duplicate records, which version of BIND that doesn't do that ? NIDAL ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rrset-order code
On Aug 20, 2013, at 3:13 PM, Nidal Shater ngiw2...@hotmail.com wrote:
we know in bind that we use rrset-order{ order random;}//where is the piece
of code that implement the random function in BIND9
so i can edit it to reach my goal
Even if you force BIND to return an RRSET in a given order (look for the code
that is enabled with the compile time option --with-fixed-rrset to see how
fixed responses are provided), you still have to make the default in every
recursive nameserver to NOT randomize the response.
ie, it ain't gonna work like you want it to on the Internet
AlanC
--
Alan Clegg | +1-919-355-8851 | a...@clegg.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
bind-users Digest, Vol 1603, Issue 4
Je suis absent jusqu'au 23 Août 2013 inclus. En cas d'urgence, vous pouvez contacter RASOAMANANA Ranto (Mob: +261320701232, e-mail: ranto.rasoaman...@orange.com). Confidentiality: This email is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Confidentialité: Ce message et les documents joints sont protégés et confidentiels. Ils sont exclusivement destinés aux personnes nommément visées ci-dessus. Toutes opinions exprimées dans cette communication ne sont pas nécessairement celles de la Société. Si celui-ci arrive chez vous par erreur, ne prenez aucune action, n'en faites pas de copie merci de bien vouloir le supprimer et en informer l'expéditeur immédiatement. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: duplicate records
Since such behavior would flagrantly violate RFC 2181, Section 5, look for a version prior to the publication date of that RFC (July 1997). - Kevin On 8/20/2013 3:14 PM, Nidal Shater wrote: we know that BIND eleminate duplicate records, which version of BIND that doesn't do that ? NIDAL ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind99 and a slave named server
On Aug 20, 2013, at 2:36 PM, LuKreme krem...@kreme.com wrote:
On 18 Aug 2013, at 19:20 , Noel Butler noel.but...@ausics.net wrote:
As has been said already, there is really very little to it, and unless you
sent it to Alan off-list, you still have _NOT_ provided the error logs
after being asked by more than one person.
Thanks, I thought I was clear.
I am *not* getting any errors, so there are no error logs. However, I am
currently running each server as a master.
You started this thread with I was getting errors so I switched to all
masters -- we wanted to help you fix the initial problem. We've now gone off
on a don't fix the old stuff, make new stuff work tangent, so, never mind
about the error messages.
What I am looking for is something (docs, a writeup, a how-to, anything) on
converting a master bind 9.9 server to a slave bind 9.9 server. I see a lot
on converting a slave to a master.
You don't find anything, because it's so easy:
To convert master to slave:
if you have:
zone example.com {
type master;// I own this.
file files/example.com; // Here's where I read them from
};
it will become:
zone example.com {
type slave; // Now a slave
file files/example.com; // Must now be writable by BIND
masters { 192.168.1.1; }; // IP address of master server here
};
Bazinga!
1. RAW versus TEXT
2. allow transfer
3. notify
4. key files1
5. dnssec-enable
6. managed-keys
1: you don't care, as the new slave will xfer over the old data
2: read the documentation, it's not part of master/slave transition, setup
good acls
3: notify just works unless you have odd configuration
4: you don't want the same key files on more than one server
5: not related to master/slave, just leave it enabled
6: that's dnssec-validation related
If you have any specific questions on these items, ask them, otherwise there
are a number of classes around (I teach one of them, several other people on
the list [that have responded to you, if I remember right] also teach them) and
I would recommend either a class or a book (again, several come to mind).
A fantastic (free) resource is: http://www.zytrax.com/books/dns/
and any changes in how root servers are setup since I am pretty sure that has
changed since I first setup bind 9.1 many eons ago (2002?).
If you are Internet visible, you don't do anything with configuring anything
about the roots, as it just works (compiled into bind since 9.3ish).
AlanC
--
Alan Clegg | +1-919-355-8851 | a...@clegg.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: d root server
Edward, Agreed. My concern though is why the following show up in my logs when the IP is already in the root hint file. checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan On Tue, 20 Aug 2013 14:40:09 -0400 Edward DeLargy eddela...@gmail.com wrote: Rohan, Normally you shouldn't need to. However, sometimes errors happen and we just need to correct them as they come. Regards, Ed On Tue, Aug 20, 2013 at 2:26 PM, rohan.he...@cwjamaica.com wrote: Thanks Edward, I didn't think I needed to edit the downloaded root hint file. In fact the d.root-server.net server is assigned the IP address in the dig output below. I do not know where 128.8.10.90 comes from. dig d.root-servers.net ; DiG 9.7.2-P3 d.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;d.root-servers.net.IN A ;; ANSWER SECTION: d.root-servers.net. 156446 IN A 199.7.91.13 Regards, Rohan On Tue, 20 Aug 2013 14:20:23 -0400 Edward DeLargy eddela...@gmail.com wrote: Ah..I also just thought of thisensure that you have two seperate IPs for the server in the hints..you may have two entries with the same IP. Regards, Ed On Tue, Aug 20, 2013 at 2:12 PM, rohan.he...@cwjamaica.com wrote: Hello, Why do I still get the following in my logs even after downloading the latest version root hint file. checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: d root server
Your bind code is old and has the old info in it. D root changed it's ip address. Bind has a built-in hints file, in case you don't setup one and it probably has the old ip address for the D root. http://blog.icann.org/2012/12/d-root/ Lyle Giese LCR Computer Services, Inc. On 08/20/13 15:44, rohan.he...@cwjamaica.com wrote: Edward, Agreed. My concern though is why the following show up in my logs when the IP is already in the root hint file. checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan On Tue, 20 Aug 2013 14:40:09 -0400 Edward DeLargy eddela...@gmail.com wrote: Rohan, Normally you shouldn't need to. However, sometimes errors happen and we just need to correct them as they come. Regards, Ed On Tue, Aug 20, 2013 at 2:26 PM, rohan.he...@cwjamaica.com wrote: Thanks Edward, I didn't think I needed to edit the downloaded root hint file. In fact the d.root-server.net server is assigned the IP address in the dig output below. I do not know where 128.8.10.90 comes from. dig d.root-servers.net ; DiG 9.7.2-P3 d.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;d.root-servers.net.IN A ;; ANSWER SECTION: d.root-servers.net. 156446 IN A 199.7.91.13 Regards, Rohan On Tue, 20 Aug 2013 14:20:23 -0400 Edward DeLargy eddela...@gmail.com wrote: Ah..I also just thought of thisensure that you have two seperate IPs for the server in the hints..you may have two entries with the same IP. Regards, Ed On Tue, Aug 20, 2013 at 2:12 PM, rohan.he...@cwjamaica.com wrote: Hello, Why do I still get the following in my logs even after downloading the latest version root hint file. checkhints: d.root-servers.net/A (128.8.10.90) extra record in hints checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users -- Lyle Giese LCR Computer Services, Inc Those who would give up Essential Liberty to purchase a little Temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 1775 ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
bind-users Digest, Vol 1603, Issue 5
Je suis absent jusqu'au 23 Août 2013 inclus. En cas d'urgence, vous pouvez contacter RASOAMANANA Ranto (Mob: +261320701232, e-mail: ranto.rasoaman...@orange.com). Confidentiality: This email is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Confidentialité: Ce message et les documents joints sont protégés et confidentiels. Ils sont exclusivement destinés aux personnes nommément visées ci-dessus. Toutes opinions exprimées dans cette communication ne sont pas nécessairement celles de la Société. Si celui-ci arrive chez vous par erreur, ne prenez aucune action, n'en faites pas de copie merci de bien vouloir le supprimer et en informer l'expéditeur immédiatement. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: d root server
Have you read the source code for these versions of BIND and examined the set of HINTS that are internal to the code inside BIND? These are loaded before any external HINTS file is loaded up. Lyle On 08/20/13 16:37, rohan.he...@cwjamaica.com wrote: Lyle, Version 9.8.4-P1 is also affected. And the hints file was downloaded during setup. Also note that even a freshly downloaded copy has the old address. Note IP 199.7.91.13 in the following dig output. dig +tcp @a.root-servers.net . ns ; DiG 9.8.4-P1 +tcp @a.root-servers.net . ns ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 6106 ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 22 ;; WARNING: recursion requested but not available ;; QUESTION SECTION: ;. IN NS ;; ANSWER SECTION: . 518400 IN NS f.root-servers.net. . 518400 IN NS h.root-servers.net. . 518400 IN NS g.root-servers.net. . 518400 IN NS c.root-servers.net. . 518400 IN NS m.root-servers.net. . 518400 IN NS k.root-servers.net. . 518400 IN NS l.root-servers.net. . 518400 IN NS i.root-servers.net. . 518400 IN NS e.root-servers.net. . 518400 IN NS d.root-servers.net. . 518400 IN NS j.root-servers.net. . 518400 IN NS b.root-servers.net. . 518400 IN NS a.root-servers.net. ;; ADDITIONAL SECTION: f.root-servers.net. 360 IN A 192.5.5.241 f.root-servers.net. 360 IN 2001:500:2f::f h.root-servers.net. 360 IN A 128.63.2.53 h.root-servers.net. 360 IN 2001:500:1::803f:235 g.root-servers.net. 360 IN A 192.112.36.4 c.root-servers.net. 360 IN A 192.33.4.12 m.root-servers.net. 360 IN A 202.12.27.33 m.root-servers.net. 360 IN 2001:dc3::35 k.root-servers.net. 360 IN A 193.0.14.129 k.root-servers.net. 360 IN 2001:7fd::1 l.root-servers.net. 360 IN A 199.7.83.42 l.root-servers.net. 360 IN 2001:500:3::42 i.root-servers.net. 360 IN A 192.36.148.17 i.root-servers.net. 360 IN 2001:7fe::53 e.root-servers.net. 360 IN A 192.203.230.10 d.root-servers.net. 360 IN A 199.7.91.13 d.root-servers.net. 360 IN 2001:500:2d::d j.root-servers.net. 360 IN A 192.58.128.30 j.root-servers.net. 360 IN 2001:503:c27::2:30 b.root-servers.net. 360 IN A 192.228.79.201 a.root-servers.net. 360 IN A 198.41.0.4 a.root-servers.net. 360 IN 2001:503:ba3e::2:30 Regards, Rohan On Tue, 20 Aug 2013 15:59:41 -0500 Lyle Giese l...@lcrcomputer.net wrote: Your bind code is old and has the old info in it. D root changed it's ip address. Bind has a built-in hints file, in case you don't setup one and it probably has the old ip address for the D root. http://blog.icann.org/2012/12/d-root/ Lyle Giese LCR Computer Services, Inc. On 08/20/13 15:44, rohan.he...@cwjamaica.com wrote: Edward, Agreed. My concern though is why the following show up in my logs when the IP is already in the root hint file. checkhints: d.root-servers.net/A (199.7.91.13) missing from hints Regards, Rohan On Tue, 20 Aug 2013 14:40:09 -0400 Edward DeLargy eddela...@gmail.com wrote: Rohan, Normally you shouldn't need to. However, sometimes errors happen and we just need to correct them as they come. Regards, Ed On Tue, Aug 20, 2013 at 2:26 PM, rohan.he...@cwjamaica.com wrote: Thanks Edward, I didn't think I needed to edit the downloaded root hint file. In fact the d.root-server.net server is assigned the IP address in the dig output below. I do not know where 128.8.10.90 comes from. dig d.root-servers.net ; DiG 9.7.2-P3 d.root-servers.net ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 54457 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;d.root-servers.net.IN A ;; ANSWER SECTION: d.root-servers.net. 156446 IN A 199.7.91.13 Regards, Rohan On Tue, 20 Aug 2013 14:20:23 -0400 Edward DeLargy eddela...@gmail.com wrote: Ah..I also just thought of thisensure that you have two seperate IPs for the server in the hints..you may have two entries with the same IP. Regards, Ed On Tue, Aug 20, 2013 at 2:12 PM, rohan.he...@cwjamaica.com wrote: Hello, Why do I
Re: private tld
On Aug 20, 2013, at 6:15 PM, Maria bind-li...@iano.org wrote: My company uses a private tld. We are working on fixing that but the fix is going to take a while, especially if our solution ends up being trying to register it with icann. Our resolvers that all internet queries go through have a forward zone statement for that tld to some internal name servers. Unfortunately, when I turn on dnssec validation our resolvers go check out the root zone, see our private zone doesn't exist, and refuse to resolve records in the zone. Is there a solution I can put in place so we can do dnssec validation in the meantime while we work on ceasing to use the private tld? Sign your private TLD and insert an explicit trust anchor for it on each of your recursive servers. AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind99 and a slave named server
On Aug 20, 2013, at 7:35 PM, LuKreme krem...@kreme.com wrote:
zone example.com {
type master;// I own this.
file files/example.com; // Here's where I read them from
};
it will become:
zone example.com {
type slave; // Now a slave
file files/example.com; // Must now be writable by BIND
masters { 192.168.1.1; }; // IP address of master server here
};
Bazinga!
And suddenly, miraculously, the master and slave will communicate with each
other and the slave will know when changes occur? Isn't that what allow
transfer and notify are for?
Yes, the master and slave will communicate and updates will happen as needed.
That's what NS records are for. And the MNAME in the SOA record. DNS theory.
1. RAW versus TEXT
2. allow transfer
3. notify
4. key files1
5. dnssec-enable
6. managed-keys
1: you don't care, as the new slave will xfer over the old data
I *do* care, honest.
What *ABOUT* raw vs text? BIND 9.9 slaves (and newer) store and expect the
transferred file in raw format on the slave. All other versions (and BIND 9.9
masters) store (and expect) the zone data in text format. You don't need to
mess with the setting unless you are doing something like looking at the zone
data on the slave using a program that expects text format. You shouldn't be
doing that anyway because the data on disk may not match what is in memory. If
you need access to the data on the slave, use dig.
When you first convert your servers to slaves, remove the existing zone data
and it will be xfer'd from the master as soon as the slave is started (this was
mentioned in a previous post).
2: read the documentation, it's not part of master/slave transition, setup
good acls
3: notify just works unless you have odd configuration
There is no allow-notify setting anymore or it's not needed?
Advanced notification mechanisms are only needed if you do things like (ugh)
hidden slaves. The flooding notify mechanism that BIND uses just works if
you have NS records that match reality.
If you need more information on this, if you post your entire configuration
file, I'm sure that someone will be more than happy to do a configuration
review.
4: you don't want the same key files on more than one server
See? that's why I asked.
5: not related to master/slave, just leave it enabled
Well, leave it disabled I guess as it's commented out in the conf file.
If it's commented out, you are leaving it enabled since that's the default.
6: that's dnssec-validation related
If you have any specific questions on these items, ask them, otherwise there
are a number of classes around (I teach one of them, several other people on
the list [that have responded to you, if I remember right] also teach them)
and I would recommend either a class or a book (again, several come to mind).
A fantastic (free) resource is: http://www.zytrax.com/books/dns/
Yes, something like that, exactly. I shall go read. Sadly, my OR book on bind
is very outdated and doesn't cover new-fangled tech like rndc-key and dnssec.
Cricket's book (o'reilly) has rndc in it. Ron's book (zytrax) covers DNSSEC in
great detail and several of the documents that I've prepared cover DNSSEC in
detail:
https://kb.isc.org/article/AA-00820/0/DNSSEC-in-6-minutes.html
and any changes in how root servers are setup since I am pretty sure that
has changed since I first setup bind 9.1 many eons ago (2002?).
If you are Internet visible, you don't do anything with configuring anything
about the roots, as it just works (compiled into bind since 9.3ish).
I distinctly remember having to go get the root file myself under either 9.0
or 9.1 and sometime since then there was a kerfuffle as one of the root
servers changed and, I could be wrong, I had to manually update that change.
Thus 9.3ish. This entire thread is caused by an upgrade to BIND 9.9 if I
remember correctly.
Don't provide a root hint zone because it's provided for you by BIND
I'm sorry if I'm coming across as a tired old grump, but I think that we've
been trying to answer your questions without doing all of the work for you.
AlanC
--
Alan Clegg | +1-919-355-8851 | a...@clegg.com
signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: private tld
DNSSEC sign the private TLD and configure its KSK as a trust anchor on the recursive resolvers. Alternatively, you can configure all your recursive resolvers as slaves for the private zone. Authoritative responses aren't validated on a mixed authoritative/recursive nameserver. Those are the only two options that immediately spring to my mind. Scott On Aug 20, 2013 5:16 PM, Maria bind-li...@iano.org wrote: My company uses a private tld. We are working on fixing that but the fix is going to take a while, especially if our solution ends up being trying to register it with icann. Our resolvers that all internet queries go through have a forward zone statement for that tld to some internal name servers. Unfortunately, when I turn on dnssec validation our resolvers go check out the root zone, see our private zone doesn't exist, and refuse to resolve records in the zone. Is there a solution I can put in place so we can do dnssec validation in the meantime while we work on ceasing to use the private tld? Thanks, Maria ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind99 and a slave named server
On Aug 20, 2013, at 10:32 PM, LuKreme krem...@kreme.com wrote: I need the data in text because sometimes, the primary dns is down, and sometimes it si down long enough to require that I switch the slave to be the primary, and that means master. I can't do that if I don't have text records. Eh... You can ALWAYS get your data in text format using dig. I'm afraid to ask, but why do you need to move from master to slave when your master is down? If it's down that long and very often, you may want to consider putting your DNS on a reliable server/circuit/data center. Here's what I did recently to do just this: https://plus.google.com/107634973406628501676/posts/6ZVyDrTw3np AlanC -- Alan Clegg | +1-919-355-8851 | a...@clegg.com signature.asc Description: Message signed with OpenPGP using GPGMail ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind99 and a slave named server
On 20 Aug 2013, at 14:38 , Alan Clegg a...@clegg.com wrote:
To convert master to slave:
[snip]
Bazinga!
OK. Not Bazinga.
$ grep covisp named.conf
zone covisp.net { type slave; file slave/covisp.net; masters {
75.148.117.92; }; };
$ rndc status
version: 9.9.3-P2
CPUs found: 2
worker threads: 2
UDP listeners per interface: 2
number of zones: 117
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 5
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
$ grep listen named.conf
listen-on { 75.148.117.93; 75.148.117.91; 127.0.0.1; };
$ dig @localhost covisp.net | grep -A2 ;; ANS | tail -2
$ dig @75.148.117.91 covisp.net | grep -A2 ;; ANS | tail -2
$ dig @ns1.covisp.net covisp.net |grep -A2 ;; ANS |tail -2
covisp.net. 86400 IN A 75.148.117.93
covisp.net. 86400 IN A 75.148.117.90
in /var/log/messages:
Aug 20 20:40:23 mail named[81006]: the working directory is not writable1
Aug 20 20:40:23 mail named[81006]: all zones loaded
Aug 20 20:40:23 mail named[81006]: running
Oh, and slave/ is empty.
$ grep covisp named.conf-master
zone covisp.net { type master; file master/covisp.net; };
$ diff /var/named/etc/namedb/master/covisp.net
/var/named/etc/namedb/slave/covisp.net
$ cp /var/named/etc/namedb/named.conf-master /var/named/etc/namedb/named.conf
$ rndc reload
$ dig @75.148.117.91 covisp.net | grep -A2 ;; ANS | tail -2
covisp.net. 86400 IN A 75.148.117.93
covisp.net. 86400 IN A 75.148.117.90
1 (the working directory is not writeable comes up every time because
/var/named/etc/namedb is owned by root and changing it causes bind to first
change it back, and then log the error anyway).
--
LOOSE TEETH DON'T NEED MY HELP Bart chalkboard Ep. AABF16
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind99 and a slave named server
Perhaps you should check that the master is running a nameserver
and that it doesn't have firewalls blocking the DNS (both UDP and
TCP).
% dig soa covisp.net @75.148.117.92
; DiG 9.10.0pre-alpha soa covisp.net @75.148.117.92
;; global options: +cmd
;; connection timed out; no servers could be reached
% dig soa covisp.net @75.148.117.92 +tcp
;; Connection to 75.148.117.92#53(75.148.117.92) for covisp.net failed:
connection refused.
%
Mark
In message 4eae48de-ea0c-4e50-a343-6d3a6b255...@kreme.com, LuKreme writes:
On 20 Aug 2013, at 14:38 , Alan Clegg a...@clegg.com wrote:
To convert master to slave:
[snip]
Bazinga!
OK. Not Bazinga.
$ grep covisp named.conf
zone covisp.net { type slave; file slave/covisp.net; masters {
75.148.117.92; }; };
$ rndc status
version: 9.9.3-P2
CPUs found: 2
worker threads: 2
UDP listeners per interface: 2
number of zones: 117
debug level: 0
xfers running: 0
xfers deferred: 0
soa queries in progress: 5
query logging is OFF
recursive clients: 0/0/1000
tcp clients: 0/100
server is up and running
$ grep listen named.conf
listen-on { 75.148.117.93; 75.148.117.91; 127.0.0.1; };
$ dig @localhost covisp.net | grep -A2 ;; ANS | tail -2
$ dig @75.148.117.91 covisp.net | grep -A2 ;; ANS | tail -2
$ dig @ns1.covisp.net covisp.net |grep -A2 ;; ANS |tail -2
covisp.net. 86400 IN A 75.148.117.93
covisp.net. 86400 IN A 75.148.117.90
in /var/log/messages:
Aug 20 20:40:23 mail named[81006]: the working directory is not writable1
Aug 20 20:40:23 mail named[81006]: all zones loaded
Aug 20 20:40:23 mail named[81006]: running
Oh, and slave/ is empty.
Which sounds like the master is blocking zone transfers.
$ grep covisp named.conf-master
zone covisp.net { type master; file master/covisp.net; };
$ diff /var/named/etc/namedb/master/covisp.net
/var/named/etc/namedb/slave/covisp.net
$ cp /var/named/etc/namedb/named.conf-master /var/named/etc/namedb/named.conf
$ rndc reload
$ dig @75.148.117.91 covisp.net | grep -A2 ;; ANS | tail -2
covisp.net. 86400 IN A 75.148.117.93
covisp.net. 86400 IN A 75.148.117.90
1 (the working directory is not writeable comes up every time because
/var/named/etc/namedb is owned by root and chang
ing it causes bind to first change it back, and then log the error anyway).
Named doesn't change the ownership. The script starting named provided
by the OS developer does that.
--
LOOSE TEETH DON'T NEED MY HELP Bart chalkboard Ep. AABF16
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: duplicate records
The answer is none. All versions did duplicate elimination even back in the BIND 4 days. Mark In message 5213d1c3.3090...@chrysler.com, Kevin Darcy writes: Since such behavior would flagrantly violate RFC 2181, Section 5, look for a version prior to the publication date of that RFC (July 1997). - Kevin On 8/20/2013 3:14 PM, Nidal Shater wrote: we know that BIND eleminate duplicate records, which version of BIND that doesn't do that ? NIDAL -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
