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 -- -Matt Chung
On 11/2/2011 2:57 PM, Matt Chung wrote:
<snip!> 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?
HTTP has no requirement that the connecting client have reverse DNS setup. Some servers have reverse lookups enabled, and some of those undoubtedly block until the record has been retrieved or all avenues of discovery have been exhausted... and this is likely where the issue exists. As to why the server or the script/application its running needs the record, you'd have to ask the developer. -- Jeff Walter Network Engineer Hurricane Electric, AS6939
On Nov 2, 2011, at 5:57 PM, Matt Chung wrote:
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?
You're returning NXDOMAIN, right? If they're doing a reverse lookup and you return NXDOMAIN it should fail quickly, or else the application is even more horribly broken than just doing reverse lookups would imply. On the other hand, if you're not responding to the PTR request then that could be causing the timeout. -Ben
What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue. It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock. On Wed, Nov 2, 2011 at 5:19 PM, Ben Jencks <ben@bjencks.net> wrote:
On Nov 2, 2011, at 5:57 PM, Matt Chung wrote:
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?
You're returning NXDOMAIN, right? If they're doing a reverse lookup and you return NXDOMAIN it should fail quickly, or else the application is even more horribly broken than just doing reverse lookups would imply. On the other hand, if you're not responding to the PTR request then that could be causing the timeout.
-Ben
PC wrote:
What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue.
It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock.
I think that returns SERVFAIL somewhere down the line? Does it make sense to reinforce the behaviour (good and bad terms left for another time), while looking forward to v6?
We really have no objections to creating records for our IPs however there was no compelling reason previously. With the manifestation of performance issues, we are currently creating a generic record for our addresses. I assumed that the applications would take absent records into consideration instead of waiting and timing out before responding with data. Trying to troubleshoot this issue from the limited visibility is difficult ; the latency the application is introducing is abstracted (unless I am unaware of that troubleshooting technique). Sent from my iPhone On Nov 2, 2011, at 5:58 PM, J <nanog@namor.ca> wrote:
PC wrote:
What happens if the ISP never defines a name server with their RIR for their provider-independent address space? Does ARIN point to somewhere which supplies NXDOMAIN? Just a thought -- I don't have a clue.
It is entirely possible they have it pointed to their non-existent or broken DNS. Given current best practices, I see no reason not to assign a generic x.x.x.x-dynamic.customer.isp.com DNS across their netblock.
I think that returns SERVFAIL somewhere down the line?
Does it make sense to reinforce the behaviour (good and bad terms left for another time), while looking forward to v6?
On Wed November 2 2011 20:27, Matt Chung wrote:
I assumed that the applications would take absent records into consideration instead of waiting and timing out before responding with data. Trying to troubleshoot this issue from the limited visibility is difficult ; the latency the application is introducing is abstracted (unless I am unaware of that troubleshooting technique).
When you mis-place your keys do you only look in one place and then give up? The calling server does not know there is "no" record until it exhausts its list of DNS servers, which is probably what is introducing the delay you are seeing (each server trying to find a PTR with each of its upsteams) until they all time out... -- Larry Smith lesmith@ecsis.net
On Wed, Nov 2, 2011 at 8:33 PM, Larry Smith <lesmith@ecsis.net> wrote:
On Wed November 2 2011 20:27, Matt Chung wrote:
I assumed that the applications would take absent records into When you mis-place your keys do you only look in one place and then give up? The calling server does not know there is "no" record until it exhausts
If the reverse zone is properly configured, but just the PTR record is missing, you get NXDOMAIN, which is not "you mis-place your keys"; it's "someone told you authoritatively that your keys don't exist", never existed or no longer existed. If you ask where your key ring went, and Frodo Baggins informs you that it doesn't exist, because it was tossed down into a pool of magma on mount doom, and you trust his reply, you stop looking for it. The only way you don't trust a valid DNS reply is if you are implementing DNSSEC, and the "authoritative proof of non-existence" doesn't validate -- -JH
paul4004> It is entirely possible they have it pointed to their paul4004> non-existent or broken DNS. Given current best practices, I paul4004> see no reason not to assign a generic paul4004> x.x.x.x-dynamic.customer.isp.com DNS across their netblock. It's already been pointed out that lame delegations are more likely problems for many. But the "we'll just pre-fill in-addr to avoid problems" isn't going to work for ip6.arpa. If anyone has enough hardware to serve the zone for a /48 (64k * 4bil * 4bil * bytes-in-record), I'd love to see it. :) We need to get web and app folks to stop counting on ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some sense for validating servers, MTAs, etc. and it's handy for traceroute but it was never a great tool and it's getting less useful with time.
It's already been pointed out that lame delegations are more likely problems for many. But the "we'll just pre-fill in-addr to avoid problems" isn't going to work for ip6.arpa. If anyone has enough hardware to serve the zone for a /48 (64k * 4bil * 4bil * bytes-in-record), I'd love to see it. :)
If PTR exists in zone file, serve it. Else, synthesize generic reverse. Jobsagoodun.
We need to get web and app folks to stop counting on ip6.arpa/in-addr.arpa as a validation of trustworthiness. PTR make some sense for validating servers, MTAs, etc. and it's handy for traceroute but it was never a great tool and it's getting less useful with time.
I've always seen it as a reasonable indication of a) minimum level of clue and b) giving a damn. If you can't be bothered or don't know how to provide even basic generic rDNS for your network, there's a reasonable chance you're lacking in other areas of network / user management. (Not "you" personally, of course). Regards, Tim.
tim> If PTR exists in zone file, serve it. Else, synthesize generic tim> reverse. Jobsagoodun. If all we're doing is lying with some generic answer that we hack our server to produce, why are we bothering? At that point, you're not proving clue. You're proving you at least bought a solution from someone with a clue... My contention is that (at least for end hosts), PTR records are mostly pointless and just overhead for DNS servers.
On 05/11/2011, at 1:14 PM, Paul Ebersman wrote:
tim> If PTR exists in zone file, serve it. Else, synthesize generic tim> reverse. Jobsagoodun.
If all we're doing is lying with some generic answer that we hack our server to produce, why are we bothering?
Because some applications rely on it working (for some definition of "working").
My contention is that (at least for end hosts), PTR records are mostly pointless and just overhead for DNS servers.
If you haven't set up PTR records for your end hosts, realistically you're going to be serving NXDOMAINs for them anyway, so there's not really any overhead introduced by supplying something generic instead... Tom
In message <FA83E0C6-DAFC-4C8C-AF46-826EDF4727F8@oneshoeco.com>, Tom Lanyon wri tes:
On 05/11/2011, at 1:14 PM, Paul Ebersman wrote:
tim> If PTR exists in zone file, serve it. Else, synthesize generic tim> reverse. Jobsagoodun. =20 If all we're doing is lying with some generic answer that we hack our server to produce, why are we bothering?
Because some applications rely on it working (for some definition of = "working").
My contention is that (at least for end hosts), PTR records are mostly pointless and just overhead for DNS servers.
If you haven't set up PTR records for your end hosts, realistically = you're going to be serving NXDOMAINs for them anyway, so there's not = really any overhead introduced by supplying something generic instead...
Tom
Except you also have to supply the A/AAAA records as well. 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 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. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka@isc.org> wrote:
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 ? Wouldn't you say blahblah192-168-0-2.city.state.dsl.example.com provides more useful information? 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. 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. 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. 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
-- Mark Andrews, ISC
-- -JH
From nanog-bounces+bonomi=mail.r-bonomi.com@nanog.org Sun Nov 6 19:58:58 2011 Date: Sun, 6 Nov 2011 19:57:51 -0600 Subject: Re: Performance Issues - PTR Records From: Jimmy Hess <mysidia@gmail.com> To: Mark Andrews <marka@isc.org> Cc: nanog@nanog.org
On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka@isc.org> wrote:
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 ?
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.
Once upon a time, Robert Bonomi <bonomi@mail.r-bonomi.com> said:
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.
Putting a customer ID in reverse DNS would probably be a violation of privacy policies. -- Chris Adams <cmadams@hiwaay.net> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
On 07/11/2011, at 12:46 PM, Robert Bonomi wrote:
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 this is really no substitution for accurate accounting records in your RADIUS system. Tom
Tom Lanyon <tom+nanog@oneshoeco.com> opined:
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 sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_ 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.
On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said:
You're missing some 'obvious' considerations. Consider a spam complaint sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_ is present in the complaint.
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.
On Mon, Nov 7, 2011 at 1:34 AM, <Valdis.Kletnieks@vt.edu> wrote:
You're missing some 'obvious' considerations. Consider a spam complaint sent with 'full headers' included. The rDNS _at_the_time_of_the_crime_ is present in the complaint. 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
On Mon, 07 Nov 2011 01:09:19 CST, Robert Bonomi said: 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. -- -JH
In message <CAAAwwbX3-LNd8hRCYwdBGhCamBwjqT6u9Xygf08GmO+RRNJjuA@mail.gmail.com> , Jimmy Hess writes:
On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka@isc.org> wrote:
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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Nov 6, 2011, at 6:57 PM, Jimmy Hess wrote:
On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews <marka@isc.org> wrote:
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 ?
Is this discussion seriously happening, again? Really? I don't think it's been 2 full months since the last round.
Mark Andrews <marka@isc.org> writes:
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? Bjørn
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. Steinar Haug, Nethelp consulting, sthaug@nethelp.no
On 7 Nov 2011, at 13:48, "sthaug@nethelp.no" <sthaug@nethelp.no> wrote:
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.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
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.. -- Leigh Porter ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
Leigh Porter <leigh.porter@ukbroadband.com> writes:
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. Bjørn
On 7 Nov 2011, at 14:03, "Bjørn Mork" <bjorn@mork.no> wrote:
Leigh Porter <leigh.porter@ukbroadband.com> writes:
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.
Bjørn
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. ______________________________________________________________________ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email ______________________________________________________________________
On 7-11-2011 14:46, sthaug@nethelp.no wrote:
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. Regards, Seth
In message <4EB8F028.8040607@dds.nl>, Seth Mos writes:
On 7-11-2011 14:46, sthaug@nethelp.no wrote:
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?
Regards,
Seth -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Tue, Nov 08, 2011 at 10:05:12PM +1100, Mark Andrews wrote:
In message <4EB8F028.8040607@dds.nl>, Seth Mos writes:
On 7-11-2011 14:46, sthaug@nethelp.no wrote:
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?
Regards,
Seth -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
the same people who trust the contents of an A record in the last 2 decades. /bill
On 2011-11-08 12:05 , Mark Andrews wrote:
In message <4EB8F028.8040607@dds.nl>, Seth Mos writes: [..] 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. Greets, Jeroen
In message <4EB90EF2.3030100@unfix.org>, Jeroen Massar writes:
On 2011-11-08 12:05 , Mark Andrews wrote:
In message <4EB8F028.8040607@dds.nl>, Seth Mos writes: [..] 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.
Greets, Jeroen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 2011-11-08 13:27 , Mark Andrews wrote:
In message <4EB90EF2.3030100@unfix.org>, Jeroen Massar writes:
On 2011-11-08 12:05 , Mark Andrews wrote:
In message <4EB8F028.8040607@dds.nl>, Seth Mos writes: [..] 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: http://www.freebsd.org/cgi/query-pr.cgi?pr=22595 And today that is still the case: http://www.freebsd.org/cgi/man.cgi?query=utmp&sektion=5 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. Greets, Jeroen
Mark Andrew wrote: [...]
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. Regards, Leo
In message <41F6C547EA49EC46B4EE1EB2BC2F341849F82D4BE8@EXVPMBX100-1.exc.icann.o rg>, Leo Vegoda writes:
Mark Andrew wrote:
[...]
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. =20 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. =20
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.=20
Regards,
Leo
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. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Fri, Nov 4, 2011 at 11:28 AM, Paul Ebersman <list-nanog2@dragon.net> wrote:
It's already been pointed out that lame delegations are more likely problems for many. But the "we'll just pre-fill in-addr to avoid problems" isn't going to work for ip6.arpa. If anyone has enough hardware to serve the zone for a /48 (64k * 4bil * 4bil * bytes-in-record), I'd love to see it. :) [snip] I can serve the zone for a /48 by creating a "sparse" zone. That is... when you ask my DNS server what such and such PTR reverses too, what I don't have a DNS entry for, it can tell you something generic.
There is no need for me to physically create 64k*4bil*4bil on a disk or memory area somewhere. I can make a plugin for my DNS server to hand you the generic result when you ask my DNS server what something reverses to... That is, I can serve you an ephemeral record without requiring an extra byte of storage beyond the life of your query :) -- -JH
----- Original Message -----
From: "Jimmy Hess" <mysidia@gmail.com>
There is no need for me to physically create 64k*4bil*4bil on a disk or memory area somewhere. I can make a plugin for my DNS server to hand you the generic result when you ask my DNS server what something reverses to...
That is, I can serve you an ephemeral record without requiring an extra byte of storage beyond the life of your query :)
This is precisely the approach taken by the DNS server package written by the tech folks at the late, lamented MindSpring -- the name of which eludes me for the moment. Cheers, -- jra -- Jay R. Ashworth Baylink jra@baylink.com Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com 2000 Land Rover DII St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274
On 11/02/2011 05:57 PM, Matt Chung wrote:
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 Blunk wrote the following on 11/3/2011 12:47 PM:
On 11/02/2011 05:57 PM, Matt Chung wrote:
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/policy/nrpm.html#seven1 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. --Blake
On 2 November 2011 17:57, Matt Chung <itsmemattchung@gmail.com> wrote:
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. *snip*
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.
participants (26)
-
Ben Jencks -
Bjørn Mork -
Blake Hudson -
bmanning＠vacation.karoshi.com -
Brett Watson -
Chris Adams -
J -
Jay Ashworth -
Jeff Walter -
Jeremy Parr -
Jeroen Massar -
Jimmy Hess -
Larry Blunk -
Larry Smith -
Leigh Porter -
Leo Vegoda -
Mark Andrews -
Matt Chung -
Paul Ebersman -
PC -
Robert Bonomi -
Seth Mos -
sthaug＠nethelp.no -
Tim Franklin -
Tom Lanyon -
Valdis.Kletnieks＠vt.edu