Re: Performance Issues - PTR Records
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
Re: Performance Issues - PTR Records
In message <41f6c547ea49ec46b4ee1eb2bc2f341849f82d4...@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: ma...@isc.org
RE: Performance Issues - PTR Records
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
Re: Performance Issues - PTR Records
On 2011-11-08 13:27 , Mark Andrews wrote: > In message <4eb90ef2.3030...@unfix.org>, Jeroen Massar writes: >> On 2011-11-08 12:05 , Mark Andrews wrote: >>> In message <4eb8f028.8040...@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
Re: Performance Issues - PTR Records
In message <4eb90ef2.3030...@unfix.org>, Jeroen Massar writes: > On 2011-11-08 12:05 , Mark Andrews wrote: > > In message <4eb8f028.8040...@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: ma...@isc.org
Re: Performance Issues - PTR Records
On 2011-11-08 12:05 , Mark Andrews wrote: > In message <4eb8f028.8040...@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
Re: Performance Issues - PTR Records
On Tue, Nov 08, 2011 at 10:05:12PM +1100, Mark Andrews wrote: > > In message <4eb8f028.8040...@dds.nl>, Seth Mos writes: > > On 7-11-2011 14:46, sth...@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: ma...@isc.org the same people who trust the contents of an A record in the last 2 decades. /bill
Re: Performance Issues - PTR Records
In message <4eb8f028.8040...@dds.nl>, Seth Mos writes: > On 7-11-2011 14:46, sth...@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: ma...@isc.org
Re: Performance Issues - PTR Records
On 7-11-2011 14:46, sth...@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
Re: Performance Issues - PTR Records
On 7 Nov 2011, at 14:03, "Bjørn Mork" wrote: > Leigh Porter 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 "20010db800010002.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 __
Re: Performance Issues - PTR Records
Leigh Porter 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 "20010db800010002.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
Re: Performance Issues - PTR Records
On 7 Nov 2011, at 13:48, "sth...@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, sth...@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 __
Re: Performance Issues - PTR 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? 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, sth...@nethelp.no
Re: Performance Issues - PTR Records
On 2 November 2011 17:57, 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. *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.
Re: Performance Issues - PTR Records
On Mon, Nov 7, 2011 at 1:34 AM, wrote: > 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. 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 .registeredat.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
Re: Performance Issues - PTR Records
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. pgpXmxHkIWeGT.pgp Description: PGP signature
Re: Performance Issues - PTR Records
Tom Lanyon 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.
Re: Performance Issues - PTR Records
Mark Andrews 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
Re: Performance Issues - PTR Records
On Nov 6, 2011, at 6:57 PM, Jimmy Hess wrote: > On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews 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.
Re: Performance Issues - PTR Records
In message , Jimmy Hess writes: > On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews 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 sayblahblah192-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: ma...@isc.org
Re: Performance Issues - PTR Records
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
Re: Performance Issues - PTR Records
Once upon a time, Robert Bonomi 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
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
Re: Performance Issues - PTR Records
> From nanog-bounces+bonomi=mail.r-bonomi@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
> To: Mark Andrews
> Cc: nanog@nanog.org
>
> On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews 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.
Re: Performance Issues - PTR Records
On Sun, Nov 6, 2011 at 7:10 PM, Mark Andrews 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 sayblahblah192-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
Re: Performance Issues - PTR Records
In message , 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/ 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: ma...@isc.org
Re: Performance Issues - PTR Records
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
Re: Performance Issues - PTR Records
- Original Message - > From: "Jimmy Hess" > 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 j...@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
Re: Performance Issues - PTR Records
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.
Re: Performance Issues - PTR Records
On Fri, Nov 4, 2011 at 11:28 AM, Paul Ebersman 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
Re: Performance Issues - PTR Records
> 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.
Re: Performance Issues - PTR Records
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.
Re: Performance Issues - PTR Records
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
Re: Performance Issues - PTR Records
On Wed, Nov 2, 2011 at 8:33 PM, Larry Smith 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
Re: Performance Issues - PTR Records
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 lesm...@ecsis.net
Re: Performance Issues - PTR Records
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 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? >
Re: Performance Issues - PTR Records
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?
Re: Performance Issues - PTR Records
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 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 > > >
Re: Performance Issues - PTR Records
On Wed, Nov 2, 2011 at 6:08 PM, Barry Shein wrote: > Another practical problem with this approach is that .IN is India but > hey, at least it blocks something :-) There are also some services out there that block connections entirely, if the user doesn't have a PTR record. I'm thinking IRC servers, MUDs, and some other services with strange security policies that check for a port 113 IDENT response and RDNS to make a dark magic security decision to block a user who has no PTR. But in the modern world... more commonly, MTAs such as sendmail are often configured to require a valid PTR record. So as an ISP, you may be breaking your user's local MTA if you don't have the correct PTR for their IP addresses. So I would say following the RFCs and implementing the proper PTRs will help with that performance issue as a side-effect of having a valid zone, and head off other issues with possibly less popular services that are still blocking connections based on lack of proper PTR. :) > -- > -Barry Shein, that'd be .ID for Indonesia -- -JH
Re: Performance Issues - PTR Records
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
RE: Performance Issues - PTR Records
> As a web host, we frequently find customers who have > added Apache rules to their ecommerce sites to block > undesirable traffic, such as credit card scammers, etc. > Not knowing any better, they often do this by just > blocking anything that ends in .in to block Indonesia > for example. Well, once you choose to block by > resolved name, now that site has to do a dns lookup > for every incoming request to see if it resolves to a > name that should be blocked. Another practical problem with this approach is that .IN is India but hey, at least it blocks something :-) -- -Barry Shein, that'd be .ID for Indonesia The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool & Die| Public Access Internet | SINCE 1989 *oo*
RE: Performance Issues - PTR Records
From: Matthew Palmer [mailto:mpal...@hezmatt.org] > > That's even less effective than you'd naively expect, given > that Indonesia's > TLD is .id... > Umm yeah, simple typo, but I appreciate the help.
Re: Performance Issues - PTR Records
On Wed, Nov 02, 2011 at 06:12:21PM -0400, David Hubbard wrote: > From: Matt Chung [mailto:itsmemattch...@gmail.com] > > 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? > > As a web host, we frequently find customers who have > added Apache rules to their ecommerce sites to block > undesirable traffic, such as credit card scammers, etc. > Not knowing any better, they often do this by just > blocking anything that ends in .in to block Indonesia > for example. That's even less effective than you'd naively expect, given that Indonesia's TLD is .id... - Matt
RE: Performance Issues - PTR Records
From: Matt Chung [mailto:itsmemattch...@gmail.com] > > 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? > As a web host, we frequently find customers who have added Apache rules to their ecommerce sites to block undesirable traffic, such as credit card scammers, etc. Not knowing any better, they often do this by just blocking anything that ends in .in to block Indonesia for example. Well, once you choose to block by resolved name, now that site has to do a dns lookup for every incoming request to see if it resolves to a name that should be blocked. Just one example, but I'm sure there are countless others that also impede performance for IP addresses without a PTR record. David
Re: Performance Issues - PTR Records
On 11/2/2011 2:57 PM, Matt Chung wrote: 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 <>
