Re: Assistance with reverse lookup zone
Hi As others have indicated, this block has been delegated to you using RFC2317 - Classless IN-ADDR.ARPA delegation. You have to make configure a zone in your named.conf named 162-27.3.187.64.in-addr.arpa. Then populate this zone with your data. Something like ... $ORIGIN 162-27.3.187.64.in-addr.arpa. 170PTR smtp3.netcraftcommunications.com. ... Regards Sven Emil Skretteberg DNS admin, EDB Business Partner On Thu, Jun 11, 2009 at 8:08 PM, Frank Pikelner frank.pikel...@netcraftcommunications.com wrote: Every now and then we get a bounce on emails that are sent through one of our mails servers located on 64.187.3.170. The bounce messages look as follows and appear to indicate that our reverse zone is missing a record, though the record is there and resolves through nslookup. The ISP delegates a number of IP addresses from the zone back to us (16 IP addresses). So my guess is that our zone file needs to be rewritten or there may be something else I'm missing. first_l...@some_domain.com: host mx.some_domain.com[xxx.xx.xx.xx] said: 450 4.7.1 Client host rejected: cannot find your hostname, [64.187.3.170] (in reply to RCPT TO command) Performing a manual reverse lookup correctly displays the correct name for 170.3.187.64.in-addr.arpa. Our zone file looks as follows (other records removed): $ORIGIN . $TTL 86400 ; 1 day 3.187.64.in-addr.arpa IN SOA ns1.blue-dot.ca. dnsadmin.ns1.blue-dot.ca. ( 2009011401 ; serial 1800 ; refresh (30 minutes) 900; retry (15 minutes) 604800 ; expire (1 week) 1800 ; minimum (30 minutes) ) NS ns1.blue-dot.ca. NS ns2.blue-dot.ca. NS ns3.blue-dot.ca. $ORIGIN 3.187.64.in-addr.arpa. 170 PTR smtp3.netcraftcommunications.com. ___ 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: Assistance with reverse lookup zone
On Fri, 2009-06-12 at 11:42 +1000, Mark Andrews wrote:
In message b86f8bceeed5184ca225e0cc10ff61163ec...@bdc03srv04.bdc.int,
Frank
Pikelner writes:
Every now and then we get a bounce on emails that are sent through one =
of our mails servers located on 64.187.3.170. The bounce messages look =
as follows and appear to indicate that our reverse zone is missing a =
record, though the record is there and resolves through nslookup. The =
ISP delegates a number of IP addresses from the zone back to us (16 IP =
addresses). So my guess is that our zone file needs to be rewritten or =
there may be something else I'm missing.
first_l...@some_domain.com: host mx.some_domain.com[xxx.xx.xx.xx] =
said: 450 4.7.1 Client
host rejected: cannot find your hostname, [64.187.3.170] (in reply =
to RCPT
TO command)
Performing a manual reverse lookup correctly displays the correct name =
for 170.3.187.64.in-addr.arpa. Our zone file looks as follows (other =
records removed):
ns1.blue-dot.ca is NOT configured to serve
162-27.3.187.64.in-addr.arpa. It should be so configured.
Mark
162-27.3.187.64.in-addr.arpa. 86400 IN NS ns3.blue-dot.ca.
162-27.3.187.64.in-addr.arpa. 86400 IN NS ns1.blue-dot.ca.
162-27.3.187.64.in-addr.arpa. 86400 IN NS ns2.blue-dot.ca.
;; Received 115 bytes from 209.135.99.3#53(ns2.toroon.grouptelecom.net) in
249 ms
3.187.64.in-addr.arpa. 1800IN SOA ns1.blue-dot.ca.
dnsadmin.ns1.blue-dot.ca. 2009011401 1800 900 604800 1800
;; Received 110 bytes from 64.187.3.170#53(ns3.blue-dot.ca) in 679 ms
Thank you for everyone's assistance. I have updated the zone files.
After the updates and restarting BIND, I run dig +trace ptr
170.3.187.64.in-addr.arpa and the result stops just prior to getting to
my DNS server and correctly resolving the name of the IP address. I'm
new to dig and do not know whether this is correct for an RFC2317 zone
delegation or whether the trace should be completing at my servers and
resolving the name. My guess is there must be something still incorrect
on my end.
Though, using NSLOOKUP against opendns servers for
170.3.187.64.in-addr.arpa does resolve the name correctly.
NAMED.CONF has the zone defined as follows:
zone 162-27.3.187.64.in-addr.arpa IN {
type master;
file 64_187_3_162-27.rev;
};
The zone file looks as follows:
$ORIGIN .
$TTL 86400 ; 1 day
162-27.3.187.64.in-addr.arpa. IN SOA ns1.blue-dot.ca.
dnsadmin.ns1.blue-dot.ca. (
2009051202 ; serial
1800 ; refresh (30 minutes)
900; retry (15 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)
NS ns1.blue-dot.ca.
NS ns2.blue-dot.ca.
NS ns3.blue-dot.ca.
$ORIGIN 162-27.3.187.64.in-addr.arpa.
170 PTR smtp3.netcraftcommunications.com.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Tracking down validation failures
On Jun 11 2009, Jeremy C. Reed wrote: On Thu, 11 Jun 2009, Chris Thompson wrote: We have recently turned on DNSSEC validation (using dlv.isc.org) in our main university-wide recursive nameservers, which are running BIND 9.6.1rc1. No-one is actually complaining, but the counts I am seeing for ValFail on the statistics channel are quite a bit higher than we were seeing during testing, running at 0.2% - 0.4% of ValAttempt (but the counter increases in bursts), and I would be happier knowing what they were coming from. Have a look at the new (experimental) query-errors category. For example: [...] It is way less noisy than the dnssec logging. This was a good suggestion - thank you. I have tried logging query-errors at debug level 4, and some of the entries do have non-zero valfail counts. (They don't add up to as much as the statistics-channel ValFail counter is increasing by, though.] Here is a half-hour sample from one of the nameservers: 12-Jun-2009 16:27:59.583 debug 4: fetch completed at resolver.c:4046 for 38.130.244.88.IN-ADDR.ARPA/PTR in 0.678061: success/not insecure [domain:88.in-addr.arpa,referral:0,restart:1,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1] 12-Jun-2009 16:35:00.415 debug 4: fetch completed at resolver.c:4046 for 102.136.103.91.IN-ADDR.ARPA/PTR in 1.045085: success/not insecure [domain:91.in-addr.arpa,referral:0,restart:1,qrysent:3,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:2] 12-Jun-2009 16:36:31.380 debug 2: fetch completed at resolver.c:2891 for 130.40.8.84.in-addr.arpa/PTR in 3.500594: failure/no valid DS [domain:40.8.84.in-addr.arpa,referral:1,restart:2,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:2] 12-Jun-2009 16:36:38.606 debug 2: fetch completed at resolver.c:2891 for 130.40.8.84.in-addr.arpa/PTR in 3.689695: failure/no valid ds [domain:40.8.84.in-addr.arpa,referral:0,restart:2,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:2] 12-Jun-2009 16:36:58.459 debug 4: fetch completed at resolver.c:4046 for 55.106.0.89.IN-ADDR.ARPA/PTR in 0.642334: success/not insecure [domain:89.in-addr.arpa,referral:0,restart:1,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1] 12-Jun-2009 16:41:53.588 debug 2: fetch completed at resolver.c:2891 for 130.40.8.84.in-addr.arpa/PTR in 4.228979: failure/no valid DS [domain:40.8.84.in-addr.arpa,referral:0,restart:2,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:2] 12-Jun-2009 16:43:34.731 debug 4: fetch completed at resolver.c:4046 for 172.164.22.213.IN-ADDR.ARPA/PTR in 0.489031: success/not insecure [domain:213.in-addr.arpa,referral:0,restart:1,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1] 12-Jun-2009 16:43:55.521 debug 2: fetch completed at resolver.c:2891 for 40.8.84.in-addr.arpa/DS in 3.186479: failure/no valid RRSIG [domain:8.84.in-addr.arpa,referral:1,restart:2,qrysent:4,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4] 12-Jun-2009 16:47:36.840 debug 4: fetch completed at resolver.c:4046 for 157.14.110.87.IN-ADDR.ARPA/PTR in 0.551489: success/not insecure [domain:87.in-addr.arpa,referral:0,restart:1,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1] 12-Jun-2009 16:47:59.038 debug 2: fetch completed at resolver.c:2891 for 40.8.84.in-addr.arpa/DS in 1.243316: failure/no valid RRSIG [domain:8.84.in-addr.arpa,referral:1,restart:2,qrysent:4,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4] 12-Jun-2009 16:48:08.100 debug 4: fetch completed at resolver.c:4046 for 126.85.252.77.IN-ADDR.ARPA/PTR in 0.635810: success/not insecure [domain:77.in-addr.arpa,referral:0,restart:1,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1] 12-Jun-2009 16:53:01.580 debug 2: fetch completed at resolver.c:2891 for 52.7.8.84.in-addr.arpa/PTR in 10.775506: failure/no valid DS [domain:8.84.in-addr.arpa,referral:0,restart:2,qrysent:4,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4] 12-Jun-2009 16:53:19.150 debug 2: fetch completed at resolver.c:2891 for 52.7.8.84.in-addr.arpa/PTR in 12.530152: failure/no valid DS [domain:8.84.in-addr.arpa,referral:0,restart:2,qrysent:4,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4] 12-Jun-2009 16:53:35.240 debug 2: fetch completed at resolver.c:2891 for 52.7.8.84.in-addr.arpa/PTR in 11.088051: failure/no valid DS [domain:8.84.in-addr.arpa,referral:0,restart:2,qrysent:4,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:4] 12-Jun-2009 16:53:51.844 debug 4: fetch completed at resolver.c:4046 for 134.240.154.88.IN-ADDR.ARPA/PTR in 0.643090: success/not insecure [domain:88.in-addr.arpa,referral:0,restart:1,qrysent:2,timeout:0, lame:0,neterr:0,badresp:0,adberr:0,findfail:0,valfail:1] The debug level 2 messages, which correspond to SERVFAILs, are all associated with 8.84.in-addr.arpa, and it does seem
Re: Assistance with reverse lookup zone
Frank Pikelner wrote:
Thank you for everyone's assistance. I have updated the zone files.
After the updates and restarting BIND, I run dig +trace ptr
170.3.187.64.in-addr.arpa and the result stops just prior to getting to
my DNS server and correctly resolving the name of the IP address. I'm
new to dig and do not know whether this is correct for an RFC2317 zone
delegation or whether the trace should be completing at my servers and
resolving the name. My guess is there must be something still incorrect
on my end.
Though, using NSLOOKUP against opendns servers for
170.3.187.64.in-addr.arpa does resolve the name correctly.
NAMED.CONF has the zone defined as follows:
zone 162-27.3.187.64.in-addr.arpa IN {
type master;
file 64_187_3_162-27.rev;
};
The zone file looks as follows:
$ORIGIN .
$TTL 86400 ; 1 day
162-27.3.187.64.in-addr.arpa. IN SOA ns1.blue-dot.ca.
dnsadmin.ns1.blue-dot.ca. (
2009051202 ; serial
1800 ; refresh (30 minutes)
900; retry (15 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)
NS ns1.blue-dot.ca.
NS ns2.blue-dot.ca.
NS ns3.blue-dot.ca.
$ORIGIN 162-27.3.187.64.in-addr.arpa.
170 PTR smtp3.netcraftcommunications.com.
*Looks like its working to me.*
% dig 170.3.187.64.in-addr.arpa. ptr
; DiG 9.4.3-P2 170.3.187.64.in-addr.arpa. ptr
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 1748
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;170.3.187.64.in-addr.arpa. IN PTR
;; ANSWER SECTION:
170.3.187.64.in-addr.arpa. 3941 IN CNAME
170.162-27.3.187.64.in-addr.arpa.
170.162-27.3.187.64.in-addr.arpa. 86335 IN PTR
smtp3.netcraftcommunications.com.
*Using dig to test at the opendns servers.*
% dig @208.67.222.222 170.3.187.64.in-addr.arpa. ptr
; DiG 9.4.3-P2 @208.67.222.222 170.3.187.64.in-addr.arpa. ptr
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 436
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;170.3.187.64.in-addr.arpa. IN PTR
;; ANSWER SECTION:
170.3.187.64.in-addr.arpa. 86400 IN CNAME
170.162-27.3.187.64.in-addr.arpa.
170.162-27.3.187.64.in-addr.arpa. 86400 IN PTR
smtp3.netcraftcommunications.com.
___
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Trying to understand DNSSEC and BIND versions better
On Jun 12, 2009, at 1:50 AM, Adam Tkac wrote: On Wed, Jun 10, 2009 at 08:37:52PM -0700, Chris Buxton wrote: A few of our customers, running servers that they describe as experiencing high traffic (by their own standards), have had to have us rebuild BIND from the stock source code for them to solve frequent crashing during such high traffic episodes. Frequent in this case typically means that named either just dies or dumps core within a few seconds of starting up. Have you ever reported the problems to the Red Hat or Debian bug tracker? Generally you don't have to be experienced programmer. Your bug report can contain, for example, named crashed with this INSIST failure: ... only. Your vendor will ask you more information if needed. Since the servers that have been affected were not mine, I did not do so. I think it is a good idea to use package from your vendor because you don't have to watch bind-announce, don't have to compile each time when bind is updated etc. You can simply run yum update or apt-get upgrade and you can be sure you have software without security issues. But feel free to compile named yourself if you prefer this approach. There's a definite argument in favor of this. However, this assumes that the vendors are on the ball. For example, for a long time after 9.3.5-P2 was released, the RH build of BIND on RHEL 5 was still using the -P1 patch. This was a real problem for a small number of our customers. For most servers, the vendor-supplied builds work fine. But IMO for high-traffic servers, it makes sense for the server administrator to do it himself. This would be true whether or not the vendor supplied build had stability problems on that server. Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Assistance with reverse lookup zone
On Jun 12, 2009, at 9:37 AM, Frank Pikelner wrote: Thank you for everyone's assistance. I have updated the zone files. After the updates and restarting BIND, I run dig +trace ptr 170.3.187.64.in-addr.arpa and the result stops just prior to getting to my DNS server and correctly resolving the name of the IP address. I'm new to dig and do not know whether this is correct for an RFC2317 zone delegation or whether the trace should be completing at my servers and resolving the name. This is normal. dig +trace does not follow the dangling CNAME record that it finds - you'll see it in the last part of the trace. Just re- run the trace with the altered name shown on the RHS of the CNAME record - 170.162-27.3.187.64.in-addr.arpa - or query with that name against the indicated name servers directly (without using +trace). $ dig 170.162-27.3.187.64.in-addr.arpa PTR +norec @ns3.blue-dot.ca ; DiG 9.4.3-P1 170.162-27.3.187.64.in-addr.arpa PTR +norec @ns3.blue-dot.ca ;; global options: printcmd ;; Got answer: ;; -HEADER- opcode: QUERY, status: NOERROR, id: 7189 ;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 0 ;; QUESTION SECTION: ;170.162-27.3.187.64.in-addr.arpa. IN PTR ;; ANSWER SECTION: 170.162-27.3.187.64.in-addr.arpa. 86400 IN PTR smtp3.netcraftcommunications.com. ;; AUTHORITY SECTION: 162-27.3.187.64.in-addr.arpa. 86400 IN NS ns2.blue-dot.ca. 162-27.3.187.64.in-addr.arpa. 86400 IN NS ns3.blue-dot.ca. 162-27.3.187.64.in-addr.arpa. 86400 IN NS ns1.blue-dot.ca. ;; Query time: 118 msec ;; SERVER: 64.187.3.170#53(64.187.3.170) ;; WHEN: Fri Jun 12 12:03:34 2009 ;; MSG SIZE rcvd: 161 Chris Buxton Professional Services Men Mice ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: querylog entries
On Fri, 12 Jun 2009, R Dicaire wrote: Hi folks, just upgraded from 9.4x to 9.6.1, and looking at my query.log I'm seeing entries appended with -EC, -ED , -EDC, etc. What does this indicate, and where can I read up on what they mean? Hi, I am just copying and pasting from the great ARM which is included with BIND: The query log entry reports the client's IP address and port number, and the query name, class and type. It also reports whether the Recursion Desired flag was set (+ if set, - if not set), if the query was signed (S), EDNS was in use (E), if DO (DNSSEC Ok) was set (D), or if CD (Checking Disabled) was set (C). Jeremy C. Reed ISC echo ... naq ninvynoyr va cevagrq obbx sbezng. | \ tr noqrsvxyzabcegi abdefiklmnoprtv ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Tracking down validation failures
At 12 Jun 2009 17:50:39 +0100, Chris Thompson c...@cam.ac.uk wrote: (They don't add up to as much as the statistics-channel ValFail counter is increasing by, though.] It's not surprising: if validation attempt succeeds with one authoritative server after some validation failures with other authoritative servers, you won't see the intermediate error in query-error log messages. But these failures are still counted in ValFail. --- JINMEI, Tatuya Internet Systems Consortium, Inc. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Slave DNS disconnect...
We recently received a /24 from a provider who said they'd delegate rDNS authority to our servers: ns1.ns-one.net (85.17.204.1) and ns2.ns-one.net (69.26.172.2) But looking at the dig trace (I won't copy it in here) for one of the IP#s (chosen at random): $ dig -x 74.124.205.95 +trace it doesn't end up at my servers, and I can't see how I can possibly have authority. But the provider assures me that they've got others set up exactly this way and that they can do rDNS. I can't, and I can't see how I could. Can anyone tell me anything I can tell my provider to assure them that's something wrong? Or if not, please tell me that I'm wrong, and I'll figure out why my zone isn't working. (In the meantime we can't send email to a lot of places because or rDNS isn't returning anything.) Thanks! Jeff -- Jeff Lasman, Nobaloney Internet Services P.O. Box 52200, Riverside, CA 92517 Our blists address used on lists is for list email only voice: +1 951 643-5345, or see: http://www.nobaloney.net/contactus.html; ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
