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.
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.
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.
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-06.
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
That's not necessarily true -- some (very large) organizations using DMARC
will reject mail from hosts without a PTR record.
- - ferg
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.
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.
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
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.
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
True, but a residential customer with a cable modem bootfile that blocks
port 25 wouldn't find that an issue.
Jason
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.
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
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.
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!
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.
> 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