In message 5279f5e1.9030...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
You misunderstand very basic points on why forward and reverse
DNS checking is useful.
If an attacker can snoop DHCP reply packet to a victim's CPE, the
attacker can snoop any packet to
Mark Andrews wrote:
The DHCP reply packet is special as is is broadcasted.
What?
Rfc3315 is explicit on it:
18.2.8. Transmission of Reply Messages
The Reply message MUST be unicast
through the interface on which the original message was received.
While IPv6 is unicast,
Reverse DNS for (typical) residential customer IPv6 addresses is dead,
people just haven¹t come to grips with it just yetŠ ;-)
When publicly-reachable services in home networks are created that may be
a different matter of course. But it is hard to imagine an ISP
automatically or dynamically
On Nov 6, 2013, at 9:02 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
Reverse DNS for (typical) residential customer IPv6 addresses is dead,
people just haven¹t come to grips with it just yetŠ ;-)
When publicly-reachable services in home networks are created that may be
a
In message 5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com, Cutler James
R writes:
On Nov 6, 2013, at 9:02 AM, Livingood, Jason
jason_living...@cable.comcast.com wrote:
Reverse DNS for (typical) residential customer IPv6 addresses is dead,
people just haven't come to grips with it
In message 5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com, Cutler James
R writes:
Dynamic DNS providers will undoubtably endeavor to make money from
and SRV entries for publicly-reachable services in SOHO and home
networks. Dynamic DNS providers are normally not delegated authority
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It would be great to have this conversation in the IETF Homenet WG, as
well as DNSops.
This would solve the gaps I identified. Not sure why I, as an ISP, would
spend money on this.
Lee
In message ce9e4e3c.367c3%...@asgard.org, Lee Howard writes:
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It would be great to have this conversation in the IETF Homenet WG, as
well as DNSops.
I did send the announcement to homenet as well with reply-to sent
to dnsop.
Sander Steffann wrote:
Also remember that this thread is on secure rDNS by the ISP,
which means you can't expect the ISP operate rDNS very securely
even though the ISP operate rest of networking not very securely.
You're linking things together that are completely orthogonal...
You
On Tue, Nov 5, 2013 at 6:00 PM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Sander Steffann wrote:
...
You're linking things together that are completely orthogonal...
You misunderstand very basic points on why forward and reverse
DNS checking is useful.
Just to note... the
In message 527986a2.6010...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Sander Steffann wrote:
Also remember that this thread is on secure rDNS by the ISP,
which means you can't expect the ISP operate rDNS very securely
even though the ISP operate rest of networking not very
Mark Andrews wrote:
You misunderstand very basic points on why forward and reverse
DNS checking is useful.
If an attacker can snoop DHCP reply packet to a victim's CPE, the
attacker can snoop any packet to a victim's server, which is
already bad.
The DHCP reply packet is special as is is
Mark Andrews ma...@isc.org writes:
That said it is possible to completely automate the secure assignment
of PTR records. It is also possible to completely automate the
secure delegation of the reverse name space. See
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
I like that.
In message 87iow8tjw9@nemi.mork.no, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
Mark Andrews ma...@isc.org writes:
That said it is possible to completely automate the secure assignment
of PTR records. It is also possible to completely automate the
secure delegation of the reverse name space.
Jimmy Hess wrote:
The trouble with end-to-end encryption as a solution;is the
difficulty/impossibility of establishing ipsec SAs with arbitrary
hosts on the internet; without manual pre-configuration of every pair of
hosts.
In this case, the ISP and the CPE are physically and
Mark Andrews wrote:
Who can see the packets sent from the local ISP to the CPE
directly connected to the ISP?
The dhcpd traffic coming in over the cable modem and you want to
send secrets in the clear over a channel like this.
Over the cable modem?
The cable modem is the CPE, which accept
In message 5274a77a.8090...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
Who can see the packets sent from the local ISP to the CPE
directly connected to the ISP?
The dhcpd traffic coming in over the cable modem and you want to
send secrets in the clear over
Mark Andrews wrote:
Over the cable modem?
Yes.
OK.
The cable modem is the CPE, which accept the DHCP packet to it.
A cable modem both accepts DHCP packets (for management of the
modem) and passes DHCP packets through to the customer device.
Even if the CPE does so, which means there
Hi,
Op 2 nov. 2013, om 12:16 heeft Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
het volgende geschreven:
Mark Andrews wrote:
A cable modem both accepts DHCP packets (for management of the
modem) and passes DHCP packets through to the customer device.
Even if the CPE does so, which
In message 5274def9.3040...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
Over the cable modem?
Yes.
OK.
The cable modem is the CPE, which accept the DHCP packet to it.
A cable modem both accepts DHCP packets (for management of the
modem) and passes
Sander Steffann wrote:
Hi,
Hi,
Even if the CPE does so, which means there is no NAT, the key to
update rDNS must, naturally, be contained only in DHCP reply to the
CPE.
You are misunderstanding the technology. Many cable operators offer a
cable modem in bridged mode so that the customer
Hi,
Also remember that this thread is on secure rDNS by the ISP,
which means you can't expect the ISP operate rDNS very securely
even though the ISP operate rest of networking not very securely.
You're linking things together that are completely orthogonal...
Sander
Mark Andrews wrote:
That said it is possible to completely automate the secure assignment
of PTR records. It is also possible to completely automate the
secure delegation of the reverse name space. See
http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
It is a lot simpler and a
On Fri, 01 Nov 2013 16:03:56 +0900, Masataka Ohta said:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
Hmm.. Shared secret between a CPE you don't necessarily control
and your own DNS server? This *will* get
On Fri, Nov 1, 2013 at 3:03 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp wrote:
Mark Andrews wrote:
That said it is possible to completely automate the secure assignment
of PTR records. It is also possible to completely automate the
secure delegation of the reverse name space. See
In message 5273525c.5060...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
That said it is possible to completely automate the secure assignment
of PTR records. It is also possible to completely automate the
secure delegation of the reverse name space. See
valdis.kletni...@vt.edu wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
Hmm.. Shared secret between a CPE you don't necessarily control
and your own DNS server?
Of course. That is the very basic
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE
device or to register the secret with the ISP.
Not necessarily. When
In message 52743027.7050...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
No it isn't. It requires a human to transfer the
In message 20131102002035.963ba96d...@rock.dv.isc.org, Mark Andrews writes:
In message 52743027.7050...@necom830.hpcl.titech.ac.jp, Masataka Ohta write
s:
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
No it isn't. It requires a human to transfer the secret to the CPE
device or to register the secret with the ISP.
Not necessarily. When
Not necessarily. When the CPE is configured through DHCP (or PPP?),
the ISP can send the secret.
Which can be seen, in many cases, by other parties
Who can see the packets sent from the local ISP to the CPE directly
connected to the ISP?
The NSA, FBI, CIA, DHS. Or, the ISP, the ISP's
(2013/11/02 10:48), Alex Rubenstein wrote:
Not necessarily. When the CPE is configured through DHCP (or PPP?),
the ISP can send the secret.
Which can be seen, in many cases, by other parties
Who can see the packets sent from the local ISP to the CPE directly
connected to the ISP?
The
we cannot assume that the connection between isp and cpe is a single entity.
a typical example will be the guy who run the dslam and the guy who run the
bras belong to two different companies in market which mandate open
access.
... which is very, very common.
On Fri, Nov 1, 2013 at 9:19 PM, Alex Rubenstein a...@corp.nac.net wrote:
a typical example will be the guy who run the dslam and the guy who run
the
bras belong to two different companies in market which mandate open
access.
... which is very, very common.
It's also a troublesome
In message 527459c4.5000...@necom830.hpcl.titech.ac.jp, Masataka Ohta writes:
Mark Andrews wrote:
It is a lot simpler and a lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.
No it isn't. It requires a human to transfer the secret
Mail admins wanting matching forward/reverse DNS and hostnames that
don't look dynamically generated is probably more of a human than an
RFC thing:
Right. Spam filtering depends on heuristics. Mail from hosts without
matching forward/reverse DNS is overwhelmingly bot spam, so checking
for it
John Levine wrote:
Right. Spam filtering depends on heuristics. Mail from hosts without
matching forward/reverse DNS is overwhelmingly bot spam, so checking for
it is a very effective heuristic.
Leading digit is clearly in widespread use beyond 3com 1and1. One of the most
effective
In the last few hours it has picked off multiple messages from each of these:
caro...@8447.com
jef...@3550.com
ronal...@0785.com
kevi...@2691.com
debora...@3585.com
kimberl...@5864.com
sara...@0858.com
zav...@131.com
qgmklyy...@163.com
pjp...@163.com
fahu...@163.com
danie...@4704.com
On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get consensus on the much more bland
statement, Some people rely on the reverse, and you might
163.com (as well as 126.com which you don't have listed) is a bit of a
special case.
It's a Chinese site that offers free email address as well as a very
popular portal site - think of it as the Chinese equivalent to Yahoo or
Hotmail.
Whilst it's certainly true that a lot of spam originates from
In message 5272e4a6.9080...@dcrocker.net, Dave Crocker writes:
On 10/30/2013 9:55 AM, Andrew Sullivan wrote:
As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get consensus on the much
relatively unimportant. I do want to make sure that we set up our
reverse DNS correctly
the only thing that's important is that forward and reverse DNS matches.
After that, there is no correct or incorrect, so you need to do something
that makes sense for your deployment.
Nick
On Wed, Oct 30, 2013 at 04:24:42PM +, Nick Hilliard wrote:
the only thing that's important is that forward and reverse DNS matches.
As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get
On Wed, Oct 30, 2013 at 9:12 AM, Nolan Rollo nro...@kw-corp.com wrote:
RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
I think you mean an Expired RFC Draft from 2006 written by the people from
SORBS states :
Which finally brings me to my questions:
It seems like the unspoken
On Wed, 30 Oct 2013, Andrew Sullivan wrote:
On Wed, Oct 30, 2013 at 04:24:42PM +, Nick Hilliard wrote:
the only thing that's important is that forward and reverse DNS matches.
As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the
On Wed, Oct 30, 2013 at 06:13:35PM +0100, Mikael Abrahamsson wrote:
The classic TCP wrapper had this as one of the security features
I would agree with that if you'd put scare-quotes around the word
security. In general anyone depending on the reverse tree to
provide them any kind of security
As for A records and PTR records matching, we've taken the approach that
we'll auto-create a matching PTR where there's only a single A record
with that IP. Otherwise, we'll add a PTR manually.
Plenty of applications can handle multiple A records; I'm not so sure
that the same holds true for
I've never seen anyone put in rDNS for networks or broadcast addresses.
I've done this a fair bit, on both a personal and professional basis. I find
it quite helpful when I forget what the subnet masks are (or fail to apply them
properly) and try and Do Something with an address that can't be
On Oct 30, 2013, at 11:55 AM, Andrew Sullivan asulli...@dyn.com wrote:
As I think I've said before on this list, when we tried to get
consensus on that claim in the DNSOP WG at the IETF, we couldn't.
Indeed, we couldn't even get consensus on the much more bland
statement, Some people rely on
On Wed, Oct 30, 2013 at 12:36:03PM -0500, Leo Bicknell wrote:
The SHOULD here is one way.
Of course, there is no SHOULD anywhere. RFC 1034 is from the era
before RFC 2119, and there really isn't any guidance on the use of the
reverse tree anywhere. It was the discovery of that very gap way
On Wed, Oct 30, 2013 at 12:12 PM, Nolan Rollo nro...@kw-corp.com wrote:
RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
When using IP addresses in host names, their numbers SHOULD be
separated by '.'s (dots) rather than any meta character such as a '-'
(dash) and
On Wed, Oct 30, 2013 at 03:22:55PM -0400, William Herrin wrote:
1. Use only English alphabetic characters (a-z, A-Z), numeric
characters (0-9), the hyphen and the period.
This was never required by any DNS RFC. Also, they're not English
characters, but ASCII ones.
The full stop character is
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm not arguing
with anyone but what potential problems could that cause with DNS?
I'm also thinking of the famous www.1and1.com, where the number 1 starts off
On Oct 30, 2013, at 17:34, Nolan Rollo nro...@kw-corp.com wrote:
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm not
arguing with anyone but what potential problems could that cause with DNS?
None.
On Wed, Oct 30, 2013 at 8:22 PM, William Herrin b...@herrin.us wrote:
Which finally brings me to my questions:
It seems like the unspoken de facto that mail admins appreciate
given the IP 203.0.113.15 is
203-0-113-15.[type].[static/dynamic].yourdomain.tld. This
seems perfectly
On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo nro...@kw-corp.com wrote:
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm not
arguing with anyone but what potential problems could that cause with DNS?
I'm
In message cacnpsnuxta3vyqsxute4x9nxfm_o+2bp7hqmbapxcm5_g5z...@mail.gmail.com
, Scott Howard writes:
On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo nro...@kw-corp.com wrote:
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off
On Wed, Oct 30, 2013 at 5:33 PM, Nolan Rollo nro...@kw-corp.com wrote:
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm
not arguing with anyone but what potential problems could that
cause with DNS?
Once
Nolan Rollo wrote:
RFC draft-msullivan-dnsop-generic-naming-schemes-00.txt states:
When using IP addresses in host names, their numbers SHOULD be
separated by '.'s (dots) rather than any meta character such as a '-'
(dash) and expressed in decimal. Host names SHOULD NOT use the '_'
Andrew Sullivan wrote:
The classic TCP wrapper had this as one of the security features
I would agree with that if you'd put scare-quotes around the word
security. In general anyone depending on the reverse tree to
provide them any kind of security is engaged in wishful thinking,
No, it's
On Wed, 30 Oct 2013 21:33:38 -, Nolan Rollo said:
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm not arguing
with anyone but what potential problems could that cause with DNS?
Only if the system
On Thu, 31 Oct 2013 07:42:44 +0900, Masataka Ohta said:
Legal enforcement on zone administrators makes related zones
insecure.
Citation, please?
pgpCicbgR2fqH.pgp
Description: PGP signature
valdis.kletni...@vt.edu wrote:
Legal enforcement on zone administrators makes related zones
insecure.
Citation, please?
Snowden.
Masataka Ohta
On October 30, 2013 at 19:07 valdis.kletni...@vt.edu (valdis.kletni...@vt.edu)
wrote:
On Wed, 30 Oct 2013 21:33:38 -, Nolan Rollo said:
So in the four examples below, 3 of them preface the IP with an alpha
character. Charter however, starts the rDNS off with a number. I'm not
* Nolan Rollo nro...@kw-corp.com:
It seems like the unspoken de facto that mail admins appreciate
given the IP 203.0.113.15 is
203-0-113-15.[type].[static/dynamic].yourdomain.tld. This seems
perfectly acceptable, it's short, detailed and to the point. Is
there really anything bad about this?
66 matches
Mail list logo
