Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
I believe business customers (with a static assignment) can request reverse DNS entries. Residential customers are not guaranteed a static assignment, so they can't get reverse set. -- Chris Adams <cma@cmadams.net>
On Wed, 9 Oct 2013 11:41:50 -0500 Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
I believe business customers (with a static assignment) can request reverse DNS entries. Residential customers are not guaranteed a static assignment, so they can't get reverse set.
-- Chris Adams <cma@cmadams.net>
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space? Robert
Once upon a time, Robert Webb <rwebb@ropeguru.com> said:
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space?
Oh, are you looking for auto-generated reverse for every address? That's not going to happen for IPv6 (and it turns out that it wasn't really a good idea for IPv4). There's no reason to have reverse DNS unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all that useful. -- Chris Adams <cma@cmadams.net>
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/9/2013 9:49 AM, Chris Adams wrote:
Once upon a time, Robert Webb <rwebb@ropeguru.com> said:
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space?
Oh, are you looking for auto-generated reverse for every address? That's not going to happen for IPv6 (and it turns out that it wasn't really a good idea for IPv4). There's no reason to have reverse DNS unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all that useful.
That's not necessarily true -- some (very large) organizations using DMARC will reject mail from hosts without a PTR record. - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSVYuKq1pz9mNUZTMRAo5dAKCCuFYjseatheC9upjRRgkzcFJ5LwCfUhhd Krgz0IA6e5dbllo8NgXbzV0= =mehI -----END PGP SIGNATURE----- -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com
Once upon a time, Paul Ferguson <fergdawgster@mykolab.com> said:
That's not necessarily true -- some (very large) organizations using DMARC will reject mail from hosts without a PTR record.
And that's a good reason to have reverse records for you mail servers. Auto-generated reverse really shouldn't be trusted for anything. -- Chris Adams <cma@cmadams.net>
On 10/9/13 12:59 PM, "Paul Ferguson" <fergdawgster@mykolab.com> wrote:
That's not necessarily true -- some (very large) organizations using DMARC will reject mail from hosts without a PTR record.
True, but a residential customer with a cable modem bootfile that blocks port 25 wouldn't find that an issue. Jason
True, but the location information, at least the state, is quasi-helpful. You may be right about PTR being a mistake, but I guess my mind approaches it from a practical, quasi-GeoIP approach. IPv6 seems to be somewhat chaotic in that realm. Plus, with web applications and services, accurate GeoIP has implications for security. On Wed, Oct 9, 2013 at 11:49 AM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Robert Webb <rwebb@ropeguru.com> said:
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space?
Oh, are you looking for auto-generated reverse for every address? That's not going to happen for IPv6 (and it turns out that it wasn't really a good idea for IPv4). There's no reason to have reverse DNS unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all that useful.
-- Chris Adams <cma@cmadams.net>
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
True, but the location information, at least the state, is quasi-helpful.
That's another good reason to have reverse records for defined router interfaces. Auto-generated reverse for eveything doesn't give any useful info though. -- Chris Adams <cma@cmadams.net>
On 2013-10-09, at 10:10, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
True, but the location information, at least the state, is quasi-helpful.
That's another good reason to have reverse records for defined router interfaces. Auto-generated reverse for eveything doesn't give any useful info though.
If people really want to use generic reverse names and have realised that the v6 address space is much too big for $GENERATE, one approach is to delegate the appropriate zones to a custom nameserver that can auto-generate PTRs on demand. There are scaling problems here, but probably nothing that can't be fixed with high TTLs and multiple nameservers. If I was doing that, my instinct would be to code against Ray Bellis' evldns (see <http://code.google.com/p/evldns/>). Note that I'm not suggesting that auto-generated v6 PTRs (or v4 PTRs) are a good idea. But I'm aware that a lack of reverse DNS on either protocol can make the helpdesk phone ring, so there is certainly a pragmatic argument in favour of it. Joe
If people really want to use generic reverse names and have realised that the v6 address space is much too big for $GENERATE, one approach is to delegate the appropriate zones to a custom nameserver that can auto-generate PTRs on demand. There are scaling problems here, but probably nothing that can't be fixed with high TTLs and multiple nameservers.
In my discussions with people at some big ISPs, I got the impression that they could do that, but it wouldn't provide any more useful information than no rDNS at all, so they don't. I'm on T-W cable, and there's no way for me to set rDNS. It'd be more trouble than it's worth, since my /64 changes every time the modem reboots which seems to be about once a month. Real servers on static addresses are different, of course. My servers are on an HE tunnel, and all have matching forward and reverse DNS. R's, John
On October 9, 2013 at 11:49 cma@cmadams.net (Chris Adams) wrote:
Once upon a time, Robert Webb <rwebb@ropeguru.com> said:
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space?
Oh, are you looking for auto-generated reverse for every address? That's not going to happen for IPv6 (and it turns out that it wasn't really a good idea for IPv4). There's no reason to have reverse DNS unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all that useful.
It's very useful for blocking spammers and other miscreants -- no reason at all to accept SMTP connections from troublesome *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN is. Perhaps not their problem, but it is useful! -- -Barry Shein The World | bzs@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*
Once upon a time, Barry Shein <bzs@world.std.com> said:
It's very useful for blocking spammers and other miscreants -- no reason at all to accept SMTP connections from troublesome *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN is.
If you are going to block like that, just block anybody without valid reverse DNS. If you don't trust provider foo.net to police their users, why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net reverse? I only see a use for reverse DNS for router interfaces (for useful traceroute info) and servers (and only really SMTP servers). Most of the rest is fluff, often out-of-date, uselessly auto-generated, etc. -- Chris Adams <cma@cmadams.net>
On October 9, 2013 at 20:18 cma@cmadams.net (Chris Adams) wrote:
Once upon a time, Barry Shein <bzs@world.std.com> said:
It's very useful for blocking spammers and other miscreants -- no reason at all to accept SMTP connections from troublesome *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN is.
If you are going to block like that, just block anybody without valid reverse DNS. If you don't trust provider foo.net to police their users, why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net reverse?
Because they do, they just do. This isn't a math proof, it's mostly social engineering. The providers aren't trying to fool anyone, in general, it's just that clients and websites get botted.
I only see a use for reverse DNS for router interfaces (for useful traceroute info) and servers (and only really SMTP servers). Most of the rest is fluff, often out-of-date, uselessly auto-generated, etc.
It's pretty amazing how much spam comes from hosts with names a lot like ns1.example.com, their name servers. Not sure why they're so easily abused but maybe it doesn't occur to them to lock down MTAs on their name servers. -- -Barry Shein The World | bzs@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*
On 10/10/13 1:09 AM, "Barry Shein" <bzs@world.std.com> wrote:
On October 9, 2013 at 20:18 cma@cmadams.net (Chris Adams) wrote:
Once upon a time, Barry Shein <bzs@world.std.com> said:
It's very useful for blocking spammers and other miscreants -- no reason at all to accept SMTP connections from troublesome *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN is.
If you are going to block like that, just block anybody without valid reverse DNS. If you don't trust provider foo.net to police their users, why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net reverse?
Because they do, they just do. This isn't a math proof, it's mostly social engineering. The providers aren't trying to fool anyone, in general, it's just that clients and websites get botted.
Except the point of this thread is that they don't. Is it easier to block inbound mail from hosts with certain high-level domain names in their PTRs than to block ranges of IP(v6) addresses? Easier for whom? Lee
On October 15, 2013 at 02:28 Lee@asgard.org (Lee Howard) wrote:
On 10/10/13 1:09 AM, "Barry Shein" <bzs@world.std.com> wrote:
On October 9, 2013 at 20:18 cma@cmadams.net (Chris Adams) wrote:
Once upon a time, Barry Shein <bzs@world.std.com> said:
It's very useful for blocking spammers and other miscreants -- no reason at all to accept SMTP connections from troublesome *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN is.
If you are going to block like that, just block anybody without valid reverse DNS. If you don't trust provider foo.net to police their users, why trust them to put valid and consistent xx-xx-xx-xx.dyn.foo.net reverse?
Because they do, they just do. This isn't a math proof, it's mostly social engineering. The providers aren't trying to fool anyone, in general, it's just that clients and websites get botted.
Except the point of this thread is that they don't.
I think the point of this thread was they don't for IPv6 and whether they should or not (BCP)? I was pointing out that reverse IP names, particularly where they follow a simple pattern, can be useful in spam blocking. That may or may not be an attractive reason to a site, but I didn't particularly claim it to be. It's just an observation.
Is it easier to block inbound mail from hosts with certain high-level domain names in their PTRs than to block ranges of IP(v6) addresses? Easier for whom?
Of course it's easier, how do I as the SMTP client know how some site manages their IPv6 blocks? But it's a pretty good guess that if I'm getting 100 msgs/second from various hosts with reverse ip names matching ip-192-168.1.*.rev.example.com I can probably block that. Most likely their SMTP server won't have a name like that. As I said (and no doubt someone will jump on) none of this is an exact science, blocking spam is not an exact science, none of the tools have mathematical, infallible accuracy. You do what you can. For whom? I'm not sure what you're asking, the SMTP client side. -- -Barry Shein The World | bzs@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*
If you want to block spam on IPv6, then you can start by rejecting connections to SMTP from any IPv6 that do not have a PTR. No need to analyze the format of the PTR. It is in several recommendations that a sending email IP must have a PTR. That ISPs will not do a PTR on all IPv6 but only on static IPv6, improves the spam blocking feature above. No need to maintain list of dynamic IP space...
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/14/2013 6:23 PM, Franck Martin wrote:
If you want to block spam on IPv6, then you can start by rejecting connections to SMTP from any IPv6 that do not have a PTR. No need to analyze the format of the PTR.
It is in several recommendations that a sending email IP must have a PTR.
That ISPs will not do a PTR on all IPv6 but only on static IPv6, improves the spam blocking feature above. No need to maintain list of dynamic IP space...
...and Franck would know -- he rejects all mail from MTAs which do not. :-) - - ferg -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 10.2.0 (Build 2317) Charset: utf-8 wj8DBQFSXJwqq1pz9mNUZTMRAkJKAKCGLnO9qEGXv5LIKxCBiZhwf7HwHQCggksf Fn3GhVzeKyHG5cSc7y5GXJw= =Gtw1 -----END PGP SIGNATURE----- -- Paul Ferguson Vice President, Threat Intelligence Internet Identity, Tacoma, Washington USA IID --> "Connect and Collaborate" --> www.internetidentity.com
On October 15, 2013 at 01:23 fmartin@linkedin.com (Franck Martin) wrote:
If you want to block spam on IPv6, then you can start by rejecting connections to SMTP from any IPv6 that do not have a PTR. No need to analyze the format of the PTR.
It is in several recommendations that a sending email IP must have a PTR.
That ISPs will not do a PTR on all IPv6 but only on static IPv6, improves the spam blocking feature above. No need to maintain list of dynamic IP space...
Well yes we don't accept email delivery from any host w/o reverse dns. At any rate I was pointing out that PTR records with easily id'd patterns, where sites choose to use them, can be useful for spam blocking. It's a weak defense but any survey of spam blocking would conclude that everything other than special case (e.g., tight whitelisting) is a weak defense. But if no one uses RDNS for hosts which they believe should not be sending email directly -- a policy decision, and the most likely effect, rendering them unable to send email to many though not all sites -- then yes, that would have the same effect on email MTAs which first reject hosts lacking RDNS and then look for various patterns in the RDNS response. It's really two different, if related, cases. Is there any reason other than email where clients might demand RDNS? For example, web sites that may not talk to a host w/o RDNS? I don't know any off hand though it sounds plausible. -- -Barry Shein The World | bzs@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*
Is there any reason other than email where clients might demand RDNS?
There's a few other protocols that want rDNS on the servers. IRC maybe. Doing rDNS on random hosts in IPv6 would be very hard. Servers are configured with static addresses which you can put in the DNS and rDNS, but normal user machines do SLAAC where the low 64 bits of the address are quasi-random. To get any sort of DNS you'd need for the routers to watch when new hosts come on line and somehow tell the relevant DNS servers what hosts need names. This would be a lot of work, so nobody does it. R's, John
That gets to the core of the original question. I figured there must be a reason for the conscious omission. However, I've noticed also that Comcast hasn't bothered to give PTR to their routers, either. I think that's a horse of a different color. Leaving out PTR on the last hop for the residential customer? Sure. Leaving out v6 PTR on your core/backbone/edge routers? Surely that's not acceptable... On Mon, Oct 14, 2013 at 9:47 PM, John Levine <johnl@iecc.com> wrote:
Is there any reason other than email where clients might demand RDNS?
There's a few other protocols that want rDNS on the servers. IRC maybe.
Doing rDNS on random hosts in IPv6 would be very hard. Servers are configured with static addresses which you can put in the DNS and rDNS, but normal user machines do SLAAC where the low 64 bits of the address are quasi-random. To get any sort of DNS you'd need for the routers to watch when new hosts come on line and somehow tell the relevant DNS servers what hosts need names.
This would be a lot of work, so nobody does it.
R's, John
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
That gets to the core of the original question. I figured there must be a reason for the conscious omission. However, I've noticed also that Comcast hasn't bothered to give PTR to their routers, either.
I have a Comcast residential circuit with IPv6, and I see reverse DNS for router hops past the first device. -- Chris Adams <cma@cmadams.net>
Sent from my iPhone so be gentle about formatting errors. On Oct 15, 2013, at 7:20 AM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
That gets to the core of the original question. I figured there must be a reason for the conscious omission. However, I've noticed also that Comcast hasn't bothered to give PTR to their routers, either.
I have a Comcast residential circuit with IPv6, and I see reverse DNS for router hops past the first device. --
CenturyLink offers 6rd to both residential customers and business, but no way to set RDNS on the individual /64 or /48s assigned to each static ipv4 address the customer has. Rather huge omission, IMHO. I got bit by this bad when !$@& google started outright rejecting email from ipv6 addresses with no RDNS. Yay exim for allowing me to tag broken remote smtp servers to only use ipv4. Brielle
On Mon, Oct 14, 2013 at 09:58:22PM -0500, Blair Trosper wrote:
Leaving out v6 PTR on your core/backbone/edge routers? Surely that's not acceptable...
As I think I said somewhere up-thread, there's really no consensus on what is "acceptable" in reverse mapping. The last time we tried to get consensus, we couldn't even get it on the blandest draft possible. Best, A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
This would be a lot of work, so nobody does it.
If someone asks for the rdns for: 2001:0db8:85a3:0042:1000:8a2e:0370:7334 it's a lot of work for example.com to return something like: 2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com ? What it means, exactly, is a different discussion. But when asked the question that would be an answer and it could more or less be generated with a single printf(). -b
On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein <bzs@world.std.com> wrote:
This would be a lot of work, so nobody does it. If someone asks for the rdns for: 2001:0db8:85a3:0042:1000:8a2e:0370:7334 it's a lot of work for example.com to return something like: 2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com ?
No... it's not a lot of work; the problem is, it's maybe worth even less than the amount of work involved though. What piece of information is being expressed there that would not be expressed by a NXDOMAIN response? Assuming the user is residential ".example.com" pertains to the ISP, not the hostname at that IP address. The ISP's info is accessible via services such as WHOIS-RWS How about some wildcard PTR record ? *.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa PTR unnamedhost.example.com. It's equally useless; and conveys equally limited information about the host. However, at least it doesn't generate spurious records that are just (IP repeated).(domain) -- -JH
On Mon, Oct 14, 2013 at 10:18:15PM -0500, Jimmy Hess wrote:
On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein <bzs@world.std.com> wrote:
This would be a lot of work, so nobody does it. If someone asks for the rdns for: 2001:0db8:85a3:0042:1000:8a2e:0370:7334 it's a lot of work for example.com to return something like: 2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com ?
No... it's not a lot of work; the problem is, it's maybe worth even less than the amount of work involved though.
What piece of information is being expressed there that would not be expressed by a NXDOMAIN response?
Assuming the user is residential ".example.com" pertains to the ISP, not the hostname at that IP address. The ISP's info is accessible via services such as WHOIS-RWS
How about some wildcard PTR record ?
*.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa PTR unnamedhost.example.com.
It's equally useless; and conveys equally limited information about the host.
However, at least it doesn't generate spurious records that are just (IP repeated).(domain)
-- -JH
Forward domains and Reverse domains are often managed by different organizations - so if you were a paranoid validator, wanting to check that the name was from the correct place, you'd want to do DNSSEC validation on both the name and the address. Not going to weigh in on the value proposition. /bill
On October 15, 2013 at 03:45 bmanning@vacation.karoshi.com (bmanning@vacation.karoshi.com) wrote:
Forward domains and Reverse domains are often managed by different organizations - so if you were a paranoid validator, wanting to check that the name was from the correct place, you'd want to do DNSSEC validation on both the name and the address.
Not going to weigh in on the value proposition.
Unless, as is frequently the case, the only test is: NXDOMAIN? Reject, Anything but NXDOMAIN? Accept. -- -Barry Shein The World | bzs@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*
On October 14, 2013 at 22:18 mysidia@gmail.com (Jimmy Hess) wrote:
On Mon, Oct 14, 2013 at 10:01 PM, Barry Shein <bzs@world.std.com> wrote:
2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com ?
No... it's not a lot of work; the problem is, it's maybe worth even less than the amount of work involved though.
What piece of information is being expressed there that would not be expressed by a NXDOMAIN response?
That your host won't be rejected, typically by email servers, in an RDNS check. It's a little strange in a way, the very existence of an RDNS response has become a policy trigger, no matter what it is.
Assuming the user is residential ".example.com" pertains to the ISP, not the hostname at that IP address. The ISP's info is accessible via services such as WHOIS-RWS
How about some wildcard PTR record ?
*.3.a.5.8.8.b.d.0.1.0.0.2.ip6.arpa PTR unnamedhost.example.com.
It's equally useless; and conveys equally limited information about the host.
That really depends on what you believe is useless (or useful.) If it lets the client send email to AOL (as one example) that might be useful. The information it conveys is that this IP address merits an RDNS response for some reason, and policy is determined on that fact.
However, at least it doesn't generate spurious records that are just (IP repeated).(domain)
Well, as I said, you're setting a different standard, that the host name returned in an RDNS query be of some meaning to a human or possibly a program. Its mere existence is considered very meaningful on the net, whatever it is. -- -Barry Shein The World | bzs@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*
On October 15, 2013 at 03:31 johnl@iecc.com (John Levine) wrote:
it's a lot of work for example.com to return something like:
2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
Add some NSEC3 records and, yeah, it's a lot of work. And for what?
Many mail servers require it as a minimum standard for speaking to their MTA. -- -Barry Shein The World | bzs@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*
Once upon a time, Barry Shein <bzs@world.std.com> said:
On October 15, 2013 at 03:31 johnl@iecc.com (John Levine) wrote:
it's a lot of work for example.com to return something like:
2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
Add some NSEC3 records and, yeah, it's a lot of work. And for what?
Many mail servers require it as a minimum standard for speaking to their MTA.
Random end users shouldn't be talking to MTAs. They should be using MSAs instead. -- Chris Adams <cma@cmadams.net>
On Tue, Oct 15, 2013 at 01:55:50PM -0500, Chris Adams wrote:
Many mail servers require it as a minimum standard for speaking to their MTA.
Random end users shouldn't be talking to MTAs. They should be using MSAs instead.
Given what TLAs have been caught doing lately, end users should be *encouraged* to run their own MTAs.
On October 15, 2013 at 13:55 cma@cmadams.net (Chris Adams) wrote:
Random end users shouldn't be talking to MTAs. They should be using MSAs instead.
That's a policy decision, some allow this, some resist it. It's too bad that we've created this exclusive club of the anointed who may speak to MTAs just because of some bad actors. It's not like the basic idea is particularly a bad one. An ideal I'd prefer is get rid of the botnets and similar through other means, improving client technology and increasing the likelihood of arrest of those who exploit them for example. What's occurring is that the same factors which led to the mass spammers is now, more and more, drawing in what might be termed "legitimate" businesses. And we're tending to use our sense of social class to distinguish which is which, not (IMHO) a good trend. But what business can resist the siren call of postage-free (i.e., nearly free) marcom with their customers? Particularly where there are millions of customers. Talk to them every day, twice a day, ten times a day! Whatever it takes, apply for this credit card, donate to this worthy cause, lowest prices on vacations in Maui, new book available... The result? I think people just ignore most email and tend towards very exclusive whitelisting one way or another (human or scripted.) But what the heck, it's free! Keep that bilge pump running. MarCom too cheap to meter! Now there's a policy issue. It's gotten so you can barely hear the spam over the roar of the ("legitimate") marcom. -- -Barry Shein The World | bzs@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*
On Oct 15, 2013, at 2:55 PM, Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Barry Shein <bzs@world.std.com> said:
On October 15, 2013 at 03:31 johnl@iecc.com (John Levine) wrote:
it's a lot of work for example.com to return something like:
2001-0db8-85a3-0042-1000-8a2e-0370-7334.example.com
Add some NSEC3 records and, yeah, it's a lot of work. And for what?
Many mail servers require it as a minimum standard for speaking to their MTA.
Random end users shouldn't be talking to MTAs. They should be using MSAs instead. -- Chris Adams <cma@cmadams.net>
Semantically confusing -- From wooledge.org: Mail Submission Agent (MSA): a relatively new term in the e-mail field. This is the component of an MTA which accepts new mail messages from an MUA, using SMTP. ====================
Many mail servers require it as a minimum standard for speaking to their MTA.
In case it's not clear, we're talking about DNS and rDNS for random devices that pop up on consumer and other lightly managed networks. Mail servers, like the ones that sent this message to and from nanog, have static IPs, with DNS configured the same way it is for static IPv4. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
In message <20131015024711.55297.qmail@joyce.lan>, "John Levine" writes:
Is there any reason other than email where clients might demand RDNS?
There's a few other protocols that want rDNS on the servers. IRC maybe.
Doing rDNS on random hosts in IPv6 would be very hard. Servers are configured with static addresses which you can put in the DNS and rDNS, but normal user machines do SLAAC where the low 64 bits of the address are quasi-random. To get any sort of DNS you'd need for the routers to watch when new hosts come on line and somehow tell the relevant DNS servers what hosts need names.
This would be a lot of work, so nobody does it.
Actually you just need to *let* the hosts update their own ptr records using UPDATE. People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self. You can even delegate the reverse zone when doing or just after a PD. * Accept NS/DNAME updates for the reverse prefix from any address in the delegated address range over TCP. This avoids having a temporatially lame delegation. named already has code to do this for /48's as I coded it to to support 6to4. * Extend DHCPv6 to support delegations (NS or DNAME) relayed via the DHCP server as part of the PD. NS records would result in a temporarially lame delegation until the zone is configured in the nameserver. Either of these moves the UPDATE traffic from the ISP's server to the customers servers. Mark
R's, John -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/15/13 7:54 AM, "Mark Andrews" <marka@isc.org> wrote:
In message <20131015024711.55297.qmail@joyce.lan>, "John Levine" writes:
Is there any reason other than email where clients might demand RDNS?
There's a few other protocols that want rDNS on the servers. IRC maybe.
Doing rDNS on random hosts in IPv6 would be very hard. Servers are configured with static addresses which you can put in the DNS and rDNS, but normal user machines do SLAAC where the low 64 bits of the address are quasi-random. To get any sort of DNS you'd need for the routers to watch when new hosts come on line and somehow tell the relevant DNS servers what hosts need names.
This would be a lot of work, so nobody does it.
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
Cool. How do I tell a residential device what name server they should send updates to? Remember that the ISP uses DHCPv6 or PPPoE or TR-069 to send configuration information to the CPE, which sends DHCPv6 or RA to hosts. "Hosts" may be computers, tablets, game consoles, phones, TVs, or other.
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
Dynamic DNS uses TCP? I didn't realize that.
You can even delegate the reverse zone when doing or just after a PD.
To a home router? How do you tell the home router that it is now authoritative for the reverse zone?
* Extend DHCPv6 to support delegations (NS or DNAME) relayed via the DHCP server as part of the PD. NS records would result in a temporarially lame delegation until the zone is configured in the nameserver.
Let me know when you need me to express support for your draft being adopted by dhc WG. Until that feature is implemented, it is of limited operational utility.
Mark
Lee
Hi Lee, I can tell it has been a long weekend here; I find myself agreeing with Mark Andrews. On 2013-10-15, at 04:32, Lee Howard <Lee@asgard.org> wrote:
On 10/15/13 7:54 AM, "Mark Andrews" <marka@isc.org> wrote:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
Cool. How do I tell a residential device what name server they should send updates to?
The device can discover the lowest zone cut for a particular owner name, and extract the MAME from the corresponding SOA.
Remember that the ISP uses DHCPv6 or PPPoE or TR-069 to send configuration information to the CPE, which sends DHCPv6 or RA to hosts. "Hosts" may be computers, tablets, game consoles, phones, TVs, or other.
Yes.
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
Dynamic DNS uses TCP? I didn't realize that.
DNS can use TCP. DNS UPDATE can use TCP.
You can even delegate the reverse zone when doing or just after a PD.
To a home router? How do you tell the home router that it is now authoritative for the reverse zone?
The device can discover that itself by looking for a delegation to itself, knowing the owner name.
* Extend DHCPv6 to support delegations (NS or DNAME) relayed via the DHCP server as part of the PD. NS records would result in a temporarially lame delegation until the zone is configured in the nameserver.
Let me know when you need me to express support for your draft being adopted by dhc WG. Until that feature is implemented, it is of limited operational utility.
There's no protocol work required for any of this in the IETF. All that is required is agreement between access providers and home gateway vendors. Home gateways already need an overhaul to stop them spraying DNS responses received on the WAN port all over the Internet, so might as well take care of this at the same time. (If I've woken up to a world where the presence or absence of an IETF BCP makes a difference to anybody in this context, then let's ditch this topic and move straight to BCP38. We can talk after that.) Joe
On 2013-10-15, at 10:35, "John R. Levine" <johnl@iecc.com> wrote:
I can tell it has been a long weekend here; I find myself agreeing with Mark Andrews.
Where do the forward records for these random devices come from?
From a domain name typed into a configuration panel on the home gateway, updated in the same manner (find the zone cut, find the MNAME, send a DNS UPDATE)? Presumably if a domain name is not specified, no DNS UPDATEs occur. I'm not commenting on the need or proper desire to have matching PTR/AAAA records for the addresses at the provider edge, I'm just saying that the mechanism Mark described seems plausible. Joe
Where do the forward records for these random devices come from?
From a domain name typed into a configuration panel on the home gateway, updated in the same manner (find the zone cut, find the MNAME, send a DNS UPDATE)?
Hmmn. Seems like a security disaster waiting to happen, but I see how the pices could work. Tnx. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
In message <alpine.BSF.2.00.1310151035270.89737@joyce.lan>, "John R. Levine" wr ites:
I can tell it has been a long weekend here; I find myself agreeing with Mar k Andrews.
Where do the forward records for these random devices come from?
Signed, Confused
They get configured though front panels, touch screens, usb connections, over the network using mDNS for initial discovery, usinge a games connector and the TV screen, etc. There are lots of way to do this. This is a solved problem as people have been providing devices with names for about as long as the devices have existed. The only difference is that they give the device a fully qualified name instead of a unqualified name. They use TSIG to authenticate the UPDATES to the forward zone which is probably what your DHCP server is using today to authenticate the updates it sends and one of the methods DynDNS supports to update the zones it serves. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
Um, Mark, forward records too. And I have to say the idea of delegating rDNS for 50 million consumers to 50 million consumer something or others is simultaneously pretty amusing and pretty horrifying. My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical. R's, John
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Seems pretty dismal to me. Wasn't a big win of IPv6 supposed to be that we could do things over without making all the same stupid mistakes we made in IPv4? Dynamic IPv4 assignment was always a hang-over from dial-up days when $ADDRESS_POOL_SIZE == $MODEM_POOL_SIZE < $SUBSCRIBER_BASE, coupled eventually with a restricted supply of addresses. We insisted on dragging it into the broadband world where the number of active connections is pretty much 1:1 with the number of paying subscribers; must we really drag the same old baggage into the IPv6 future? Regards, Tim.
On 10/15/2013 08:35 AM, TJ wrote:
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Really? I think my IPv6 address form Comcast has changed (maybe) twice in the last 18 months, and I think it was only once.
There's an entire universe within ietf who thinks that seamless renumbering is a Big Deal. We're obviously not completely there -- especially within residential -- but any path forward should not count on the stability of prefixes. Anywhere. Mike
Michael Thomas <mike@mtcc.com> writes:
On 10/15/2013 08:35 AM, TJ wrote:
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Really? I think my IPv6 address form Comcast has changed (maybe) twice in the last 18 months, and I think it was only once.
There's an entire universe within ietf who thinks that seamless renumbering is a Big Deal. We're obviously not completely there -- especially within residential -- but any path forward should not count on the stability of prefixes. Anywhere.
Agreed. We will allocate semi-static prefixes, but have decided to do strict aggregation of retail subscriber prefixes on the BNGs. This means that the allocations will be perceived as static by most users, but there are no guarantees. We will renumber if the users move between BNGs, regardless of reason. Including moving DSLAMs/OLTs. Having said that: Renumbering is not going to be seemless, even for simple home networks. The last time I changed my home prefix, I completely forgot that I had put the old one into a cups access list. Took me a while to figure out why I couldn't make the printer work a month or so later... Typical static entries being added over time are: - DNS glue - access lists, both in your network and in other networks - interface config on devices where you don't want SLAAC or DHCPv6 - server application configuration (you do want your mail server to use a specific source address and not just choose one, right?) + everything I forgot No, renumbering is not going to be seemless. Yes, a smarter person could automate everything I list above, but we all know that's not going to happen. Bjørn
On 10/15/13 9:48 AM, Bjørn Mork wrote:
Michael Thomas <mike@mtcc.com> writes:
Typical static entries being added over time are: - DNS glue - access lists, both in your network and in other networks - interface config on devices where you don't want SLAAC or DHCPv6 - server application configuration (you do want your mail server to use a specific source address and not just choose one, right?) + everything I forgot
No, renumbering is not going to be seemless. Yes, a smarter person could automate everything I list above, but we all know that's not going to happen.
I've always been something of a skeptic how seams "seamless" will actually have :) But there has been a tremendous amount of effort in the v6 world to make renumbering a first class citizen. In the mean time, if we do nothing else be keep track of where all of those pesky ip address bearing files are, we can at least keep throwing them over the wall to the ietf as to what they expect us to do with them. Mike
In message <87iowyo4yn.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Michael Thomas <mike@mtcc.com> writes:
On 10/15/2013 08:35 AM, TJ wrote:
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Really? I think my IPv6 address form Comcast has changed (maybe) twice in the la= st 18 months, and I think it was only once.
There's an entire universe within ietf who thinks that seamless renumbering is a Big Deal. We're obviously not completely there -- especially within residential -- but any path forward should not count on the stability of prefixes. Anywhere.
Agreed.
We will allocate semi-static prefixes, but have decided to do strict aggregation of retail subscriber prefixes on the BNGs. This means that the allocations will be perceived as static by most users, but there are no guarantees. We will renumber if the users move between BNGs, regardless of reason. Including moving DSLAMs/OLTs.
Having said that: Renumbering is not going to be seemless, even for simple home networks. The last time I changed my home prefix, I completely forgot that I had put the old one into a cups access list. Took me a while to figure out why I couldn't make the printer work a month or so later...
Typical static entries being added over time are: - DNS glue
Well this is solvable using UPDATE + TSIG to update the glue held in the parent zones. People have used stored user names and passwords to update things automatically for decades. TSIG is just a user name and a password. For RRR managed zones see draft-andrews-dnsop-updating-parent-zones.
- access lists, both in your network and in other networks
Complain to your equipment vendor if they don't support dynamic updating of these lists.
- interface config on devices where you don't want SLAAC or DHCPv6
Well if you refuse to use methods that are designed to make renumbering events less painful you only have yourself to blame.
- server application configuration (you do want your mail server to use a specific source address and not just choose one, right?)
Why do you care about the address other than it has a PTR record associated with it. You can tell IP stacks to NOT use privacy addresses when selecting the source address to use for outgoing connections.
+ everything I forgot
No, renumbering is not going to be seemless. Yes, a smarter person could automate everything I list above, but we all know that's not going to happen.
No, we don't know it won't happen. You just tackle one problem at a time and very soon you have a machine that can be renumbered automatically. It's about configuring the machine in the first place. Mark
Bj=C3=B8rn
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On 10/15/13 5:48 PM, "Bjørn Mork" <bjorn@mork.no> wrote:
No, renumbering is not going to be seemless. Yes, a smarter person could automate everything I list above, but we all know that's not going to happen.
The 6renum WG at IETF just closed, with a list of work items remaining for other WGs to complete. I recommend RFC6879 in particular, with RFC6866 describing some parts of the problems and RFC7010 being the outstanding work. The IETF has generally been taken as an assumption that the home network is unmanaged (see the Homenet charter and architecture document, for instance). The administrator of a managed network can follow RFC6879 and renumber pretty seamlessly. In the unmanaged home, since everything is automatic, renumbering should be seamless. Yes, more tools are needed (thus RFC7010). Lee
Lee Howard <Lee@asgard.org> writes:
The 6renum WG at IETF just closed, with a list of work items remaining for other WGs to complete. I recommend RFC6879 in particular, with RFC6866 describing some parts of the problems and RFC7010 being the outstanding work.
The IETF has generally been taken as an assumption that the home network is
unmanaged (see the Homenet charter and architecture document, for instance). The administrator of a managed network can follow RFC6879 and renumber pretty seamlessly.
Yes, given - careful planning - smart macro usage - some scripting Feel free to show me a typical business site with more than 2 of those in place... FWIW, I did a little exercise on my home network, running just a few basic services which I assume most businesses will run as well. This resulted in a number of text configuration file formats requiring requiring knowlegde of the prefix list (i.e. not suitable for DNS names): - spamassasin (trusted_networks) - BIND (recursion allowed acl) - sendmail (relaying access) - ntp (peer access) - cups (printer access) - squid (http proxy access) All of these use different configuration syntax and generally do not support macro expansion of the prefix. So you'd have to script any updates. I'm in particular fond of the sendmail and ntp syntaxes, which can best be described as "weird". sendmail: IPv6:2001:0db8:0f00 RELAY ntp: restrict 2001:db8:f00:: mask ffff:ffff:ffff:: nomodify When you can't even standardize on a prefix syntax, how the heck are you going to make renumbering seamless??
In the unmanaged home, since everything is automatic, renumbering should be seamless.
Most homes will have at least one manually configured IP device. Typical candidates are - printers - media (video and/or audio) playback devices - additional wlan access points We can close our eyes and ignore them, but they are still there. Yes, yes, the firmware programmers are going to get much much smarter when they add IPv6 to these devices. I'm sure. I'm still in favour of reducing the renumbering burden as much as possible, even for home networks. Bjørn
In message <87y55sjcc7.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Lee Howard <Lee@asgard.org> writes:
The 6renum WG at IETF just closed, with a list of work items remaining for other WGs to complete. I recommend RFC6879 in particular, with RFC6866 describing some parts of the problems and RFC7010 being the outstanding work.
The IETF has generally been taken as an assumption that the home network is
unmanaged (see the Homenet charter and architecture document, for instance). The administrator of a managed network can follow RFC6879 and renumber pretty seamlessly.
Yes, given - careful planning - smart macro usage - some scripting
Feel free to show me a typical business site with more than 2 of those in place...
FWIW, I did a little exercise on my home network, running just a few basic services which I assume most businesses will run as well. This resulted in a number of text configuration file formats requiring requiring knowlegde of the prefix list (i.e. not suitable for DNS names): - spamassasin (trusted_networks) - BIND (recursion allowed acl)
Named actually looks at netmasks and prefix lengths on interfaces and generates named acls based on those. Named regularly scans the interface list and adjusts the named acl based on the changes it sees. It could use a routing socket rather than a timer to do this. The default allow-recursion acl uses that named acl. If the site prefix length was available to it, say via being advertised in the RA, it would also generate a "localsite" acl.
- sendmail (relaying access) - ntp (peer access) - cups (printer access) - squid (http proxy access)
All of these use different configuration syntax and generally do not support macro expansion of the prefix. So you'd have to script any updates.
I'm in particular fond of the sendmail and ntp syntaxes, which can best be described as "weird".
sendmail: IPv6:2001:0db8:0f00 RELAY
ntp: restrict 2001:db8:f00:: mask ffff:ffff:ffff:: nomodify
When you can't even standardize on a prefix syntax, how the heck are you going to make renumbering seamless??
You have a daemon that reconfigures components of the system when new interfaces are. I already have dhclient do this for me with IPv4. It already goes and talks to machines on the other side of the world and reconfigures them because the IPv4 address my ISP is giving me as changed. You have templated configuration files for that daemon to use.
In the unmanaged home, since everything is automatic, renumbering should be seamless.
Most homes will have at least one manually configured IP device. Typical candidates are - printers - media (video and/or audio) playback devices - additional wlan access points
We can close our eyes and ignore them, but they are still there. Yes, yes, the firmware programmers are going to get much much smarter when they add IPv6 to these devices. I'm sure.
Firstly ULA's will save a lot of these devices as they don't need to be visible outside of the house. For those that do need to be externally reachable a "Renumber Ready" campaign would help the punter choose the right box.
I'm still in favour of reducing the renumbering burden as much as possible, even for home networks.
Bjørn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Really? I think my IPv6 address form Comcast has changed (maybe) twice in the last 18 months, and I think it was only once.
Could it be a non-persistent DUID on the CPE maybe? It tends to get more rare as home router implementors get their IPv6 right, but we still see some in the wild. (it makes an interesting attack vector also...) /JF
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Really?
Yes, it's T-W and I believe it's deliberate. Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
On Oct 15, 2013, at 8:13 PM, John R. Levine <johnl@iecc.com> wrote:
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
Really?
Yes, it's T-W and I believe it's deliberate.
http://tools.ietf.org/html/draft-ietf-6renum-gap-analysis-08
Regards, John Levine, johnl@iecc.com, Primary Perpetrator of "The Internet for Dummies", Please consider the environment before reading this e-mail. http://jl.ly
On Oct 15, 2013, at 7:26 AM, John R. Levine <johnl@iecc.com> wrote:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
I don't think that any host out there should be updating the PTR record associated with the privacy address it's using for outgoing connections. if the provider the prefix is delgated to respond with a genric RR well fine. but I doubt very much that there would be any circumstances where you'd want hosts doing PTR updates for addresses they're only using because their slaac address is a form of information leakage.
Um, Mark, forward records too.
And I have to say the idea of delegating rDNS for 50 million consumers to 50 million consumer something or others is simultaneously pretty amusing and pretty horrifying.
My cable company assigns me a different prefix every time the modem reboots, about once a month, and I think that's pretty typical.
R's, John
In message <574B5044-E7C5-4EF0-AC67-BE1F3E5EE105@bogus.com>, joel jaeggli write s:
On Oct 15, 2013, at 7:26 AM, John R. Levine <johnl@iecc.com> wrote:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
I don't think that any host out there should be updating the PTR record associated with the privacy address it's using for outgoing connections. if the provider the prefix is delgated to respond with a genric RR well fine. but I doubt very much that there would be any circumstances where you'd want hosts doing PTR updates for addresses they're only using because their slaac address is a form of information leakage.
Why don't you let the USER decide whether privacy addresses get PTR records or not. This is a policy decision for the USER not IETF, NANOG or any other body including the manufacturer. It might default off but that should be the end of it. This is about ALLOWING them to do it. Not REQUIRING them to do it. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews <marka@isc.org> writes:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
You can even delegate the reverse zone when doing or just after a PD.
* Accept NS/DNAME updates for the reverse prefix from any address in the delegated address range over TCP. This avoids having a temporatially lame delegation. named already has code to do this for /48's as I coded it to to support 6to4.
This sounded like an excellent idea at first, but then I started thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation? I don't think so. I am not even sure I would want them all to be able to update the PTR record for the addresses they use. Bjørn
On 2013-10-15, at 10:57, Bjørn Mork <bjorn@mork.no> wrote:
Mark Andrews <marka@isc.org> writes:
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
This sounded like an excellent idea at first, but then I started thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
I think what you'd be doing is giving anybody you have assigned an IPv6 address to the ability to update the PTR (or a delegation, since Mark suggested that too) for that particular address. So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse delegations" (if you've been assigned a /48). Joe
Joe Abley <jabley@hopcount.ca> writes:
On 2013-10-15, at 10:57, Bjørn Mork <bjorn@mork.no> wrote:
Mark Andrews <marka@isc.org> writes:
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
This sounded like an excellent idea at first, but then I started thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
I think what you'd be doing is giving anybody you have assigned an IPv6 address to the ability to update the PTR (or a delegation, since Mark suggested that too) for that particular address.
So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse delegations" (if you've been assigned a /48).
Ah, right. I understood the proposal as "any address within then /48 can update the delegation for the /48 reverse". But if that would be 2^80 distinct delegations or PTRs, then I am worrying about luser stupidiy and the ability to DoS the name server. I guess this can be combined with some sort of limit, making it fly? Still don't see the advantage of being able to delegate if it's only single address delegations. But allowing a limited number of PTR updates based on TCP sounds like a nice idea. Going to consider that. For the full /48 delegation I don't see any other option than making it part of a self service portal. But the marketing/product droids usually don't want that sort of "complex" techical stuff for retail users. Probably for good reasons... In any case: All of you should expect legitimate, technical brilliant users attempting to connect to your SMTP servers from IPv6 addresses with no PTR records. This is not going to go away. You are of course free to refuse those connections, but personally I find a that rather arrogant and pretty stupid decision. The existence of a PTR record is one of many factors to consider for your spam filter. There never has been any reason to make it an absolute requirement, and I am pretty sure the score needs to be lowered with IPv6. Bjørn (yes, my mail server has a proper IPv6 reverse record, but that's only because I am in a position to create the reverse delegation....)
On 10/15/13 10:20 AM, Bjørn Mork wrote:
In any case: All of you should expect legitimate, technical brilliant users attempting to connect to your SMTP servers from IPv6 addresses with no PTR records. This is not going to go away. You are of course free to refuse those connections, but personally I find a that rather arrogant and pretty stupid decision. The existence of a PTR record is one of many factors to consider for your spam filter. There never has been any reason to make it an absolute requirement, and I am pretty sure the score needs to be lowered with IPv6.
Or, as an alternative, actually use the SPF records that multiple big companies keep telling people to make sure they have. I have my SPF records set to allow my IPv6 and IPv4 senders, why are they ignoring that and going just for an outright reject on inbound ipv6 mail? At least, if its a defer, it has the chance to bounce over to one of my backup mail servers that doesn't have IPv6 (or in one case, has a mail server out of my directly assigned from ARIN /48 with working rdns). -- Brielle Bruns The Summit Open Source Development Group http://www.sosdg.org / http://www.ahbl.org
In message <87mwmao693.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Joe Abley <jabley@hopcount.ca> writes:
On 2013-10-15, at 10:57, Bj=C3=B8rn Mork <bjorn@mork.no> wrote:
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self. =20 This sounded like an excellent idea at first, but then I started
Mark Andrews <marka@isc.org> writes: =20 thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
I think what you'd be doing is giving anybody you have assigned an IPv6 address to the ability to update the PTR (or a delegation, since Mark suggested that too) for that particular address.
So, it's not "my reverse delegation", it's "my 2^80 or fewer reverse delegations" (if you've been assigned a /48).
Ah, right. I understood the proposal as "any address within then /48 can update the delegation for the /48 reverse".
But if that would be 2^80 distinct delegations or PTRs, then I am worrying about luser stupidiy and the ability to DoS the name server. I guess this can be combined with some sort of limit, making it fly? Still don't see the advantage of being able to delegate if it's only single address delegations. But allowing a limited number of PTR updates based on TCP sounds like a nice idea. Going to consider that.
No that would be 1 delegation. e.g. x.x.x.x.8.b.d.0.1.0.0.2.ip6.arpa
For the full /48 delegation I don't see any other option than making it part of a self service portal. But the marketing/product droids usually don't want that sort of "complex" techical stuff for retail users. Probably for good reasons...
I can see this being done completely automatically by the CPE device. It is trivial to code. It just required ISP's to *allow* it to happen. * CPE generates a RSA key pair. Stores this in non-volatile memory. [needs to be coded, no protocol work required] * CPE generates DHCP PD request which includes a "KEY-RDATA" option which contains a RSASHA256 KEY RDATA. [needs to be coded, needs code point allocated but otherwise no protocol work required] * DHCP server updates DNS server based on the prefix it is delegating and the KEY-RDATA using TSIG for authentication and responds with prefix. If this is a new PD it will clear out all the old DNS records as part of the delegation processs. If there are multiple prefixes being delegated the DNS server will be updated for all of them. [needs to be coded. uses existing protocols] * The CPE device configures the nameserver built in to it to server the reverse of the delegated prefixes. [needs to be coded, no protocol work required] * CPE device generates DNS update which delegates the reverse name space to itself and uses SIG(0) to sign the request with owner name matching the reverse of the delegated prefix. [needs to be coded, uses existing protocols] * The ISP's DNS server is configured to accept self signed requests. It examines the request. Looks at the KEY record added by the DHCP server and decides the request is valid. [exists, uses existing protocols] At this stage the reverse space has been delegated to the CPE device which can accept updates from machines within the home.
In any case: All of you should expect legitimate, technical brilliant users attempting to connect to your SMTP servers from IPv6 addresses with no PTR records. This is not going to go away. You are of course free to refuse those connections, but personally I find a that rather arrogant and pretty stupid decision. The existence of a PTR record is one of many factors to consider for your spam filter. There never has been any reason to make it an absolute requirement, and I am pretty sure the score needs to be lowered with IPv6.
Bj=C3=B8rn (yes, my mail server has a proper IPv6 reverse record, but that's only because I am in a position to create the reverse delegation....) -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
I can see this being done completely automatically by the CPE device. It is trivial to code. It just required ISP's to *allow* it to happen.
The rest of the plan looks OK at first glance.. However, step 0:
* CPE generates a RSA key pair. Stores this in non-volatile memory. [needs to be coded, no protocol work required]
has proven to be a lot harder to do in the field than one might expect, due to the very limited amount of entropy sources available to a CPE that Joe Sixpack just pulled out of a Best Buy shopping bag. Witness the truly huge pile of CPE that generate horribly insecure weak self-signed certs for https....
In message <199168.1381928361@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu writes:
On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
I can see this being done completely automatically by the CPE device. It is trivial to code. It just required ISP's to *allow* it to happen.
The rest of the plan looks OK at first glance.. However, step 0:
* CPE generates a RSA key pair. Stores this in non-volatile memory. [needs to be coded, no protocol work required]
has proven to be a lot harder to do in the field than one might expect, due to the very limited amount of entropy sources available to a CPE that Joe Sixpack just pulled out of a Best Buy shopping bag. Witness the truly huge pile of CPE that generate horribly insecure weak self-signed certs for https. ...
Which is easily solvable when you design the CPE device to have good sources of hardware randomness. CPE devices are no longer just routers which shuffle packets. There are lots of activities that CPE deviced do that require good randomness and it only costs a couple of cents to add it the devices. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Oct 17, 2013 at 12:12:03AM +1100, Mark Andrews wrote:
In message <199168.1381928361@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt.edu writes:
On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
* CPE generates a RSA key pair. Stores this in non-volatile memory. [needs to be coded, no protocol work required]
has proven to be a lot harder to do in the field than one might expect, due to the very limited amount of entropy sources available to a CPE that Joe Sixpack just pulled out of a Best Buy shopping bag. Witness the truly huge pile of CPE that generate horribly insecure weak self-signed certs for https. ...
Which is easily solvable when you design the CPE device to have good sources of hardware randomness. CPE devices are no longer just routers which shuffle packets. There are lots of activities that CPE deviced do that require good randomness and it only costs a couple of cents to add it the devices.
I'm sure the NSA would be happy to chip in to ensure that the best[0] possible source of randomness is available. - Matt [0] *Who* the decision is best for is left open to the imagination. -- Generally the folk who love the environment in vague, frilly ways are at odds with folk who love the environment next to the mashed potatoes. -- Anthony de Boer, in a place that does not exist
In message <20131016212547.GC31165@hezmatt.org>, Matt Palmer writes:
On Thu, Oct 17, 2013 at 12:12:03AM +1100, Mark Andrews wrote:
In message <199168.1381928361@turing-police.cc.vt.edu>, Valdis.Kletnieks@vt .edu writes:
On Wed, 16 Oct 2013 18:50:29 +1100, Mark Andrews said:
* CPE generates a RSA key pair. Stores this in non-volatile memory. [needs to be coded, no protocol work required]
has proven to be a lot harder to do in the field than one might expect, d ue to the very limited amount of entropy sources available to a CPE that Joe Sixpack just pulled out of a Best Buy shopping bag. Witness the truly hu ge pile of CPE that generate horribly insecure weak self-signed certs for ht tps. ...
Which is easily solvable when you design the CPE device to have good sources of hardware randomness. CPE devices are no longer just routers which shuffle packets. There are lots of activities that CPE deviced do that require good randomness and it only costs a couple of cents to add it the devices.
I'm sure the NSA would be happy to chip in to ensure that the best[0] possible source of randomness is available.
- Matt
[0] *Who* the decision is best for is left open to the imagination.
CPE devices need both battery backed time of day clocks and sources of hardware randomness. Modern Intel CPU's provide hardware based random numbers. It is not like other cpu manufactures can't do the same thing. This doesn't increase the chip count or pcb real estate used. It's time CPE Router vendors did a re-think. Mark
-- Generally the folk who love the environment in vague, frilly ways are at odds with folk who love the environment next to the mashed potatoes. -- Anthony de Boer, in a place that does not exist -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
In message <96674964-CE5B-4462-AB5C-4CC27351E40C@orthanc.ca>, Lyndon Nerenberg writes:
On 2013-10-16, at 4:03 PM, Mark Andrews <marka@isc.org> wrote:
Modern Intel CPU's provide hardware based random numbers.
Randomness vetted by whom? :-P
I really don't care for this purpose. I'm much more worries about the image being tampered with than the hardware random number generator. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On Thu, Oct 17, 2013 at 10:03:42AM +1100, Mark Andrews wrote:
Modern Intel CPU's provide hardware based random numbers. It is not like other cpu manufactures can't do the same thing. This doesn't increase the chip count or pcb real estate used.
Specifically Intel's RNG is inauditable. It should not be used as a single source of entropy, but always mixed in with others, unrelated sources of entropy. There used to be an USB stick RNG called Entropykey, but that one is currently unavailable. A cheap/improvised, trusted way to get some physical entropy could be USB SDRs http://sdr.osmocom.org/trac/wiki/rtl-sdr especially if hooked up to an analog wideband white noise generator http://www.maximintegrated.com/app-notes/index.mvp/id/3469 instead of just listening to the aether. Never use entropy as is, mix it into a PRNG, use as many entropy sources as you can. Packet timing (IRQs) can be a source of entropy in a network device.
It's time CPE Router vendors did a re-think.
In message <8738o2poov.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Mark Andrews <marka@isc.org> writes:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
You can even delegate the reverse zone when doing or just after a PD.
* Accept NS/DNAME updates for the reverse prefix from any address in the delegated address range over TCP. This avoids having a temporatially lame delegation. named already has code to do this for /48's as I coded it to to support 6to4.
This sounded like an excellent idea at first, but then I started thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
Yet this is essentially what 6to4 has been doing for years. See RFC 5158. Sometimes good enough is all that is needed. One could add a KEY record at the same time as you add the NS/DNAME records and use SIG(0) to authenticate subsequent updates to the delegation based on that key. The DHCP server would clear delegations on new PD presumably using a TSIG signed UPDATE request. if no sig0 then allow update tcp-6to4 if self-signed the allow update if this tsig then allow update Named already has the concepts of "this tsig", "self-signed", "tcp-6to4". It doesn't have the concept of "no sig0" but adding this sort of thing is relatively straight forward. A third method would be for the CPE could send a KEY record rdata in the DHCP PD request that the DHCP server which would add to the zone with a owner name based on the allocated prefix. SIG(0) would then be used to authenticate further update requests at or below this name. This is just bolting together existing technologies in more useful ways. Mark
I don't think so. I am not even sure I would want them all to be able to update the PTR record for the addresses they use.
Bj=C3=B8rn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
Mark Andrews <marka@isc.org> writes:
In message <8738o2poov.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Mark Andrews <marka@isc.org> writes:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
You can even delegate the reverse zone when doing or just after a PD.
* Accept NS/DNAME updates for the reverse prefix from any address in the delegated address range over TCP. This avoids having a temporatially lame delegation. named already has code to do this for /48's as I coded it to to support 6to4.
This sounded like an excellent idea at first, but then I started thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
Yet this is essentially what 6to4 has been doing for years. See RFC 5158. Sometimes good enough is all that is needed.
Yes. Could be. But there will always be these paranoid users which do not want to allow their teenage childrens hacker friends to change delegations and create cooool names...
One could add a KEY record at the same time as you add the NS/DNAME records and use SIG(0) to authenticate subsequent updates to the delegation based on that key.
I really like this idea.
The DHCP server would clear delegations on new PD presumably using a TSIG signed UPDATE request.
I would only do the clearing when changing the prefix owner in the DHCPv6 backend database, but I guess that depends on how you do the allocations.
if no sig0 then allow update tcp-6to4 if self-signed the allow update if this tsig then allow update
Named already has the concepts of "this tsig", "self-signed", "tcp-6to4". It doesn't have the concept of "no sig0" but adding this sort of thing is relatively straight forward.
Some sort of "this name+RR exists" conditional would be useful in the policy. I would like to make the policy depend on if self-signed then allow update if KEY(zone) exists then deny update if tcp-self then allow update KEY PTR Actually, a count of records would be useful: if this tsig then allow update if self-signed then allow update if count(KEY, zone) > 0 then deny update if tcp-self then allow update zone KEY if count(PTR, *.zone) > 5 then deny update if tcp-self then allow update *.zone PTR Does BIND do automatic validation of NS updates vs other records? I.e. if a NS record exists, are PTR updates inside the delegated zone automatically denied?
A third method would be for the CPE could send a KEY record rdata in the DHCP PD request that the DHCP server which would add to the zone with a owner name based on the allocated prefix. SIG(0) would then be used to authenticate further update requests at or below this name.
That would also work. But it requires co-ordinated DCHPv6 client and server support, making it less likely to succeed IMHO. Making those behave is difficult enough alread. Still, one additional concern showed up when discussing these ideas with people being paid to be paranoid: Spamming botnets are real. Most users won't ever touch their reverse DNS records. In particular, those users with botnet controlled PCs are not going to have any KEYs. Until the bot programmers discover that *they* now have the power to add proper PTR and SPF records for their spam service... Haven't they yet discovered this on 6to4? Well, I guess they have now, and you will all just deny mail from 6to4 addresses regardless of DNS. Bjørn
In message <8738o1ob07.fsf@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Mark Andrews <marka@isc.org> writes:
In message <8738o2poov.fsf@nemi.mork.no>, =3D?utf-8?Q?Bj=3DC3=3DB8rn_Mork= ?=3D writes:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
People keep saying the PTR records don't mean anything yet still demand really strong authentication for updates of PTR records. TCP is more than a strong enough authenticator to support update from self.
You can even delegate the reverse zone when doing or just after a PD.
* Accept NS/DNAME updates for the reverse prefix from any address in the delegated address range over TCP. This avoids having a temporatially lame delegation. named already has code to do this for /48's as I coded it to to support 6to4. =20 This sounded like an excellent idea at first, but then I started
Mark Andrews <marka@isc.org> writes: =20 thinking: As a home user, would I really want to give anyone with access to my network the right to change my reverse delegation?
Yet this is essentially what 6to4 has been doing for years. See RFC 5158. Sometimes good enough is all that is needed.
Yes. Could be. But there will always be these paranoid users which do not want to allow their teenage childrens hacker friends to change delegations and create cooool names...
One could add a KEY record at the same time as you add the NS/DNAME records and use SIG(0) to authenticate subsequent updates to the delegation based on that key.
I really like this idea.
The DHCP server would clear delegations on new PD presumably using a TSIG signed UPDATE request.
I would only do the clearing when changing the prefix owner in the DHCPv6 backend database, but I guess that depends on how you do the allocations.
if no sig0 then allow update tcp-6to4 if self-signed the allow update if this tsig then allow update
Named already has the concepts of "this tsig", "self-signed", "tcp-6to4". It doesn't have the concept of "no sig0" but adding this sort of thing is relatively straight forward.
Some sort of "this name+RR exists" conditional would be useful in the polic= y.
I would like to make the policy depend on if self-signed then allow update if KEY(zone) exists then deny update if tcp-self then allow update KEY PTR
Actually, a count of records would be useful:
if this tsig then allow update if self-signed then allow update if count(KEY, zone) > 0 then deny update if tcp-self then allow update zone KEY if count(PTR, *.zone) > 5 then deny update if tcp-self then allow update *.zone PTR
Does BIND do automatic validation of NS updates vs other records? I.e. if a NS record exists, are PTR updates inside the delegated zone automatically denied?
A third method would be for the CPE could send a KEY record rdata in the DHCP PD request that the DHCP server which would add to the zone with a owner name based on the allocated prefix. SIG(0) would then be used to authenticate further update requests at or below this name.
That would also work. But it requires co-ordinated DCHPv6 client and server support, making it less likely to succeed IMHO. Making those behave is difficult enough alread.
However *now* is the perfect time to do this as many ISP's are only starting to think about how to do IPv6. This means installing *new* DHCP servers. Similarly most households don't yet have a IPv6 CPE device. We are talking "basically" green field.
Still, one additional concern showed up when discussing these ideas with people being paid to be paranoid: Spamming botnets are real. Most users won't ever touch their reverse DNS records. In particular, those users with botnet controlled PCs are not going to have any KEYs. Until the bot programmers discover that *they* now have the power to add proper PTR and SPF records for their spam service...
Your customers should be able to get names for their machines registered in the DNS. If that means that generic names go the way of the dinasour then so be it. Remember generic names were only used because there was specified method to do this originally and inertia took over for IPv4. This is like the reason people used ISP to send and receive email was because they were not alway connected and it was slightly less hassle.
Haven't they yet discovered this on 6to4? Well, I guess they have now, and you will all just deny mail from 6to4 addresses regardless of DNS.
Bj=C3=B8rn -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On October 15, 2013 at 15:54 marka@isc.org (Mark Andrews) wrote:
Actually you just need to *let* the hosts update their own ptr records using UPDATE.
Well, that's an interesting proposal and worthwhile considering. I proposed something vaguely similar vis a vis WHOIS recently (it's not entirely original with me), just put it a URL (or similar) in an RR which when queried will return whatever WHOIS info the owner of the domain wants to return, including nothing. Something like: IN RRR http://www.example.com/whois where RRR is TBD. Could even be a mailto, for example, or anything, the info in place even if it's brief. Someone back I think in 2001 proposed using the SRV RR for this, it's maybe a little awkward in format but same idea basically. -- -Barry Shein The World | bzs@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*
Sent from my iPhone On Oct 15, 2013, at 8:59 AM, Bjørn Mork <bjorn@mork.no> wrote:
Doug Barton <dougb@dougbarton.us> writes:
On 10/14/2013 07:47 PM, John Levine wrote:
Doing rDNS on random hosts in IPv6 would be very hard.
* PTR generic.reverse.record.isp.net.
can we move on now?
Sure. If you can explain how that is going to resolve forward.
Wildcard A records like have been done forever (even if not exactly recommended)?
Er, right as I sent that I realized I'm getting a E_NOCOFFEE error and that only works on the name side of it, not on the address side. In theory, you could do a *.rdns.isp.com and use something like the powerdns pipe backend to provide proper A record from 1.0.0.127.rdns.isp.com. Sent from my iPhone On Oct 15, 2013, at 9:06 AM, Brielle Bruns <bruns@2mbit.com> wrote:
Sent from my iPhone
On Oct 15, 2013, at 8:59 AM, Bjørn Mork <bjorn@mork.no> wrote:
Doug Barton <dougb@dougbarton.us> writes:
On 10/14/2013 07:47 PM, John Levine wrote:
Doing rDNS on random hosts in IPv6 would be very hard.
* PTR generic.reverse.record.isp.net.
can we move on now?
Sure. If you can explain how that is going to resolve forward.
Wildcard A records like have been done forever (even if not exactly recommended)?
Brielle Bruns <bruns@2mbit.com> writes:
Sent from my iPhone
On Oct 15, 2013, at 8:59 AM, Bjørn Mork <bjorn@mork.no> wrote:
Doug Barton <dougb@dougbarton.us> writes:
On 10/14/2013 07:47 PM, John Levine wrote:
Doing rDNS on random hosts in IPv6 would be very hard.
* PTR generic.reverse.record.isp.net.
can we move on now?
Sure. If you can explain how that is going to resolve forward.
Wildcard A records like have been done forever (even if not exactly recommended)?
Maybe. Personally I put a lot more trust into an IPv6 address with no PTR than an IPv6 address with a PTR not resolving back to the same address. Bjørn
"JL" == John Levine <johnl@iecc.com> writes:
JL> but normal user machines do SLAAC where the low 64 bits of the JL> address are quasi-random. To get any sort of DNS you'd need for JL> the routers to watch when new hosts come on line and somehow tell JL> the relevant DNS servers what hosts need names. One of the arguments put forward by those who prefer dhcp6 was that the dhcp6 server could do that for any leases. Just like for dhcp4. For SLAAC, something based on mdns might do? Ie, a multicast address where a box can announce that it just joined the lan at a specified v6. That also might be reasonable for privacy addresses. -JimC (just brainstorming) -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
In message <21077.65231.279689.263778@world.std.com>, Barry Shein writes:
On October 9, 2013 at 11:49 cma@cmadams.net (Chris Adams) wrote:
Once upon a time, Robert Webb <rwebb@ropeguru.com> said:
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space?
Oh, are you looking for auto-generated reverse for every address? That's not going to happen for IPv6 (and it turns out that it wasn't really a good idea for IPv4). There's no reason to have reverse DNS unless it has meaning, and "12-34-56-78.rev.domain.net" isn't really all that useful.
It's very useful for blocking spammers and other miscreants -- no reason at all to accept SMTP connections from troublesome *.rev.domain.net at all, no matter what the preceding NNN-NNN-NNN-NNN is.
Perhaps not their problem, but it is useful!
And not accepting SMTP from everybody leaves your customers exposed to NSA and others snooping the wires or ISP being subject to warrentless requests to send all the email delivered to their submission and other servers to various government agencies under the idiotic notion that email is always sent in the clear so it doesn't need a warrant. Direct to MX reduces the risk of snooping to the two end points and end point MITM can be detected with the use of tls. If we want secure email, and we should want secure email, then we should be pushing for direct to MX with every customer hosting their own MX server and start tls on by default. Yes that comes with the risk of additional spam but get over it and run proper abuse desks. Mark
-- -Barry Shein
The World | bzs@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*
-- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@isc.org
On October 10, 2013 at 12:35 marka@isc.org (Mark Andrews) wrote:
Yes that comes with the risk of additional spam but get over it and run proper abuse desks.
With all due respect I don't think you have an inkling of the magnitude of the spam problem if you can say something like this. And what does it have to do with recipient ISP abuse desks? Your basic point is well taken, it would be better if everyone could do end to end TLS etc. Not so much to evade the NSA (probably hopeless for most people) but the more run of the mill snooper. It's all just an arms race. -- -Barry Shein The World | bzs@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*
That's essentially what I'm getting at. If the v6 addresses/blocks are allocated in a similar fashion to IPv4, where the octets are clearly named by state and "hsd1", then I don't see why they should lack PTR. However, even if they're not assigned or delegated in that way, it'd be helpful to have SOME form of PTR on there. Otherwise, they'd be a lot like Google, leaving the traceroute and end-point PTR left up to our imagination (even though it's available internally to Google employees). I understand why Google lacks PTR to some extent with anycast and the mobility of their v4 addresses, but I suspect that Comcast isn't doing anything that sophisticated. On Wed, Oct 9, 2013 at 11:47 AM, Robert Webb <rwebb@ropeguru.com> wrote:
On Wed, 9 Oct 2013 11:41:50 -0500 Chris Adams <cma@cmadams.net> wrote:
Once upon a time, Blair Trosper <blair.trosper@gmail.com> said:
Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
I believe business customers (with a static assignment) can request reverse DNS entries. Residential customers are not guaranteed a static assignment, so they can't get reverse set.
-- Chris Adams <cma@cmadams.net>
But how would thet differ from the IPv4 address space which has PTR records for all their IP's? Just the shear number they would have to deal with in the IPv6 space?
Robert
On 10/9/13 12:52 PM, "Blair Trosper" <blair.trosper@gmail.com> wrote:
That's essentially what I'm getting at. If the v6 addresses/blocks are allocated in a similar fashion to IPv4, where the octets are clearly named by state and "hsd1", then I don't see why they should lack PTR.
With the small # of IPv4 addresses, generating PTRs was not a big deal. That is not the case for IPv6 and I believe most large scale network operators would agree with that.
However, even if they're not assigned or delegated in that way, it'd be helpful to have SOME form of PTR on there.
Helpful for what, precisely? Jason
On Wed, Oct 09, 2013 at 11:35:16AM -0500, Blair Trosper wrote:
Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
Probably because of the considerations in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06. I seem to remember someone showing up in DNSOP one time to argue for a draft that the reverse mapping should just be optional under IPv6, but I can't lay my hands on the draft. The last time DNSOP tried to come up with recommendations about the reverse tree, the resulting document was http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-0.... It says, roughly, "Well, some peple use the reverse tree and some don't. You might want to think about that, or not." Despite asserting a version of "A or not-A", we were unable to achieve consensus, so I think the hope of consistency in the reverse tree is not supported by operational evidence. Best, A -- Andrew Sullivan Dyn, Inc. asullivan@dyn.com v: +1 603 663 0448
On 9 October 2013 09:58, Andrew Sullivan <asullivan@dyn.com> wrote:
On Wed, Oct 09, 2013 at 11:35:16AM -0500, Blair Trosper wrote:
Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
Probably because of the considerations in http://tools.ietf.org/html/draft-howard-isp-ip6rdns-06. I seem to remember someone showing up in DNSOP one time to argue for a draft that the reverse mapping should just be optional under IPv6, but I can't lay my hands on the draft. The last time DNSOP tried to come up with recommendations about the reverse tree, the resulting document was http://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-0.... It says, roughly, "Well, some peple use the reverse tree and some don't. You might want to think about that, or not." Despite asserting a version of "A or not-A", we were unable to achieve consensus, so I think the hope of consistency in the reverse tree is not supported by operational evidence.
Yet, apparently, Google has very recently completely stopped accepting email with no PTR records. On my Linode over the summer, it seems like this was the first mention of IPv6 in my errorlog: Aug 17 03:16:07 (none) dma[7de9.b8dd8ca8]: remote delivery to gmail-smtp-in.l.google.com [2607:f8b0:400e:c01::1b] failed after final DATA: 550-5.7.1 [2600:3c01:XXXX:: 16] The sender does not meet basic ipv6 sending#015#012550-5.7.1 guidelines of authentication and rdns resolution of sending ip.#015#012550-5.7.1 Please review#015#012550 5.7.1 https://support.google.com/mail/answer/81126for more information. zo6si1884856pac.170 - gsmtp Prior to 2013-08-17, most messages were delivered nightly without much problems (although these cron jobs did often end up in the Spam folder, and had to be rescued manually); after 2013-08-17, there was only one nightly message that got through, on 2013-08-26, and completely nothing since then: Sep 6 03:15:50 (none) dma[7f00.b9012ca8]: remote delivery to gmail-smtp-in.l.google.com [2a00:1450:4008:c01::1a] failed after final DATA: 550-5.7.1 [2600:3c01:XXXX:: 16] Our system has detected that this message#015#012550-5.7.1 does not meet IPv6 sending guidelines regarding PTR records and#015#012550-5.7.1 authentication. Please review#015#012550 5.7.1 https://support.google.com/mail/answer/81126 for more information. qk9si240507bkb.323 - gsmtp Oct 9 03:15:48 (none) dma[966a.b8dc0ca8]: remote delivery to gmail-smtp-in.l.google.com [2607:f8b0:400e:c01::1b] failed after final DATA: 550-5.7.1 [2600:3c01:XXXX:: 16] Our system has detected that this message#015#012550-5.7.1 does not meet IPv6 sending guidelines regarding PTR records and#015#012550-5.7.1 authentication. Please review#015#012550-5.7.1 https://support.google.com/mail/?p=ipv6_authentication_error for more#015#012550 5.7.1 information. vs7si29857999pbc.145 - gsmtp C.
Once upon a time, Constantine A. Murenin <mureninc@gmail.com> said:
On my Linode over the summer, it seems like this was the first mention of IPv6 in my errorlog:
I didn't see a problem, but my OCD-ness kicked in immediately when I got my Linode IPv6 - I've always had valid reverse DNS on IPv6 and IPv4 there. -- Chris Adams <cma@cmadams.net>
On 10/10/13 03:30, Constantine A. Murenin wrote:
Yet, apparently, Google has very recently completely stopped accepting email with no PTR records.
They also don't try very hard to get the PTR record. If the packet is lost, has a routing issue, or a DDoS prevents reliable access to the name servers, you will also get emails hard rejected until it resolves again. I'd always had correct rDNS so it took quite some head scratching to figure out the hiccup.
On Oct 9, 2013, at 12:35 PM, Blair Trosper <blair.trosper@gmail.com> wrote:
Does anyone know why (or can someone from Comcast explain why) there is no PTR on their residential/business IPv6 addresses?
Which IPv6 addresses: 1 delegated WAN address? 2 end systems on delegated LAN prefix or with static assignments? In my experience with Comcast Business Internet: 1 the delegated WAN address does have an (almost useless) PTR record which is essentially the AAAA spelled backward. 2 PTR records for automatically configured end systems on a local LAN are a local responsibility. Static IP assignments may come with PTR entries, depending on business arrangements. Since neither Comcast or any other DNS provider has any direct knowledge of your local network configuration, you cannot expect to see any PTR DNS records for local systems unless you make some business (and technical) arrangements with a DNS provider. If you really need PTR record for your local SMTP servers, arrange for them with your DNS provider, even if that provider is you. James R. Cutler james.cutler@consultant.com
participants (31)
-
Andrew Sullivan -
Barry Shein -
Bjørn Mork -
Blair Trosper -
bmanning＠vacation.karoshi.com -
Brielle Bruns -
Chris Adams -
Constantine A. Murenin -
Cutler James R -
Doug Barton -
Eugen Leitl -
Franck Martin -
James Cloos -
Jean-Francois.TremblayING＠videotron.com -
Jimmy Hess -
Joe Abley -
joel jaeggli -
John Levine -
John R. Levine
-
Lee Howard -
Livingood, Jason -
Lyndon Nerenberg -
Mark Andrews -
Matt Palmer -
Michael Thomas -
Paul Ferguson -
Robert Webb -
Ted Cooper -
Tim Franklin -
TJ -
Valdis.Kletnieks＠vt.edu