REVERSE DNS Practices.
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 -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments
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 :D Thanks On 21 Mar 2009 10:32:30 -0000, John Levine <johnl@iecc.com> wrote:
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
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 On Sat, Mar 21, 2009 at 01:38:55PM +0300, bruce@yoafrica.com wrote:
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 :D
Thanks
On 21 Mar 2009 10:32:30 -0000, John Levine <johnl@iecc.com> wrote:
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
On Sat, Mar 21, 2009 at 8:00 AM, <bmanning@vacation.karoshi.com> wrote:
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 On Sat, Mar 21, 2009 at 01:38:55PM +0300, bruce@yoafrica.com wrote: > 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 :D > > Thanks > > On 21 Mar 2009 10:32:30 -0000, John Levine <johnl@iecc.com> wrote: > >> 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 > -- Jamie Rishaw // .com.arpa@j <- reverse it. ish. [Impressive C-level Title Here], arpa / arpa labs
On 21/03/2009, at 11:30 PM, bmanning@vacation.karoshi.com wrote:
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 -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net
bmanning@vacation.karoshi.com writes:
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.
I have a question. Is this an abuse problem? some ISPs require their domain to be in the rdns in an effort to herd abuse reports to the correct org. Is this generally considered useless? Is it generally considered OK to hand relatively untrusted users the keys to their own rdns? (I'm forcing my own customers to have a rdns of something.xen.prgmr.com for several months, Much to the chagrin of many presumably innocent and legitimate customers. )
On Sat, 2009-03-28 at 03:12 -0400, Luke S Crawford wrote:
bmanning@vacation.karoshi.com writes:
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.
I have a question. Is this an abuse problem? some ISPs require their domain to be in the rdns in an effort to herd abuse reports to the correct org. Is this generally considered useless? Is it generally considered OK to hand relatively untrusted users the keys to their own rdns?
(I'm forcing my own customers to have a rdns of something.xen.prgmr.com for several months, Much to the chagrin of many presumably innocent and legitimate customers. )
We allow RDNS controls to RapidXen customers since January 2009. It seems to be ok. We do have the ability to disable RDNS access to specific users if we feel it is being abused, however. -- William Pitcock SystemInPlace - Simple Hosting Solutions 1-866-519-6149
The recommendations in this draft proposal have worked for me: http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt Frank -----Original Message----- From: bruce@yoafrica.com [mailto:bruce@yoafrica.com] Sent: Saturday, March 21, 2009 5:39 AM To: John Levine Cc: nanog@nanog.org Subject: Re: REVERSE DNS Practices. 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 :D Thanks On 21 Mar 2009 10:32:30 -0000, John Levine <johnl@iecc.com> wrote:
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
on Sat, Mar 21, 2009 at 12:44:15PM -0500, Frank Bulk wrote:
The recommendations in this draft proposal have worked for me: http://tools.ietf.org/id/draft-msullivan-dnsop-generic-naming-schemes-00.txt
Also: http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-0... 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 -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
On Saturday 21 March 2009 06:38:55 pm bruce@yoafrica.com wrote:
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 :D
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.
On Sun, Mar 22, 2009 at 10:30:07AM +0800, Mark Tinka wrote:
On Saturday 21 March 2009 06:38:55 pm bruce@yoafrica.com wrote:
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 :D
As regards core infrastructure, I posted the below on this list a while back, not sure if it'll help.
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. On 25/03/2009, at 4:12 AM, William Allen Simpson 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
Matthew F. Ringel wrote: 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.
-- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net
on Thu, Mar 26, 2009 at 10:26:59AM +1030, Tom Wright wrote:
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. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
$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 -- <xterm> The problem with America is stupidity. I'm not saying there should be a capital punishment for stupidity, but why don't we just take the safety labels off of everything and let the problem solve itself? http://www.bash.org/?4753
on Thu, Mar 26, 2009 at 08:44:57PM +1100, Martin Barry wrote:
$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. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
On Thu, Mar 26, 2009, Steven Champeon wrote: [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
on Fri, Mar 27, 2009 at 02:14:27AM +0900, Adrian Chadd wrote:
On Thu, Mar 26, 2009, Steven Champeon wrote:
[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?
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. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
On 27/03/2009, at 3:26 AM, Steven Champeon wrote:
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). http://www.internode.on.net/support/faq/email/port_filtering/ -- Kind Regards, Tom Wright Internode Network Operations P: +61 8 8228 2999 W: http://www.internode.on.net
on Fri, Mar 27, 2009 at 11:39:49AM +1030, Tom Wright wrote:
On 27/03/2009, at 3:26 AM, Steven Champeon wrote:
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. -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
on Thu, Mar 26, 2009 at 01:22:17AM -0400, Steven Champeon wrote:
on Thu, Mar 26, 2009 at 10:26:59AM +1030, Tom Wright wrote:
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.):
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 -- hesketh.com/inc. v: +1(919)834-2552 f: +1(919)834-2553 w: http://hesketh.com/ antispam news, solutions for sendmail, exim, postfix: http://enemieslist.com/
participants (15)
-
Adrian Chadd -
Beavis -
bmanning＠vacation.karoshi.com -
bruce＠yoafrica.com -
Frank Bulk -
jamie rishaw -
John Levine -
Luke S Crawford -
Mark Tinka -
Martin Barry -
Matthew F. Ringel -
Steven Champeon -
Tom Wright -
William Allen Simpson -
William Pitcock