Subnet reverse delagation, RFC 2317
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
Recursion is only allowed for the local networks, but why the server
thinks recursion is needed in the first place?
Server ns1.qnet.fi, BIND 9.7.1-P1 W2K3
named.conf:
zone 128/25.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.25-128;
};
;
;File: named.62.142.217.25-128
;
$TTL 86400
$ORIGIN 128/25.217.142.62.IN-ADDR.ARPA.
@IN SOAns1.qnet.fi. xxx.qnet.fi. (
201007281 ; serial number
28800 ; refresh every 12 hours
7200 ; retry after 2 hours
604800 ; expire after 2 weeks
86400) ; default ttl is 2 days
;
@IN NSns1.qnet.fi.
IN NSns2.qnet.fi.
IN NSns3.qnet.fi.
200 IN PTR x200.qnet.fi.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamically add zones
Is there a patch for bind 9 to add new zones dynamically without having to run rndc reconfig? This feature is being added in BIND 9.7.2. It's available now in the beta version, 9.7.2b1. -- 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: Subnet reverse delagation, RFC 2317
On 07/29/2010 08:58 AM, Jukka Pakkanen wrote: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work It doesn't look like the reverse is deleted to you: $ dig +comm +nocmd +noques +nostat @ns6.sci.fi 25.217.142.62.in-addr.arpa ptr ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 i.e. no CNAME records for the sub-/24. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 11:29, Phil Mayers kirjoitti: On 07/29/2010 08:58 AM, Jukka Pakkanen wrote: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work It doesn't look like the reverse is deleted to you: $ dig +comm +nocmd +noques +nostat @ns6.sci.fi 25.217.142.62.in-addr.arpa ptr ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600INSOAns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 i.e. no CNAME records for the sub-/24. What kind of output should I see in that query above? The subnet we should have delegated to us is 62.142.217.128/25. Jukka ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 29/07/10 10:00, Jukka Pakkanen wrote: 29.7.2010 11:29, Phil Mayers kirjoitti: On 07/29/2010 08:58 AM, Jukka Pakkanen wrote: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work It doesn't look like the reverse is deleted to you: $ dig +comm +nocmd +noques +nostat @ns6.sci.fi 25.217.142.62.in-addr.arpa ptr ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 35109 ;; flags: qr aa rd; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; WARNING: recursion requested but not available ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600INSOAns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 i.e. no CNAME records for the sub-/24. What kind of output should I see in that query above? The subnet we should have delegated to us is 62.142.217.128/25. Sorry, I'm being slightly dumb and getting confused. The zone is delegated fine. As you've spotted, two of the 5 servers are responding (ns5.sci.fi and ns3.sci.fi) but the three others (ns[1,2,3].qnet.fi) return recursion needed Presumably those servers aren't actually serving the zone correctly. Are you using views? If so, do you have the zone statement in all the applicable views? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
AUTO: Paveza Jr, Gary L is out of the office. (returning 08/02/2010)
I am out of the office until 08/02/2010. I am currently out of the office. If you need Unix Admin assistance please contact USW_21st_PLD-UnixAdmins for assistance. Note: This is an automated response to your message bind-users Digest, Vol 589, Issue 2 sent on 7/29/2010 3:45:51 AM. This is the only notification you will receive while this person is away. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 13:45, Phil Mayers kirjoitti:
On 29/07/10 10:00, Jukka Pakkanen wrote:
29.7.2010 11:29, Phil Mayers kirjoitti:
On 07/29/2010 08:58 AM, Jukka Pakkanen wrote:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
Sorry, I'm being slightly dumb and getting confused. The zone is
delegated fine.
As you've spotted, two of the 5 servers are responding (ns5.sci.fi and
ns3.sci.fi) but the three others (ns[1,2,3].qnet.fi) return recursion
needed
Presumably those servers aren't actually serving the zone correctly.
Are you using views? If so, do you have the zone statement in all the
applicable views?
No views on place, here's yet the whole named.conf from ns1.qnet.fi,
only irrelevant zones removed.
acl qnet {62.142.220.0/24; 62.142.221.0/24; 62.142.217.128/25;
217.152.62.176/29; 80.248.251.173/32; };
acl qnetservers {62.142.220.5/32; 62.142.220.6/32; 62.142.217.134/32;
213.192.189.2/32; 195.74.0.10; };
acl admin {62.142.220.0/28; 62.142.217.128/29; };
acl bogusnets {0.0.0.0/8; 1.0.0.0/8; 2.0.0.0/8; 192.0.2.0/24;
224.0.0.0/3; 10.0.0.0/8; 172.16.0.0/12; 192.168.0.0/16; };
options {
directory C:\windows\system32\dns\etc\namedb;
pid-file named.pid;
allow-query { any; };
allow-recursion { qnet; };
allow-transfer { qnetservers; };
blackhole { bogusnets; };
version Enttententten...;
statistics-file named_stats.txt;
max-cache-size 128M;
};
key rndc-key {
algorithm hmac-md5;
secret xxx;
};
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { rndc-key; };
inet 62.142.220.5 port 953 allow { admin; } keys { rndc-key; };
};
logging {
category lame-servers { null; };
category edns-disabled { null; };
};
zone . { type hint; file root.hint; };
.
zone 64/27.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.27-64;
};
zone 128/25.217.142.62.in-addr.arpa {
type master;
file named.62.142.217.25-128;
};
zone 220.142.62.in-addr.arpa {
type master;
file named.62.142.220;
};
zone 221.142.62.in-addr.arpa {
type master;
file named.62.142.221;
};
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind Clustering
I know BIND does not currently support multi-master. And I understand that trying to strap together my own pseudo-multi-master implementation using BIND, bubble gum, and tape isn't a sustainable solution. But, nevertheless, I don't really need a true multi-master implementation -- I just need to keep my backup master relatively up to date without relying on frequent freeze-copy-thaw operations. I would be happy to have the updates go to one slave, and then be replicated to both the active master and the backup master. I would deal with drift via brute force i.e. I would have the active master copy over to the backup master on a once or twice a day basis, not once every 5 minutes. I think it would be great if there were a new config construct added whereby the update-forward target(s) are explicitly specified. In the case where the masters are slaves of a hidden master that is directly reachable, it would allow for the updates to be directly forwarded to the primary master instead of being forwarded twice. And if multiple update-forward targets are specified, then all targets always get an update. This could be used to maintain a duplicate (hidden) master and/or eliminate the failure-delay when the multiple masters switch over, take turns being the master. And possibly the specified update-forward target construct could also have an optional behavior of forward-to-all or stop-on-first-success. if current behavior is preferred, but with a different list than then zone-transfer master list. Better yet, I would like add update-forwarding for master zones -- perhaps it could be called update-replication. I guess what I would really like to see is multiple MNAME targets accommodated right in the SOA, but I imagine that would have a serious compatibility challenge. Or else maybe a new zone type called backup-master that acts like a slave until an rndc control flips its operation state. I would like to get see some more comments on this. And I would really appreciate it if someone could tell me where in the source code I should look to find where the update-forward targets are obtained so that I can evaluate what it would take for me to write my own modifications. Thanks. -- Gordon A. Lang - Original Message - From: Chris Buxton chris.p.bux...@gmail.com To: Gordon A. Lang gl...@goalex.com; bind-users@lists.isc.org Sent: Wednesday, July 28, 2010 11:22 PM Subject: Re: Bind Clustering Updates are always forwarded to the zone masters, as configured in the zone statement itself. And yes, the update is only forwarded (successfully) once. BIND assumes that each zone has exactly one primary master. That's why updates are forwarded only once. If you want a true multi-master setup, you'll need to look at other options. For example: - BIND with modifications or additional software. - Microsoft DNS and AD-integrated zones. There are other options. Regards, Chris Buxton Bluecat Networks On 7/28/10, Gordon A. Lang gl...@goalex.com wrote: This reply is a few months delayed, but this issue is still very important to me, and I'm hoping you can take a few minutes to help out. I finally took some time to read through the code, and unfortunately I was unable to identify where forward target(s) are obtained in the update forwarding action. There's a lot of structure to reverse engineer -- too much for a casual effort. So perhaps you can tell me where I can find the pertinent code... ? My belief was that somewhere in the code, the SOA record is obtained, and the MNAME is used as the forward target -- this belief was based on trial and error observations. What you suggested is that the update forwarding actually uses the masters list from the named.conf file for forwarding targets. I was unable to find clues one way or another. But another thing about your response that leaves me wondering if I fully understand your response is that you say it walks the list of masters trying each one in turn, and with the word trying in there, it suggests that it walks the list only until the first successful update. Perhaps I am incorrectly reading into it, but if you could clarify that point, I would appreciate it. --- I would expect that if the masters list is used, then ALL masters should always get the updates. Thanks in advance. -- Gordon A. Lang - Original Message - From: Mark Andrews ma...@isc.org To: Gordon A. Lang gl...@goalex.com Cc: bind-users@lists.isc.org Sent: Friday, April 09, 2010 5:58 PM Subject: Re: Bind Clustering In message a2e77adf810a44d1b6aa8ab760abd...@corp.fsroot.flagstar.com, Gordon A. Lang writes: Regarding my wild idea for synchronizing mulitiple dynamic masters.. my idea is flawed. Evidently, the allow-update-forwarding only forwards to the MNAME configured in the SOA. I was thinking it forwarded to the masters configured in the conf file. Oh well. I guess we'll just have to wait for ISC to implement
Re: Subnet reverse delagation, RFC 2317
In message 4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 2010-07-29 09:58, Jukka Pakkanen wrote Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because it is: dig -x looks for 200.217.142.62.in-addr.arpa. Your server is not a master for this zone; instead it's master for 128/25.217.142.62.in-addr.arpa. The original request (200.217.142.62.in-addr.arpa.) is mapped via a CNAME to a name inside your zone, but this mapping is done by the ns3.sci.fi. nameserver; hence recursion is needed. Niobos ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 14:23, Mark Andrews kirjoitti: In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. Uuh... NOW I'm confused :) There's definitely something wrong somewhere, because reverse-DNS for 62.142.217.128/25 is not working as it should. ns1.qnet.fi should be the authoritive reverse DNS server for that IP range, but it's not serving. Getting recursion requested but not available. While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. 62.142.220.0/24 has been delegated to out servers (qnet servers) and have been working fine for years. And are working at them moment. Mentioning 62.142.220.5 was just to inform that with similar configuration, this /24 reverse dns works ok. The problem is the 62.142.217.128/25 network, which should be delegated to out servers, but for some reason they respond with recursion needed. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. 62.142.217.5 is NOT supposed to be delegated to our servers. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. I'm not asking that. If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. If it's a slave, how can I administer the zone? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 14:26, Niobos kirjoitti: On 2010-07-29 09:58, Jukka Pakkanen wrote Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because it is: dig -x looks for 200.217.142.62.in-addr.arpa. Your server is not a master for this zone; instead it's master for 128/25.217.142.62.in-addr.arpa. The original request (200.217.142.62.in-addr.arpa.) is mapped via a CNAME to a name inside your zone, but this mapping is done by the ns3.sci.fi. nameserver; hence recursion is needed. Ok, this makes sense to me too. But what is the fix, I can't allow general recursion for the world? Is it possible to allow recursion for this zone only? (sorry being lazy, I'm sure this is in the ARM..). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 29/07/10 12:34, Jukka Pakkanen wrote:
29.7.2010 14:23, Mark Andrews kirjoitti:
In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
There is NOTHING wrong here. You are not testing the servers properly.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
No - Mark is right (apologies for my confusing posts). Assume an example
IP of 62.142.217.200. Your server is authoritative for:
200.128/25.217.142.62.in-addr.arpa.
...not:
200.217.142.62.in-addr.arpa.
ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent
zone, so can answer a dig -x THEIP directly.
$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr
;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa. IN PTR
;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 IN CNAME
200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 14:50, Phil Mayers kirjoitti:
On 29/07/10 12:34, Jukka Pakkanen wrote:
29.7.2010 14:23, Mark Andrews kirjoitti:
In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
There is NOTHING wrong here. You are not testing the servers properly.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
No - Mark is right (apologies for my confusing posts). Assume an
example IP of 62.142.217.200. Your server is authoritative for:
200.128/25.217.142.62.in-addr.arpa.
...not:
200.217.142.62.in-addr.arpa.
ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent
zone, so can answer a dig -x THEIP directly.
$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr
;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa.INPTR
;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 INCNAME
200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___
Yeah, this makes sense. But my question still is, what is wrong in our
setup, since the goal is we can administer the 62.142.217.128/25 reverse
DNS, without asking our upstream provider sci.fi for changes to the zone?
I also understand the requirement for the recursion, but I don't believe
the cure is to allow recursion to any in the global options. I'm just
browsing the net for zone specific recursion options, but haven't found
anything yet...
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Bind Clustering
One solution that was floated recently around here was to use dynamically loaded zones (http://bind-dlz.sourceforge.net/) with an underlying storage mechanism that does bidirectional replication (a directory service like LDAP or a database) for the masters, this way, whichever one gets the update, the others get. The downside is that DLZ is basically a rearchitecture of your DNS setup, and will require the two extra pieces to maintain (the DLZ portion and the underlying replicating source). -DTK On Thu, Jul 29, 2010 at 6:25 AM, Gordon A. Lang gl...@goalex.com wrote: I know BIND does not currently support multi-master. And I understand that trying to strap together my own pseudo-multi-master implementation using BIND, bubble gum, and tape isn't a sustainable solution. But, nevertheless, I don't really need a true multi-master implementation -- I just need to keep my backup master relatively up to date without relying on frequent freeze-copy-thaw operations. I would be happy to have the updates go to one slave, and then be replicated to both the active master and the backup master. I would deal with drift via brute force i.e. I would have the active master copy over to the backup master on a once or twice a day basis, not once every 5 minutes. I think it would be great if there were a new config construct added whereby the update-forward target(s) are explicitly specified. In the case where the masters are slaves of a hidden master that is directly reachable, it would allow for the updates to be directly forwarded to the primary master instead of being forwarded twice. And if multiple update-forward targets are specified, then all targets always get an update. This could be used to maintain a duplicate (hidden) master and/or eliminate the failure-delay when the multiple masters switch over, take turns being the master. And possibly the specified update-forward target construct could also have an optional behavior of forward-to-all or stop-on-first-success. if current behavior is preferred, but with a different list than then zone-transfer master list. Better yet, I would like add update-forwarding for master zones -- perhaps it could be called update-replication. I guess what I would really like to see is multiple MNAME targets accommodated right in the SOA, but I imagine that would have a serious compatibility challenge. Or else maybe a new zone type called backup-master that acts like a slave until an rndc control flips its operation state. I would like to get see some more comments on this. And I would really appreciate it if someone could tell me where in the source code I should look to find where the update-forward targets are obtained so that I can evaluate what it would take for me to write my own modifications. Thanks. -- Gordon A. Lang - Original Message - From: Chris Buxton chris.p.bux...@gmail.com To: Gordon A. Lang gl...@goalex.com; bind-users@lists.isc.org Sent: Wednesday, July 28, 2010 11:22 PM Subject: Re: Bind Clustering Updates are always forwarded to the zone masters, as configured in the zone statement itself. And yes, the update is only forwarded (successfully) once. BIND assumes that each zone has exactly one primary master. That's why updates are forwarded only once. If you want a true multi-master setup, you'll need to look at other options. For example: - BIND with modifications or additional software. - Microsoft DNS and AD-integrated zones. There are other options. Regards, Chris Buxton Bluecat Networks On 7/28/10, Gordon A. Lang gl...@goalex.com wrote: This reply is a few months delayed, but this issue is still very important to me, and I'm hoping you can take a few minutes to help out. I finally took some time to read through the code, and unfortunately I was unable to identify where forward target(s) are obtained in the update forwarding action. There's a lot of structure to reverse engineer -- too much for a casual effort. So perhaps you can tell me where I can find the pertinent code... ? My belief was that somewhere in the code, the SOA record is obtained, and the MNAME is used as the forward target -- this belief was based on trial and error observations. What you suggested is that the update forwarding actually uses the masters list from the named.conf file for forwarding targets. I was unable to find clues one way or another. But another thing about your response that leaves me wondering if I fully understand your response is that you say it walks the list of masters trying each one in turn, and with the word trying in there, it suggests that it walks the list only until the first successful update. Perhaps I am incorrectly reading into it, but if you could clarify that point, I would appreciate it. --- I would expect that if the masters list is used, then ALL masters should always get the updates. Thanks in advance. -- Gordon A.
Re: Subnet reverse delagation, RFC 2317
In message 4c516756.5060...@qnet.fi, Jukka Pakkanen writes: 29.7.2010 14:23, Mark Andrews kirjoitti: In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. Uuh... NOW I'm confused :) You were confused before but didn't know it. :-) You were asking the wrong question to the wrong server. When you ask the right questions to the right servers it works. There's definitely something wrong somewhere, because reverse-DNS for 62.142.217.128/25 is not working as it should. The only thing wrong is your understanding of what should be happening. ns1.qnet.fi should be the authoritive reverse DNS server for that IP range, but it's not serving. Getting recursion requested but not available. DNS servers are authoritative for namespaces NOT address spaces. Reverse zone use a specific mapping from address space to namespace (i.e. reverse the decimal values of the octets and append IN-ADDR.ARPA). RFC 2317 the maps from the reverse namespace (x.x.x.x.in-addr.arpa) to a second namespace using CNAME records (in this case x.128/25.x.x.x.in-addr.arpa). While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. 62.142.220.0/24 has been delegated to out servers (qnet servers) and have been working fine for years. And are working at them moment. Mentioning 62.142.220.5 was just to inform that with similar configuration, this /24 reverse dns works ok. The problem is the 62.142.217.128/25 network, which should be delegated to out servers, but for some reason they respond with recursion needed. No. 128/25.217.142.62.IN-ADDR.ARPA has been delegated to your servers. If 62.142.217.128/25 was delegated to you servers you would have 128 zones, 128.217.142.62.IN-ADDR.ARPA ... 255.217.142.62.IN-ADDR.ARPA. The reverses for 62.142.217.128/25 is still served by the servers for 217.142.62.IN-ADDR.ARPA. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARP A then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. 62.142.217.5 is NOT supposed to be delegated to our servers. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. I'm not asking that. But you are. Please read the question section of the answers you get back. ; DiG 9.3.6-P1 @ns1.qnet.fi -x 62.142.220.5 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. If it's a slave, how can I administer the zone? You don't. You just have a copy of the zone locally. The administrator for 217.142.62.IN-ADDR.ARPA changes it. RFC 2317 states that servers for the parent should serve the slave zone. The reverse is also true but is not stated. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 07/29/2010 01:38 PM, bind-users-requ...@lists.isc.org wrote: Date: Thu, 29 Jul 2010 14:38:20 +0300 From: Jukka Pakkanenjukka.pakka...@qnet.fi Subject: Re: Subnet reverse delagation, RFC 2317 To:bind-users@lists.isc.org Message-ID:4c51682c.3080...@qnet.fi Content-Type: text/plain; charset=ISO-8859-1; format=flowed 29.7.2010 14:26, Niobos kirjoitti: On 2010-07-29 09:58, Jukka Pakkanen wrote Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because it is: dig -x looks for 200.217.142.62.in-addr.arpa. Your server is not a master for this zone; instead it's master for 128/25.217.142.62.in-addr.arpa. The original request (200.217.142.62.in-addr.arpa.) is mapped via a CNAME to a name inside your zone, but this mapping is done by the ns3.sci.fi. nameserver; hence recursion is needed. Ok, this makes sense to me too. But what is the fix, I can't allow general recursion for the world? Is it possible to allow recursion for this zone only? (sorry being lazy, I'm sure this is in the ARM..). I cannot understand why you need RFC 2317 delegation when you have two c-classes? But that's not an answer to problem. # whois 62.142.220.5 [snip] inetnum: 62.142.220.0 - 62.142.221.255 netname: Q-NET I see right that there's delegation data on ns6.sci.fi. name server... # dig +trace -x 62.142.220.5 [snip] 142.62.in-addr.arpa.172800 IN NS ns3.sci.fi. 142.62.in-addr.arpa.172800 IN NS ns6.sci.fi. 142.62.in-addr.arpa.172800 IN NS ns5.sci.fi. 142.62.in-addr.arpa.172800 IN NS ns.ripe.net. ;; Received 172 bytes from 192.134.0.49#53(NS3.NIC.FR) in 206 ms 220.142.62.in-addr.arpa. 14400 IN NS ns3.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns5.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns6.sci.fi. ;; Received 151 bytes from 195.74.0.10#53(ns3.sci.fi) in 217 ms 5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns3.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns1.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns2.qnet.fi. ;; Received 154 bytes from 195.74.0.59#53(ns6.sci.fi) in 224 ms ...and further investigation is indicating... # dig +norecurse @ns3.sci.fi. -x 62.142.220.5 ; DiG 9.6.1 +norecurse @ns3.sci.fi. -x 62.142.220.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 16475 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 220.142.62.in-addr.arpa. 14400 IN NS ns5.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns6.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns3.sci.fi. ;; ADDITIONAL SECTION: ns3.sci.fi. 14400 IN A 195.74.0.10 ns5.sci.fi. 14400 IN A 213.192.189.2 ns6.sci.fi. 14400 IN A 195.74.0.59 ;; Query time: 375 msec ;; SERVER: 195.74.0.10#53(195.74.0.10) ;; WHEN: Thu Jul 29 14:07:38 2010 ;; MSG SIZE rcvd: 151 # dig +norecurse @ns5.sci.fi. -x 62.142.220.5 ; DiG 9.6.1 +norecurse @ns5.sci.fi. -x 62.142.220.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26753 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR ;; ANSWER SECTION: 5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi. ;; AUTHORITY SECTION: 220.142.62.in-addr.arpa. 86400 IN NS ns3.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns2.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns1.qnet.fi. ;; Query time: 422 msec ;; SERVER: 213.192.189.2#53(213.192.189.2) ;; WHEN: Thu Jul 29 14:07:47 2010 ;; MSG SIZE rcvd: 154 # dig +norecurse @ns6.sci.fi. -x 62.142.220.5 ; DiG 9.6.1 +norecurse @ns6.sci.fi. -x 62.142.220.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38750 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR ;; ANSWER SECTION: 5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi. ;; AUTHORITY SECTION: 220.142.62.in-addr.arpa. 86400 IN NS ns1.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns3.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns2.qnet.fi. ;; Query time: 303 msec ;; SERVER:
Re: Three NameServer DOSing my dns1
Hello Dave Sparro, Am 2010-07-28 10:11:52, hacktest Du folgendes herunter: That host name does show up in your e-mail headers. That may be why there are some people curious about that host name. On 28.07.10 23:24, Michelle Konzack wrote: But why do they query my server 3 times per second? deep parsing of e-mail headers by spam filtering software, I guess. Apparently because of your fake ssmtp header. -- 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. Chernobyl was an Windows 95 beta test site. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
In message 4c516d09.7080...@qnet.fi, Jukka Pakkanen writes:
29.7.2010 14:50, Phil Mayers kirjoitti:
On 29/07/10 12:34, Jukka Pakkanen wrote:
29.7.2010 14:23, Mark Andrews kirjoitti:
In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes:
Doing first time the RFC 2317 style subnet reverse DNS, and have a
problem with recursion. When doing a query like dig @ns1.qnet.fi -x
62.142.217.200 is succeeds from the local network, but outside I get
recursion requested but not available. Our /24 reverse zones work
fine, the server knows it's the master and serves ok, like dig
@ns1.qnet.fi -x 62.142.220.5.
There is NOTHING wrong here. You are not testing the servers properly.
Uuh... NOW I'm confused :)
There's definitely something wrong somewhere, because reverse-DNS for
62.142.217.128/25 is not working as it should.
ns1.qnet.fi should be the authoritive reverse DNS server for that IP
range, but it's not serving. Getting recursion requested but not
available.
No - Mark is right (apologies for my confusing posts). Assume an
example IP of 62.142.217.200. Your server is authoritative for:
200.128/25.217.142.62.in-addr.arpa.
...not:
200.217.142.62.in-addr.arpa.
ns{3,5}.sci.fi have CNAMEs linking the two because they own the parent
zone, so can answer a dig -x THEIP directly.
$ dig @ns3.sci.fi 200.217.142.62.in-addr.arpa ptr
;; QUESTION SECTION:
;200.217.142.62.in-addr.arpa.INPTR
;; ANSWER SECTION:
200.217.142.62.in-addr.arpa. 14400 INCNAME
200.128/25.217.142.62.in-addr.arpa.
200.128/25.217.142.62.in-addr.arpa. 86400 IN PTR x200.qnet.fi.
___
Yeah, this makes sense. But my question still is, what is wrong in our
setup,
!!! NOTHING
since the goal is we can administer the 62.142.217.128/25 reverse
DNS, without asking our upstream provider sci.fi for changes to the zone?
You update 128/25.217.142.62.in-addr.arpa. SCI.FI doesn't need to do
anything more. They have done the one time changes required to make
this work.
I also understand the requirement for the recursion, but I don't believe
the cure is to allow recursion to any in the global options. I'm just
browsing the net for zone specific recursion options, but haven't found
anything yet...
The rest of the world won't ask your servers about 217.142.62.in-addr.arpa
because the zone is NOT delegated to them. They will be asked about
128/25.217.142.62.in-addr.arpa because that zone is delegated to them.
___
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
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 15:10, Mark Andrews kirjoitti: In message4c516756.5060...@qnet.fi, Jukka Pakkanen writes: 29.7.2010 14:23, Mark Andrews kirjoitti: In message4c5134af.2080...@qnet.fi, Jukka Pakkanen writes: Doing first time the RFC 2317 style subnet reverse DNS, and have a problem with recursion. When doing a query like dig @ns1.qnet.fi -x 62.142.217.200 is succeeds from the local network, but outside I get recursion requested but not available. Our /24 reverse zones work fine, the server knows it's the master and serves ok, like dig @ns1.qnet.fi -x 62.142.220.5. There is NOTHING wrong here. You are not testing the servers properly. Uuh... NOW I'm confused :) You were confused before but didn't know it. :-) I knew it, but after your message I was more confused... You were asking the wrong question to the wrong server. When you ask the right questions to the right servers it works. Well, the goal is to be able to administer the reverse DNS of that zone, and at the moment it's not happening. So there is still something wrong. Somewhere. I have to think about this from the endusers point of view as well, and for them the reverse DNS is broken. There's definitely something wrong somewhere, because reverse-DNS for 62.142.217.128/25 is not working as it should. The only thing wrong is your understanding of what should be happening. I can't agree with that. Reverse DNS for IP address range 62.142.217.128-254 is not working as we wish. So something is wrong somewhere. Maybe my terminology about address spaces name spaces is off, but I suppose everybody at the list understands what I'm after. ns1.qnet.fi should be the authoritive reverse DNS server for that IP range, but it's not serving. Getting recursion requested but not available. While ns1.qnet.fi is authoritative for 128/25.217.142.62.IN-ADDR.ARPA, it is not authoritative for 217.142.62.IN-ADDR.ARPA. When you do dig @ns1.qnet.fi -x 62.142.220.5 you are asking for PTR 5.217.142.62.IN-ADDR.ARPA which ns1.qnet.fi does not serve. 62.142.220.0/24 has been delegated to out servers (qnet servers) and have been working fine for years. And are working at them moment. Mentioning 62.142.220.5 was just to inform that with similar configuration, this /24 reverse dns works ok. The problem is the 62.142.217.128/25 network, which should be delegated to out servers, but for some reason they respond with recursion needed. No. 128/25.217.142.62.IN-ADDR.ARPA has been delegated to your servers. If 62.142.217.128/25 was delegated to you servers you would have 128 zones, 128.217.142.62.IN-ADDR.ARPA ... 255.217.142.62.IN-ADDR.ARPA. The reverses for 62.142.217.128/25 is still served by the servers for 217.142.62.IN-ADDR.ARPA. Recursive server will ask the servers for 217.142.62.IN-ADDR.ARPA for PTR 5.217.142.62.IN-ADDR.ARPA, see the CNAME to 5.128/25.217.142.62.IN-ADDR.ARPA I think you have missed the difference between the two cases/networks, one network of IP address is 62.142.217.128/25, the other one on 62.142.220.0/24, otherwise I don't understand where you get the number 5 in the messages refering to this problem? then ask the servers for 128/25.217.142.62.IN-ADDR.ARPA for the PTR record at 5.128/25.217.142.62.IN-ADDR.ARPA. It will then combine the two answers and send it back to the original client. 62.142.217.5 is NOT supposed to be delegated to our servers. Like said, this IP has nothing to do with us. Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because you are asking the wrong server about 5.217.142.62.IN-ADDR.ARPA. I'm not asking that. But you are. No I'm not :) Please read the question section of the answers you get back. ; DiG 9.3.6-P1 @ns1.qnet.fi -x 62.142.220.5 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR This is not the 62.142.217.128/25 network, where I have this problem. This is 62.142.220.0/24 network. Which works fine, regarding the reverse DNS. If ns1.qnet.fi is made a slave of 217.142.62.IN-ADDR.ARPA it would then have all the information required to answer the query without asking other services. If it's a slave, how can I administer the zone? You don't. You just have a copy of the zone locally. The administrator for 217.142.62.IN-ADDR.ARPA changes it. So we gat back to my original problem again, how can I administer the zone on our server? What needs to be done, in addition or differently of what's been done now. Of course I could have asked how can I have reverse DNS delegated and working for IP addresses 62.142.217.128-254 to our Bind servers so that we can administer the reverse DNS of these IP addresses, but instead I tried to be more specific, tell what's been done, and what happens. And asked we I'm doing wrong when
Re: Subnet reverse delagation, RFC 2317
Please everybody just forget the 62.142.220.0/24 network and 62.142.220.5 address, the problem is not about them. It was just to inform that our servers are doing regular /24 reverse DNS just fine. The problem is we are trying to set up and administer reverse DNS for 62.142.217.128/25 IP network. 29.7.2010 15:10, Sami Kerola kirjoitti: On 07/29/2010 01:38 PM, bind-users-requ...@lists.isc.org wrote: Date: Thu, 29 Jul 2010 14:38:20 +0300 From: Jukka Pakkanenjukka.pakka...@qnet.fi Subject: Re: Subnet reverse delagation, RFC 2317 To:bind-users@lists.isc.org Message-ID:4c51682c.3080...@qnet.fi Content-Type: text/plain; charset=ISO-8859-1; format=flowed 29.7.2010 14:26, Niobos kirjoitti: On 2010-07-29 09:58, Jukka Pakkanen wrote Recursion is only allowed for the local networks, but why the server thinks recursion is needed in the first place? Because it is: dig -x looks for 200.217.142.62.in-addr.arpa. Your server is not a master for this zone; instead it's master for 128/25.217.142.62.in-addr.arpa. The original request (200.217.142.62.in-addr.arpa.) is mapped via a CNAME to a name inside your zone, but this mapping is done by the ns3.sci.fi. nameserver; hence recursion is needed. Ok, this makes sense to me too. But what is the fix, I can't allow general recursion for the world? Is it possible to allow recursion for this zone only? (sorry being lazy, I'm sure this is in the ARM..). I cannot understand why you need RFC 2317 delegation when you have two c-classes? But that's not an answer to problem. # whois 62.142.220.5 [snip] inetnum: 62.142.220.0 - 62.142.221.255 netname: Q-NET I see right that there's delegation data on ns6.sci.fi. name server... # dig +trace -x 62.142.220.5 [snip] 142.62.in-addr.arpa.172800 IN NS ns3.sci.fi. 142.62.in-addr.arpa.172800 IN NS ns6.sci.fi. 142.62.in-addr.arpa.172800 IN NS ns5.sci.fi. 142.62.in-addr.arpa.172800 IN NS ns.ripe.net. ;; Received 172 bytes from 192.134.0.49#53(NS3.NIC.FR) in 206 ms 220.142.62.in-addr.arpa. 14400 IN NS ns3.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns5.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns6.sci.fi. ;; Received 151 bytes from 195.74.0.10#53(ns3.sci.fi) in 217 ms 5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns3.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns1.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns2.qnet.fi. ;; Received 154 bytes from 195.74.0.59#53(ns6.sci.fi) in 224 ms ...and further investigation is indicating... # dig +norecurse @ns3.sci.fi. -x 62.142.220.5 ; DiG 9.6.1 +norecurse @ns3.sci.fi. -x 62.142.220.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 16475 ;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 3, ADDITIONAL: 3 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR ;; AUTHORITY SECTION: 220.142.62.in-addr.arpa. 14400 IN NS ns5.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns6.sci.fi. 220.142.62.in-addr.arpa. 14400 IN NS ns3.sci.fi. ;; ADDITIONAL SECTION: ns3.sci.fi. 14400 IN A 195.74.0.10 ns5.sci.fi. 14400 IN A 213.192.189.2 ns6.sci.fi. 14400 IN A 195.74.0.59 ;; Query time: 375 msec ;; SERVER: 195.74.0.10#53(195.74.0.10) ;; WHEN: Thu Jul 29 14:07:38 2010 ;; MSG SIZE rcvd: 151 # dig +norecurse @ns5.sci.fi. -x 62.142.220.5 ; DiG 9.6.1 +norecurse @ns5.sci.fi. -x 62.142.220.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 26753 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR ;; ANSWER SECTION: 5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR qntsrv2.qnet.fi. 5.220.142.62.in-addr.arpa. 86400 IN PTR ns1.qnet.fi. ;; AUTHORITY SECTION: 220.142.62.in-addr.arpa. 86400 IN NS ns3.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns2.qnet.fi. 220.142.62.in-addr.arpa. 86400 IN NS ns1.qnet.fi. ;; Query time: 422 msec ;; SERVER: 213.192.189.2#53(213.192.189.2) ;; WHEN: Thu Jul 29 14:07:47 2010 ;; MSG SIZE rcvd: 154 # dig +norecurse @ns6.sci.fi. -x 62.142.220.5 ; DiG 9.6.1 +norecurse @ns6.sci.fi. -x 62.142.220.5 ; (1 server found) ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 38750 ;; flags: qr aa; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;5.220.142.62.in-addr.arpa. IN PTR ;; ANSWER SECTION: 5.220.142.62.in-addr.arpa. 86400 IN PTR qnet.fi. 5.220.142.62.in-addr.arpa.
Re: Subnet reverse delagation, RFC 2317
29.7.2010 15:21, Mark Andrews kirjoitti: Yeah, this makes sense. But my question still is, what is wrong in our setup, !!! NOTHING Well, then everything is good and I can go to my vacation... hopefully the clients whose IP addresses are NOT server correctly in the reverse DNS agree with this :o ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 15:43, Jukka Pakkanen kirjoitti: Please everybody just forget the 62.142.220.0/24 network and 62.142.220.5 address, the problem is not about them. It was just to inform that our servers are doing regular /24 reverse DNS just fine. The problem is we are trying to set up and administer reverse DNS for 62.142.217.128/25 IP network. An update, now it seems to be working. dig -x 62.142.217.200 from non-local network returns correct answer. Don't know if the upstream provider did something, ttl expired or something. Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
Sorry about using 5 instead of something from 128 to 255 in the examples. That said there is nothing wrong here. The rest of the world will get the correct answers without recursion being enabled on that server and it will NEVER be asked the question you were testing with in normal operation. ; DiG 9.3.6-P1 -x 62.142.217.128 ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 29681 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;128.217.142.62.in-addr.arpa. IN PTR ;; ANSWER SECTION: 128.217.142.62.in-addr.arpa. 13978 IN CNAME 128.128/25.217.142.62.in-addr.arpa. ;; AUTHORITY SECTION: 128/25.217.142.62.in-addr.arpa. 10378 IN SOAns1.qnet.fi. helpdesk.qnet.fi. 201007292 28800 7200 604800 86400 ;; Query time: 4 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 22:56:55 2010 ;; MSG SIZE rcvd: 126 Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 16:00, Mark Andrews kirjoitti: Sorry about using 5 instead of something from 128 to 255 in the examples. That said there is nothing wrong here. Now I can agree :) However earlier our servers only answered to the local queries about those IP addresses, started working during this afternoon from non-local networks as well. My wild guess is there's a ttl in the original reverse DNS server for that (or parent) zone, which messed things?? ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
On 2010-07-29 15:00, Jukka Pakkanen wrote: Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. From my point of view, 62.142.217.64 is served by ns3.sci.fi (and its slaves) and is not delegated to you (ns1.qnet.fi). ; DiG 9.7.0-P1 64.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;64.217.142.62.in-addr.arpa.IN A ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 ;; Query time: 64 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 16:04:12 2010 ;; MSG SIZE rcvd: 101 ; DiG 9.7.0-P1 128.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 20252 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;128.217.142.62.in-addr.arpa. IN A ;; ANSWER SECTION: 128.217.142.62.in-addr.arpa. 14400 IN CNAME 128.128/25.217.142.62.in-addr.arpa. ;; AUTHORITY SECTION: 128/25.217.142.62.in-addr.arpa. 10800 IN SOAns1.qnet.fi. helpdesk.qnet.fi. 201007292 28800 7200 604800 86400 ;; Query time: 1172 msec ;; SERVER: 127.0.0.1#53(127.0.0.1) ;; WHEN: Thu Jul 29 16:05:36 2010 ;; MSG SIZE rcvd: 126 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Subnet reverse delagation, RFC 2317
29.7.2010 17:06, Niobos kirjoitti: On 2010-07-29 15:00, Jukka Pakkanen wrote: Anyway we also have 62.142.217.64/27 IP network (you know what I mean) which should be delegated to our servers, but that still doesn't work. But it's probably a delegation problem. From my point of view, 62.142.217.64 is served by ns3.sci.fi (and its slaves) and is not delegated to you (ns1.qnet.fi). ; DiG 9.7.0-P1 64.217.142.62.in-addr.arpa. ;; global options: +cmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NXDOMAIN, id: 5200 ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0 ;; QUESTION SECTION: ;64.217.142.62.in-addr.arpa.IN A ;; AUTHORITY SECTION: 217.142.62.in-addr.arpa. 3600 IN SOA ns3.sci.fi. hostmaster.sci.fi. 1280318067 3600 900 604800 3600 Thanks, looks the same here. Already contacted sci.fi hostmaster about this. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Three NameServer DOSing my dns1
Hello Matus UHLAR - fantomas, Am 2010-07-29 14:12:54, hacktest Du folgendes herunter: On 28.07.10 23:24, Michelle Konzack wrote: But why do they query my server 3 times per second? deep parsing of e-mail headers by spam filtering software, I guess. Which is the last crap! Spamassassin does this too and I had to whitelist more then 2000 E-Mails do to the high amount of false-positives. Apparently because of your fake ssmtp header. Which fake ssmtp header? How do you thinkI can send mails? My workstation has ssmtp for securtity reason installed like all of my machines which do not receive any mails but have only to send out messages like logs or alarms... courier is my official Relay which is used by more then 8000 users. Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Three NameServer DOSing my dns1
Am 2010-07-29 14:12:54, hacktest Du folgendes herunter: On 28.07.10 23:24, Michelle Konzack wrote: But why do they query my server 3 times per second? Hello Matus UHLAR - fantomas, deep parsing of e-mail headers by spam filtering software, I guess. On 29.07.10 19:16, Michelle Konzack wrote: Which is the last crap! Spamassassin does this too and I had to whitelist more then 2000 E-Mails do to the high amount of false-positives. apparently internal_networks set up incorrectly? Apparently because of your fake ssmtp header. Which fake ssmtp header? I see the name michelle1.private.tamay-dogan.net in two headers: Received: from michelle1.private.tamay-dogan.net (router.private.tamay-dogan.net [:::192.168.0.65]) (AUTH: LOGIN michelle.konzack) by mail.tamay-dogan.net with esmtp; Thu, 29 Jul 2010 19:16:29 +0200 id 0002C6F8.4C51B76D.55D9 Received: by michelle1.private.tamay-dogan.net (sSMTP sendmail emulation); Thu, 29 Jul 2010 19:16:28 +0200 since the former contains IP address, I guess it's the latter that causes some kind of spam filters try to resolve the IP. Note that I'm just guessing and it's apparently not spamassassin. However there are many spam filters deeply parsing headers and some qute incorrectly. I think you are on spamassassin-users mailing list and you could remember that problems with deeply parsed headers on some mailservers are mentioned there quite often. How do you thinkI can send mails? My workstation has ssmtp for securtity reason installed like all of my machines which do not receive any mails but have only to send out messages like logs or alarms... I'm not objecting against ssmtp, I know what's that (and I use it in some situations although I prefer msmtp ) but it's possible that the inserted header causes some filters try to resolve your hostname. You can try using msmtp or similar smtp client to see if it helps. courier is my official Relay which is used by more then 8000 users. I know because I've seen your posts on courier-users mailing list too. Actually I even know you are debian user, guess why :-) HOWEVER! To return to this ML's topic: Your hostname is private and inaccessible from the outside. The requesters get SERVFAIL reply which apparently makes them retry. If you provided them any IP address (e.g. 127.0.0.1) they could be satisfied and stop trying (until the cached record expires). You can try this if it makes you angry. -- 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. LSD will make your ECS screen display 16.7 million colors ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Three NameServer DOSing my dns1
Hello Matus UHLAR - fantomas, Am 2010-07-29 19:37:50, hacktest Du folgendes herunter: apparently internal_networks set up incorrectly? No it is the problem if a customer connect trough a VPN to the Router of the employer/enterprise and send out messages using the the companys own mail relay and fro there it comes to me to the rest of the world Note: My customers are in my network through FTTH. I see the name michelle1.private.tamay-dogan.net in two headers: Received: from michelle1.private.tamay-dogan.net (router.private.tamay-dogan.net [:::192.168.0.65]) (AUTH: LOGIN michelle.konzack) by mail.tamay-dogan.net with esmtp; Thu, 29 Jul 2010 19:16:29 +0200 id 0002C6F8.4C51B76D.55D9 Received: by michelle1.private.tamay-dogan.net (sSMTP sendmail emulation); Thu, 29 Jul 2010 19:16:28 +0200 This is because 192.168.0.65 is the gateway of my private /26 network which is NATed and is conected directly on my router. Note that I'm just guessing and it's apparently not spamassassin. However there are many spam filters deeply parsing headers and some qute incorrectly. I think you are on spamassassin-users mailing list and you could remember that problems with deeply parsed headers on some mailservers are mentioned there quite often. I know the threads... header causes some filters try to resolve your hostname. You can try using msmtp or similar smtp client to see if it helps. Already tried. It is always the same and RFC conform. :-D I know because I've seen your posts on courier-users mailing list too. Actually I even know you are debian user, guess why :-) hehehe Your hostname is private and inaccessible from the outside. The requesters get SERVFAIL reply which apparently makes them retry. If you provided them any IP address (e.g. 127.0.0.1) they could be satisfied and stop trying (until the cached record expires). You can try this if it makes you angry. I have removed the REJECT and immediatly gotten over 7000 MAILER-DAEMON errors from arround the world and this idiots are attaching WHOLE messages including attackments to it. 99% are MAILER-DAEMON messages du to faked From: using linux4michelle. Also the tries from dtag.de, t-dialin.net and arcor-ip.de are mostly MAILERDAEMON spam. Tomorrow I will call the Deutsche Telecom directly in Ofenburg/Germany since I am angy and I like to bother them. They should be a little bit busy like me. :-D Thanks, Greetings and nice Day/Evening Michelle Konzack -- # Debian GNU/Linux Consultant ## Development of Intranet and Embedded Systems with Debian GNU/Linux itsyst...@tdnet France EURL itsyst...@tdnet UG (limited liability) Owner Michelle KonzackOwner Michelle Konzack Apt. 917 (homeoffice) 50, rue de Soultz Kinzigstraße 17 67100 Strasbourg/France 77694 Kehl/Germany Tel: +33-6-61925193 mobil Tel: +49-177-9351947 mobil Tel: +33-9-52705884 fix http://www.itsystems.tamay-dogan.net/ http://www.flexray4linux.org/ http://www.debian.tamay-dogan.net/ http://www.can4linux.org/ Jabber linux4miche...@jabber.ccc.de ICQ#328449886 Linux-User #280138 with the Linux Counter, http://counter.li.org/ signature.pgp Description: Digital signature ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Three NameServer DOSing my dns1
On 7/29/2010 2:11 PM, Michelle Konzack wrote: Hello Matus UHLAR - fantomas, Your hostname is private and inaccessible from the outside. The requesters get SERVFAIL reply which apparently makes them retry. If you provided them any IP address (e.g. 127.0.0.1) they could be satisfied and stop trying (until the cached record expires). You can try this if it makes you angry. I have removed the REJECT and immediatly gotten over 7000 MAILER-DAEMON errors from arround the world and this idiots are attaching WHOLE messages including attackments to it. 99% are MAILER-DAEMON messages du to faked From: usinglinux4michelle. Also the tries fromdtag.de,t-dialin.net andarcor-ip.de are mostly MAILERDAEMON spam. If there are spammers sending mail claiming to be from: linux4miche...@michelle1.private.tamay-dogan.net that would be another reason you would be seeing the queries. (Although I'd expect them to come from a lot more DNS servers; maybe it is targeted spam). Anyway, nothing says that you *have* to give an answer that actually leads back to your mail server for that hostname. -- Dave ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamically add zones
Alan/ Evan,
Thanks didn't get to reading the beta release notes yet. Wow, how timely is
this :)
Thanks
-m
On Wed, Jul 28, 2010 at 8:08 PM, Alan Clegg acl...@isc.org wrote:
On 7/28/2010 10:41 PM, Mike Flathers wrote:
Is there a patch for bind 9 to add new zones dynamically without
having to run rndc reconfig? The server stops answering queries when
reconfig is loading in the new config as the config grows this timeout
increases. I haven't hit the source code yet, but something like rndc
addzone zonename [config options | clone zone] would be nice :)
Look for it in BIND 9.7.2
Here's what I have that creates zones, makes them dynamic and signs them
with no human interference (producing the DS record for the parent):
==SNIP==
#!/bin/bash
cd /etc/namedb
cp template master/${1}
rndc addzone ${1} { type master\;\
file \master/${1}\\;\
update-policy local\; \
auto-dnssec maintain\; \
}\;
dnssec-keygen -f KSK -K /etc/namedb/keys $1
dnssec-dsfromkey -2 /etc/namedb/keys/K${1}.*.key ds/${1}
dnssec-keygen -K /etc/namedb/keys $1
rndc sign ${1}
==SNIP==
Yes, no error checking, etc, but it works well as a proof-of-concept...
___
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: Dynamically add zones
Alan,
I was playing around with your example. I can get it to add the zone ( that is
no rndc errors or syslog messages).
I see it send notifies for the new zone in my log.
29-Jul-2010 23:06:47.063 notify: info: zone exampledomain.com/IN: sending
notifies (serial 12)
I also added the global option new-zone-file my_new_zones.dat and I see that
file being populated with the new zones statements I've added via rndc.
The server however responds with a REFUSED for this zone or any others done via
addzone.
If i take the zone option statement in my_new_zones.dat and apply them to
named.conf and reconfig it resolves just fine. Anyone else experiencing this?
Can't wait for this feature to become finalized :)
Dan Durrer
No-IP.com
On Jul 28, 2010, at 8:08 PM, Alan Clegg wrote:
On 7/28/2010 10:41 PM, Mike Flathers wrote:
Is there a patch for bind 9 to add new zones dynamically without
having to run rndc reconfig? The server stops answering queries when
reconfig is loading in the new config as the config grows this timeout
increases. I haven't hit the source code yet, but something like rndc
addzone zonename [config options | clone zone] would be nice :)
Look for it in BIND 9.7.2
Here's what I have that creates zones, makes them dynamic and signs them
with no human interference (producing the DS record for the parent):
==SNIP==
#!/bin/bash
cd /etc/namedb
cp template master/${1}
rndc addzone ${1} { type master\;\
file \master/${1}\\;\
update-policy local\; \
auto-dnssec maintain\; \
}\;
dnssec-keygen -f KSK -K /etc/namedb/keys $1
dnssec-dsfromkey -2 /etc/namedb/keys/K${1}.*.key ds/${1}
dnssec-keygen -K /etc/namedb/keys $1
rndc sign ${1}
==SNIP==
Yes, no error checking, etc, but it works well as a proof-of-concept...
___
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: Dynamically add zones
On 7/29/2010 7:19 PM, Dan Durrer wrote:
Alan,
I was playing around with your example. I can get it to add the zone
( that is no rndc errors or syslog messages).
I see it send notifies for the new zone in my log.
29-Jul-2010 23:06:47.063 notify: info: zone exampledomain.com/IN:
sending notifies (serial 12)
I also added the global option new-zone-file my_new_zones.dat and
I see that file being populated with the new zones statements I've
added via rndc.
The server however responds with a REFUSED for this zone or any
others done via addzone.
If i take the zone option statement in my_new_zones.dat and apply
them to named.conf and reconfig it resolves just fine. Anyone else
experiencing this?
include the my_new_zones.dat into your named.conf... my entire
named.conf on the sample system reads:
SNIP
options {
directory /etc/namedb;
dnssec-enable yes;
dnssec-validation yes;
new-zone-file /etc/namedb/managed.zone.list;
key-directory /etc/namedb/keys;
};
include /etc/namedb/zone.list;
SNIP
Note that the syntax for this set of tools (dynamic zone creation) is a
bit in flux and may be completely changed between 9.7.2 and 9.7.3. The
functionality will be there, but it might be a bit different in
implementation.. (beware!)
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Dynamically add zones
Alan,
So is managed.zone.list and zone.list named differently on purpose or is that
a typo?
Dan
On Jul 29, 2010, at 5:23 PM, Alan Clegg acl...@isc.org wrote:
On 7/29/2010 7:19 PM, Dan Durrer wrote:
Alan,
I was playing around with your example. I can get it to add the zone
( that is no rndc errors or syslog messages).
I see it send notifies for the new zone in my log.
29-Jul-2010 23:06:47.063 notify: info: zone exampledomain.com/IN:
sending notifies (serial 12)
I also added the global option new-zone-file my_new_zones.dat and
I see that file being populated with the new zones statements I've
added via rndc.
The server however responds with a REFUSED for this zone or any
others done via addzone.
If i take the zone option statement in my_new_zones.dat and apply
them to named.conf and reconfig it resolves just fine. Anyone else
experiencing this?
include the my_new_zones.dat into your named.conf... my entire
named.conf on the sample system reads:
SNIP
options {
directory /etc/namedb;
dnssec-enable yes;
dnssec-validation yes;
new-zone-file /etc/namedb/managed.zone.list;
key-directory /etc/namedb/keys;
};
include /etc/namedb/zone.list;
SNIP
Note that the syntax for this set of tools (dynamic zone creation) is a
bit in flux and may be completely changed between 9.7.2 and 9.7.3. The
functionality will be there, but it might be a bit different in
implementation.. (beware!)
AlanC
___
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: Dynamically add zones
On 7/29/2010 5:38 PM, Jack Tavares wrote:
Will this functionality be available through an api?
Or will it just be through rndc ?
Not sure what API we would use beyond rndc. If you have
recommendations, please e-mail me directly or give me a phone call
(+1-919-355-885) and let's talk about it...
What error checking and reporting will it give?
Error checking is about as good as editing named.conf by hand and then
running named-checkconf. The log on the server receiving the 'rndc'
command gets useful things like:
--SNIP--
30-Jul-2010 00:25:29.013 received control channel command 'addzone
clegg.com { type slave; file slave/clegg.com'
30-Jul-2010 00:25:29.014 none:1: missing ';' before end of file
30-Jul-2010 00:25:29.014 none:1: '}' expected near end of file
--SNIP--
and
--SNIP--
30-Jul-2010 00:42:26.717 received control channel command 'addzone
boo!bad.com { type master; file master/boo!bad.com; update-policy
local; auto-dnssec maintain; };'
30-Jul-2010 00:42:26.717 none:1: '{' expected near '!'
--SNIP--
Unfortunately, rndc isn't very talkative on error messages, but it does
complain if something goes wrong:
When adding a zone that is already in the named.conf:
--SNIP--
r...@ubuntu:/etc/namedb# ./addslavezone clegg.com
rndc: 'addzone' failed: already exists
--SNIP--
And with a bad name:
--SNIP--
r...@ubuntu:/etc/namedb# ./addzone boo\!bad.com
rndc: 'addzone' failed: unexpected token
--SNIP--
Once scripted to do pre-rndc error checking, I'm sure that someone
will be able to write a heck of a frontend -- we expect nothing less.
:)
AlanC
signature.asc
Description: OpenPGP digital signature
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
