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 author
In message <5964ada4-8fcf-4fce-9e64-7474ccae5...@consultant.com>, Cutler James
R writes:
> On Nov 6, 2013, at 9:02 AM, Livingood, Jason
> wrote:
>
> > Reverse DNS for (typical) residential customer IPv6 addresses is dead,
> > people just haven't come to grips with it just yet.;-)
> >
> >
> > Wh
On Nov 6, 2013, at 9:02 AM, Livingood, Jason
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 different matter of course.
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 gene
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.
>
> Whi
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 sn
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 spe
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
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 not
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
In message , 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. While I am in homenet I woul
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 <87iow8tjw9@nemi.mork.no>, =?utf-8?Q?Bj=C3=B8rn_Mork?= writes:
> Mark Andrews 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. Se
Mark Andrews 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. I'd real
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
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
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
Hi,
Op 2 nov. 2013, om 12:16 heeft Masataka Ohta
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 means there is no NAT, the k
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
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
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
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 an
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 hu
On Fri, Nov 1, 2013 at 9:19 PM, Alex Rubenstein 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 situation for t
> 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.
(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
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.
Alex Rubenstein wrote:
>> >> Not necessarily. When the CPE is co
> >> 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
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.
>>
>>
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
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 tr
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.
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 ba
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. S
On Fri, Nov 1, 2013 at 3:03 AM, Masataka Ohta
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
>> http://tools.ietf.org/html/
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
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
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 th
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
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 w
>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
>
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 heur
>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
* Nolan Rollo :
> 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?
Mail admin
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
valdis.kletni...@vt.edu wrote:
>> Legal enforcement on zone administrators makes related zones
>> insecure.
>
> Citation, please?
Snowden.
Masataka Ohta
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
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 in
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,
N
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 '_
On Wed, Oct 30, 2013 at 5:33 PM, Nolan Rollo 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 upon a time ther
In message
, Scott Howard writes:
> On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo 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 coul
On Wed, Oct 30, 2013 at 2:33 PM, Nolan Rollo 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 also thinking of
On Wed, Oct 30, 2013 at 8:22 PM, William Herrin 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 acceptable,
On Oct 30, 2013, at 17:34, Nolan Rollo 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.
> I'm also thinking
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 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
On Wed, Oct 30, 2013 at 12:12 PM, 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.
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 b
On Oct 30, 2013, at 11: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,
> 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
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
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
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 IET
On Wed, Oct 30, 2013 at 9:12 AM, Nolan Rollo 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 de facto that
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 co
> 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
I've been (probably needlessly) pouring over the Reverse DNS RFCs for long
enough to actually have questions about a subject that should be relatively
unimportant. I do want to make sure that we set up our reverse DNS correctly
and most efficiently the first time so that we don't irritate other
68 matches
Mail list logo
