> MacOS and Windows can both populate the reverse zone for you as can
> dhcp servers.
> The practice of filling out the reverse zone with fake PTR record [...]
OK.. let's say you're a DSL provider. Are you going to have your
DHCP server populating the forward and reverse DNS? With what, the
account holder's name? somename.example.com ?
With what the machine told you to populate it with. If the hostname
isn't specified in the request uses your default naming scheme.
Wouldn't you say blahblah192-168-0-2.city.state.dsl.example.com
provides more useful information?
No.
First of all, you know that the IP address is an end user, an access
network's end user's one IP address,
an endpoint, rather than a subnet assigned to an actual multinode network.
Is it? Even today with IPv4 you don't have to hand out single addresses
to customers.
Second of all, you know it's an ISP, and you have city and state
information of the network service.
This is more useful than arbitrary user made up hostname.
In your opinion. It may not be in the customer's opinion and they are
the ones leasing the address.
The hostname is more meaningful on "real networks" such as SMB LANs,
Enterprise intranets, web farms, server networks, and other places
where generic records should not be assigned, but the PTR should be
the actual hostname.
New flash. "real networks" already exist in homes. The only reason
they arn't visible outside the home is that ISP's have been
ridiculously slow in making IPv6 available to the homes and with that
the potential for directly address machines.
If the IP address is dynamic or autoconfigured for _those_ types of
networks, then yes, automatic RDNS registration makes sense. If it's
static, not so much.
Dynamic DNS registration is also complicated to make secure.... as
in preventing hosts from updating other hosts' records or mucking
around the zone in other unwanted ways requires complex key
management and ACL configuration
No. It's not really complicated to make secure. It's quite possible
to prevent machines muking up others records.
The practice of filling out the reverse zone with fake PTR record
started before there was wide spread support for UPDATE/DNS. There
isn't any need for this to be done anymore. Machines are capable
of adding records for themselves.
How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to
the end user. Should I delegate reverse DNS as well? If so, to whom?
Or is it the CPEs responibility to dynamically add records for whatever
addresses it sees on the internal LAN(s)? Are there CPEs capable of
doing this?
Or will the end systems themselves do the update against my DNS server?
If so, how do I authenticate that?
>> OK.. let's say you're a DSL provider. Are you going to have your
>> DHCP server populating the forward and reverse DNS? With what, the
>> account holder's name? somename.example.com ?
>
> I'll suggest that (a) IF the addresses do migrate among different customers
> of the ISP, (b) the addresses handed out are publicly routable, AND (c) the
> CPE has to 'authenticate' itself to the head-end, then it is _very_ useful
> *to*the*ISP* to have dynamically-assigned DNS records of the form:
> cust.{accountid}.{locationid}.ISP.{com/net/TLD}
> or something of the sort.
>
> Something of that sort can save a -lot- of time/effort in identifying the
> customer involved in a complaint.
Surely that's only useful if they're still allocated the address at the time
of investigating said complaint; a dynamically updating DNS record like thi
s is really no substitution for accurate accounting records in your RADIUS s
ystem.
You're missing some 'obvious' considerations. Consider a spam complaint
is present in the complaint. Yes, you need to confirm that -that- customer
was on that IP at that time -- but having an identifier for the customer
makes the verification check much quicker/simpler, and requires less skils
on the part of the front-line person dealing with the complaint.
No, it doesn't *always* provide a short-cut to identification, but it is
useful "often enough' to be well worth considering.
And if the rDNS isn't provided, any sane MTA will have included the IP address
and timestamp involved, which shouldn't take you all *that* much longer to
track down to one of your users.
I wouldn't take for granted that "IP address plus timestamp" can be
used to track down
a user after the fact. This is not always the case, plenty of times
it is not; the user may not be logged on anymore, and there might be
no historical data available, or the lifetime of the historical data
short enough, that it expired before the complaint came in, possibly
24 hours or more later. Especially not on shared LANs, where an
unruly user might actually select some random IP address and use it
without permission.
The RDNS will help in some of those cases if you don't keep/have
sufficient information to identify
a user by IP address, if your ability to create a mapping is
unreliable... for example,
you can't really be sure about accurate clock synchronization in the
timestamps of
the MTAs to any detail info you may have.
But even with RDNS there is still a matching problem... DNS records
have TTLs. The old mapping for an IP address can live in a cache for a
significant amount of time.
Sometimes unruly DNS servers or unruly applications fail to correctly
implement DNS, and wind up holding a record past its TTL... an "old
PTR mapping" for the IP address may be reported in message headers.
The result can be a previous customer's ID in such a scheme would
appear in the complaint.
Now I suppose you could include another piece of info in the reverse record
<custid>.registeredat<timestamp>.checksum
And then if the purported timestamp in the complaint is after the
'next DNS record registration time' + TTL
you know that the RDNS on the complaint listed is invalid
To maintain integrity in that case... you would need to ensure the IP
address could not be recycled to another user before all DNS records
cached at the logoff time + DNS registration interval expired.
> The practice of filling out the reverse zone with fake PTR record
> started before there was wide spread support for UPDATE/DNS. There
> isn't any need for this to be done anymore. Machines are capable
> of adding records for themselves.
How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to
the end user. Should I delegate reverse DNS as well? If so, to whom?
Or is it the CPEs responibility to dynamically add records for whatever
addresses it sees on the internal LAN(s)? Are there CPEs capable of
doing this?
Or will the end systems themselves do the update against my DNS server?
If so, how do I authenticate that?
With my ISP hat on, I find the idea of customer CPEs updating their
own PTR records to be completely unacceptable. So I guess I'll either
live without the reverse DNS, or use a name server that can synthesize
answers on the fly.
I have been experiencing this same issue as an end user, my ISP does not
provide PTR records for their address pools. YouTube, xkcd, Mozilla.org,
among others, are slow to load initially. Coming from AS15146 here.
Indeed, there is no way I would allow that either. But really, providing a reverse zone and forward zone to match is a case of five minutes and a shell script or a DNS that as Steinar said, will synthesise results.
Indeed, there is no way I would allow that either. But really,
providing a reverse zone and forward zone to match is a case of five
minutes and a shell script or a DNS that as Steinar said, will
synthesise results.
It's really not all that difficult..
No, not at all. It's just totally pointless. Any IPv6 address is just
as pretty as a synthesized name. Maybe even prettier. Do you prefer
"2001:db8:1::2" or "20010db8000100000000000000000002.rev.example.com"?
If we're going to provide any reverse DNS for end users, then it is
because we can create names which actually improves something.
Yup it is pointless.. Mine are all ipadrress.domain which is of course, pointless.. I suppose at least somebody would glean that perhaps its a home user rather than a business or server on that address but that's all.
With IPv6 arguably even more pointless as you say.
That seems like a really nice feature, create a reverse record to spoof
a mail server and the reverse DNS will match up.
If the domain does not employ SPF it will look legit, forward and
reverse won't match up ofcourse. Not sure how many mailservers have
issues with that if the reverse matches up.
>>> The practice of filling out the reverse zone with fake PTR record
>>> started before there was wide spread support for UPDATE/DNS. There
>>> isn't any need for this to be done anymore. Machines are capable
>>> of adding records for themselves.
>>
>> How do I setup this for DHCPv6-PD? Say, I delegate 2001:db8:42::/48 to
>> the end user. Should I delegate reverse DNS as well? If so, to whom?
>>
>> Or is it the CPEs responibility to dynamically add records for whatever
>> addresses it sees on the internal LAN(s)? Are there CPEs capable of
>> doing this?
>>
>> Or will the end systems themselves do the update against my DNS server?
>> If so, how do I authenticate that?
>
> With my ISP hat on, I find the idea of customer CPEs updating their
> own PTR records to be completely unacceptable. So I guess I'll either
> live without the reverse DNS, or use a name server that can synthesize
> answers on the fly.
That seems like a really nice feature, create a reverse record to spoof
a mail server and the reverse DNS will match up.
If the domain does not employ SPF it will look legit, forward and
reverse won't match up ofcourse. Not sure how many mailservers have
issues with that if the reverse matches up.
Sounds like a fine way to employ a spam botnet.
Sounds like FUD. Who has trusted the contents of a PTR record in the
last 2 decades?
Sounds like FUD. Who has trusted the contents of a PTR record in the
last 2 decades?
Lots of tools (read: SSH, Spam-checks, oh and IRCd's trust PTR, but
only if the reverse => forward => reverse. And you don't want to know
how many silly people enable the "if user comes from .in they must be
from Indonesia^WIndia thus block them" Apache option as recently
mentioned on this very thread.
Also, note that your precious operating system will likely store the
PTR, sometimes even without doing the reverse->forward->reverse check.
As such, you set up a PTR + Forward properly for a host, try to 'hack' a
box by password guessing, the log entries will only have the PTR
recorded, and you just drop the PTR+Forward from DNS (as they are under
your control) the admin comes in, sees all those nice hosts in their
logs but as it is gone from DNS will never ever find you. This
especially goes for 'who' (utmp) which makes that mistake. Fortunately
SSH at least logs both IP + hostname, the more info the better.
That said though the PTR->forward->PTR check is a proper check and a
really great way to figure out if the source SMTP host was actually set
up with at least some admin doing it the right way. If they can't be
bothered to set that up, why should you bother to accept that mail, or a
better choice, just score it a bit negatively at least.
[..]
> Sounds like FUD. Who has trusted the contents of a PTR record in the
> last 2 decades?
Lots of tools (read: SSH, Spam-checks, oh and IRCd's trust PTR, but
only if the reverse => forward => reverse. And you don't want to know
how many silly people enable the "if user comes from .in they must be
from Indonesia^WIndia thus block them" Apache option as recently
mentioned on this very thread.
They arn't trusting the reverse record. They are trusting the forward
record to verify the reverse record. They know that the reverse record
is untrustworthy as the owner of the reverse zone can put whatever they
want there without spoofing anything.
Also, note that your precious operating system will likely store the
PTR, sometimes even without doing the reverse->forward->reverse check.
As such, you set up a PTR + Forward properly for a host, try to 'hack' a
box by password guessing, the log entries will only have the PTR
recorded, and you just drop the PTR+Forward from DNS (as they are under
your control) the admin comes in, sees all those nice hosts in their
logs but as it is gone from DNS will never ever find you. This
especially goes for 'who' (utmp) which makes that mistake. Fortunately
SSH at least logs both IP + hostname, the more info the better.
Who trusts logs of names without actual addresses? No one sane
does.
That said though the PTR->forward->PTR check is a proper check and a
really great way to figure out if the source SMTP host was actually set
up with at least some admin doing it the right way. If they can't be
bothered to set that up, why should you bother to accept that mail, or a
better choice, just score it a bit negatively at least.
Which only works as a filter because ISP's decided to prevent home
users from putting valid PTR records in the DNS for their own
machines. It has nothing to do with clue or knowlege.
Sounds like FUD. Who has trusted the contents of a PTR record in the
last 2 decades?
Lots of tools (read: SSH, Spam-checks, oh and IRCd's trust PTR, but
only if the reverse => forward => reverse. And you don't want to know
how many silly people enable the "if user comes from .in they must be
from Indonesia^WIndia thus block them" Apache option as recently
mentioned on this very thread.
They arn't trusting the reverse record. They are trusting the forward
record to verify the reverse record. They know that the reverse record
is untrustworthy as the owner of the reverse zone can put whatever they
want there without spoofing anything.
Of course that is the case. The PTR itself is useless, but in combo with
checking it with the forward it is a very valuable resource.
(Add DNSSEC to the mix and you are even sure that nobody spoofed it on
the wire for you
Also, note that your precious operating system will likely store the
PTR, sometimes even without doing the reverse->forward->reverse check.
As such, you set up a PTR + Forward properly for a host, try to 'hack' a
box by password guessing, the log entries will only have the PTR
recorded, and you just drop the PTR+Forward from DNS (as they are under
your control) the admin comes in, sees all those nice hosts in their
logs but as it is gone from DNS will never ever find you. This
especially goes for 'who' (utmp) which makes that mistake. Fortunately
SSH at least logs both IP + hostname, the more info the better.
Who trusts logs of names without actual addresses? No one sane
does.
Well, only one decade back some people from this very list mentioned
that to a certain OS that is used quite a lot by a lot of people:
Note there is just ut_host there is no address being stored, I hope you
yourself btw don't use any FreeBSD based devices as otherwise that
little attempt at an insult goes for you too
That said though the PTR->forward->PTR check is a proper check and a
really great way to figure out if the source SMTP host was actually set
up with at least some admin doing it the right way. If they can't be
bothered to set that up, why should you bother to accept that mail, or a
better choice, just score it a bit negatively at least.
Which only works as a filter because ISP's decided to prevent home
users from putting valid PTR records in the DNS for their own
machines. It has nothing to do with clue or knowlege.
I don't think ISPs 'decide' to not let users set up reverse DNS, it is
generally a 'feature' for which they can ask more moneyz.
If ISPs would allow it (which I am for btw) then they only pass the test
anyway if they can properly setup reverse->forward->reverse.
Which is likely the case anyway for quite some ISPs who populate
reverses with a matching forward&reverse based on the IP.
> That said though the PTR->forward->PTR check is a proper check and a
> really great way to figure out if the source SMTP host was actually set
> up with at least some admin doing it the right way. If they can't be
> bothered to set that up, why should you bother to accept that mail, or a
> better choice, just score it a bit negatively at least.
Which only works as a filter because ISP's decided to prevent home
users from putting valid PTR records in the DNS for their own
machines. It has nothing to do with clue or knowlege.
Some do but some don't. I seem to remember a very nice little web interface for setting reverse DNS when I used xs4all's service in the Netherlands.
But many do. As I said the ability to set up PTR records has
*nothing* to do with the clue level of the administrator. It has
everything to do with what the ISP will let you do.
Larry Blunk wrote the following on 11/3/2011 12:47 PM:
I work for a regional ISP and very recently there has been an influx of
calls reporting "slowness" when accessing certain websites (i.e
google.com/voice/b) via HTTP. After performing a tcpdump and analyzing the
session, I have been able to pinpoint the latency at the application
layer. After the tcp session has been established, it takes up to 15-20
seconds before the application begins sending data. The root of the
problem was that the PTR record for our customer(s) address does not
exist. As soon as the record is created, latency from the application is
eliminated. This is analogous to latency when accessing a server over SSH
when no PTR is available.
A seperate packet capture from another customer exhibiting similar
performance behavior showed many TCP retransmissions. At first glance, I
assumed this was network related however this correlates with the
application not responding and inducing retransmissions at the TCP layer
(different symptoms, same problem).
Historically, there was no compelling reason to create PTR records for our
CPE however more and more applications seem to be dependent on it.
Although we will be assigning a record for each address, my question is why
is the application (specifically HTTP) dependent on a reverse record ?
What is the purpose?
Hope this is helpful as well
We recently encountered a similar issue with a customer.
The sites that had slowness issues were configured to
use the traditional Google Analytics javascript instead
of the newer asynchronous code.
The problem was not the lack of a PTR record, but rather
the in-addr delegation was pointing to lame servers that were
no longer responding (hence the long timeouts as the
Google servers attempted to perform reverse lookups
on the client IP's). As others have pointed out, as long
as there's a valid nameserver responding, a lack of PTR
record would not cause issues as an NXDOMAIN record would
be sent back immediately and the Google Analytics server
will move on.
-Larry Blunk
Merit
Larry, you're absolutely correct. One has to wonder what the continued debate is about. The Op likely had a DNS loop, misconfiguration, or lame servers. Correcting that issue should resolve any "slowness". The issue then is whether the application requires a valid PTR (or subsequent matching forward record) such as SMTP.
BTW, ARIN requires valid IN-ADDR.ARPA domain records. The specific record may be NXDOMAIN (non-existant), but the server cannot be lame - https://www.arin.net/participate/policy/nrpm/
I believe just about all of us on this list have agreed to this policy. However, my experience tells me that many people choose to ignore it. This thread is evidence of such.
trust PTR, but