Re: rDNS for RFC1918 network fails
Hi, On Sun, Jan 24, 2021 at 4:44 PM Mark Andrews wrote: > > Use the correct zone name. > > 1.168.192.IN-ADDR.ARPA > > You have the full /24 so you don’t need to use RFC2317 techniques. Thanks so much. That worked great. ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS for RFC1918 network fails
Use the correct zone name.
1.168.192.IN-ADDR.ARPA
You have the full /24 so you don’t need to use RFC2317 techniques.
--
Mark Andrews
> On 25 Jan 2021, at 08:04, Alex wrote:
>
> Hi, I have a fedora32 system with bind-9.11.25 and having a problem
> with setting up a reverse zone for a 192.168.1.0/24 internal network.
>
> It loads okay, but queries fail:
>
> # host 192.168.1.1
> Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
>
> Jan 24 15:56:26 orion bash[1967667]: zone inside.example.com/IN:
> loaded serial 103
> Jan 24 15:56:26 orion bash[1967667]: zone
> 0-24.1.168.192.in-addr.arpa/IN: loaded serial 107
> Jan 24 15:56:26 orion bash[1967667]: zone localhost.localdomain/IN:
> loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone localhost/IN: loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
> loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone 1.0.0.127.in-addr.arpa/IN:
> loaded serial 0
> Jan 24 15:56:26 orion bash[1967667]: zone 0.in-addr.arpa/IN: loaded serial 0
> Jan 24 15:56:26 orion named[1967669]: starting BIND
> 9.11.25-RedHat-9.11.25-2.fc32 (Extended Support Version)
>
> Here is my /etc/named.conf zone info for the forward and reverse:
>
> acl "trusted" {
>{ 127/8; };
>{ 68.195.111.40/29; };
>{ 192.168.1.0/24; };
> };
>
> zone "inside.example.com." {
>type master;
>file "master/inside.example.com.db";
>forwarders {};
>allow-query { trusted; };
>allow-transfer { none; };
> };
>
> zone "0-24.1.168.192.in-addr.arpa." {
>type master;
>file "master/192.168.1.db";
>allow-query { trusted; };
>allow-transfer { none; };
> };
>
> Here is the actual zone file.
> /var/named/chroot/var/named/master/192.168.1.db
>
> $TTL 1H
> $ORIGIN 0-24.1.168.192.in-addr.arpa.
> @ 3600 IN SOA orion.inside.example.com. admin.example.com.
> 107 3H 1H 1W 1H
> @ 3600 IN NS orion.inside.example.com.
> @ 3600 IN A 192.168.1.1
>
> 1 IN PTR orion.inside.example.com.
> 150 IN PTR pixie.inside.example.com.
>
> What could I possibly be doing wrong? When I run dig +trace it doesn't
> appear to look to the local name server, but instead goes to the
> Internet and the top-level name servers.
>
> # dig +trace any 150.1.168.192.in-addr.arpa.
>
> Thanks,
> Alex
> ___
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
> from this list
>
> ISC funds the development of this software with paid support subscriptions.
> Contact us at https://www.isc.org/contact/ for more information.
>
>
> 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
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
rDNS for RFC1918 network fails
Hi, I have a fedora32 system with bind-9.11.25 and having a problem
with setting up a reverse zone for a 192.168.1.0/24 internal network.
It loads okay, but queries fail:
# host 192.168.1.1
Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN)
Jan 24 15:56:26 orion bash[1967667]: zone inside.example.com/IN:
loaded serial 103
Jan 24 15:56:26 orion bash[1967667]: zone
0-24.1.168.192.in-addr.arpa/IN: loaded serial 107
Jan 24 15:56:26 orion bash[1967667]: zone localhost.localdomain/IN:
loaded serial 0
Jan 24 15:56:26 orion bash[1967667]: zone localhost/IN: loaded serial 0
Jan 24 15:56:26 orion bash[1967667]: zone
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa/IN:
loaded serial 0
Jan 24 15:56:26 orion bash[1967667]: zone 1.0.0.127.in-addr.arpa/IN:
loaded serial 0
Jan 24 15:56:26 orion bash[1967667]: zone 0.in-addr.arpa/IN: loaded serial 0
Jan 24 15:56:26 orion named[1967669]: starting BIND
9.11.25-RedHat-9.11.25-2.fc32 (Extended Support Version)
Here is my /etc/named.conf zone info for the forward and reverse:
acl "trusted" {
{ 127/8; };
{ 68.195.111.40/29; };
{ 192.168.1.0/24; };
};
zone "inside.example.com." {
type master;
file "master/inside.example.com.db";
forwarders {};
allow-query { trusted; };
allow-transfer { none; };
};
zone "0-24.1.168.192.in-addr.arpa." {
type master;
file "master/192.168.1.db";
allow-query { trusted; };
allow-transfer { none; };
};
Here is the actual zone file.
/var/named/chroot/var/named/master/192.168.1.db
$TTL 1H
$ORIGIN 0-24.1.168.192.in-addr.arpa.
@ 3600 IN SOA orion.inside.example.com. admin.example.com.
107 3H 1H 1W 1H
@ 3600 IN NS orion.inside.example.com.
@ 3600 IN A 192.168.1.1
1 IN PTR orion.inside.example.com.
150 IN PTR pixie.inside.example.com.
What could I possibly be doing wrong? When I run dig +trace it doesn't
appear to look to the local name server, but instead goes to the
Internet and the top-level name servers.
# dig +trace any 150.1.168.192.in-addr.arpa.
Thanks,
Alex
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: round-robin bug in 9.12.1-P2 for rDNS?
> > This sounds a bit like #336 [1], > > Nope - we got bit by that when we upgraded > to 9.12, which is what resulted in the explicit > config for rrset-order. > > > If you can still reproduce this with current > > master (or with current v9_12 branch), please > > open a new GitLab issue. > > Please forgive my ignorance on this point, > but is running the FreeBSD package for > 9.12.1-P2 sufficient to meet this? It probably is, the #336 bit above was a long shot. Please open a GitLab issue, supplying version information and a configuration which allows reproducing this behavior. Thanks! -- Best regards, Michał Kępień ___ 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: round-robin bug in 9.12.1-P2 for rDNS?
Hi Michał, Thanks for the ack. > This sounds a bit like #336 [1], Nope - we got bit by that when we upgraded to 9.12, which is what resulted in the explicit config for rrset-order. > If you can still reproduce this with current > master (or with current v9_12 branch), please > open a new GitLab issue. Please forgive my ignorance on this point, but is running the FreeBSD package for 9.12.1-P2 sufficient to meet this? We don't usually build directly from source (for operational reasons). Many thanks and best regards, mark ___ 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: round-robin bug in 9.12.1-P2 for rDNS?
> I have a funny issue that looks buggish > to me. I have an RRSET with two > A records that our auth DNS servers happily > round-robin, which can be observed with > > dig unix.lt.ucsc.edu @adns1.ucsc.edu > > However, our recursive DNS servers, with > the same rrset-order config will not round-robin > these records. > > BUT, if I add a third A record, the rDNS servers > then round-robin. > > I can punch in some config elements here if > it is useful, but this smells like a bug, and > maybe I should be reporting on gitlab. > > Thoughts? This sounds a bit like #336 [1], but you mentioned rrset-order being explicitly set in your configuration, so it might be something else. If you can still reproduce this with current master (or with current v9_12 branch), please open a new GitLab issue. Thanks! [1] https://gitlab.isc.org/isc-projects/bind9/issues/336 -- Best regards, Michał Kępień ___ 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
round-robin bug in 9.12.1-P2 for rDNS?
Hi folks, I have a funny issue that looks buggish to me. I have an RRSET with two A records that our auth DNS servers happily round-robin, which can be observed with dig unix.lt.ucsc.edu @adns1.ucsc.edu However, our recursive DNS servers, with the same rrset-order config will not round-robin these records. BUT, if I add a third A record, the rDNS servers then round-robin. I can punch in some config elements here if it is useful, but this smells like a bug, and maybe I should be reporting on gitlab. Thoughts? mark ___ 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: rDNS
In message <bed324186eba4d68a4fbf4513747e...@mxph4chrw.fgremc.it>, "Darcy Kevin
(FCA)" writes:
> I think the ISP may have done something untoward with
> 87.233.202.162.in-addr.arpa, since I'm
> getting a NODATA response for that name, from the 233.202.162.in-addr.arpa
> zone, most probabl
> y because it's an empty non-terminal. But what would be under that, and why?
They just haven't put in a CNAME for the broadcast address.
; <<>> DiG 9.12.0-pre-alpha+hotspot+add-prefetch+marka <<>>
87.233.202.162.in-addr.arpa ptr
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 57508
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
; COOKIE: ca17d311c21b67e97ff0dfc358829ec97d7d5f968d33a429 (good)
;; QUESTION SECTION:
;87.233.202.162.in-addr.arpa. IN PTR
;; AUTHORITY SECTION:
233.202.162.in-addr.arpa. 3583 IN SOA ns1.swbell.net.
postmaster.swbell.net. 2016061700 10800 900 604800 3600
;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Sat Jan 21 10:35:37 EST 2017
;; MSG SIZE rcvd: 145
Mark
> - Kevin
>
>
> -Original Message-
> From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark
> Andrews
> Sent: Friday, January 20, 2017 3:55 PM
> To: bind-us...@isc.org
> Subject: Re: rDNS
>
>
> You have the netblock 162.202.233.80-162.202.233.87 (162.202.233.80/29).
>
> When software performs a reverse lookup it constructs a DNS name from the
> address like 80.233
> .202.162.in-addr.arpa. Now as the netblock is not a full /24 you either have
> to create 8 zon
> es, one for each PTR record, or provide records at those names which map the
> lookups to new n
> ames. The later is what has been done here.
> The technique is described in RFC 2317.
>
> ATT has delegated a zone for the first address in the address block to you.
> That zone is cal
> led 80.233.202.162.in-addr.arpa. It has then added CNAME records to map
> lookups for the rest
> of the address in your address block into this zone.
>
> e.g.
>
> 81.233.202.162.in-addr.arpa. CNAME 81.80.233.202.162.in-addr.arpa.
> ...
> 86.233.202.162.in-addr.arpa. CNAME 86.80.233.202.162.in-addr.arpa.
>
> The 80.233.202.162.in-addr.arpa zone should look like this.
>
> $TTL 1h
> @ SOA ns1.archaxis.net. me.archaxis.net. (
> 2017012002 ; Serial
> 1h ; Refresh
> 1h ; Retry
> 4w ; Expire
> 1h ) ; Negative cashing TTL
> NS ns1.archaxis.net.
> NS ns2.archaxis.net.
> PTR network.archaxis.net.
> 81PTR alpha.archaxis.net.
> 82PTR bravo.archaxis.net.
> 87PTR broadcast.archaxis.net.
>
> I increased the expire field to 4 weeks as it was way too small.
> Note the reverse for 162.202.233.80 is NOT mapped to a new name so the PTR
> record for that ad
> dress is at the zone's apex. As all the records had a TTL of 1 hour I set
> the default TTL to
> that value and removed the per record setting of the TTL. I also removed
> the class field as
> that is inherited from the zone's declaration.
>
> Don't forget to bump the zones serial when you install it.
>
> Once you have the above sorted out and have tested it. You now need to slave
> the zone 233.20
> 2.162.in-addr.arpa as that contains the CNAME records. ATT should allow you
> to transfer it.
> If they don't find a ISP that knows what they are doing. You need a local
> copy of the zone
> so that when you link goes down you can still do reverse lookups.
>
> zone "233.202.162.in-addr.arpa" {
> type slave;
> masters { 151.164.1.1; };
> file "233.202.162.in-addr.arpa";
> };
>
> Mark
>
> In message <20170120162146.ga14...@fantomas.sk>, Matus UHLAR - fantomas
> writes:
> > On 20.01.17 09:57, Ron Wingfield wrote:
> > > I am having difficulty configuring reverse DNS. This has been a
> > problem
> > > for over a year between my server(s) and my ISP, AT Specifically, I
> > > cannot eMail to any recipient that requires rDNS verification, e.g.,
> > > SBCglobal.net, Comcast.net, or AOL. Very frustrating.
> >
> > > . . .why shouldnt this point to my server, 162.202.233.81 and not
> > > AT?
> >
> > because reverse domains are also tracked from the DNS root:
> >
> > 233.202.162.in-addr.arpa. 7200IN SOA ns1.swbell.net.
> > postmaster.swbell.net. 2016061700 10800 900 604800 3600
> >
> > 81.233.202.162.in-addr.arpa.7200IN
RE: rDNS
I think the ISP may have done something untoward with
87.233.202.162.in-addr.arpa, since I'm getting a NODATA response for that name,
from the 233.202.162.in-addr.arpa zone, most probably because it's an empty
non-terminal. But what would be under that, and why?
- Kevin
-Original Message-
From: bind-users [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Mark
Andrews
Sent: Friday, January 20, 2017 3:55 PM
To: bind-us...@isc.org
Subject: Re: rDNS
You have the netblock 162.202.233.80-162.202.233.87 (162.202.233.80/29).
When software performs a reverse lookup it constructs a DNS name from the
address like 80.233.202.162.in-addr.arpa. Now as the netblock is not a full
/24 you either have to create 8 zones, one for each PTR record, or provide
records at those names which map the lookups to new names. The later is what
has been done here.
The technique is described in RFC 2317.
ATT has delegated a zone for the first address in the address block to you.
That zone is called 80.233.202.162.in-addr.arpa. It has then added CNAME
records to map lookups for the rest of the address in your address block into
this zone.
e.g.
81.233.202.162.in-addr.arpa. CNAME 81.80.233.202.162.in-addr.arpa.
...
86.233.202.162.in-addr.arpa. CNAME 86.80.233.202.162.in-addr.arpa.
The 80.233.202.162.in-addr.arpa zone should look like this.
$TTL 1h
@ SOA ns1.archaxis.net. me.archaxis.net. (
2017012002 ; Serial
1h ; Refresh
1h ; Retry
4w ; Expire
1h ) ; Negative cashing TTL
NS ns1.archaxis.net.
NS ns2.archaxis.net.
PTR network.archaxis.net.
81 PTR alpha.archaxis.net.
82 PTR bravo.archaxis.net.
87 PTR broadcast.archaxis.net.
I increased the expire field to 4 weeks as it was way too small.
Note the reverse for 162.202.233.80 is NOT mapped to a new name so the PTR
record for that address is at the zone's apex. As all the records had a TTL of
1 hour I set the default TTL to that value and removed the per record setting
of the TTL. I also removed the class field as that is inherited from the
zone's declaration.
Don't forget to bump the zones serial when you install it.
Once you have the above sorted out and have tested it. You now need to slave
the zone 233.202.162.in-addr.arpa as that contains the CNAME records. ATT
should allow you to transfer it. If they don't find a ISP that knows what they
are doing. You need a local copy of the zone so that when you link goes down
you can still do reverse lookups.
zone "233.202.162.in-addr.arpa" {
type slave;
masters { 151.164.1.1; };
file "233.202.162.in-addr.arpa";
};
Mark
In message <20170120162146.ga14...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 20.01.17 09:57, Ron Wingfield wrote:
> > I am having difficulty configuring reverse DNS. This has been a
> problem
> > for over a year between my server(s) and my ISP, AT Specifically, I
> > cannot eMail to any recipient that requires rDNS verification, e.g.,
> > SBCglobal.net, Comcast.net, or AOL. Very frustrating.
>
> > . . .why shouldnt this point to my server, 162.202.233.81 and not
> > AT?
>
> because reverse domains are also tracked from the DNS root:
>
> 233.202.162.in-addr.arpa. 7200IN SOA ns1.swbell.net.
> postmaster.swbell.net. 2016061700 10800 900 604800 3600
>
> 81.233.202.162.in-addr.arpa. 7200IN CNAME
> 81.80.233.202.162.in-addr.arpa.
>
> > I have coded my BIND 9 in-addr.arpa zone file as follows:
> >
> > $ORIGIN 233.202.162.in-addr.arpa.
>
> stop defining $ORIGIN in zone file. the $ORIGIN is taken from named "zone"
> statement.
>
> According to those above you have to configure zone
> 80.233.202.162.in-addr.arpa.
> and adk swbell.net to fetchit from you.
>
> > $TTL 3h
> > @ IN SOA ns1.archaxis.net. me.archaxis.net. (
> >2017012002 ; Serial
> >1h ; Refresh
> >1h ; Retry
> >1h ; Expire
> >1h ) ; Negative cashing TTL
> >
> >3600 IN NS ns1.archaxis.net.
> >3600 IN NS ns2.archaxis.net.
> >
> > 80 3600 IN PTR network.archaxis.net.
> > 81 3600 IN PTR alpha.archaxis.net.
> > 82 3600 IN PTR bravo.archaxis.net.
> > 87 3600 IN PTR broadcast.archaxis.net.
> >
> > What is wrong? Is this my problem, or with AT?
>
>
>
> --
> 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.
> Spam is for losers who can't get business any other
Re: rDNS
You have the netblock 162.202.233.80-162.202.233.87 (162.202.233.80/29).
When software performs a reverse lookup it constructs a DNS name
from the address like 80.233.202.162.in-addr.arpa. Now as the
netblock is not a full /24 you either have to create 8 zones, one
for each PTR record, or provide records at those names which map
the lookups to new names. The later is what has been done here.
The technique is described in RFC 2317.
ATT has delegated a zone for the first address in the address block
to you. That zone is called 80.233.202.162.in-addr.arpa. It has
then added CNAME records to map lookups for the rest of the address
in your address block into this zone.
e.g.
81.233.202.162.in-addr.arpa. CNAME 81.80.233.202.162.in-addr.arpa.
...
86.233.202.162.in-addr.arpa. CNAME 86.80.233.202.162.in-addr.arpa.
The 80.233.202.162.in-addr.arpa zone should look like this.
$TTL 1h
@ SOA ns1.archaxis.net. me.archaxis.net. (
2017012002 ; Serial
1h ; Refresh
1h ; Retry
4w ; Expire
1h ) ; Negative cashing TTL
NS ns1.archaxis.net.
NS ns2.archaxis.net.
PTR network.archaxis.net.
81 PTR alpha.archaxis.net.
82 PTR bravo.archaxis.net.
87 PTR broadcast.archaxis.net.
I increased the expire field to 4 weeks as it was way too small.
Note the reverse for 162.202.233.80 is NOT mapped to a new name so
the PTR record for that address is at the zone's apex. As all the
records had a TTL of 1 hour I set the default TTL to that value and
removed the per record setting of the TTL. I also removed the class
field as that is inherited from the zone's declaration.
Don't forget to bump the zones serial when you install it.
Once you have the above sorted out and have tested it. You now
need to slave the zone 233.202.162.in-addr.arpa as that contains
the CNAME records. ATT should allow you to transfer it. If they
don't find a ISP that knows what they are doing. You need a local
copy of the zone so that when you link goes down you can still do
reverse lookups.
zone "233.202.162.in-addr.arpa" {
type slave;
masters { 151.164.1.1; };
file "233.202.162.in-addr.arpa";
};
Mark
In message <20170120162146.ga14...@fantomas.sk>, Matus UHLAR - fantomas writes:
> On 20.01.17 09:57, Ron Wingfield wrote:
> > I am having difficulty configuring reverse DNS. This has been a
> problem
> > for over a year between my server(s) and my ISP, AT Specifically, I
> > cannot eMail to any recipient that requires rDNS verification, e.g.,
> > SBCglobal.net, Comcast.net, or AOL. Very frustrating.
>
> > . . .why shouldnt this point to my server, 162.202.233.81 and not
> > AT?
>
> because reverse domains are also tracked from the DNS root:
>
> 233.202.162.in-addr.arpa. 7200IN SOA ns1.swbell.net.
> postmaster.swbell.net. 2016061700 10800 900 604800 3600
>
> 81.233.202.162.in-addr.arpa. 7200IN CNAME
> 81.80.233.202.162.in-addr.arpa.
>
> > I have coded my BIND 9 in-addr.arpa zone file as follows:
> >
> > $ORIGIN 233.202.162.in-addr.arpa.
>
> stop defining $ORIGIN in zone file. the $ORIGIN is taken from named "zone"
> statement.
>
> According to those above you have to configure zone
> 80.233.202.162.in-addr.arpa.
> and adk swbell.net to fetchit from you.
>
> > $TTL 3h
> > @ IN SOA ns1.archaxis.net. me.archaxis.net. (
> >2017012002 ; Serial
> >1h ; Refresh
> >1h ; Retry
> >1h ; Expire
> >1h ) ; Negative cashing TTL
> >
> >3600 IN NS ns1.archaxis.net.
> >3600 IN NS ns2.archaxis.net.
> >
> > 80 3600 IN PTR network.archaxis.net.
> > 81 3600 IN PTR alpha.archaxis.net.
> > 82 3600 IN PTR bravo.archaxis.net.
> > 87 3600 IN PTR broadcast.archaxis.net.
> >
> > What is wrong? Is this my problem, or with AT?
>
>
>
> --
> 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.
> Spam is for losers who can't get business any other way.
> ___
> 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: rDNS
So if the DNS resolver used is "OK", then is there a problem with my code for the in-addr.arpa zone file? . . .rDNS is not working. On 1/20/2017 10:19 AM, Bob Harold wrote: On Fri, Jan 20, 2017 at 10:57 AM, Ron Wingfield <ron.wingfi...@archaxis.net> wrote: I am having difficulty configuring reverse DNS. This has been a problem for over a year between my server(s) and my ISP, AT Specifically, I cannot eMail to any recipient that requires rDNS verification, e.g., SBCglobal.net, Comcast.net, or AOL. Very frustrating. Two examples of dig: # dig -t mx alpha.archaxis.net ANSWER: 0, AUTHORITY: 1, Why does this first example, digging the FQDN of alpha.archaxis.net reports one authority but no answers? # dig -t mx archaxis.net ANSWER: 2, AUTHORITY: 0, . . .yet this second example. digging the FQDN of archaxis.net reports no authority but 2 answers? (The) ;; ANSWER SECTION: (of both examples) reports: archaxis.net. 10800 IN MX 30 bravo.archaxis.net. archaxis.net. 10800 IN MX 20 alpha.archaxis.net. In both cases, the reported server is an AT server ;; SERVER: 68.94.157.9#53 . . .why shouldn’t this “point” to my server, 162.202.233.81 and not AT’s? Just to clear up the confusion on this point: dig is telling you that "SERVER: 68.94.157.9#53" is the DNS resolver that your computer used to answer the DNS question. That server is not part of the answer to the question. I have coded my BIND 9 in-addr.arpa zone file as follows: $ORIGIN 233.202.162.in-addr.arpa. $TTL 3h @ IN SOA ns1.archaxis.net. me.archaxis.net. ( 2017012002 ; Serial 1h ; Refresh 1h ; Retry 1h ; Expire 1h ) ; Negative cashing TTL 3600 IN NS ns1.archaxis.net. 3600 IN NS ns2.archaxis.net. 80 3600 IN PTR network.archaxis.net. 81 3600 IN PTR alpha.archaxis.net. 82 3600 IN PTR bravo.archaxis.net. 87 3600 IN PTR broadcast.archaxis.net. What is wrong? Is this my problem, or with AT? -- Bob Harold ___ 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: rDNS
On 20.01.17 09:57, Ron Wingfield wrote: I am having difficulty configuring reverse DNS. This has been a problem for over a year between my server(s) and my ISP, AT Specifically, I cannot eMail to any recipient that requires rDNS verification, e.g., SBCglobal.net, Comcast.net, or AOL. Very frustrating. . . .why shouldn’t this “point” to my server, 162.202.233.81 and not AT’s? because reverse domains are also tracked from the DNS root: 233.202.162.in-addr.arpa. 7200IN SOA ns1.swbell.net. postmaster.swbell.net. 2016061700 10800 900 604800 3600 81.233.202.162.in-addr.arpa.7200IN CNAME 81.80.233.202.162.in-addr.arpa. I have coded my BIND 9 in-addr.arpa zone file as follows: $ORIGIN 233.202.162.in-addr.arpa. stop defining $ORIGIN in zone file. the $ORIGIN is taken from named "zone" statement. According to those above you have to configure zone 80.233.202.162.in-addr.arpa. and adk swbell.net to fetchit from you. $TTL 3h @ IN SOA ns1.archaxis.net. me.archaxis.net. ( 2017012002 ; Serial 1h ; Refresh 1h ; Retry 1h ; Expire 1h ) ; Negative cashing TTL 3600 IN NS ns1.archaxis.net. 3600 IN NS ns2.archaxis.net. 80 3600 IN PTR network.archaxis.net. 81 3600 IN PTR alpha.archaxis.net. 82 3600 IN PTR bravo.archaxis.net. 87 3600 IN PTR broadcast.archaxis.net. What is wrong? Is this my problem, or with AT? -- 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. Spam is for losers who can't get business any other way. ___ 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: rDNS
On Fri, Jan 20, 2017 at 10:57 AM, Ron Wingfield <ron.wingfi...@archaxis.net> wrote: > I am having difficulty configuring reverse DNS. This has been a problem > for over a year between my server(s) and my ISP, AT Specifically, I > cannot eMail to any recipient that requires rDNS verification, e.g., > SBCglobal.net, Comcast.net, or AOL. Very frustrating. > > Two examples of dig: > > # dig -t mx alpha.archaxis.net > ANSWER: 0, AUTHORITY: 1, > > Why does this first example, digging the FQDN of alpha.archaxis.net > reports one authority but no answers? > > # dig -t mx archaxis.net > ANSWER: 2, AUTHORITY: 0, > > . . .yet this second example. digging the FQDN of archaxis.net reports no > authority but 2 answers? > > (The) ;; ANSWER SECTION: (of both examples) reports: > archaxis.net. 10800 IN MX 30 bravo.archaxis.net. > archaxis.net. 10800 IN MX 20 alpha.archaxis.net. > > In both cases, the reported server is an AT server ;; SERVER: > 68.94.157.9#53 > . . .why shouldn’t this “point” to my server, 162.202.233.81 and not > AT’s? > Just to clear up the confusion on this point: dig is telling you that "SERVER: 68.94.157.9#53" is the DNS resolver that your computer used to answer the DNS question. That server is not part of the answer to the question. > > I have coded my BIND 9 in-addr.arpa zone file as follows: > > $ORIGIN 233.202.162.in-addr.arpa. > $TTL 3h > @ IN SOA ns1.archaxis.net. me.archaxis.net. ( > 2017012002 <(201)%20701-2002>; Serial > 1h ; Refresh > 1h ; Retry > 1h ; Expire > 1h ); Negative cashing TTL > > 3600IN NS ns1.archaxis.net. > 3600IN NS ns2.archaxis.net. > > 80 3600IN PTR network.archaxis.net. > 81 3600IN PTR alpha.archaxis.net. > 82 3600IN PTR bravo.archaxis.net. > 87 3600IN PTR broadcast.archaxis.net. > > What is wrong? Is this my problem, or with AT? > -- Bob Harold ___ 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: rDNS
I manage delegated and not but ISP delegate (can do but is not forced to do it) only if you own at least the C subnet (all). If you only own some IP from a C subnet as DNS ZONEs on reverse lookups handle an entire C subnet and can't be delegated only 3, 5, 10 IP from a subnet so if you don't own a full C subnet or ISP don't want to delegate (if your DNS server will be unreachable could arm something on ISP) you only can try to ask the ISP to map names on their DNS , ISP DNS and even this not all ISP do or is done with default IN-ADDR-ARPA naming. Alberto Colosi ITC , NetWork & Security Architect & Admin From: bind-users <bind-users-boun...@lists.isc.org> on behalf of Reindl Harald <h.rei...@thelounge.net> Sent: Friday, January 20, 2017 5:06 PM To: bind-users@lists.isc.org Subject: Re: rDNS Am 20.01.2017 um 16:57 schrieb Ron Wingfield: > I am having difficulty configuring reverse DNS. This has been a problem > for over a year between my server(s) and my ISP, AT Specifically, I > cannot eMail to any recipient that requires rDNS verification, e.g., > SBCglobal.net, Comcast.net, or AOL. Very frustrating. > > In both cases, the reported server is an AT server ;; SERVER: > 68.94.157.9#53 > . . .why shouldn't this "point" to my server, 162.202.233.81 and not AT's? because the rDNS has *nothing* to do with your domain and mostly also not with your DNS server (except you have a own subnet and it's delegated by the ISP) you are not the netowner - you must talk to your ISP ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users Info Page - Internet Systems Consortium<https://lists.isc.org/mailman/listinfo/bind-users> lists.isc.org To see the collection of prior postings to the list, visit the bind-users Archives. Using bind-users: To post a message to all the list members, send ... bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users bind-users Info Page - Internet Systems Consortium<https://lists.isc.org/mailman/listinfo/bind-users> lists.isc.org To see the collection of prior postings to the list, visit the bind-users Archives. Using bind-users: To post a message to all the list members, send ... ___ 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: rDNS
Am 20.01.2017 um 16:57 schrieb Ron Wingfield: I am having difficulty configuring reverse DNS. This has been a problem for over a year between my server(s) and my ISP, AT Specifically, I cannot eMail to any recipient that requires rDNS verification, e.g., SBCglobal.net, Comcast.net, or AOL. Very frustrating. In both cases, the reported server is an AT server ;; SERVER: 68.94.157.9#53 . . .why shouldn’t this “point” to my server, 162.202.233.81 and not AT’s? because the rDNS has *nothing* to do with your domain and mostly also not with your DNS server (except you have a own subnet and it's delegated by the ISP) you are not the netowner - you must talk to your ISP ___ 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
rDNS
I am having difficulty configuring reverse DNS. This has been a problem for over a year between my server(s) and my ISP, AT Specifically, I cannot eMail to any recipient that requires rDNS verification, e.g., SBCglobal.net, Comcast.net, or AOL. Very frustrating. Two examples of dig: # dig -t mx alpha.archaxis.net ANSWER: 0, AUTHORITY: 1, Why does this first example, digging the FQDN of alpha.archaxis.net reports one authority but no answers? # dig -t mx archaxis.net ANSWER: 2, AUTHORITY: 0, . . .yet this second example. digging the FQDN of archaxis.net reports no authority but 2 answers? (The) ;; ANSWER SECTION: (of both examples) reports: archaxis.net. 10800 IN MX 30 bravo.archaxis.net. archaxis.net. 10800 IN MX 20 alpha.archaxis.net. In both cases, the reported server is an AT server ;; SERVER: 68.94.157.9#53 . . .why shouldn’t this “point” to my server, 162.202.233.81 and not AT’s? I have coded my BIND 9 in-addr.arpa zone file as follows: $ORIGIN 233.202.162.in-addr.arpa. $TTL 3h @ IN SOA ns1.archaxis.net. me.archaxis.net. ( 2017012002 ; Serial 1h ; Refresh 1h ; Retry 1h ; Expire 1h ) ; Negative cashing TTL 3600 IN NS ns1.archaxis.net. 3600 IN NS ns2.archaxis.net. 80 3600 IN PTR network.archaxis.net. 81 3600 IN PTR alpha.archaxis.net. 82 3600 IN PTR bravo.archaxis.net. 87 3600 IN PTR broadcast.archaxis.net. What is wrong? Is this my problem, or with AT? ___ 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
Size boundaries for zones of IPv6 rDNS
Hi! Are there size limits for zones of IPv6 reverse DNS ? For example, is this a valid zone? 5.a.8.3.4.f.3.0.c.a.d.f.ip6.arpa Thank you in advance! -- Thiago Henrique www.adminlinux.com.br ___ 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: Size boundaries for zones of IPv6 rDNS
-Original Message-
From: Listas lis...@adminlinux.com.br
Date: Thursday, November 14, 2013 12:57 PM
To: bind-users@lists.isc.org bind-users@lists.isc.org
Subject: Size boundaries for zones of IPv6 rDNS
Hi!
Are there size limits for zones of IPv6 reverse DNS ?
For example, is this a valid zone?
5.a.8.3.4.f.3.0.c.a.d.f.ip6.arpa
Thank you in advance!
Looks valid to me.
zone 1.0.0.4.8.6.8.1.1.0.0.2.ip6.arpa {
type master;
file external/master/2001.1868.4001.db;
};
zone 0.0.2.1.3.0.0.2.1.0.1.0.0.2.6.2.ip6.arpa {
type master;
file external/master/2620.101.2003.1200.db;
};
etc
http://www.zytrax.com/books/dns/ch3/#ipv6
___
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
authoritative rDNS
I set up a subnet on my server, complete with rdns, and ARIN has been adjusted for my two dns servers (ns.qcislands.net ns2.qcislands.net) the subnet: 23.235.75.0/24 if you do a lookup of, for instance: 23.235.75.10 and bounce that nslookup off of other dns servers, SOME say: Authoritative answers can be found from: ns ns2 others, well, at least google 8.8.8.8 do not show anything as authoritative, altho the IP DOES resolve. I am curious if 8.8.8.8 isn't trying, or instead, am I missing something which 8.8.8.8 considers incomplete and therefore un-authoritative ? I just want to make sure my setup is accurate. Thanks. ___ 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: authoritative rDNS
In article mailman.1483.1381387501.20661.bind-us...@lists.isc.org, Jim Pazarena b...@paz.bz wrote: I set up a subnet on my server, complete with rdns, and ARIN has been adjusted for my two dns servers (ns.qcislands.net ns2.qcislands.net) the subnet: 23.235.75.0/24 if you do a lookup of, for instance: 23.235.75.10 and bounce that nslookup off of other dns servers, SOME say: Authoritative answers can be found from: ns ns2 others, well, at least google 8.8.8.8 do not show anything as authoritative, altho the IP DOES resolve. I am curious if 8.8.8.8 isn't trying, or instead, am I missing something which 8.8.8.8 considers incomplete and therefore un-authoritative ? I just want to make sure my setup is accurate. Thanks. Including the Authority Section in a response is optional (unless it's a delegation or negative response). If you ask them explicitly for the NS records they show it: $ dig @8.8.8.8 -x 23.235.75 ns ;; ANSWER SECTION: 75.235.23.in-addr.arpa. 21600 IN NS ns2.qcislands.net. 75.235.23.in-addr.arpa. 21600 IN NS ns.qcislands.net. -- 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: Nintendo('s NSes) are asking my IP for it's rdns
On 24/07/12 14:30, Brian J. Murrell wrote: Why? I mean other than a knee-jerk reaction to that behavior not (yet) being documented in an RFC somewhere? I mean for practical purposes why is what they are (or rather, could be, assuming my suggestion about what they could be doing is correct) doing necessarily bad? The obvious implication of that behaviour is lots of DNS packets to IPs around the world that may not be (probably *are* not) running a DNS server. Based on the numbers coming in and out of my own resolvers (which aren't even that busy), suffice to say I think that traffic would be at best problematic, and at worst harmful. I can think of a bunch of ways this might cause problems, but frankly I lack the energy to get into a discussion about it. Maybe others are more interested ;o) DNS is well-specified in the RFCs. Sure. So there is no room for expansion? Absolutely. I look forward to the internet draft ;o) In all seriousness, I don't dismiss that the behaviour *could* be useful. I just think that, in general, sending unsolicited requests to unknown IP addresses, on a well-known protocol/port is sub-optimal. ___ 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: Nintendo('s NSes) are asking my IP for it's rdns
I'm assuming this greatunwashed view has recursion turned off, right?
If so, then the following approaches come to mind:
a) create a master zone for 5.37.58.216.in-addr.arpa in the
non-recursive view, putting the PTR record at the apex
b) become a stealth (unpublished) slave for 5.37.58.216.in-addr.arpa
(or its closest-enclosing zone) in the non-recursive view. Your ISP
would need to permit zone transfers to make this approach work
c) define a new view with match-recursive-only and lock it down so
that queries from external address ranges are only allowed for
5.37.58.216.in-addr.arpa (or its closest-enclosing zone), which you
would define as type stub or type forward in that view. Of course,
this method will only work if these Nintendo queries are actually RD=1
(have you verified this?). As a precaution, you might want to
double-check your query logs (or a packet capture) and see if any of the
queries currently being answered successfully from your
non-authoritative view are actually -- and superfluously -- RD=1. If
this is the case, you'll have to either fix the clients, or define the
relevant authoritative zones in *both* views in order to keep those
clients from breaking.
In other words, for approach (c), you might have:
/* our clients, allow to recurse */
view internal_clients {
match-clients { x.x.x/24; }; /* or match-destinations, depending on
your setup */
recursion yes;
...
/* implicit or explicit hints file, forwarders, whatever */
}
/* match only external RD=1 queries, deny everything except some
specific zone(s) */
view slightly_washed_Nintendoids {
match-recursive-only yes;
recursion yes;
allow-query { none; };
zone 37.58.216.in-addr.arpa {
type stub;
file 37.58.216.in-addr.arpa;
allow-query { any; }; /* override view default */
masters { y.y.y.y; }; /* ISP's nameservers */
};
...
/* might need some authoritative-zone definitions here, if you have
misconfigured clients */
...
};
/* match external RD=0 queries, answer from authoritative data only */
view greatunwashed {
recursion no;
/* allow-query-cache { any; }; /* if you prefer to return upwards
referrals rather than REFUSED for queries outside of authoritative data */
...
/* authoritative-zone definitions here */
...
};
- Kevin
On 7/24/2012 7:05 AM, Brian J. Murrell wrote:
I've come across something interesting in my named logs:
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache)
'5.37.58.216.in-addr.arpa/PTR/IN' denied
where 216.58.37.216 is my IP address, assigned by my ISP and reverse
resolved by my ISP's name servers.
What is interesting is the fact that 205.166.76.12 are asking me
(216.58.37.216) for the PTR for my address.
Is this just broken NS software or are they (Nintendo, FWIW) doing
something interesting, like giving everyone an opportunity to provide
an rdns for their own IP address without everyone having to make
classless in-addr.arpa delegation arrangements with their ISP (which
mine refused to do)?
It's kind of a neat concept if it's not just an accident of broken NS
software.
Has anyone else seen anything like this before? Is there some
(proposed even) standard for doing this that I'm not aware of?
In any case, now to the BIND part. It seems reasonable for me to
answer that query, either with my own data or simply by allowing
that query to recurse.
I suppose I could create a zone for it and put some data in it for
that one record if I wanted to provide my own data. But what if I
just wanted to allow recursive queries on that name so that I simply
returned whatever the proper NSes for it reports? I guess I could add
a zone record for it with a forwarder(s) configured to the name's proper
NSes, yes? But that means me having to maintain those forward records
in tandem with my ISP playing musical NSes (which I don't expect but
why create a possible maintenance headache).
So how could I configure BIND to allow a query for 5.37.58.216.in-
addr.arpa to be recursive for everyone, but of course, continue to
disallow general open recursive querying for names not served here?
Cheers,
b.
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from
Nintendo('s NSes) are asking my IP for it's rdns
I've come across something interesting in my named logs: 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied where 216.58.37.216 is my IP address, assigned by my ISP and reverse resolved by my ISP's name servers. What is interesting is the fact that 205.166.76.12 are asking me (216.58.37.216) for the PTR for my address. Is this just broken NS software or are they (Nintendo, FWIW) doing something interesting, like giving everyone an opportunity to provide an rdns for their own IP address without everyone having to make classless in-addr.arpa delegation arrangements with their ISP (which mine refused to do)? It's kind of a neat concept if it's not just an accident of broken NS software. Has anyone else seen anything like this before? Is there some (proposed even) standard for doing this that I'm not aware of? In any case, now to the BIND part. It seems reasonable for me to answer that query, either with my own data or simply by allowing that query to recurse. I suppose I could create a zone for it and put some data in it for that one record if I wanted to provide my own data. But what if I just wanted to allow recursive queries on that name so that I simply returned whatever the proper NSes for it reports? I guess I could add a zone record for it with a forwarder(s) configured to the name's proper NSes, yes? But that means me having to maintain those forward records in tandem with my ISP playing musical NSes (which I don't expect but why create a possible maintenance headache). So how could I configure BIND to allow a query for 5.37.58.216.in- addr.arpa to be recursive for everyone, but of course, continue to disallow general open recursive querying for names not served here? Cheers, b. signature.asc Description: OpenPGP digital signature ___ 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: Nintendo('s NSes) are asking my IP for it's rdns
On 12-07-24 07:05 AM, Brian J. Murrell wrote: I've come across something interesting in my named logs: 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:14:37 named client 205.166.76.12#60486: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:37 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied 00:16:38 named client 205.166.76.12#55728: view greatunwashed: query (cache) '5.37.58.216.in-addr.arpa/PTR/IN' denied where 216.58.37.216 That should be 216.58.37.5. is my IP address, assigned by my ISP and reverse resolved by my ISP's name servers. What is interesting is the fact that 205.166.76.12 are asking me (216.58.37.216) for the PTR for my address. And again, that should be 216.58.37.5. Sorry for the typos. Cheers, b. signature.asc Description: OpenPGP digital signature ___ 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: Nintendo('s NSes) are asking my IP for it's rdns
On 24/07/12 12:05, Brian J. Murrell wrote: Is this just broken NS software or are they (Nintendo, FWIW) doing Looks broken to me. I note that IP doesn't have a reverse. This suggests to me it's not any kind of nameserver, but rather part of their general pool - perhaps a random desktop. However, this page: http://vega.sra-tohoku.co.jp/~kabe/misc/dnsprober.html ...suggests it is part of some kind of probing/exploration infrastructure, although the page author seems a bit, erm... how to put this?... intense, about unexpected DNS traffic ;o) something interesting, like giving everyone an opportunity to provide an rdns for their own IP address without everyone having to make classless in-addr.arpa delegation arrangements with their ISP (which mine refused to do)? Change ISP? It's kind of a neat concept if it's not just an accident of broken NS software. I don't think that's what is going on. But even if it were, I think that would be a bad idea, personally. DNS is well-specified in the RFCs. Violating those to work around lazy ISPs is not a good solution. Has anyone else seen anything like this before? Is there some (proposed even) standard for doing this that I'm not aware of? We see all kinds of weird nonsense come into our DNS servers. We see LOTS AND LOTS of these two zones, continually: 75.97.111.76#27300: view main: query (cache) 'mx241.emailfiltering.com/A/IN' denied 41.218.219.221#26895: view main: query (cache) 'service17.mimecast.com/A/IN' denied But we also see a trickle of other crap that is nothing to do with us, for example: 190.26.0.2#16074: view main: query (cache) 'ns1.webservices.net/A/IN' denied 59.90.143.134#48824: view main: query (cache) 'a20.g.akamai.net/A/IN' denied I've never established why this happens, whether it's some kind of attempt at cache poisoning from botnets or just broken software. But frankly I don't care - I just ignore it. ___ 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: Nintendo('s NSes) are asking my IP for it's rdns
On 12-07-24 07:53 AM, Phil Mayers wrote: On 24/07/12 12:05, Brian J. Murrell wrote: Change ISP? A. You must be one of those people who live in that part of the world where internet service providing is not a monopoly, duopoly or at best a price-fixing oligopoly. :-) Unfortunately that's not all of us. Besides, although my ISP won't delegate the in-addr.arpa. for my one single IP address to me, they will allow me to tell them what to put in for it's PTR. So it doesn't totally suck. I don't think that's what is going on. But even if it were, I think that would be a bad idea, personally. Why? I mean other than a knee-jerk reaction to that behavior not (yet) being documented in an RFC somewhere? I mean for practical purposes why is what they are (or rather, could be, assuming my suggestion about what they could be doing is correct) doing necessarily bad? DNS is well-specified in the RFCs. Sure. So there is no room for expansion? Violating those to work around lazy ISPs is not a good solution. What exactly is it violating? Is there somewhere in an RFC that says an NS MUST NOT try to query a nameserver at a given IP for the PTR RR for itself? If we assume they are first going to an IP address to see if it's willing to provide a PTR for itself and then falling back to using the procedure defined in the RFCs and asking the NSes defined for that IP, what are they breaking? It seems to be they are extending, not violating. The fact that it's Nintendo which does create networkable hardware is what makes me wonder if it's more by design than brokenness. What if, for example, they put a lightweight NS into all of their hardware (i.e. handheld and other game units) that returns a PTR for it's own IP as a means of identifying the unit? Certainly, they could have just invented their own who are you protocol, but instead they decided to do something interesting with an existing protocol that already answers who is. My son has a gameboy or 2. It might be interesting to see if it responds to a PTR query. I will have to wait for him to come back from camp to see. We see all kinds of weird nonsense come into our DNS servers. We see LOTS AND LOTS of these two zones, continually: 75.97.111.76#27300: view main: query (cache) 'mx241.emailfiltering.com/A/IN' denied 41.218.219.221#26895: view main: query (cache) 'service17.mimecast.com/A/IN' denied Yeah, but these are not interesting. These look like either misconfigured resolvers, or opendns probing, or something. The thing that makes the behavior I posted about interesting (IMHO) is the possible usefulness of it. But we also see a trickle of other crap that is nothing to do with us, for example: 190.26.0.2#16074: view main: query (cache) 'ns1.webservices.net/A/IN' denied 59.90.143.134#48824: view main: query (cache) 'a20.g.akamai.net/A/IN' denied Sure, I think we all get that. Same as above. But none of it is interesting. I've never established why this happens, whether it's some kind of attempt at cache poisoning from botnets or just broken software. But frankly I don't care - I just ignore it. Of course. So do I. And I have been ignoring the queries I posted about until I realized they had some interesting aspect to them. Cheers, b. signature.asc Description: OpenPGP digital signature ___ 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: lists.isc.org rDNS failed, DNSSEC?
In message 1330508848.24108.140661042811...@webmail.messagingengine.com, nudge writes: A thought regarding the pros and cons of DNSSEC that I don't recall being mentioned. There are a whole set of things you can do once you have secure DNS. You just have to use your imagination. This one has always been blindling obvious. Was reverse-dns verification introduced in response to a lack of confidence in forward-dns? This can cause much frustration, especially in smaller environments. If the implementation of DNSSEC allowed us to avoid using reverse-dns then perhaps that could be beneficial to many. Not accepting SMTP from machines without a reverse DNS entry has nothing to do with the security of the DNS (forward or reverse). It had (past tense) to do with a strong correlation between compromised machines spewing out spam and lack of reverse DNS entries. If you actually read the RFCs they say do NOT do this check. If you are sane you only use it as one input into deciding if email is spam. The lack of a PTR record, by itself, shouldn't be enough to get a piece of email rejected though I do know lots of sites do it. Mark -- 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: lists.isc.org rDNS failed, DNSSEC?
Please allow a, partly/mostly, non-technical feedback as security officer for a tld (.eu) First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Point taken, but let me come back on those later. The (non-technical) response : When I get in my car, I put my safety belt on. (I know some may point at undesired effects, and I do not want to have that discussion in this list), but the point is : I do hope I will never need the protection offered by the safety belt, but if, then I'll be happy I took the precaution. The similarity to DNSSEC is that we all hope we will not need the protection it offers, but if an attacker finds it interesting to attempt to exploit, I will be glad I took the precaution of activating DNSSEC. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. Does this mean we don't have to put the safety belt on ? I daresay : no. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. To conclude (some technical) suggestions : - when offering DNSSEC on authoritative name servers, try to rely on automation (like scripts). (rather than humans to type - and re-type - the same commands over and over) - allow yourself a period of testing. Do *not* immediately have DS information put in the parent zone (thus completing the chain-of-trust but also : making validation mandatory. After all : this is a *test* period) ((look how TLDs migrate towards DNSSEC. Exactly the same : first offer DNSKEYs and RRSIGs, but no DS in the root-zone)) - and may I also plead for validation on caching/forwarding name servers ? Because it makes no sense to add signatures that can be validated to DNS replies, if the signatures are simply ignored. Kind regards, Marc Lampo Security Officer EURid (for .eu) -Original Message- From: michoski [mailto:micho...@cisco.com] Sent: 24 February 2012 06:01 AM To: vinny_abe...@dell.com; kob6...@gmail.com; ma...@isc.org Cc: bind-us...@isc.org Subject: Re: lists.isc.org rDNS failed, DNSSEC? On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html -- Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ 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: lists.isc.org rDNS failed, DNSSEC?
On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote: Please allow a, partly/mostly, non-technical feedback as security officer for a tld (.eu) First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Point taken, but let me come back on those later. The (non-technical) response : When I get in my car, I put my safety belt on. (I know some may point at undesired effects, and I do not want to have that discussion in this list), but the point is : I do hope I will never need the protection offered by the safety belt, but if, then I'll be happy I took the precaution. The similarity to DNSSEC is that we all hope we will not need the protection it offers, but if an attacker finds it interesting to attempt to exploit, I will be glad I took the precaution of activating DNSSEC. Speaking of course from my own lowly perspective, this thread (I started it) has made me much more cautious in proceeding with deployment of DNSSEC, and I am strongly considering disabling verification on my resolvers. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. Does this mean we don't have to put the safety belt on ? I daresay : no. Your analogy is weak, because while a safety belt has only minor drawbacks, DNSSEC verification has been quite intrusive for me, and AFAIK only a source of problems, not benefits. (Granted, if there was a benefit, namely to be protected from hostile data, I wouldn't know the difference easily.) In a wreck wearing a safety belt, you may get bruised along the belt line, but afterwards you get to look up at the glass in front of you and not see where your gashed, bloody forehead struck. Clear cut trade, minor annoyance for significant benefit. Doing DNSSEC verification in 2012 is lopsided the other way. You cannot resolve the names you need sometimes. You're probably not receiving any actual protection from spoofing. Last night I was unable to check the weather forecast, because the fine folks at NOAA.gov / weather.gov broke their DNSSEC. Lo and behold today I see fresh RRSIG records. They only last a week. I suppose there are different classes of failures; unfortunately on the resolver, there is only one result, SERVFAIL, to cover all. It would be better if there was a way to distinguish the oops, admin bungled DNSSEC errors from the ones which are more likely to be indicative of spoofing. The hardest part of that might be to decide which is which. IME the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. If the KSK does not match the parent's DS, or if there is a DS but the zone is unsigned, maybe we are looking at a real attack. Still not likely, but more likely than the case of the expired RRSIG. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. I suppose, but then I don't really worry much, personally, about the kind of naughty things a DNS spoofer might do. I have no money, so giving them my bank credentials won't do them any good. :) To conclude (some technical) suggestions : - when offering DNSSEC on authoritative name servers, try to rely on automation (like scripts). (rather than humans to type - and re-type - the same commands over and over) - allow yourself a period of testing. Do *not* immediately have DS information put in the parent zone (thus completing the chain-of-trust but also : making validation mandatory. After all : this is a *test* period) ((look how TLDs migrate towards DNSSEC. Exactly the same : first offer DNSKEYs and RRSIGs, but no DS in the root-zone)) Agreed. - and may I also plead for validation on caching/forwarding name servers ? Because it makes no sense to add signatures that can be validated to DNS replies, if the signatures are simply ignored. At this point, those of us who do the validation are the ones who are suffering. I think we need something like a softfail, at least for expired RRSIGs. I don't know if it is possible to make that distinction, however. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ Please visit
Re: lists.isc.org rDNS failed, DNSSEC?
On 2/28/12 9:26 AM, /dev/rob0 r...@gmx.co.uk wrote: On Tue, Feb 28, 2012 at 01:16:16PM +0100, Marc Lampo wrote: First of all : I do not deny DNSSEC adds a challenge for administrators. They must understand that adding this additional SECurity aspect, will generate extra work (keygeneration/re-generation/signing and re-signing). Similar to compiling, enabling, maintaining SSH when telnet always came enabled by default in inetd.conf. ;-) That's automatic these days. Speaking of course from my own lowly perspective, this thread (I started it) has made me much more cautious in proceeding with deployment of DNSSEC, and I am strongly considering disabling verification on my resolvers. Yes, I think timing is everything. How popular are these attacks against which DNSSEC offers protection ? From what I can see, my view being limited, the most 'effective', for lack of a better word, in 2011 were not DNS related. Social engineering, making people do something (click URL, open attachment) is a far more effective way, for attackers, to get their thing done. It wasn't just 2011, social engineering has always been a trump card. There are a lot of papers on spearphishing and the like (or watch Sneakers)... but, alas, that's another thread. Does this mean we don't have to put the safety belt on ? I daresay : no. Your analogy is weak, because while a safety belt has only minor drawbacks, DNSSEC verification has been quite intrusive for me, and AFAIK only a source of problems, not benefits. Well, sometimes... One drawback of a safety belt (being EMT trained) is that if you careen off a bridge (or end up in water some other way, it happens) the device sometimes malfunctions and you can't get out of the car. Drowning has always been one of my fears -- it's why I took swimming lessons early and avoided the Navy -- it's not a minor drawback for most. That said, they make $5 belt cutters you can keep in your glove box which mitigates this concern. The right tools can make all the difference. (Granted, if there was a benefit, namely to be protected from hostile data, I wouldn't know the difference easily.) snip Doing DNSSEC verification in 2012 is lopsided the other way. You cannot resolve the names you need sometimes. You're probably not receiving any actual protection from spoofing. I feel similarly. I do see risk in the non DNSSEC world (thanks to Kaminsky and others), but not so common or devastating to justify the cost and associated risks of deployment today. I think the right tools (inline signing!) will reduce TCO and generally make more folks jump onboard. Attackers constantly look for new ways, therefore if an attacker comes up with an approach that becomes popular because of ease/speed/effectiveness and that approach would have been prevented by DNSSEC, we would have been happy that we already deployed DNSSEC. I suppose, but then I don't really worry much, personally, about the kind of naughty things a DNS spoofer might do. I have no money, so giving them my bank credentials won't do them any good. :) For small shops or personal domains, it's ultimately up to the owner/administrator to decide... You are right, the risk may not be a concern at all in some cases. However, making it easier to do when the risk is present is somewhere I'm happy to see ISC making progress. -- I have never met a man so ignorant that I couldn't learn something from him. -- Galileo Galilei ___ 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: lists.isc.org rDNS failed, DNSSEC?
I suppose there are different classes of failures; unfortunately on the resolver, there is only one result, SERVFAIL, to cover all. It would be better if there was a way to distinguish the oops, admin bungled DNSSEC errors from the ones which are more likely to be indicative of spoofing. I'd like to see an EDNS(0) option that returns a detailed explanation of how a SERVFAIL happened. (I intend to write that IETF draft when engineering work gets out of my way enough that I have time to do it.) But it won't help until clients learn how to request that option and do something useful with the result. The hardest part of that might be to decide which is which. IME the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. BIND has this: dnssec-accept-expired yes; Note that it opens you to replay attacks, but misconfigured zones are more common than replay attacks, for now anyway. -- Evan Hunt -- e...@isc.org Internet Systems Consortium, Inc. ___ 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: lists.isc.org rDNS failed, DNSSEC?
In message cb725c9f.24ec1%micho...@cisco.com, michoski writes: Doing DNSSEC verification in 2012 is lopsided the other way. You cannot resolve the names you need sometimes. You're probably not receiving any actual protection from spoofing. I feel similarly. I do see risk in the non DNSSEC world (thanks to Kaminsky and others), but not so common or devastating to justify the cost and associated risks of deployment today. I think the right tools (inline signing!) will reduce TCO and generally make more folks jump onboard. DNSSEC is also a enabling technology. SSH already takes advantage of it. The DANE working group of the IETF is defining how to authenticate CERTs using the DNS associated with a DNS name which is a much more natural way of doing this than using a CA. With DNSSEC it is possible to cryptographically secure SMTP and be able to detect m-i-m attacks. DNSSEC protects the MX records (explict or implict). This lets you securely know which machine you are supposed to be connecting to, by name, and hence which CERTs are valid with STARTTLS given that name. Mark -- 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: lists.isc.org rDNS failed, DNSSEC?
On Tue, Feb 28, 2012 at 06:28:54PM +, Evan Hunt wrote: the one that bites us most often is that of the expired RRSIG. If we could log that but go ahead and accept the data, most of the pain would stop. BIND has this: dnssec-accept-expired yes; Note that it opens you to replay attacks, but misconfigured zones are more common than replay attacks, for now anyway. Ah! Thanks. I should have checked thr ARM before posting. I guess I'll keep my validation on with this option, see how it goes. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ 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
lists.isc.org rDNS failed, DNSSEC?
Yesterday I looked in mail logs for something else and stumbled upon this (times are UTC): rob0@harrier:~$ grep 'unknown\[149\.20\.64\.75\]' /var/log/maillog | wc 2713607 44087 rob0@harrier:~$ grep 'unknown\[149\.20\.64\.75\]' /var/log/maillog | head -1 Feb 21 05:28:25 harrier postfix/smtpd[4653]: connect from unknown[149.20.64.75] rob0@harrier:~$ grep 'unknown\[149\.20\.64\.75\]' /var/log/maillog | tail -1 Feb 21 21:32:06 harrier postfix/smtpd[3575]: disconnect from unknown[149.20.64.75] During that time I tried a dig 75.64.20.149.in-addr.arpa. any and got SERVFAIL. I checked 64.20.149.in-addr.arpa at Sandia's DNSViz, and it was fine. I was in a hurry so I didn't think to check 75.64.20.149.in-addr.arpa. I whitelisted 149.20.64.75 so this list's mail would come through; went on with other things. I was thinking that the problem might have been on my end, but I changed nothing before nor since; 75.64.20.149.in-addr.arpa/IN/PTR since 21:32 UTC yesterday has been returning lists.isc.org. Any idea (especially from ISC folks) what might have caused this? This is the scary thing about DNSSEC: a lot of valid zones might suffer from temporary glitches wherein signatures fail. I know one of my own zones had expired signatures awhile, and I have seen it with subscribers on my own Mailman lists. -- http://rob0.nodns4.us/ -- system administration and consulting Offlist GMX mail is seen only if /dev/rob0 is in the Subject: ___ 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: lists.isc.org rDNS failed, DNSSEC?
There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. Mark -- 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: lists.isc.org rDNS failed, DNSSEC?
On Thu, Feb 23, 2012 at 2:47 PM, Mark Andrews ma...@isc.org wrote: There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. I've seen several places, mostly in .gov bitten by this one and I'll admit that it almost caught me, but the fact that the ISC tripped over this says volumes about how careful people have to be about handling details when DNSSEC is added. It simply can't be the set and forget DNS of the past, at least not until and unless tools become far more bullet-proof. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: lists.isc.org rDNS failed, DNSSEC?
I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. -Vinny -Original Message- From: bind-users-bounces+vinny_abello=dell@lists.isc.org [mailto:bind-users-bounces+vinny_abello=dell@lists.isc.org] On Behalf Of Kevin Oberman Sent: Thursday, February 23, 2012 6:21 PM To: Mark Andrews Cc: bind-us...@isc.org Subject: Re: lists.isc.org rDNS failed, DNSSEC? On Thu, Feb 23, 2012 at 2:47 PM, Mark Andrews ma...@isc.org wrote: There was a issues with the delegation of some zones. NS records were not added to the parent zone when they should have been but the scripts which sign the zones added DS records which caused the parent zone not to be resigned. The signatures for the parent zone eventually expired which caused resolution failures for all the children of the parent zone rather than just the zones with a broken delegation. The scripts that sign the zones did report the error but those reports were overlooked. Operations is looking at their proceedures and what additional checking can be done to prevent a repeat. I've seen several places, mostly in .gov bitten by this one and I'll admit that it almost caught me, but the fact that the ISC tripped over this says volumes about how careful people have to be about handling details when DNSSEC is added. It simply can't be the set and forget DNS of the past, at least not until and unless tools become far more bullet-proof. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: lists.isc.org rDNS failed, DNSSEC?
On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html -- Time is the coin of your life. It is the only coin you have, and only you can determine how it will be spent. Be careful lest you let other people spend it for you. -- Carl Sandburg ___ 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: lists.isc.org rDNS failed, DNSSEC?
On Thu, Feb 23, 2012 at 9:00 PM, michoski micho...@cisco.com wrote: On 2/23/12 8:48 PM, vinny_abe...@dell.com vinny_abe...@dell.com wrote: I kind of had the same thought... If ISC had a DNS outage due to expired signatures of a zone, what chance do I have in successfully deploying and maintaining DNSSEC for my zones? Sure, everyone makes mistakes, but I think it speaks volumes to the inherent complexity and the further need for simplifying the maintenance of signed zones. I know that progress is continually being made on this front and I think others agree... Just pointing it out again. I have nothing against DNSSEC, personally. I'd love to deploy it. I just don't have the time to maintain it or worry about maintaining it right now. Much agreed, though I want to point out that you should only generally deploy DNSSEC (or any new technology?) if the benefit outweighs the cost. Adopting new technology just because usually leads to trouble (or overworked admins that give up and go elsewhere). What's the potential risk to your organization if the mythical determined attacker is able to negatively or positively spoof resource records under your control? Maybe not much for you, maybe millions for financial orgs. If the potential cost to the organization is high enough... It will justify paying a team of folks to maintain DNSSEC. :-) That said, I too look forward to a day when security is easier and more automatic. Much progress has been made, and I have high hopes and faith in ISC and the DNS community at large. http://www.jnd.org/books.html FWIW, we have been signing daily and rolling ZSKs every 2 weeks for over a year with no glitches at all, though we are using a non-BIND solution (Secure64) to do the signing. Still, it tells me that it is possible and I suspect that BIND 10 will move closer to that point. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: rdns for /20
On 4/13/2010 6:42 PM, Jason Davis wrote: Hello, Is their an easy way to rdns a /20. I can only find examples for a /24 You need to create individual zones for each /24. -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS Round-Robin
On Wed, Jul 8, 2009 at 5:08 PM, Mark Andrewsma...@isc.org wrote: RRsets are unordered. Software and configurations should be prepared for this. Where ordering is required it is built into the RR type. Mark On 14.07.09 14:02, Bryan Irvine wrote: I've think I've found the confirmation I was looking for in RFC 2181 section 10.2. Does this seem to confirm that round-robin PTR's are perfectly legal? yes, they are perfectly legal. However I don't know about any application that would require nor benefit of them, and I don't recommend using them. With most of applications doing reverse resolution and using its result anyhow it's still better to have always the same name... -- 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. To Boot or not to Boot, that's the question. [WD1270 Caviar] ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS Round-Robin
Matus UHLAR - fantomas wrote: On Wed, Jul 8, 2009 at 5:08 PM, Mark Andrewsma...@isc.org wrote: RRsets are unordered. Software and configurations should be prepared for this. Where ordering is required it is built into the RR type. Mark On 14.07.09 14:02, Bryan Irvine wrote: I've think I've found the confirmation I was looking for in RFC 2181 section 10.2. Does this seem to confirm that round-robin PTR's are perfectly legal? yes, they are perfectly legal. However I don't know about any application that would require nor benefit of them, and I don't recommend using them. With most of applications doing reverse resolution and using its result anyhow it's still better to have always the same name... Since we're nitpicking standards here, let's be clear that there is a distinction between multiple-record RRsets, which refers to the structure of the DNS database in a particular area, and round-robin, which refers to how a multiple-record RRset is treated when being given in a response from a resolver. It is perfectly legal to have multiple PTR records in a given RRset. It is also perfectly legal for a resolver to round robin the records of a PTR RRset in its responses. Round robin behavior is not, by standards, *required* of any resolver. As Mark put it RRsets are unordered. So, if the question is: does a round-robin PTR conform to standards?, then the answer is yes. Both elements of that -- the RRset having multiple records and the resolver performing 'round robin' sorting of those records -- are optional and legal. But, if the question is: given a PTR RRset with multiple records, *must* this result in a 'round robin'? then the answer is no. No resolver is *required* to round robin anything. If it gives the RRset always in a fixed order, or randomly, or using some other algorithm, e.g. optimizing the response to place addresses that are considered closer to the requesting client at the top of the list (BIND does this via its sortlist facility), then these are all legal. Hopefully that clarifies things. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS Round-Robin
On Wed, Jul 8, 2009 at 5:08 PM, Mark Andrewsma...@isc.org wrote: In message 53d706300907081412r191946eeo5c9a66657bf8e...@mail.gmail.com, Bryan Irvine writes: On Mon, Jul 6, 2009 at 4:08 PM, Kevin Darcyk...@chrysler.com wrote: Bryan Irvine wrote: Other than to really annoy me; =A0is there a valid reason for rr rDNS? Once upon a time, BIND specifically *disabled* round-robin behavior for non-address (A/) record types. PTR RRsets, among other types, were always given in a fixed order. But, I just tried a quick test, and it appears that round-robin has been re-enabled for PTRs. Accident? I have no idea why anyone would want this behavior, except perhaps to deliberately make things annoying and the que= ry results inconsistent, in the hopes that people will prevent the creation = of round-robin PTRs in the first place. Yes but is it explicitely forbidden anywhere? RFC's maybe? I can't find anything that says you shouldn't other than the majority of people say it's dumb. (Sometimes you need an RFC to point to in order to get someone to fix something that is clearly not working correctly). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users RRsets are unordered. Software and configurations should be prepared for this. Where ordering is required it is built into the RR type. Mark I've think I've found the confirmation I was looking for in RFC 2181 section 10.2. Does this seem to confirm that round-robin PTR's are perfectly legal? 10.2. PTR records Confusion about canonical names has lead to a belief that a PTR record should have exactly one RR in its RRSet. This is incorrect, the relevant section of RFC1034 (section 3.6.2) indicates that the value of a PTR record should be a canonical name. That is, it should not be an alias. There is no implication in that section that only one PTR record is permitted for a name. No such restriction should be inferred. Note that while the value of a PTR record must not be an alias, there is no requirement that the process of resolving a PTR record not encounter any aliases. The label that is being looked up for a PTR value might have a CNAME record. That is, it might be an alias. The value of that CNAME RR, if not another alias, which it should not be, will give the location where the PTR record is found. That record gives the result of the PTR type lookup. This final result, the value of the PTR RR, is the label which must not be an alias. ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS Round-Robin
On Mon, Jul 6, 2009 at 4:08 PM, Kevin Darcyk...@chrysler.com wrote: Bryan Irvine wrote: Other than to really annoy me; is there a valid reason for rr rDNS? Once upon a time, BIND specifically *disabled* round-robin behavior for non-address (A/) record types. PTR RRsets, among other types, were always given in a fixed order. But, I just tried a quick test, and it appears that round-robin has been re-enabled for PTRs. Accident? I have no idea why anyone would want this behavior, except perhaps to deliberately make things annoying and the query results inconsistent, in the hopes that people will prevent the creation of round-robin PTRs in the first place. Yes but is it explicitely forbidden anywhere? RFC's maybe? I can't find anything that says you shouldn't other than the majority of people say it's dumb. (Sometimes you need an RFC to point to in order to get someone to fix something that is clearly not working correctly). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS Round-Robin
In message 53d706300907081412r191946eeo5c9a66657bf8e...@mail.gmail.com, Bryan Irvine writes: On Mon, Jul 6, 2009 at 4:08 PM, Kevin Darcyk...@chrysler.com wrote: Bryan Irvine wrote: Other than to really annoy me; =A0is there a valid reason for rr rDNS? Once upon a time, BIND specifically *disabled* round-robin behavior for non-address (A/) record types. PTR RRsets, among other types, were always given in a fixed order. But, I just tried a quick test, and it appears that round-robin has been re-enabled for PTRs. Accident? I have no idea why anyone would want this behavior, except perhaps to deliberately make things annoying and the que= ry results inconsistent, in the hopes that people will prevent the creation = of round-robin PTRs in the first place. Yes but is it explicitely forbidden anywhere? RFC's maybe? I can't find anything that says you shouldn't other than the majority of people say it's dumb. (Sometimes you need an RFC to point to in order to get someone to fix something that is clearly not working correctly). ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users RRsets are unordered. Software and configurations should be prepared for this. Where ordering is required it is built into the RR type. 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
rDNS Round-Robin
Other than to really annoy me; is there a valid reason for rr rDNS? -Bryan ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS Round-Robin
Bryan Irvine wrote: Other than to really annoy me; is there a valid reason for rr rDNS? Once upon a time, BIND specifically *disabled* round-robin behavior for non-address (A/) record types. PTR RRsets, among other types, were always given in a fixed order. But, I just tried a quick test, and it appears that round-robin has been re-enabled for PTRs. Accident? I have no idea why anyone would want this behavior, except perhaps to deliberately make things annoying and the query results inconsistent, in the hopes that people will prevent the creation of round-robin PTRs in the first place. By the way, as a personal preference, I hate the term rDNS. Sounds like a whole different protocol, much as rwhois is a different protocol from the original whois. But this is misleading, since it's merely a different way (special naming convention and a semi-special QTYPE) of using the *same* protocol. - Kevin ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
rDNS for /20
I've read the relevant parts of DNS and Bind over and over again, and I'm still going crazy. I've searched this list going back about three years. I've googled. Each step confuses me more frown. I'm trying to set up a reverse delegation to two nameservers for a /20. Netmask is 255.255.240.0 (I think). Is there a cookbook somewhere? Thanks in advance for any possible help. 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
Re: rDNS for /20
In message 200903122311.24920.bli...@nobaloney.net, Jeff Lasman writes: I've read the relevant parts of DNS and Bind over and over again, and I'm still going crazy. I've searched this list going back about three years. I've googled. Each step confuses me more frown. I'm trying to set up a reverse delegation to two nameservers for a /20. Netmask is 255.255.240.0 (I think). Is there a cookbook somewhere? Thanks in advance for any possible help. Just set up each of the /24's which make up the /20. 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 -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: mark_andr...@isc.org ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS for /20
Jeff Lasman wrote: I've read the relevant parts of DNS and Bind over and over again, and I'm still going crazy. I've searched this list going back about three years. I've googled. Each step confuses me more frown. It would help if you described in more detail what you've tried, and what is confusing you. I'm trying to set up a reverse delegation to two nameservers for a /20. The easiest way to do this is to set it up as 16 /24s. Are you trying to do something different? Netmask is 255.255.240.0 (I think). I'm not sure why you're mentioning this, is there some relevance to what you're trying to do? hope this helps, Doug ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS for /20
On Thursday 12 March 2009 11:23 pm, Doug Barton wrote: It would help if you described in more detail what you've tried, and what is confusing you. Haven't tried anything yet; still waiting for the assignment to us. I was hoping to get a headstart on understanding the job. I'm trying to set up a reverse delegation to two nameservers for a /20. The easiest way to do this is to set it up as 16 /24s. Are you trying to do something different? Only difference is that all I need to do is set up the nameserver assignment; I don't have to do the actual rDNS. Why are we doing it at all? Because the gent I'm doing it for wants himself in the middle. Netmask is 255.255.240.0 (I think). I'm not sure why you're mentioning this, is there some relevance to what you're trying to do? I'm not sure either; I was just covering bases smile. It does. 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
Re: rDNS for /20
On Thursday 12 March 2009 11:17 pm, Mark Andrews wrote: Just set up each of the /24's which make up the /20. That's what I thought I had to do. I don't even have to assign the rDNS; I only have to set the nameservers. Do I still need lines for each individual IP# in each /24? Or is there an easier way? Why are we doing this at all; why don't we just have it assigned to the end client? Because the guy I'm doing it for wants it this way. 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
RE: rDNS for /20
You can use one $GENERATE statement in each zone to generate all 256 CNAME records for that zone. Ben -Original Message- From: bind-users-boun...@lists.isc.org [mailto:bind-users-boun...@lists.isc.org] On Behalf Of Jeff Lasman Sent: Friday, March 13, 2009 3:31 PM To: Mark Andrews Cc: bind-us...@isc.org Subject: Re: rDNS for /20 On Thursday 12 March 2009 11:17 pm, Mark Andrews wrote: Just set up each of the /24's which make up the /20. That's what I thought I had to do. I don't even have to assign the rDNS; I only have to set the nameservers. Do I still need lines for each individual IP# in each /24? Or is there an easier way? Why are we doing this at all; why don't we just have it assigned to the end client? Because the guy I'm doing it for wants it this way. 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 ___ bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: rDNS for /20
On Friday 13 March 2009 03:14 pm, Ben Bridges wrote: You can use one $GENERATE statement in each zone to generate all 256 CNAME records for that zone. I couldn't remember the name of that statement for the life of me. 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
