> $GENERATE, as someone else pointed out, solves that problem for you?
> (Does it scale for IPv6? I can't recall - but surely this could be
> scripted too.)
> No. A /64 has 18,446,744,073,709,551,616 addresses. Even if you
> had machines that supported zettabytes of data the zone would never
> load in human lifetimes.Can you wildcard it?
No point. address -> name -> address doesn't work with wildcards.
Maybe because it's redundant: a PTR check should be automatic on any
incoming SMTP connection. Just think of all the traffic their survey
tool generated in compiling this totally useless list.
The humanity!
Nicolai
I find SpamRats' lists helpful in spam filtering as a low scoring list
because it puts some new emitters which haven't had time to build up bad
reputation "over the top". Having said that, they actually have 3 lists,
and only one of those 3 lists involves listing IPs ONLY based on "no
PTR". They also have an "all" list, but they document on their web site
how to query the "all" list, but then ignore those return codes
indicating the "no PTR" list.
That is how I use them because I didn't need their "no PTR" list since
it would be redundant for me since I was already checking for "no PTR"
myself... and I didn't want to score twice on that one attribute.
But if your information is accurate and I understand you correctly, then
I agree that they shouldn't list the whole /24 in their PTR list if SOME
of those IPs *do* have PTRs.
(Actually, I wasn't aware that any of their lists involved /24 blocks.
They should probably be more clear about that on their web site.)
On their web site, on the http://www.spamrats.com/about.php page, under
the heading, "NEW - SpamRats All", they describe this method of querying
their "all" list, but ignoring their PTR list's particular return code.
I think they made THAT suggestion FOR VERY GOOD REASON. Therefore, you
could use this to your advantage by going back to whichever recipient
blocked your mail and say... "hey, you're NOT using spamRATS in a manner
that they suggested", then point them to the section I referenced and
explain that many don't use their "no PTR" list since most spam filters
already do that. Maybe that could be a short term solution for you?
(probably better than nothing)
My information is correct. The /24 is listed _only_ on the no-ptr list.
No point. address -> name -> address doesn't work with wildcards.
(Still an IPv6 implementation virgin, just curious
)
If you want to do generic IPv6 rDNS for all your hosts, you're
stuck with a variety of less than great possibilities.
One is a stunt rDNS server that synthesizes the records on demand.
(Bonus points for doing DNSSEC, too. Double bonus points for doing
NSEC3.) Another is instrumenting the routers so that when they notice
a new host on their network, they somehow send an update to the DNS
servers to install rDNS for that host.
If I had to guess, I would say that we'll eventually agree than on
IPv6 networks, mail servers and other hosts who have reputations that
matter will have fixed addresses assigned statically or via DHCP and
rDNS, random client hosts won't. Teeth will gnash at how this makes
some hosts second class and it violates the end to end principle, but
tough noogies.
R's,
John
>No point. address -> name -> address doesn't work with wildcards.
>
>> (Still an IPv6 implementation virgin, just curiousIf you want to do generic IPv6 rDNS for all your hosts, you're
stuck with a variety of less than great possibilities.One is a stunt rDNS server that synthesizes the records on demand.
(Bonus points for doing DNSSEC, too. Double bonus points for doing
NSEC3.)
NSEC3 is a waste of time in ip6.arpa or any similarly structured
zone so -1000000 for doing NEC3 and effectively doing a DoS attack
against yourself and the client resolvers.
One is a stunt rDNS server that synthesizes the records on demand.
(Bonus points for doing DNSSEC, too. Double bonus points for doing
NSEC3.)NSEC3 is a waste of time in ip6.arpa or any similarly structured
zone so -1000000 for doing NEC3 and effectively doing a DoS attack
against yourself and the client resolvers.
I know, but figuring out on the fly what order the hashes are would be quite a coding feat.
R's,
John
In message <alpine.BSF.2.00.1301100106560.55043@joyce.lan>, "John R. Levine" wr
ites:
>> One is a stunt rDNS server that synthesizes the records on demand.
>> (Bonus points for doing DNSSEC, too. Double bonus points for doing
>> NSEC3.)
>
> NSEC3 is a waste of time in ip6.arpa or any similarly structured
> zone so -1000000 for doing NEC3 and effectively doing a DoS attack
> against yourself and the client resolvers.I know, but figuring out on the fly what order the hashes are would
be quite a coding feat.
subtract labels until you have one which fits the namespace pattern.
that is the closest encloser <ce>. hash that name for the closest
encloser. hash <label>.<ce> add/subtact one for the second half
of the noqname proof. hash *.<ce> add/subtact one for the no
wildcard proof.
> Can you wildcard it?
No point. address -> name -> address doesn't work with wildcards.
OTOH, if the requirement is "must have PTR" and/or "organisation fwd
domain name should show up in PTR RDATA" then wildcards have a place. And
yes, BIND loads and answers, as expected.
*.4.4.3.0.5.a.0.0.8.b.d.0.1.0.0.2.ip6.arpa. PTR a.node.on.vlan344.namn.se.
...will work just fine, for instance. I did it for a 200+ segment LAN
party, couple years ago. And as is usual with wildcards, if you do need
to insert a real record, it will take over just as expected.
If you believe that BCP for your own servers is to have PTRs,
are you giving the caveat to your customers that they shouldn't
be running mail service without dealing with you for PTRs? Are
you accepting their mail without these PTRs?
That bit of customer service philosophy aside, two obvious
answers are wildcard (weak) or to hand the customers the keys
to their own fate (best). Just delegate to them. Hopefully you
are at least handing them addresses in clumps to make it less
annoying on your zone files.
Cheers,
Joe
This is (and has been) a best practice for most of a decade, ever since
the rise of the zombies. Real mail servers have matching A and PTR
records, and real (i.e., non-generic) FQDN hostnames. They also
HELO/EHLO with real, non-generic FQDN hostnames that resolve, and
which (preferably) match that in the A record. Everything else is
at best suspect and probably either (a) a zombie or (b) incompetently run.
Thus -- and these are examples seen in a local spamtrap in the last
few hours -- none of these should be permitted to even *attempt* to
deliver mail to real live addresses:
2.132.135.33 (no rdns)
37.44.121.227 (no rdns)
41.97.154.184 (no rdns)
41.191.104.24 (no rdns)
46.177.235.253 ppp046177235253.access.hol.gr
60.254.50.150 50.254.60.150.hathway.com
64.25.225.52 (no rdns)
74.7.101.50 (no rdns)
77.126.116.112 (no rdns)
79.180.105.90 bzq-79-180-105-90.red.bezeqint.net
80.232.221.197 (no rdns)
81.248.60.11 lcayenne-151-5-11.w81-248.abo.wanadoo.fr
85.30.103.215 (no rdns)
88.77.212.175 dslb-088-077-212-175.pools.arcor-ip.net
89.223.2.149 ip-149.2.223.89.net.unnet.ru
93.86.110.126 93-86-110-126.dynamic.isp.telekom.rs
95.140.197.66 host-95-140-197-66.customers.adc.am
110.49.235.132 (no rdns)
117.6.200.103 (no rdns)
117.212.210.190 (no rdns)
120.61.90.56 triband-mum-120.61.90.56.mtnl.net.in
122.163.226.123 abts-north-dynamic-123.226.163.122.airtelbroadband.in
122.166.232.127 abts-kk-static-127.232.166.122.airtelbroadband.in
123.24.97.69 dynamic.vdc.vn
123.24.198.246 (no rdns)
178.126.109.101 (no rdns)
190.66.167.111 (no rdns)
195.128.253.152 ip253-152.dl.uz.ua
200.56.5.180 200-56-5-180.dynamic.axtel.net
200.67.199.254 dsl-200-67-199-254-sta.prod-empresarial.com.mx
201.230.49.12 client-201.230.49.12.speedy.net.pe
206.55.180.8 (no rdns)
213.175.137.146 (no rdns)
220.227.74.69 (no rdns)
222.124.11.26 26.subnet222-124-11.astinet.telkom.net.id
222.253.178.173 localhost
---rsk
Because hitting things in memory is the only way we can ever respond to a data request.
This wording is about as excellent as those who've been quoted on record to say people wouldn't want TVs ("boxes of wood") in their living rooms, etc.
-J
What label would you suggest be used for PTR records in unassigned space?
If it is a standard best practice, why don't the RIRs do it for space
that they have not yet assigned?
Would this apply to IPv6 as well?
Unused space generally gets a $generate type generic scripted runs which
could be whatever, like ip-ad-dr-ess.example.com
Not rid unallocated space, not that there's much of it in v4
As for v6 how popular do you see it getting for mail?
Are you implying that when the internet otherwise moves on to IPv6, we'll
still inexplicably use IPv4 for mail?
Jima
RE: PTRs for IPv6, see
http://tools.ietf.org/html/draft-howard-isp-ip6rdns-05
I've had many excellent suggestions for updates to it, which I intend to
treat in the next couple of weeks. I don¹t cover PTRs for servers,
because I don't see a scalability problem.
However, I don't think I understand the conversation below. Pointers to
make me smarter?
Thanks,
Lee
IMHO mail is one of the easiest "first things" to turn on for IPv6. Nobody is going to really notice a 1s delay if they connect() and you're not listening on IPv6 but are on IPv4.
There are concerns from the spam/blacklist communities that IPv6 will make it too hard to roll-up spam information, so many enterprises will likely stick to IPv4 along the long-tail of deployment as it will nearly always work.
I also see lots of people with 2002: address in my mail-log relying on 6to4 gateways, e.g.:
puck:~$ host doors.huapi.net.ar
doors.huapi.net.ar has address 190.136.177.222
doors.huapi.net.ar has address 168.83.68.202
doors.huapi.net.ar has IPv6 address 2002:be88:b1de::1
puck:~$ host warner.fm
warner.fm has address 66.59.109.136
warner.fm has IPv6 address 2002:423b:6d88::1
warner.fm mail is handled by 10 argo.pyxos.net.
puck:~$ host x25.se.
x25.se has address 83.227.190.248
x25.se has IPv6 address 2002:53e3:bef8::1
x25.se mail is handled by 1 x25.se.
I suspect folks will run these sorts of gateways for some time..
- Jared
Some fixed string like "unassigned.<yourdomain>"? This would make it
obvious that something is wrong if ever it leaks out.
-- Matthias
Unused space generally gets a $generate type generic scripted runs which could be whatever, like ip-ad-dr-ess.example.com <http://ip-ad-dr-ess.example.com>
If the IP address hasn't been assigned to example.com, why would make a DNS entry that implies that it has?
Not rid unallocated space, not that there's much of it in v4
Why not?
As for v6 how popular do you see it getting for mail?
What does mail have to do with DNS policy for unassigned IP addresses?
ARGH, ok, enough with: They can have any policy they like, it's their
equipment and no one is being forced to use them.
That's tacit, I'd hope.
Doesn't mean people can't do dopey things well within their rights and
maybe sounding it out would give them some clue, or at least warn
others to stay away, tho I'd agree NANOG is probably not the right
venue.