hi,
I want to ask some folks out there that maintain reverse DNS queries
of their respective IP blocks. I want to know if there is a need for
me to contact my upstream provider. I am in charge of 2 /24's under
LACNIC. I've already registered my DNS servers on LACNIC. but for some
weird reason it's not owning reverse resolves. any tips would be
gladly appreciated.
thanks,
b
I want to ask some folks out there that maintain reverse DNS queries
of their respective IP blocks. I want to know if there is a need for
me to contact my upstream provider. I am in charge of 2 /24's under
LACNIC. I've already registered my DNS servers on LACNIC. but for some
weird reason it's not owning reverse resolves. any tips would be
gladly appreciated.
The RIRs don't maintain rDNS for you. You'll have to trace the
delegations downward from in-addr.arpa, find out who's handling your
/24's, and contact them to get them to delegate your chunks to you.
R's,
John
Slighty related...
Can people please post their recommended reverse dns naming conventions for a small ISP with growth and scalability in mind.
I already have one drawn up, but I would like to contrast and compare 
Thanks
the 20th or 21st century answer?
if you really don't care about the actual node, then you should map the
numbers to topologically significant names - after all, the reverse map
follows topology, not some goofball - layer 9 - ego trip thing.
or - the more modern approach is to let the node (w/ proper authorization)
do a secure dynamic update of the revserse map - so the forward and reverse
delegations match. ... a -VERY- useful technique.
--bill
the 20th or 21st century answer?
if you really don't care about the actual node, then you should map
the
numbers to topologically significant names - after all, the reverse
map
follows topology, not some goofball - layer 9 - ego trip thing.
For routing / backbone devices/interfaces/loopbacks, absolutely. <<<
There are security implications [sort of] with being verbose about
infrastructure naming, but obscurity in DNS never stopped a crawler from
walking the ipv4 space looking for vulnerabilities...
I'm going to guess tho that your question pertains to user ips.
For end-user (dsl/dial/cable/eyeball) ips on a small or large scale,
simpler is better. <<<
There's no need to put "-slip" or 'ppp' or isdn or dial or poolXXX or city
names in an in-addr.
Nobody needs to know, nobody will probably care, and eventually, it'll
change somehow.
There is a quite elegant, database-friendly, probably-easy-to-generate/code
sans textfiles method - a rather clever nomenclature for its insanely
ginormous [yes, thats the technical term] user ip pools. AOL uses it in
their user pools.
* each octet is converted to a to byte hex value, and concatenated.
example: 172.137.220.58 = AC89DC3A.ipt.aol.com.
o It's short, simple, and not geographically tying or revealing (your
noc should know where your dial blocks sit) 
etc etc.
o Being hex, It's also not language-specific ..
o Win factor? With a different SLD or subdomain (e.g. /ipt/.aol.com)
, queries can be offloaded to less critical nameservers
The problem eventually, as bill hints to, is that hostnames (esp. in-addr)
*will* change. A certain phone co out here (cant tell you their name, but
their initials are sbc) is annoyingly famous for this.
Tens of thousands of in-addrs resolve to hostnames with locations in other
states, other time zones, because, pools get shuffled around.. and really,
nobody likes to sit and manage DNS all day. Even noc monkies.
Using the hex method solves this.
or - the more modern approach is to let the node (w/ proper
authorization) do a secure dynamic update of the revserse map - so the
forward and reverse delegations match. ... a -VERY- useful technique.
Lots of administration in this one, too, tho.. keys, manual definitions ..
i suppose it could be automated, but you still have client configs,
interoperability issues, and worst case / improperly configured dns update
controls, namespace collisions.
A lot of this of course is about context.
What are the IPs purposed to? Infrastructure? Users?
Everyone's mileage will vary, but, I've yet to come across any serious
issues with dotted quads to hex...
-jamie
> Slighty related...
>
> Can people please post their recommended reverse dns naming
conventions for a small ISP with growth and scalability in mind.
> I already have one drawn up, but I would like to contrast and compare
>
> Thanks
>
> >> I want to ask some folks out there that maintain reverse DNS
queries
> >>of their respective IP blocks. I want to know if there is a need for
> >>me to contact my upstream provider. I am in charge of 2 /24's under
> >>LACNIC. I've already registered my DNS servers on LACNIC. but for
some
The recommendations in this draft proposal have worked for me:
http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt
Frank
As regards core infrastructure, I posted the below on this
list a while back, not sure if it'll help.
http://www.merit.edu/mail.archives/nanog/msg01341.html
YMMV.
Cheers,
Mark.
if you really don't care about the actual node, then you should map the
numbers to topologically significant names - after all, the reverse map
follows topology, not some goofball - layer 9 - ego trip thing.
Agreed - and its certainly manageable if you automate the process.
Generating reverse lookups from your config backups is a pretty
reliable way of doing this for infrastructure/dynamic allocations.
Your NOC staff will love it because they won't have to worry
when they shuffle around local pools, or turn up new interfaces.
or - the more modern approach is to let the node (w/ proper authorization)
do a secure dynamic update of the revserse map - so the forward and reverse
delegations match. ... a -VERY- useful technique.
Are there any network operators actually doing this on a large scale?
-- Tom
Also:
http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06
http://tools.ietf.org/html/draft-ietf-dnsop-inaddr-required-07
In any case, it depends on whether those IPs will house legitimate
sources of mail; I *strongly* recommend indicating whether an IP is
dynamically or statically assigned, and (ideally) what sort of tech is
in use (dialup? DSL? cable? wifi? etc) so that mail admins can make
decisions about whether or not to allow mail from those hosts. (Hrm, do
I want mail from a dynamic wifi IP? not so much; static generic dsl?
okay, maybe for now).
If you want to be friendly to folks who don't necessarily want to
have to use regexes to match your dynamics, make sure that if you
do use some sort of topology- or geography-based naming, that you
put the "dynamic" or "static" token as far to the right as possible,
so that you end up with
rdu-1-2-3-4.cable.dynamic.example.net
instead of
dyn-1-2-3-4.cable.rdu.example.net
because it's a lot easier for mail admins to block 'dynamic.example.net'
than to have to have local access.db entries for every last geography
you're serving, or have to use regexes. And please don't mix dynamics
and statics under the same naming conventions.
Finally, if you *do* intend for these IPs to house legit mail servers
(or mail sources, for that matter), whether yours or your clients', for
the love of all that is good and holy, give them /custom/ PTRs that
indicate the actual domain of the responsible party, rather than just
giving them generic names in your domain, unless you really want to
act as an abuse report gateway for your clients.
HTH,
Steve
Similarly, I did a presentation on this a while ago. This may be of
some use.
http://www.nanog.org/meetings/nanog31/abstracts.php?pt=NjExJm5hbm9nMzE=&nm=nanog31
(also: http://tinyurl.com/cuqv5e )
The details of the presentation are more geared to a multi-campus
enterprise network (i.e. a university), but the two larger lessons
that came out of moving the university over to a more standard naming
scheme were:
Derivability: Being able to synthesize the name with a few pieces of
data makes naming and debugging easier.
Longer is okay: Barring software limitations on name length, a longer
name is not a problem if a person knows that they're going to get it
right on the first try. We used CNAMEs if we wanted abbreviations.
YMMV
....Matt
Matthew F. Ringel wrote:
Derivability: Being able to synthesize the name with a few pieces of
data makes naming and debugging easier.
I agree. Remember, this is mostly going to show up in log files, and
they need to be easily skimmed by even the newest staff.
Longer is okay: Barring software limitations on name length, a longer
name is not a problem if a person knows that they're going to get it
right on the first try. We used CNAMEs if we wanted abbreviations.
Clarity and consistency are paramount!
I'm of the mind that you (we) should always setup the reverse *first*
for each block. Only after that's propagated, then add the A records
and CNAMEs.
When you change from dynamic or unused assignments to static or a
specific customer domain, update the reverse *first*, then the A or
CNAME. The reverse lists become your assurance that you haven't
accidentally added duplicate assignments.
Another hint (from the days we had a lot of directed broadcast attacks):
indicate never used addresses and broadcast addresses in the reverse
list (such as reserved0, reserved31, reserved32, reserved255), although
you will *never* have them in the A records (I always add a reminder
comment line on the forward side). That makes them stand out in the log.
Don't forget to block (and log) your reserved addresses at your boundary
routers! A script to check the ACL against the reverse DNS is good,
although many routers will handle this semi-automatically now.
So, you'll have a fully defined and propagated reverse list, even though
the forward side hosts don't exist (yet). Security folks sometimes
worry that makes scanning targeting easier, but arguably similar effort
to ping those addresses will yield similar results.
It's most important for security to document the vulnerabilities
(reverse addresses help with self-documentation). Sometimes, folks
deliberately hide their systems in a sparsely populated block of fully
defined reverse addresses.
Don't be afraid to create zones for each
location, DNS lends itself to this kind of
hierarchy naturally.
I find this is tidier than lengthy A records.
I.e, hostname.location.domain
This also makes your zones a little more
manageable (although on all accounts, some
simple automation will ensure happiness forever
more).
I guess I'm speaking more from an ISP point of
view.
Don't be afraid to create zones for each
location, DNS lends itself to this kind of
hierarchy naturally.I find this is tidier than lengthy A records.
I.e, hostname.location.domain
And yet makes it more difficult for anyone else to simply set
aside ALL of your dynamics as offlimits using simple substrings
(say, in sendmail's access.db or using postfix check_client_access).
Don't be that guy.
Oh, yeah. You already are (quick! guess which of these are actually
dynamic, and which static, who's residential, who's business, etc.):
adsl.internode.on.net
gaw.internode.on.net
padsl.internode.on.net
adsl.adelaide.on.net
link.internode.on.net
as0.adl2.internode.on.net
lns1.adl2.internode.on.net
lns2.adl2.internode.on.net
lns3.adl2.internode.on.net
lns4.adl2.internode.on.net
lns11.adl2.internode.on.net
lns5.adl2.internode.on.net
lns1.adl4.internode.on.net
lns2.adl4.internode.on.net
lns3.adl4.internode.on.net
lns10.adl6.internode.on.net
lns1.bne1.internode.on.net
lns2.bne1.internode.on.net
lns1.bne4.internode.on.net
lns2.bne4.internode.on.net
lns1.cbr1.internode.on.net
lns2.cbr1.internode.on.net
lns1.hba1.internode.on.net
lns1.mel4.internode.on.net
lns2.mel4.internode.on.net
lns3.mel4.internode.on.net
lns4.mel4.internode.on.net
lns1.mel6.internode.on.net
lns2.mel6.internode.on.net
lns4.mel6.internode.on.net
lns1.per1.internode.on.net
lns1.syd2.internode.on.net
lns1.syd6.internode.on.net
lns2.syd6.internode.on.net
lns4.syd6.internode.on.net
lns1.syd7.internode.on.net
lns2.syd7.internode.on.net
lns3.syd7.internode.on.net
cor2.adl2.internode.on.net
lns10.adl2.internode.on.net
lns10.mel4.internode.on.net
lns10.syd6.internode.on.net
lns10.syd7.internode.on.net
nsw.adsl.internode.on.net
qld.adsl.internode.on.net
qld.padsl.internode.on.net
sa.adsl.internode.on.net
tas.adsl.internode.on.net
vic.adsl.internode.on.net
wa.adsl.internode.on.net
Oh, there's also 'static.internode.on.net', so the safe bet is to
assume that ALL of the rest are dynamic. Correct bet? Who knows.
$quoted_author = "Steven Champeon" ;
adsl.internode.on.net
gaw.internode.on.net
padsl.internode.on.net
adsl.adelaide.on.net
link.internode.on.net
as0.adl2.internode.on.net
lns1.adl2.internode.on.net
...and so on and so on.
You do realise that they were all infrastructure devices which would never
send email? LNS isn't a big enough giveaway?
Oh, there's also 'static.internode.on.net', so the safe bet is to
assume that ALL of the rest are dynamic. Correct bet? Who knows.
That's a safe assumption.
So ignore static.internode.on.net, their MXes and block everything else
*.on.net
cheers
marty
$quoted_author = "Steven Champeon" ;
>
> adsl.internode.on.net
> gaw.internode.on.net
> padsl.internode.on.net
> adsl.adelaide.on.net
> link.internode.on.net
> as0.adl2.internode.on.net
> lns1.adl2.internode.on.net...and so on and so on.
You do realise that they were all infrastructure devices which would
never send email? LNS isn't a big enough giveaway?
You do realize that we've seen mail from all of these, which is why
they're even on our radar, right? PaDSL is a VPN service. ADSL is a
pretty straightforward label. 'link'? Who knows? If you don't take the
time to think about your labeling and tokens, don't be surprised if
other people not privy to your internal naming scheme start guessing.
Especially if they're spewing spam and viruses like a firehose.
> Oh, there's also 'static.internode.on.net', so the safe bet is to
> assume that ALL of the rest are dynamic. Correct bet? Who knows.That's a safe assumption.
Unfortunately, it's not. Even more unfortunately, we see more junk
from their generic statics than we do from their obvious dynamics.
[snip interode related hostnames such as this]
> > adsl.adelaide.on.net
> That's a safe assumption.
Unfortunately, it's not. Even more unfortunately, we see more junk
from their generic statics than we do from their obvious dynamics.
Have you tried just contacting internode in Australia about this?
Adrian
We maintain patterns for some 21K domains. No, we don't contact every
ISP we see abusive traffic from, as it would take far longer than simply
blocking based on evidence. We've been down that road before, and
frankly it's a stunning waste of time. In the six years we've been doing
this, we've had maybe two ISPs actually take the time to rename based on
a recognition that doing so would be a boon to the antispam community
and a good PR move. One of them took about 18 months to do so, and is
still not finished across their entire network. The other has since
reverted to stupid naming, presumably because the clue left the
building. We've seen some adoption of sane naming practices, probably as
a response to deliverability problems, but it's far from widespread.
Especially if they're spewing spam and viruses like a firehose.
If you're talking about our net blocks, then
please do drop me a line. We're quite serious
about minimising the spam sent from our network,
and we'd be happy to investigate.
Unfortunately, it's not. Even more unfortunately, we see more junk
from their generic statics than we do from their obvious dynamics.
That seems about right. We filter port 25 outbound from
our dynamic ranges (by default).
Especially if they're spewing spam and viruses like a firehose.
If you're talking about our net blocks, then
please do drop me a line. We're quite serious
about minimising the spam sent from our network,
and we'd be happy to investigate.
Thanks, but I think it's easy enough for you to rsync a copy of CBL or
other DNSBL zones and grepcidr through it for your own netblocks, so
I'll just continue as I am. I appreciate the offer, though, and don't
doubt the sincerity. I just don't have time to police your networks for
you, much less everyone else's.
Unfortunately, it's not. Even more unfortunately, we see more junk
from their generic statics than we do from their obvious dynamics.That seems about right. We filter port 25 outbound from
our dynamic ranges (by default).
http://www.internode.on.net/support/faq/email/port_filtering/
How long have you been doing this? And do all of your statically
assigned internode.on.net PTRs contain the token 'static'? Or not? If
not, why not? In any case, do you provide custom PTRs for those who ask?
If so, why not provide them for /all/ customers with statics?
The hosts with 'padsl' tokens - are they all NAT/VPNs (Private Access
DSL, a la THUS) , or just "Personal ADSL"? Are your hosts with ppp
tokens dynamic, static, or a mixture? I see both types; hosts wstarting
with 'ppp' and containing a 'static' token, and others without.
Martin Barry mentioned 'LNS' as a big giveaway as to the sort of nodes
those are, and suggested that they're infrastructure devices which would
never send mail, yet in the past couple weeks we've seen connections
from the following hosts:
ppp121-44-233-193.lns1.per1.internode.on.net
ppp118-208-178-233.lns10.mel4.internode.on.net
ppp224-33.lns3.syd7.internode.on.net
ppp121-44-110-124.lns10.syd6.internode.on.net
So I guess they're not that sort of device. <shrug>
Under Technobabble on the Web page above, you specify which services are
usually static and which dynamic, making distinctions between Home,
SOHO, Corporate and so forth, but your naming doesn't reflect those
distinctions. (Think Road Runner, who uses res.rr.com for nearly all of
their home cable hookups, and biz.rr.com for their business cable).
Thanks for any assistance/clarification you can provide.
As there seems to have been some misunderstanding as to what I was
advocating, to the extent that some people have accused me of calling
Tom and Internode out for criticism for their leaky network, etc. etc.,
I'll try to explain again.
Due to the botnet problem, generic reverse DNS is a useful indicator of
the risk involved in accepting email from a given source.
I have a large (~36K patterns) collection of regexes that attempt to
classify said rDNS into assignment type and various other subtypes, as
well as the technology in use, on the grounds that certain types of
names are highly correlated to spambot-infected hosts, or their
relative likelihood of being/staying infected, anyway.
I personally don't care if every ISP on the planet uses vague and
uninformative PTR naming, as long as they do so consistently. It's
actually in my interest to have the names be impenetrably obtuse, as
we license the patterns to various appliance and reputation service
providers and ISPs, etc.
I am also aware, however, that many folks do not have such a collection
of regexes for classified PTR naming conventions, and so whenever the
subject of naming comes up, I try to point out reasons why there are
best practices that should be followed, if only for the sake of mail
admins being able to collectively block all mail from dynamics or
generics on a certain source network in a reliable manner.
First among those practices is to indicate dynamicity /first/; in Tom's
example, you might even set up zones for each of your allocations - one
for dynamics, and one for statics.
What Tom was actually recommending, though, was to use geographies as
the first (rightmost) token, which while it may have certain merits in
offloading management responsibility, makes it difficult for everyone
else, as it multiples the number of substrings you need to throw into
your MTA filtering config.
When I mentioned "spewing spam and viruses", I wasn't necessarily
singling out Tom or Internode for irresponsibility, and as it turns out
their volumes here are relatively low compared to others (and may, in
fact, be the fault of customers whose networks they don't control at
all, if they're all statically assigned).
I was merely saying that it will be much more favorably received by a
mail admin who is seeing high volumes of crud from a given network if
said admin can block it all with one rule, instead of having to collect
dozens.
Nonetheless, there are inconsistencies in the on.net naming; some hosts
have 'static' as a token, some others are apparently static but lack
that token, and so forth. So, if I've looked at millions of hostnames
and classified tens of thousands of patterns and I can't tell whether
a given host is static or dynamic, I can't expect someone with little
experience in global DNS label/token meanings to be able to, either.
In the subsequent thread, we saw that Internode port blocks outbound 25,
so some substrings I had considered dynamic may well not be. I've asked
for more information and hope that I can correct my classifications.
Given that most of my patterns came from hostnames who've tried to send
me spam, it may be that my patterns pre-date their port 25 blocks. I
have no way of knowing. I've got patterns going back six years or more,
and just because I have a pattern doesn't mean I've seen traffic from
a host matching the pattern recently.
We also saw that padsl could mean "personal ADSL", or "private access
DSL / VPN"; that "LNS" may be a network management tool, an L2TP Network
Server, or a PPPoE node served *by* that server, and may well mean
something else entirely (Lancaster Airport, Laboratory for Nuclear
Science, and so forth).
The main point still stands: clarity in naming, especially of end user
nodes, is important. If I gave anyone the wrong impression about Tom or
Internode, or their relative responsibility as network operators, I
apologize. I had no such intent.
Steve