Re: Classless PTR query issue
On Tuesday, May 7, 2013 9:06:53 PM UTC-4, Doug Barton wrote: On 05/07/2013 01:50 PM, Matus UHLAR - fantomas wrote: On 07.05.13 11:06, Michael Varre wrote: So interestingly they did give me their setup and this is their response, and my warm and fuzzy feeling continues to go out the window: They use SimpleDNS Record Name: 65.246.59.108.in-addr.arpa DNS Server (FQDN): dns1.kishmish.com. TTL: 1 Hour I'd imagine this is wrong since 65 is my starting IP rather than my network IP, which is 64. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. https://dougbarton.us/DNS/2317.html I sent them the RFC yesterday and even sent them the KB article from SimpleDNS.com but I think they still have something done incorrectly. It's amazing how large hosts take proper DNS administration for granted these days. I don't have time to teach them how to do this anymore, so unfortunately I think I'm going to throw in the towel and just have them create the PTR records for me...right now I just need them to resolve! Thanks everyone for your input. I will reference this thread for them in the next few weeks if I'm able to fine someone able to make the proper changes. ___ 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
Classless PTR query issue
I'm setting up a new zone, similar to the many I've created successfully on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated to my
dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external: query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried setting
up reverse dns to be setup by a cpanel server, but I'm not sure this is
relevant. It creates two views, internal and external. This is getting
serviced out of the external view, which really is just setup to answer any
question for which it has an answer. So i _really_ don't think it's relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
___
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: Classless PTR query issue
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created successfully on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external: query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure this
is relevant. It creates two views, internal and external. This is getting
serviced out of the external view, which really is just setup to answer any
question for which it has an answer. So i _really_ don't think it's relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
___
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: Classless PTR query issue
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created successfully on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated
to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external:
query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure
this
is relevant. It creates two views, internal and external. This is getting
serviced out of the external view, which really is just setup to answer any
question for which it has an answer. So i _really_ don't think it's
relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how to
delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside would
point to it being setup wrong by the ISP? .90 is one of my assigned IP's
withing my /26. My GW IP address is .65. Maybe that is where I've gone wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a
random number (one of the downfalls of obfuscating IP's on a mailing list).
consider that really 9.9.9.9, and that it is NOT one of my IP's - just a client
on the internet.
___
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: Classless PTR query issue
I recommend dig +trace -x on one of your assigned IPs. Compare with
the result from a known-good sub-24 rev dns delegation. The ISP
should be returning something like:
162.48.168.205.in-addr.arpa. 43200 IN CNAME
162.160-175.48.168.205.in-addr.arpa.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns.norchemlab.com.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.norchemlab.com.
and your NS should respond for the 160-175 zone. The particular
naming convention doesn't matter, but has to be consistent between you
and your ISP. The filename of the zone doesn't need to match the zone
name, although that seems to be a popular misconception.. Slashes (as
in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention
since, if the filename and zone DO match, they imply use of a
subdirectory.
Good luck,
Justin
On Tue, May 07, 2013 at 08:45:49AM -0700, Michael Varre wrote:
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created successfully
on
other ISPs to answer with PTR records for a /26 the ISP has sub-delegated
to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external:
query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure
this
is relevant. It creates two views, internal and external. This is
getting
serviced out of the external view, which really is just setup to answer
any
question for which it has an answer. So i _really_ don't think it's
relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how to
delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside would
point to it being setup wrong by the ISP? .90 is one of my assigned IP's
withing my /26. My GW IP address is .65. Maybe that is where I've gone wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a
random number (one of the downfalls of obfuscating IP's on a mailing list).
consider that really 9.9.9.9, and that it is NOT one of my IP's - just a
client on the internet.
___
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: Classless PTR query issue
On Tuesday, May 7, 2013 12:04:10 PM UTC-4, Justin T Pryzby wrote: I recommend dig +trace -x on one of your assigned IPs. Compare with the result from a known-good sub-24 rev dns delegation. The ISP should be returning something like: 162.48.168.205.in-addr.arpa. 43200 IN CNAME 162.160-175.48.168.205.in-addr.arpa. 160-175.48.168.205.in-addr.arpa. 43200 IN NSns.norchemlab.com. 160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.norchemlab.com. and your NS should respond for the 160-175 zone. The particular naming convention doesn't matter, but has to be consistent between you and your ISP. The filename of the zone doesn't need to match the zone name, although that seems to be a popular misconception.. Slashes (as in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention since, if the filename and zone DO match, they imply use of a subdirectory. Good luck, Justin Thanks Justin, I've been testing with dig and that's how I got the failed results posted previously. My digs lead me to believe their zones are named the same as mine, with -'s instead of /'s. dig -x 1.1.1.90 +trace snipped ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms end I've requested they confirm their setup, but I don't know how forthcoming they'll be. ___ 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: Classless PTR query issue
On Tuesday, May 7, 2013 12:04:10 PM UTC-4, Justin T Pryzby wrote:
I recommend dig +trace -x on one of your assigned IPs. Compare with
the result from a known-good sub-24 rev dns delegation. The ISP
should be returning something like:
162.48.168.205.in-addr.arpa. 43200 IN CNAME
162.160-175.48.168.205.in-addr.arpa.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns.norchemlab.com.
160-175.48.168.205.in-addr.arpa. 43200 IN NSns1.norchemlab.com.
and your NS should respond for the 160-175 zone. The particular
naming convention doesn't matter, but has to be consistent between you
and your ISP. The filename of the zone doesn't need to match the zone
name, although that seems to be a popular misconception.. Slashes (as
in 160/28.48.168.205.in-addr.arpa) are mildly inconvenient convention
since, if the filename and zone DO match, they imply use of a
subdirectory.
Good luck,
Justin
On Tue, May 07, 2013 at 08:45:49AM -0700, Michael Varre wrote:
On Tuesday, May 7, 2013 11:34:07 AM UTC-4, Barry Margolin wrote:
In article mailman.240.1367938655.20661.bind-us...@lists.isc.org,
Michael Varre mva...@gmail.com wrote:
I'm setting up a new zone, similar to the many I've created
successfully on
other ISPs to answer with PTR records for a /26 the ISP has
sub-delegated to
my dns servers and it continues to fail:
May 7 08:18:31 dns1 named[25328]: client 1.1.1.1#62125: view external:
query
(cache) '90.1.1.1.in-addr.arpa/PTR/IN' denied
My named.conf is setup as
zone 64-26.1.1.1.in-addr.arpa {
type master;
file /var/named/64-26.1.1.1.in-addr.arpa.db;
};
zone record is:
$TTL 14400
64-26.1.1.1.in-addr.arpa. 86400 IN SOA dns1.myns.com.
me.my.com. (
2013050702 ;Serial
Number
86400 ;refresh
7200 ;retry
1209600 ;expire
86400 ;minimum
)
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns1.myns.com.
64-26.1.1.1.in-addr.arpa. 86400 IN NS dns2.myns.com.
90 14400 IN PTR apple.somedomain.com.
Mind you this is a cpanel server and this is the first time I've tried
setting up reverse dns to be setup by a cpanel server, but I'm not sure
this
is relevant. It creates two views, internal and external. This is
getting
serviced out of the external view, which really is just setup to answer
any
question for which it has an answer. So i _really_ don't think it's
relevant
but for the sake of troubleshooting I thought I might disclose that.
Anyone have any ideas? Thanks in advance.
If you're getting queries for 90.1.1.1.in-addr.arpa from outside
clients, it means that the ISP has not set up the proper classless
reverse delegation. They're delegating 1.1.1.in-addr.arpa to you instead
of 64-26.1.1.1.in-addr.arpa.
But the client IP appears to be one of your own addresses. They should
be pointing to your caching server, not the authoritative server. It
should then follow the ISP's delegation. If you're using the same
server for auth and caching, you need to put the local IPs in the
allow-query ACL.
--
Barry Margolin
Arlington, MA
Thanks for the response Barry. First, I have a hunch they don't know how
to delegate classlessly. They seemed very confused at first.
Why would you think that queries for 90.1.1.1.in-addr.arpa from outside
would point to it being setup wrong by the ISP? .90 is one of my assigned
IP's withing my /26. My GW IP address is .65. Maybe that is where I've gone
wrong?
I think my example may have confused things a bit. The 1.1.1.1 was just a
random number (one of the downfalls of obfuscating IP's on a mailing list).
consider that really 9.9.9.9, and that it is NOT one of my IP's - just a
client on the internet.
___
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
So interestingly they did give me
Re: Classless PTR query issue
On Tue, May 07, 2013 at 09:52:16AM -0700, Michael Varre wrote: Thanks Justin, I've been testing with dig and that's how I got the failed results posted previously. My digs lead me to believe their zones are named the same as mine, with -'s instead of /'s. dig -x 1.1.1.90 +trace snipped ;; Received 180 bytes from 199.253.183.183#53(b.in-addr-servers.arpa) in 89 ms 1.1.1.in-addr.arpa. 86400 IN NS NS1.myisp.COM. 1.1.1.in-addr.arpa. 86400 IN NS NS2.myisp.COM. ;; Received 89 bytes from 199.180.180.63#53(r.arin.net) in 55 ms 90.1.1.1.in-addr.arpa. 3600 IN NS dns1.myns.com. ;; Received 75 bytes from 13.13.13.13#53(NS1.myisp.COM) in 84 ms ;; Received 44 bytes from 1.1.1.90#53(dns1.myns.com) in 80 ms end I've requested they confirm their setup, but I don't know how forthcoming they'll be. I don't see any - (or /) in your dig output, which indicates that the ISP delegation isn't using RFC2317-style delegation with CNAMES. It appears they may have manually added NS records for each of 64 IPs. That's messy and inelegant for them, and doesn't work right either. The ISP is responding with NS for 90.1.1.1, which means that the next query must ask a quesion *below* that: something.90.1.1.1. That's why a CNAME is needed, with an additional, artificial subzone, allowing proper delegation. Otherwise, it's a so-called horizontal referal. In the past, when I've requested RFC2317/sub-24 delegation of rev dns, I've included/suggested BIND syntax (but it's still sometimes taken multiple attempts to be correctly implemented). $ORIGIN 196.185.205.in-addr.arpa. 32-47 NS ns.norchemlab.com. 32-47 NS ns1.norchemlab.com. $GENERATE 32-47 $ CNAME $.32-47 Justin ___ 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: Classless PTR query issue
and so much for keeping my ip's and hosts private :) ___ 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: Classless PTR query issue
In article mailman.246.1367950255.20661.bind-us...@lists.isc.org,
Justin T Pryzby justinpry...@users.sourceforge.net wrote:
It appears they may have manually added NS records for each of 64 IPs.
That's messy and inelegant for them, and doesn't work right either.
The ISP is responding with NS for 90.1.1.1, which means that the next
query must ask a quesion *below* that: something.90.1.1.1. That's why
a CNAME is needed, with an additional, artificial subzone, allowing
proper delegation. Otherwise, it's a so-called horizontal referal.
Actually, this kind of referral works OK -- it's how you find the SOA of
a subdomain, for instance.
The strictly legal way to implement this in the subdomain's server is to
have separate zones for each IP:
zone 65.1.1.1.in-addr.arpa {
type master;
filename 1.1.1.65.rev;
};
zone 66.1.1.1.in-addr.arpa {
type master;
filename 1.1.1.66.rev;
};
...
Each of these reverse zone files should then contain a PTR record at the
apex:
@ IN SOA ...
IN NS dns1.yourdomain.com.
IN PTR hostname.yourdomain.com.
In practice, though, what people often do in this case is create a
1.1.1.in-addr.arpa zone. The problem with this is that the responses
will claim authority for the /24, even though the ISP is supposed to be
authoritative. This may cause some servers to reject the responses (or
worse, cache these authority records and lose the ability to do reverse
lookups in the rest of the /24).
But you really should point them to RFC2317, and get them to do it right.
--
Barry Margolin
Arlington, MA
___
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: Classless PTR query issue
On 07.05.13 11:06, Michael Varre wrote: So interestingly they did give me their setup and this is their response, and my warm and fuzzy feeling continues to go out the window: They use SimpleDNS Record Name: 65.246.59.108.in-addr.arpa DNS Server (FQDN): dns1.kishmish.com. TTL: 1 Hour I'd imagine this is wrong since 65 is my starting IP rather than my network IP, which is 64. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. -- 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. Saving Private Ryan... Private Ryan exists. Overwrite? (Y/N) ___ 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: Classless PTR query issue
On 05/07/2013 01:50 PM, Matus UHLAR - fantomas wrote: On 07.05.13 11:06, Michael Varre wrote: So interestingly they did give me their setup and this is their response, and my warm and fuzzy feeling continues to go out the window: They use SimpleDNS Record Name: 65.246.59.108.in-addr.arpa DNS Server (FQDN): dns1.kishmish.com. TTL: 1 Hour I'd imagine this is wrong since 65 is my starting IP rather than my network IP, which is 64. they use that sucking djbdns-like way of delegating zones. Instead of creating one zone and pointing 16 CNAMEs into it, they want you to create 16 zones. Advise them to read RFC 2317 and do things right way. https://dougbarton.us/DNS/2317.html ___ 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
query issue
Hi hoping someone with more DNS experience then me can help me figure out this strange issue. I have a domain kingstonmass.org that I'm having problems resolving anything for from one NS server but it work from the other. The issue seems to be when I query for kingstonmass.org I get stuck on the org servers however this only happens for that domain all other .org domains that I tried have worked. Here is an example from tcpdump 11:03:39.305895 IP ns1.frv.ma.meganet.net.43514 c0.org.afilias-nst.org.domain: 54553 [1au] A? www.dreamphotos.org. (48) 11:03:39.343982 IP c0.org.afilias-nst.org.domain ns1.frv.ma.meganet.net.43514: 54553- 0/6/1 (591) However when I query kingstonmass.org I don't see any returned answer and it eventually times out. 11:03:34.310559 2002:c690:8cc6:c:206:5bff:fe8e:334d.54795 b2.org.afilias-nst.org.domain: 54297 NS? kingstonmass.org. (34) Again when querying this with my other DNS server it works fine. On the server I'm having issues with I can ping all the pingable org servers and the NS servers for the domain in question. The odd thing is with host I can see the NS records for the domain but with dig it doesn't work. I'm not sure what the difference is between the two commands. Also using host I cant get an MX listing. I'm hoping someone has an idea. Thanks, Paul [root@ns1 ~]# host -v -t ns kingstonmass.org Trying kingstonmass.org ;; -HEADER- opcode: QUERY, status: NOERROR, id: 51371 ;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 4 ;; QUESTION SECTION: ;kingstonmass.org. IN NS ;; ANSWER SECTION: kingstonmass.org. 1932IN NS ns2.gis.net. kingstonmass.org. 1932IN NS ns1.gis.net. kingstonmass.org. 1932IN NS mns01.domaincontrol.com. ;; ADDITIONAL SECTION: ns1.gis.net.561 IN A 208.218.130.9 ns2.gis.net.561 IN A 208.218.130.10 mns01.domaincontrol.com. 83692 IN A 216.69.185.34 mns01.domaincontrol.com. 83692 IN 2607:f208:206::22 Received 190 bytes from 209.213.64.2#53 in 1 ms ; DiG 9.2.4 +trace +time=300 kingstonmass.org ns ;; global options: printcmd . 515761 IN NS e.root-servers.net. . 515761 IN NS g.root-servers.net. . 515761 IN NS f.root-servers.net. . 515761 IN NS j.root-servers.net. . 515761 IN NS l.root-servers.net. . 515761 IN NS b.root-servers.net. . 515761 IN NS i.root-servers.net. . 515761 IN NS h.root-servers.net. . 515761 IN NS a.root-servers.net. . 515761 IN NS c.root-servers.net. . 515761 IN NS m.root-servers.net. . 515761 IN NS k.root-servers.net. . 515761 IN NS d.root-servers.net. ;; Received 512 bytes from 209.213.64.2#53(209.213.64.2) in 1 ms org.172800 IN NS a0.org.afilias-nst.info. org.172800 IN NS a2.org.afilias-nst.info. org.172800 IN NS b0.org.afilias-nst.org. org.172800 IN NS b2.org.afilias-nst.org. org.172800 IN NS c0.org.afilias-nst.info. org.172800 IN NS d0.org.afilias-nst.org. ;; Received 439 bytes from 192.203.230.10#53(e.root-servers.net) in 11 ms ;; connection timed out; no servers could be reached ___ 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: query issue
On 29/03/2012 17:35, Paul A wrote: Hi Paul, However when I query kingstonmass.org I don't see any returned answer and it eventually times out. 11:03:34.310559 2002:c690:8cc6:c:206:5bff:fe8e:334d.54795 b2.org.afilias-nst.org.domain: 54297 NS? kingstonmass.org. (34) Again when querying this with my other DNS server it works fine. On the server I'm having issues with I can ping all the pingable org servers and the NS servers for the domain in question. I notice that the query is going out with an IPv6 source address. Do you have any firewalls or router ACLs blocking DNS back to IPv6 addresses in your network? I also note that kingstonmass.org has delegation to 2 name servers in the ORG zone, but 3 name servers at its apex. The additional name server, mns01.domaincontrol.com, gives a REFUSED response to a query for the domain. Regards, Anand Buddhdev RIPE NCC ___ 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: query issue
Looking further into this I do have an ipv6 on that server, a 6to4 ip (which I didn't configure and I have to figure out how it got there). However I notice sometimes the query goes out as ipv6 6to4 ip and sometimes as an ipv4 but I'm not sure why that is if anyone can explain why some queries are sourced from the 6to4 ipv6 instead of the ipv4 ip that would be great. Looks like when it goes out as a ipv6 6to4 ip I'm not getting a returned answers which makes sense because I have no relay routers for ipv6 packets coming in. paul -Original Message- From: bind-users-bounces+pamaral=meganet@lists.isc.org [mailto:bind-users-bounces+pamaral=meganet@lists.isc.org] On Behalf Of Anand Buddhdev Sent: Thursday, March 29, 2012 11:46 AM To: Paul A Cc: bind-us...@isc.org Subject: Re: query issue On 29/03/2012 17:35, Paul A wrote: Hi Paul, However when I query kingstonmass.org I don't see any returned answer and it eventually times out. 11:03:34.310559 2002:c690:8cc6:c:206:5bff:fe8e:334d.54795 b2.org.afilias-nst.org.domain: 54297 NS? kingstonmass.org. (34) Again when querying this with my other DNS server it works fine. On the server I'm having issues with I can ping all the pingable org servers and the NS servers for the domain in question. I notice that the query is going out with an IPv6 source address. Do you have any firewalls or router ACLs blocking DNS back to IPv6 addresses in your network? I also note that kingstonmass.org has delegation to 2 name servers in the ORG zone, but 3 name servers at its apex. The additional name server, mns01.domaincontrol.com, gives a REFUSED response to a query for the domain. Regards, Anand Buddhdev RIPE NCC ___ 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: query issue
On 3/29/2012 11:45 AM, Anand Buddhdev wrote: On 29/03/2012 17:35, Paul A wrote: Hi Paul, However when I query kingstonmass.org I don't see any returned answer and it eventually times out. 11:03:34.310559 2002:c690:8cc6:c:206:5bff:fe8e:334d.54795 b2.org.afilias-nst.org.domain: 54297 NS? kingstonmass.org. (34) Again when querying this with my other DNS server it works fine. On the server I'm having issues with I can ping all the pingable org servers and the NS servers for the domain in question. I notice that the query is going out with an IPv6 source address. Specifically, a 6to4 address, with 198.144.140.198 (otherwise known as c690:8cc6) as the IPv4 endpoint of the tunnel. This was originally specified in RFC 3056 (http://www.rfc-editor.org/rfc/rfc3056.txt), but more recently there has been an informational RFC (http://www.rfc-editor.org/rfc/rfc6343.txt) enumerating the many problems associated with 6to4, and casting doubt on its long-term viability as an IPv4-to-IPv6 transition mechanism - Kevin ___ 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: query issue
At 08:45 29-03-2012, Anand Buddhdev wrote: I also note that kingstonmass.org has delegation to 2 name servers in the ORG zone, but 3 name servers at its apex. The additional name server, mns01.domaincontrol.com, gives a REFUSED response to a query for the domain. From mns01.domaincontrol.com: ;; ANSWER SECTION: kingstonmass.org. 3600IN NS mns02.domaincontrol.com. kingstonmass.org. 3600IN NS mns01.domaincontrol.com. ns1.gis.net and ns2.gis.net return a different answer. Regards, -sm ___ 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: query issue
Aside from the NS issue the problem was def related to having an 6to4 ipv6 address on the eth0 interface of my name server. Once I removed that ipv6 ip all is working well. Which leaves me with some questions, Does bind try on an ipv6 addr 1st? I suspect it does. The name servers for the domain below on the whois are ns2/ns1/gis.net so I should have been querying those servers which don't have ipv6 addr however they have an NS record in the zone pointing to mns01.domaincontrol.com which has an ipv6 addr but it's not listed on the whois output. Basically im not sure why my queries for kingstonmass.org where being sourced from an ipv6. ;; ANSWER SECTION: kingstonmass.org. 3387IN NS ns2.gis.net. kingstonmass.org. 3387IN NS ns1.gis.net. kingstonmass.org. 3387IN NS mns01.domaincontrol.com. ;; ADDITIONAL SECTION: mns01.domaincontrol.com. 67665 IN A 216.69.185.34 mns01.domaincontrol.com. 67665 IN 2607:f208:206::22 thanks Paul -Original Message- From: bind-users-bounces+pamaral=meganet@lists.isc.org [mailto:bind-users-bounces+pamaral=meganet@lists.isc.org] On Behalf Of SM Sent: Thursday, March 29, 2012 1:14 PM To: bind-us...@isc.org Subject: Re: query issue At 08:45 29-03-2012, Anand Buddhdev wrote: I also note that kingstonmass.org has delegation to 2 name servers in the ORG zone, but 3 name servers at its apex. The additional name server, mns01.domaincontrol.com, gives a REFUSED response to a query for the domain. From mns01.domaincontrol.com: ;; ANSWER SECTION: kingstonmass.org. 3600IN NS mns02.domaincontrol.com. kingstonmass.org. 3600IN NS mns01.domaincontrol.com. ns1.gis.net and ns2.gis.net return a different answer. Regards, -sm ___ 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: query issue
In message 012901cd0de7$fcf45590$f6dd00b0$@net, Paul A writes: Aside from the NS issue the problem was def related to having an 6to4 ipv6 address on the eth0 interface of my name server. Once I removed that ipv6 ip all is working well. Which leaves me with some questions, Does bind try on an ipv6 addr 1st? I suspect it does. All things being equal, yes it will try IPv6 first. However most of the time there is some history and it will make other decisions. The name servers for the domain below on the whois are ns2/ns1/gis.net so I should have been querying those servers which don't have ipv6 addr however they have an NS record in the zone pointing to mns01.domaincontrol.com which has an ipv6 addr but it's not listed on the whois output. Basically im not sure why my queries for kingstonmass.org where being sourced from an ipv6. The queries are sent to that address because named has learnt that mns01.domaincontrol.com has a IPv6 address. mns01.domaincontrol.com isn't responding to me over IPv6 either. ;; ANSWER SECTION: kingstonmass.org. 3387IN NS ns2.gis.net. kingstonmass.org. 3387IN NS ns1.gis.net. kingstonmass.org. 3387IN NS mns01.domaincontrol.com. ;; ADDITIONAL SECTION: mns01.domaincontrol.com. 67665 IN A 216.69.185.34 mns01.domaincontrol.com. 67665 IN 2607:f208:206::22 thanks Paul -Original Message- From: bind-users-bounces+pamaral=meganet@lists.isc.org [mailto:bind-users-bounces+pamaral=meganet@lists.isc.org] On Behalf Of SM Sent: Thursday, March 29, 2012 1:14 PM To: bind-us...@isc.org Subject: Re: query issue At 08:45 29-03-2012, Anand Buddhdev wrote: I also note that kingstonmass.org has delegation to 2 name servers in the ORG zone, but 3 name servers at its apex. The additional name server, mns01.domaincontrol.com, gives a REFUSED response to a query for the domain. From mns01.domaincontrol.com: ;; ANSWER SECTION: kingstonmass.org. 3600IN NS mns02.domaincontrol.com. kingstonmass.org. 3600IN NS mns01.domaincontrol.com. ns1.gis.net and ns2.gis.net return a different answer. Regards, -sm ___ 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 -- 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: Odd query issue
Kevin, Thanks for the good ideas. Here is what I am seeing based on your recommendations: 1. Zone has expired (to confirm: check logs) No errors or notices regarding the zone being expired. 2. Corrupted/truncated journal file (to confirm: check logs, or, shut down gracefully, delete journal and start up again) I've shut down BIND, removed all files under the slave directory, and restarted BIND - no help. Other zones that are delegated from the same server are populated. 3. www.blah.com is a delegation in your slave copy of the zone, and the delegated nameservers are all returning SERVFAIL, are lame, give bogus answers, some combination of the above, etc. (to confirm: do the lookup non-recursively, or a zone transfer of blah.com; if www.blah.com shows as a delegation, query the delegated nameservers directly and see what they return) I am able to query the master directly, without issue as well as perform a zone transfer (though I get an error, ;; communications error to 10.x.x.x#53: connection reset). I'm assuming that this is due to the fact that the response is greater than 512 bytes perhaps. Brian ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd query issue
On 8/3/2010 7:50 AM, Atkins, Brian (GD/VA-NSOC) wrote: Kevin, Thanks for the good ideas. Here is what I am seeing based on your recommendations: 1. Zone has expired (to confirm: check logs) No errors or notices regarding the zone being expired. 2. Corrupted/truncated journal file (to confirm: check logs, or, shut down gracefully, delete journal and start up again) I've shut down BIND, removed all files under the slave directory, and restarted BIND - no help. Other zones that are delegated from the same server are populated. 3. www.blah.com is a delegation in your slave copy of the zone, and the delegated nameservers are all returning SERVFAIL, are lame, give bogus answers, some combination of the above, etc. (to confirm: do the lookup non-recursively, or a zone transfer of blah.com; if www.blah.com shows as a delegation, query the delegated nameservers directly and see what they return) So, just to be clear: is www.blah.com delegated to another nameserver or set of nameservers? Or is it contained within the blah.com zone itself? My option #3 above referred to a relatively-unlikely scenario where a www.blah.com delegation was (temporarily) present in your slave copy, even though you indicated that on the master server, www.blah.com was contained in the blah.com zone. I am able to query the master directly, without issue as well as perform a zone transfer (though I get an error, ;; communications error to 10.x.x.x#53: connection reset). I'm assuming that this is due to the fact that the response is greater than 512 bytes perhaps. The 512-byte restriction only applies to UDP. Sounds like you may have a problem with performing TCP transactions with the master, most likely because of naively-implemented firewall rules. You can confirm or deny this via the +vc (virtual circuit = TCP) option to dig. If TCP between you and the master is completely broken, your zone transfers aren't going to work and the zone will expire, if it hasn't already. I'd double-check whether the zone is expired, maybe by restarting named with a high debug level. It's a little troubling that other slave zones -- I assume that's what you meant when you said that are delegated -- from the same master are working. But, are all the EXPIRE settings the same? Maybe this is just the _first_ zone that expired. Again, the logs should help here. Are zone transfers succeeding or failing for blah.com and for other zones. If there are failures, what are the error messages in the logs? - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Odd query issue
In message 4c58668d.2010...@chrysler.com, Kevin Darcy writes: On 8/3/2010 7:50 AM, Atkins, Brian (GD/VA-NSOC) wrote: Kevin, Thanks for the good ideas. Here is what I am seeing based on your recommendations: 1. Zone has expired (to confirm: check logs) No errors or notices regarding the zone being expired. 2. Corrupted/truncated journal file (to confirm: check logs, or, shut down gracefully, delete journal and start up again) I've shut down BIND, removed all files under the slave directory, and restarted BIND - no help. Other zones that are delegated from the same server are populated. 3. www.blah.com is a delegation in your slave copy of the zone, and the delegated nameservers are all returning SERVFAIL, are lame, give bogus answers, some combination of the above, etc. (to confirm: do the lookup non-recursively, or a zone transfer of blah.com; if www.blah.com shows as a delegation, query the delegated nameservers directly and see what they return) So, just to be clear: is www.blah.com delegated to another nameserver or set of nameservers? Or is it contained within the blah.com zone itself? My option #3 above referred to a relatively-unlikely scenario where a www.blah.com delegation was (temporarily) present in your slave copy, even though you indicated that on the master server, www.blah.com was contained in the blah.com zone. I am able to query the master directly, without issue as well as perform a zone transfer (though I get an error, ;; communications error to 10.x.x.x#53: connection reset). I'm assuming that this is due to the fact that the response is greater than 512 bytes perhaps. The 512-byte restriction only applies to UDP. Sounds like you may have a problem with performing TCP transactions with the master, most likely because of naively-implemented firewall rules. You can confirm or deny this via the +vc (virtual circuit = TCP) option to dig. If TCP between you and the master is completely broken, your zone transfers aren't going to work and the zone will expire, if it hasn't already. I'd double-check whether the zone is expired, maybe by restarting named with a high debug level. It's a little troubling that other slave zones -- I assume that's what you meant when you said that are delegated -- from the same master are working. But, are all the EXPIRE settings the same? Maybe this is just the _first_ zone that expired. Or that the other zones are smaller and this one is big enough that PMTUD kicks in. Again, the logs should help here. Are zone transfers succeeding or failing for blah.com and for other zones. If there are failures, what are the error messages in the logs? - Kevin -- 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: Odd query issue
On 8/2/2010 10:17 AM, Atkins, Brian (GD/VA-NSOC) wrote: Any ideas to point me in the right direction? What do the log files show surrounding the query? 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: Odd query issue
1. Zone has expired (to confirm: check logs)
2. Corrupted/truncated journal file (to confirm: check logs, or, shut
down gracefully, delete journal and start up again)
3. www.blah.com is a delegation in your slave copy of the zone, and the
delegated nameservers are all returning SERVFAIL, are lame, give bogus
answers, some combination of the above, etc. (to confirm: do the lookup
non-recursively, or a zone transfer of blah.com; if www.blah.com shows
as a delegation, query the delegated nameservers directly and see what
they return)
- Kevin
On 8/2/2010 10:17 AM, Atkins, Brian (GD/VA-NSOC) wrote:
I'm troubleshooting an issue with internal resolution of a domain. I
have 2 identical slave servers that resolve for domains that have been
delegated to our group. However, while one of the servers can
successfully provide the responses, the other cannot. I've checked with
the network gurus to verify there is not a possibility of a firewall or
IPS rule causing the issue, but came back empty-handed.
Here's the breakdown (please don't laugh at the antiques...):
Sun V210's running Solaris 5.8
BIND 9.5.1-P3
...
zone blah.com {
type slave;
file /slave/db.blah.com;
masters { 10.xxx.xxx.xxx; };
allow-transfer { none; };
allow-query { all-clients; };
};
...
# Query local server (one with issues) fails
$ dig www.blah.com.
; DiG 9.5.1-P3 www.blah.com.
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: SERVFAIL, id: 1735
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
; www.blah.com. IN A
;; Query time: 2 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Aug 2 14:12:48 2010
;; MSG SIZE rcvd: 29
# Query master directly or twin server from problem server succeeds
$ dig @10.xxx.xxx.xxx www.blah.com.
; DiG 9.5.1-P3 @10.xxx.xxx.xxx www.blah.com.
; (1 server found)
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY, status: NOERROR, id: 341
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
; www.blah.com. IN A
;; ANSWER SECTION:
www.blah.com.300 IN A 10.xxx.xxx.xxx
;; Query time: 34 msec
;; SERVER: 10.xxx.xxx.xxx #53(10.xxx.xxx.xxx)
;; WHEN: Mon Aug 2 14:14:16 2010
;; MSG SIZE rcvd: 45
Any ideas to point me in the right direction?
Thanks,
Brian
___
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
