Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 to
> provide PTR records for ISP managed addresses, making provision of
> complementary  and PTR records highly unlikely.
>
> Because of the cost of scaling and delegation issues I agree with Jason
> and see no compelling business case for rDNS services for SOHO or
> residential users.

Did you BOTHER TO READ the draft before commenting as the comments
imply that you haven't.  Nothing in the draft is more difficult
than is what is already being done inside enterprises networks today
every single minute of the day.

Enterprise DHCP servers construct DNS PTR records and add them to
the DNS using TSIG signed UPDATE requests.  They do it at one per
machine.

This is DHCP servers constucting a DNS KEY record and adding it to
the DNS using TSIG signed UPDATE requests.  The amount is ONE per
customer.  ISP's already support a PTR record per customer so your
scale arguement is blown out of the water.  This is draft addresses
the delegation issue by automating it so that any CPE device from
any manufacture can perform the delegation without humans being
involved.

Mark

> It's dead,
>   Jim
>
> James R. Cutler
> james.cut...@consultant.com

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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.;-)
> >
> >
> > 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 generating reverse records for all the IPv6
> > addresses handed out to your average residential users.
> >
> > Jason

This discussion is currently NOT about ISP's generating PTR records
for IPv6 reverse.

It is about the automatic delegation of the DNS reverse namespace
to to servers under customer control when the CPE device requests
it as part of the Prefix Delegation request.  This is about a adding
KEY, DS and NS records at the delegation point in a secure manner.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Cutler James R]

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. But it is hard to imagine an ISP
> automatically or dynamically generating reverse records for all the IPv6
> addresses handed out to your average residential users.
> 
> Jason
> 
> 
> On 11/5/13, 12:31 AM, "Lee Howard"  wrote:
> 
>> 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
>> 
>> 
>> 
> 
> 

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 to provide PTR records for ISP 
managed addresses, making provision of complementary  and PTR records 
highly unlikely.  

Because of the cost of scaling and delegation issues I agree with Jason and see 
no compelling business case for rDNS services for SOHO or residential users. 

It’s dead,
Jim 

James R. Cutler
james.cut...@consultant.com






signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Reverse DNS RFCs and Recommendations

[Livingood, Jason]

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 generating reverse records for all the IPv6
addresses handed out to your average residential users.

Jason


On 11/5/13, 12:31 AM, "Lee Howard"  wrote:

>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
>
>
>

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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, IPv4 isn't and having a scheme that will work
> for IPv4 as well as IPv6 is useful.

In your draft, you wrote:

   CPE generates DHCPv6 Prefix Delegation [RFC3633] request which

Moreover, even for IPv4, the scheme can (and should) mandate unicast
DHCP reply.

> Also there is NO GUARANTEE that
> the response can't be seen so you design the protocol to work when
> it can be seen.

Your misunderstanding on DHCPv6 is OK, because you also
misunderstand that it were more secure?

Then, as there is NO GUARANTEE that CAs of DNSSEC can't be
compromised, you MUST design the protocol to work when they
can be compromised.

>> And carrying TSIG key in DHCP reply is just secure from the both
>> sides.
>
> Not in the clear it isn't.

Clear text in DHCP reply is just secure when required security
level allows to use DHCP.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 a victim's server, which is
> >> already bad.
> > 
> > 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, IPv4 isn't and having a scheme that will work
for IPv4 as well as IPv6 is useful.  Also there is NO GUARANTEE that
the response can't be seen so you design the protocol to work when
it can be seen.

> >> That is, Mark's security model is broken only to introduce
> >> obscurity with worse security.
> > 
> > This is a about adding a delegation into the DNS securely so only
> > the machine that the prefix is delegated to and the ISP can update
> > it.  There are a number of reasons to want to do this securely from
> > both the ISP side and the customer side regardless of whether you
> > secure the DNS responses themselves.
> 
> And carrying TSIG key in DHCP reply is just secure from the both sides.

Not in the clear it isn't.
 
>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 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.

>> That is, Mark's security model is broken only to introduce
>> obscurity with worse security.
> 
> This is a about adding a delegation into the DNS securely so only
> the machine that the prefix is delegated to and the ISP can update
> it.  There are a number of reasons to want to do this securely from
> both the ISP side and the customer side regardless of whether you
> secure the DNS responses themselves.

And carrying TSIG key in DHCP reply is just secure from the both sides.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 securely.
> > 
> > You're linking things together that are completely orthogonal...
> 
> 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 broadcasted.  The
unicast traffic isn't seen.

> Worse, the attacker can override a connection to the server by
> forging reply packets as if they are returned by the legitimate
> server with correct TCP sequence numbers etc, which is especially
> effective if combined with DOS attack to the legitimate server.
>
> 
> Thus, there is no point to make forward and reverse DNS secure.
> 
> That is, Mark's security model is broken only to introduce
> obscurity with worse security.

This is a about adding a delegation into the DNS securely so only
the machine that the prefix is delegated to and the ISP can update
it.  There are a number of reasons to want to do this securely from
both the ISP side and the customer side regardless of whether you
secure the DNS responses themselves.

>   Masataka Ohta
> 
> PS
> 
> If the server and its clients share some secret for mutual
> authentication as protection against snooping, there is no
> point to make forward and reverse DNS secure.
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Jimmy Hess]

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 main reason checking reverse DNS stays useful:  is
because that it is so hard to change in many cases.

Specifically:  if a server at some IP address X is under the control of a
spammer;   and rDNS is not setup,  or  rDNS  points to some
 dynamic-looking hostname,

It will be difficult or not possible for the spammer to modify the RDNS of
the IP address, in many cases;  the RDNS is  most often managed by the ISP.

Or it may be in a DNS infrastructure running on separate networks, with
separate access credentials.


If RDNS were easy to change;  e.g. if you just needed to guess a password
to the server,  and get signing key information from a DHCP transaction;
 the spammer would just change it.


Delegating  "Secure RDNS update"   with prefix delegation  may in fact,
 make RDNS information so easy to publish, that the spammers of the
world can do it,  after  compromising a router or  host on the victim
network,  and just  "Registering the better hostname in the DNS".



The update process may be "secure",  but there are new attack vectors.


The value of  even looking at RDNS,  let alone worrying about
Forward+Reverse DNS  agreement/confirmation   may not translate well to
IPv6.


--
-JH

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 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.

Worse, the attacker can override a connection to the server by
forging reply packets as if they are returned by the legitimate
server with correct TCP sequence numbers etc, which is especially
effective if combined with DOS attack to the legitimate server.

Thus, there is no point to make forward and reverse DNS secure.

That is, Mark's security model is broken only to introduce
obscurity with worse security.

Masataka Ohta

PS

If the server and its clients share some secret for mutual
authentication as protection against snooping, there is no
point to make forward and reverse DNS secure.

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 would prefer the conversation
in one place in the IETF.  I do realise that it also needs to be
here and potentially other places.

> This would solve the gaps I identified.  Not sure why I, as an ISP, would
> spend money on this.

What money do they need to spend once the DHCP server supports it?

It's a little bit of disk, a little bit of memory, a little bit
less DNS traffic to their servers (as the referral will push
queries to the customer's DNS servers) which is will come in at
cents per customer per annum.  Enterprises effectively do the
equivalent amount of work today registering PTR records in the DNS
using TSIG requests from the DHCP server.

Mark

> Lee
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Lee Howard]

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

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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.  See
> > http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
>
> I like that.  I'd really like to see CPE vendors implementing it.
>
> AFAICT, it is perfectly possible to apply that on top of the idea you
> had about letting TCP clients update their own key. CPEs supporting the
> DHCPv6 option will use that, while the others still have the ability to
> add a KEY record from a TCP client in the deletated prefix.  As long as
> you let TSIG signed updates trump anything and do not allow unsigned
> updates if there is a KEY, then these should work just fine together.
>
> But I believe the draft could use a couple of clarifications to avoid
> interpretation bugs:
>
>CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
>includes a KEY-RDATA option (code point TBA) which contains a the
>rdata of a DNS KEY record containing a RSASHA256 key using the public
>components of the previously generated RSA key pair.
>
> Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
> "top level" option?  I.e. will it be possible to set different keys for
> (the theoretical) multi-prefix requests?

As far as I cans see there is no point in using different key RDATA.
All it does is introduce key management problems.  I expect a CPE
to only use a single public key for all prefixes that are delegated
to it.  That said we should look at rolling the key.  CPE replacement
etc.

> We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
> it is important to explicitly state where such options, which may be
> considered local to part of the DHCPv6 message, belong.  I do know that
> RFC3315 is clear on the default:
>
>Unless otherwise noted, each option may appear only in the options
>area of a DHCP message and may appear only once.
>
> But experience with OPTION_DNS_SERVERS has shown that this is not
> enough.  Pleace be explicit about where in the packet any new DHCPv6
> options belong.
>
>
>CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
>name space to itself and others if they have been configured.  The
>CPE uses SIG(0) [RFC2931] to sign the request with owner name
>matching the reverse of the delegated prefix.
>
> This could use a few examples and clarifications wrt the owner name.  I
> interpret it as:
>
>  IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>
> But what about for example IA_PD = 2001:db8:2:4::/62 ?  Are you going to
> add multiple owner names, or should there be some rule here allowing
> multiple delegations with a single owner name for PD on non-nibble
> boundaries?  For example
>
>  IA_PD = 2001:db8:2:4::/62
>=> owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>   allowed to update:
>  4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>  5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>  6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
>  7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

The DHCP server would add multiple KEY records each with the same
RDATA.  This would still be a single DNS UPDATE transaction. A non
nibble aligned PD results in multiple delegations in the DNS.

The CPE would perform multiple DNS UPDATE requests, one for each
delegation.

Doing it the other way would require telling the nameserver the
nameserver that key A is allowed to update B, C and D as well.

With multiple keys each one is self describing about what it can
update.  In terms of named's update policy you would just add this
grant clause to the zone configuration on the master to allow the
CPE to add/update the delegation.

update-policy {
grant * self *;
};

> (not that I would ever consider delegating prefixes on anything but
> nibble boundaries, but someone else might - and the draft should
> consider this possibility)
> 
> 
> 
> Bj=C3=B8rn
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Bjørn Mork]

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 really like to see CPE vendors implementing it.

AFAICT, it is perfectly possible to apply that on top of the idea you
had about letting TCP clients update their own key. CPEs supporting the
DHCPv6 option will use that, while the others still have the ability to
add a KEY record from a TCP client in the deletated prefix.  As long as
you let TSIG signed updates trump anything and do not allow unsigned
updates if there is a KEY, then these should work just fine together.

But I believe the draft could use a couple of clarifications to avoid
interpretation bugs:

   CPE generates DHCPv6 Prefix Delegation [RFC3633] request which
   includes a KEY-RDATA option (code point TBA) which contains a the
   rdata of a DNS KEY record containing a RSASHA256 key using the public
   components of the previously generated RSA key pair.

Is this new DHCPv6 option to be placed under OPTION_IA_PD, or is it a
"top level" option?  I.e. will it be possible to set different keys for
(the theoretical) multi-prefix requests?

We've already seen confusion wrt placement of the OPTION_DNS_SERVERS, so
it is important to explicitly state where such options, which may be
considered local to part of the DHCPv6 message, belong.  I do know that
RFC3315 is clear on the default:

   Unless otherwise noted, each option may appear only in the options
   area of a DHCP message and may appear only once.  

But experience with OPTION_DNS_SERVERS has shown that this is not
enough.  Pleace be explicit about where in the packet any new DHCPv6
options belong.


   CPE device generates DNS UPDATE [RFC2136] which delegates the reverse
   name space to itself and others if they have been configured.  The
   CPE uses SIG(0) [RFC2931] to sign the request with owner name
   matching the reverse of the delegated prefix.

This could use a few examples and clarifications wrt the owner name.  I
interpret it as:

 IA_PD = 2001:db8:1::/48 => owner name = 1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa

But what about for example IA_PD = 2001:db8:2:4::/62 ?  Are you going to
add multiple owner names, or should there be some rule here allowing
multiple delegations with a single owner name for PD on non-nibble
boundaries?  For example

 IA_PD = 2001:db8:2:4::/62 
   => owner name = 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
  allowed to update:
 4.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
 5.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
 6.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
 7.0.0.0.2.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa


(not that I would ever consider delegating prefixes on anything but
nibble boundaries, but someone else might - and the draft should
consider this possibility)



Bjørn

Re: Reverse DNS RFCs and Recommendations

[Sander Steffann]

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

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 can attach his own
> home-router behind it.

The situation is no different from:

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

Though some ISPs do not operate their network very securely,
you can't have better security than that offered by your local
ISP.

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.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 DHCP packets through to the customer device.
> 
> 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.

A cable modem is a media converter.  That can be managed and that
management interface also uses DHCP is irrelevent.

> And, I'm afraid your draft assumes that the CPE behaves as a
> DHCP server for local hosts, which means the CPE is responsible
> for rDNS registration.

My draft assumes the CPE device is a PD client.  It may or may not
be a DHCP server for the internal network.  Again that is irrelevent.

>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Sander Steffann]

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 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 can attach his own home-router 
behind it. Sending keys over a medium shared between multiple customers is not 
safe.

Cheers,
Sander

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 is no NAT, the key
to update rDNS must, naturally, be contained only in DHCP reply
to the CPE.

And, I'm afraid your draft assumes that the CPE behaves as a
DHCP server for local hosts, which means the CPE is responsible
for rDNS registration.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 a channel like this.
> 
> Over the cable modem?

Yes.
 
> 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.

>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 the DHCP packet to it.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 directly
connected with modest security, which makes automation possible.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 to the CPE
> >>> device or to register the secret with the ISP.
> >>
> >> 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 dhcpd traffic coming in over the cable modem and you want to
send secrets in the clear over a channel like this.

bsdi# tcpdump -n -i sis0 port bootpc
tcpdump: listening on sis0
15:05:15.637252 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc58c07ae 
flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp]
15:05:15.650590 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc58c07ae 
flags:0x8000 Y:122.106.168.231 G:10.72.0.1 ether 0:1d:9:81:64:ba [|bootp]
15:05:34.942619 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb 
flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 0:17:ee:4c:f3:74 
[|bootp]
15:05:36.975213 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb 
secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 
0:17:ee:4c:f3:74 [|bootp]
15:05:36.992714 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x122cf3bb 
secs:2 flags:0x8000 Y:10.72.194.250 S:10.72.0.1 G:10.72.0.1 ether 
0:17:ee:4c:f3:74 [|bootp]
15:05:55.931705 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 
flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:57.951400 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 secs:2 
flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:57.964049 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x732 secs:2 
flags:0x8000 Y:10.72.3.3 S:10.72.0.1 G:10.72.0.1 ether 0:11:1a:19:25:a2 [|bootp]
15:05:58.930921 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2af 
flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:00.054322 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2b0 
flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:00.068061 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0xc7dba2b0 
flags:0x8000 Y:122.106.152.0 G:10.72.0.1 ether 0:14:bf:a0:db:c8 [|bootp]
15:06:08.933232 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 
flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 0:1a:de:6f:99:e6 
[|bootp]
15:06:10.941233 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 
secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 
0:1a:de:6f:99:e6 [|bootp]
15:06:10.959519 10.72.0.1.67 > 255.255.255.255.68:  hops:1 xid:0x111fb9c2 
secs:2 flags:0x8000 Y:10.72.23.110 S:10.72.0.1 G:10.72.0.1 ether 
0:1a:de:6f:99:e6 [|bootp]
^C
10638 packets received by filter
0 packets dropped by kernel
bsdi# 

> If you mind wire tapping, you have other things to worry
> about, which needs your access line encrypted (by a manually
> configured password), which makes DHCP packets invisible.
> 
>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Jimmy Hess]

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 the ISP;  it may be  "open access" on
paper,  but  DSLAMs and  bras  break,  and then the ISP is potentially at
the mercy of  bureaucratic support walls and the  DSLAM operator,   who
would love to create as many weeks delay in repair as possible and pay lip
service to getting issues addressed;  for the end user to get frustrated,
blame the ISP, and switch service  to their own.


But yeah  sniffing/tapping can targetthe underlying link provider.

Or it can even involve  agents  tapping into  copper wires  with alligator
clips,  unbeknownst to even the DSLAM operator.


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.


-- 
-JH

RE: Reverse DNS RFCs and Recommendations

[Alex Rubenstein]

> 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.

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

(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 NSA, FBI, CIA, DHS.

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

> Or, the ISP, the ISP's employees, contractors, sub-contractors.

If you can't trust the ISP, you can't make rDNS operated
by the ISP secure.

> Or the phone company handling the PPPOE, L2TP, or whatever else.

>> If you mind wire tapping, you have other things to worry
>> about, which needs your access line encrypted (by a manually
>> configured password), which makes DHCP packets invisible.

> Or the WiFi sniffer on the street outside.

Does your CPE retransmit a received DHCP reply to Wifi?

Masataka Ohta

RE: Reverse DNS RFCs and Recommendations

[Beng Hui Ong]

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 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 employees, contractors, 
>sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever 
>else. Or the WiFi sniffer on the street outside.
>
>
>
>

RE: Reverse DNS RFCs and Recommendations

[Alex Rubenstein]

> >> 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 employees, contractors, 
sub-contractors. Or the phone company handling the PPPOE, L2TP, or whatever 
else. Or the WiFi sniffer on the street outside.

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 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?

If you mind wire tapping, you have other things to worry
about, which needs your access line encrypted (by a manually
configured password), which makes DHCP packets invisible.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 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 the CPE is configured through DHCP (or
> > PPP?), the ISP can send the secret.
> 
> Which can be seen, in many cases, by other parties which is why I
> discounted plain TSIG key exchanges over DHCP years ago regardless
> of which side send the key material.

Now you could do a DH key exchange over DHCP then do a encrypted
TSIG key exchange.  This however also requires a encrypted key
exchange of the TSIG with the nameserver.  The DHCP server could
do this with TKEY.

Note a full DH key exhange is not strictly required.  The CPE could
just send a public key and the DHCP server could encrypt the TSIG
secret using it when replying.

> > > I'm talking about just building this into CPE devices and having it
> > > just work with no human involvement.
> > 
> > See above.
> > 
> > Involving DNSSEC here is overkill and unnecessarily introduce
> > vulnerabilities.
> 
> You do realise that you can use KEY records without DNSSEC.  The
> KEY record is in the zone to be updated so it is implictly trusted.
> 
> > Masataka Ohta
> -- 
> Mark Andrews, ISC
> 1 Seymour St., Dundas Valley, NSW 2117, Australia
> PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 secret to the CPE
> > device or to register the secret with the ISP.
> 
> 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 which is why I
discounted plain TSIG key exchanges over DHCP years ago regardless
of which side send the key material.

> > I'm talking about just building this into CPE devices and having it
> > just work with no human involvement.
> 
> See above.
> 
> Involving DNSSEC here is overkill and unnecessarily introduce
> vulnerabilities.

You do realise that you can use KEY records without DNSSEC.  The
KEY record is in the zone to be updated so it is implictly trusted.

>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 the CPE is configured through DHCP (or
PPP?), the ISP can send the secret.

> I'm talking about just building this into CPE devices and having it
> just work with no human involvement.

See above.

Involving DNSSEC here is overkill and unnecessarily introduce
vulnerabilities.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

 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 requirement for any security
between two parties.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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
> > http://tools.ietf.org/html/draft-andrews-dnsop-pd-reverse-00
> 
> 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.

I'm talking about just building this into CPE devices and having it
just work with no human involvement.

> As the secret can be directly shared end to end, it is more
> secure than DNSSEC involving untrustworthy third parties.
> 
>   Masataka Ohta
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[William Herrin]

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/draft-andrews-dnsop-pd-reverse-00
>
> 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.

Howdy,

I hope you don't mean to suggest that a user should be able to use his
normal ISP username and password to set those DNS records which the
ISP has determined that he's allowed to set. That's just crazy talk!

Regards,
Bill Herrin


-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Reverse DNS RFCs and Recommendations

[Valdis . Kletnieks]

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 you a dartboard with
your picture on it at the ISP's help desk.


pgp9_mr_OWSEw.pgp
Description: PGP signature

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 lot more practical just to
use shared secret between a CPE and a ISP's name server
for TSIG generation.

As the secret can be directly shared end to end, it is more
secure than DNSSEC involving untrustworthy third parties.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 more bland
> > statement, "Some people rely on the reverse, and you might want to
> > take that into consideration when running your services."
> >
> > Now, IETF non-consensus on the way the Internet works is hardly a
> > surprise, but I thought I'd point this out just in case people want to
> > be prepared for flames from people who feel strongly about the matter.
> 
> 
> I'm beginning to think that documenting failures to get consensus could 
> be almost as important as documenting successes, in order to provide a 
> basis for countering folks who claim something is required, when there's 
> explicit public experience that it isn't.
> 
> Looks to me that Andrew's note is an example of that potential benefit. 
>   Rather than having to have someone remember this stuff, anyone could 
> point to the 'failure' document.

There is consensus.  There SHOULD be PTR records.  This is even
documented in various RFC.

Now the methods IPS's use to do this for home customer addresses
with IPv4 don't scale to IPv6.  They also don't let the home customer
specify the name in the PTR record.

Additionally ISP's use PTR records as a revenue source by only
offering to set them to commercial customers.  Part of this is
that it is often a manual proceedure.

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 (yes
I am aware of the typos which I will fix once the submission window
re-opens).  Similar techiques can be applied to individual IPv4
delegations.  You add PTR records rather than NS and DS records.

In named the SIG(0) signed UPDATE requests are granted using

update-policy { grant * self *; };

when setting up the reverse zone.  The code to do it is over a
decade old at this point.

It just requires willingness to do it.  For ISP's to come out of
the 90's and use the technology that was designed to allow this to
happen.

Mark

> d/
> 
> -- 
> Dave Crocker
> Brandenburg InternetWorking
> bbiw.net
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Scott Howard]

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 there, simply
classifying it as a spam site isn't (necessarily) correct, in the same way
that classifying yahoo or hotmail as spam isn't correct. The company behind
163.com is actually listed on the NASDAQ...

You did mention heuristics, so I'm guessing you're not actually just
outright blacklisting it, just wanted to point out that all number-only
domains aren't necessarily spam-only.

  Scott



On Thu, Oct 31, 2013 at 3:49 PM, Tony Hain  wrote:

> 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 heuristics in my acl list is:
> \N^.*@\d{3,}\.(cn|com|net|org|us|asia)
>
> 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
> hele...@2620.com
>
>
>
>

Re: Reverse DNS RFCs and Recommendations

[Dave Crocker]

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 want to
take that into consideration when running your services."

Now, IETF non-consensus on the way the Internet works is hardly a
surprise, but I thought I'd point this out just in case people want to
be prepared for flames from people who feel strongly about the matter.



I'm beginning to think that documenting failures to get consensus could 
be almost as important as documenting successes, in order to provide a 
basis for countering folks who claim something is required, when there's 
explicit public experience that it isn't.


Looks to me that Andrew's note is an example of that potential benefit. 
 Rather than having to have someone remember this stuff, anyone could 
point to the 'failure' document.


d/

--
Dave Crocker
Brandenburg InternetWorking
bbiw.net

Re: Reverse DNS RFCs and Recommendations

[John Levine]

>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
>hele...@2620.com

163.com is Netease, one of the larger ISPs in China.  If you don't
have any users who speak Chinese, you can probably block it, but if
you do, you'll get complaints.

RE: Reverse DNS RFCs and Recommendations

[Tony Hain]

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 heuristics in my acl list is:
\N^.*@\d{3,}\.(cn|com|net|org|us|asia)

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
hele...@2620.com

Re: Reverse DNS RFCs and Recommendations

[John Levine]

>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 is a very effective heuristic.

Mail from hosts with names that look dynamic is also quite spammy, but
figuring out what looks dynamic is quite hard.  I know someone who's been
tuning his regexes for years.  For most people, third party lists like
the Spamhaus PBL are more reliable.

R's,
John

Re: Reverse DNS RFCs and Recommendations

[Stefan Förster]

* 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 admins wanting matching forward/reverse DNS and hostnames that
don't "look dynamically generated" is probably more of a human than an
RFC thing: "We used to get a lot of spam from dialup IPs, or IPs
without matching reverse DNS, so let's reject anything that comes from
an IP without FcRDNS and greylist anything with more than X dashes and
Y dots in it's hostname."


Stefan


signature.asc
Description: Digital signature

Re: Reverse DNS RFCs and Recommendations

[Barry Shein]

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 
 > > arguing
 > > with anyone but what potential problems could that cause with DNS?
 > 
 > Only if the system involved got on the net before 3com did (as RFC1123
 > specifically relaxed this requirement back in 1989).
 > 
 > And at that point, Indiana Jones would say "It belongs in a *museum*".
 > 

Back when I put Boston University on the net, pre-DNS, an accidentally
included host name with a leading digit submitted for the HOSTS.TXT
file brought down probably over half the net, many many unix systems.

There was a bug in the program which converted from the HOSTS.TXT
format to the unix /etc/hosts format. It went into a loop filling the
root partitions which in those days hung a unix system hard, and many
sites used unix systems as their main or only internet connection, no
fancy on-site routers back then.

Typically sites loaded the new HOSTS.TXT file after (or exactly at)
midnight automatically so not a lot of systems staff around to recover
which made it all the more painful.

So I heard a lot about this "no leading digits in host names rule" the
next day though when everyone calmed down it was agreed that the
conversion program shouldn't have behaved so poorly.

-- 
-Barry Shein

The World  | b...@theworld.com   | http://www.TheWorld.com
Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada
Software Tool & Die| Public Access Internet | SINCE 1989 *oo*

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

valdis.kletni...@vt.edu wrote:

>> Legal enforcement on zone administrators makes related zones
>> insecure.
> 
> Citation, please?

Snowden.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Valdis . Kletnieks]

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

Re: Reverse DNS RFCs and Recommendations

[Valdis . Kletnieks]

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 involved got on the net before 3com did (as RFC1123
specifically relaxed this requirement back in 1989).

And at that point, Indiana Jones would say "It belongs in a *museum*".



pgpRk8VBQ522p.pgp
Description: PGP signature

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 you who have wishful thinking.

> particularly if the lookup isn't validated with DNSSEC.

As is discussed recently in IETF main and dns MLs, Lack of
secure time in most environment makes DNSSEC insecure.

Legal enforcement on zone administrators makes related zones
insecure.

For most users, security by plain DNS with reverse look up is
fine.

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[Masataka Ohta]

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 '_'
> (underscore) character, host names for hosts with any form of SMTP
> mail service MUST NOT use the '_' (underscore) character.  It is
> preferable to use the IP address in reverse format in the same way
> the the IN-ADDR.ARPA. domain is defined.

That's not correct.

Not all domain names are host names, which is why '_' is allowed
for some domain names such as:

  _ldap._tcp.example.com [rfc2782]

However, though rfc1034 specifies;

   For example, when naming a mail domain, the user should satisfy
   both the rules of this memo and those in RFC-822.  When creating
   a new host name, the old rules for HOSTS.TXT should be followed.

both of "should" in the rfc should, today, be interpreted as "MUST".

Masataka Ohta

Re: Reverse DNS RFCs and Recommendations

[William Herrin]

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 there were buggy software implementations which
looked at the first character of the "name" to decide whether it was a
host name or an IP address. How many of them still exist? Not many
would be my guess.

> 3. Start each section of the name with a letter, not a number or hyphen.

The question I would ask myself is: will I recognize a gain from
putting a digit first in the name instead of a letter? If yes, it's
probably enough of an advantage to not worry about the old
implementations. If no (and it surely seems to be "no" in Nolan's
case) then keep to the conventions that work even with the ancient
buggy crap.

Regards,
Bill Herrin

-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Reverse DNS RFCs and Recommendations

[Mark Andrews]

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 could that cause with DNS?
> > I'm also thinking of the famous  www.1and1.com, where the number "1"
> > starts off one of the sections.
> >
> 
> Using domain name parts that start with a number will likely cause issues
> for anyone running resolvers written in the 80's.
> 
> Anyone running resolvers that are less than ~25 years will likely not have
> any issues.
> 
>   Scott

To be more precise it will cause no problems with the DNS.  Some
pre RFC 1123 gethostbyname implementations may reject the name
but the DNS doesn't care.

Mark
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Reverse DNS RFCs and Recommendations

[Scott Howard]

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 the famous  www.1and1.com, where the number "1"
> starts off one of the sections.
>

Using domain name parts that start with a number will likely cause issues
for anyone running resolvers written in the 80's.

Anyone running resolvers that are less than ~25 years will likely not have
any issues.

  Scott

Re: Reverse DNS RFCs and Recommendations

[Matthias Leisi]

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, it's short, detailed and to the
> > point. Is there really anything bad about this?
>
>
> reputation services. They use this information when classifying the
> source and grouping sources into netblocks. If you take the time to
> distinguish your intended mail servers from your dialup address pool
> they'll try not to include your mail server when they ban mail
> directly from your dialup address pool.
>

At dnswl.org, we identify new servers from looking at the rDNS in what we
see is being queried through our logs. Names with "dynamic", "dialup" etc
or that look like they have an embedded IPv4 address are discarded through
that channel.

-- Matthias

Re: Reverse DNS RFCs and Recommendations

[Joe Abley]

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 of the famous  www.1and1.com, where the number "1" starts 
> off one of the sections.

Which is fine.


Joe

RE: Reverse DNS RFCs and Recommendations

[Nolan Rollo]

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 
one of the sections. 



3. Start each section of the name with a letter, not a number or hyphen.



> Actual Examples:
> cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX 
> d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX 
> c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX 
> 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

Re: Reverse DNS RFCs and Recommendations

[Andrew Sullivan]

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 not actually part of the name.  It's a
separator.  For presentation format (i.e. the one you see and
manipulate) you need to use it, but be aware that it is not a part of
the name as such.  (This is why IDNA can't provide an "alternate"
separator.)

In my opinion, it's really better to think in terms of labels.  Labels
are separated by dots in presentation format, and by label length
markers in wire format.  In order to maximise interoperability, it is
wise to stick to the LDH rule (which is roughly what William says
above: ASCII letters either upper or lower case, digts, and the
hyphen).  But in principle, labels can be made of any octets you like.

Note that, if you use IDNA (internationalized labels) in the most
recent version (IDNA2008), the U-label form doesn't allow upper case.
This yields the bizarre example that Fass is a label (LDG) and fass is
a label (LDH) and faß is a label (U-label) but Faß is _not_ a valid
label.

> 3. Start each section of the name with a letter, not a number or hyphen.

This isn't a requirement and hasn't been since the so-called "3com
rule" change in RFC 1123.  See RFC 1123 section 2.1.  The topmost
label, however, _cannot_ begin with a number.  No label may begin with
a hyphen.

> 4. Two hyphens can't be side by side, nor can a hyphen start or end a
> section of the name.

Two hyphens can be side be side, but if you plan to be compatible with
IDNA they can't be side by side in the 3d and 4th positions.  That is,
foobar--baz is a perfectly good label.  fo--obarbaz is not.  This is
so that strategies along the lines of "xn--", which is used for INDA,
can be used again in the future for other issues.

> Finally, the cardinal rule of reverse dns: whatever name the address
> resolves to must resolve back to the address. 

This is a requirement for matching reverse.  As I've already suggested
in this thread more than once, it is by no means an uncontroversial
claim.

Best,

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: Reverse DNS RFCs and Recommendations

[William Herrin]

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.  Host names SHOULD NOT use the '_'
>(underscore) character, host names for hosts with any form of SMTP
>mail service MUST NOT use the '_' (underscore) character.  It is
>preferable to use the IP address in reverse format in the same way
>the the IN-ADDR.ARPA. domain is defined.

Hi Nolan,

Although no longer strictly required by the DNS RFCs, names which
follow these conventions are more likely to work with everyone else's
DNS servers.

1. Use only English alphabetic characters (a-z, A-Z), numeric
characters (0-9), the hyphen and the period.

2. The periods separate non-null sections of the name. You can't start
a name with a period or have two periods side by side.

3. Start each section of the name with a letter, not a number or hyphen.

4. Two hyphens can't be side by side, nor can a hyphen start or end a
section of the name.


Finally, the cardinal rule of reverse dns: whatever name the address
resolves to must resolve back to the address. If you don't do that,
you're basically asking for a whole bunch of servers on the Internet
to reject your connections.  So:

13.12.11.10.in-addr.arpa PTR bob.examplecompany.com.
bob.examplecompany.com. A 10.11.12.15

is wrong (13!=15) and will cause your users problems! Also, if you
omit the A record and simply have the PTR record, that too will cause
your users problems. If you omit the A record, you should also omit
the PTR record and let the address stand without DNS.


> Actual Examples:
> cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX
> d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX
> c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX
> 24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

All of these examples are fine provided the forward DNS (A record) matches.



> 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, it's short, detailed and to the
> point. Is there really anything bad about this?

This is mainly for the benefit of the folks who run RBLs or other mail
reputation services. They use this information when classifying the
source and grouping sources into netblocks. If you take the time to
distinguish your intended mail servers from your dialup address pool
they'll try not to include your mail server when they ban mail
directly from your dialup address pool.

It's more a human factors question than supporting any automation.
You're hoping that by explaining your network to the antispammers
they'll cut you some slack when one of your doofus users gets pwned by
a spam bot. Many will. Some won't.


> What, if any would you name a network, gateway, broadcast address?
> Should the PTR be empty?

Pretty much whatever you want or nothing at all. If it doesn't
originate packets then nobody out there cares what it's named.

Regards,
Bill Herrin




-- 
William D. Herrin  her...@dirtside.com  b...@herrin.us
3005 Crane Dr. .. Web: 
Falls Church, VA 22042-3004

Re: Reverse DNS RFCs and Recommendations

[Andrew Sullivan]

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 back
in 2006 that caused me to try to resurrect Daniel Senie's original
draft and drive it through DNSOP.  I think I was less cynical in those days.

> purpose here.  Tools that receive IP addresses will generate names
> using reverse lookups, those names should then work.  For instance if
> trace route gives a name, "ping " should then work.

Rather than "should" here, I'd prefer to say that it'd be nice if they
work (just so that people don't mistake that should for a 2119 word).
But the distinction you're making is roughly parallel with the
distinction draft-ietf-dnsop-reverse-mapping-considerations-06 made
between existing and matching reverse entries.  I agree this
distinction is worth keeping in mind.  

> But the opposite is not true.  Many forward records may point to the
> same IP address, and there is no need for reverses to match.

I can assure you that there are people who insist that they _do_ need
to match.  It's also possible to have those multiple matches, as long
as the list is not too long.  I think the view that every forward must
have a matching reverse is somewhat unrealistic; but the last time I
expressed such a strong opinion about the reverse tree I landed in a
long interaction with the proprietor of av8.net, so I'm disinclined to
defend my opinion very hard. 

I do think that the people who think that the reverse tree is entirely
optional are neglecting the interoperability consequences of that
decision.  That interoperation is the only real reason I can see to
maintain the reverse; but it's a pretty important reason!

Best,

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: Reverse DNS RFCs and Recommendations

[Leo Bicknell]

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, and you might want to
> take that into consideration when running your services."  

It's taking all of my willpower to avoid an IETF rant. :)

The "SHOULD" here is one way.  A PTR record should point to a valid
forward name that resolves to the same IP address.  To quote RFC 1034,
a PTR is "a pointer to another part of the domain name space".  If the
RHS of a PTR is not a valid domain name, that's just not true.

But rather than some pedantic rant about standards there's a practical
purpose here.  Tools that receive IP addresses will generate names
using reverse lookups, those names should then work.  For instance if
trace route gives a name, "ping " should then work.

But the opposite is not true.  Many forward records may point to the
same IP address, and there is no need for reverses to match.

(in shorthand)

10.0.0.1 PTR webhosting.foo.com
webhosting.foo.com A 10.0.0.1
www.sitea.com A 10.0.0.1
www.siteb.com A 10.0.0.1
www.sitec.com A 10.0.0.1

-- 
   Leo Bicknell - bickn...@ufp.org - CCIE 3440
PGP keys at http://www.ufp.org/~bicknell/







signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Reverse DNS RFCs and Recommendations

[Tim Franklin]

> 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 a host.

Regards,
Tim.

Re: Reverse DNS RFCs and Recommendations

[John Miller]

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 PTR records.


John

Re: Reverse DNS RFCs and Recommendations

[Andrew Sullivan]

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 is engaged in wishful thinking,
particularly if the lookup isn't validated with DNSSEC.  (But yes,
that's waht the TCP wrappers package was supposed to be doing.)

A 

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: Reverse DNS RFCs and Recommendations

[Mikael Abrahamsson]

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 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 want to
take that into consideration when running your services."


The classic TCP wrapper had this as one of the security features, if 
reverse said something and this couldn't be verified by doing a forward 
lookup, the reverse was treated as invalid and not used for name based 
policies.


--
Mikael Abrahamssonemail: swm...@swm.pp.se

Re: Reverse DNS RFCs and Recommendations

[Scott Howard]

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 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?
>

No. Nothing at all, and as you've already discovered it's what is used by
probably the majority of providers that include IP addresses in rDNS.


> What, if any would you name a network, gateway, broadcast address? Should
> the PTR be empty?
>

I've never seen anyone put in rDNS for networks or broadcast addresses.
 (Naming networks was common many years ago, but it never made the jump to
DNS from what I've seen).  rDNS for gateways can be helpful for traceroute,
and there are a few documents that provide examples of naming schemes for
such hosts, but I can't seem to find them right now...  Again, these are
only samples - there's not such thing as a "right" answer.

On Wed, Oct 30, 2013 at 9:24 AM, Nick Hilliard  wrote:

> 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.
>

Well, yes and no...  It's true that there's no "correct" answer, but there
are "incorrect" answers - such as putting the term "dynamic" in the rDNS
for an email server. It may not be incorrect enough to break an RFC, but
it's still the wrong thing to do!

  Scott

Re: Reverse DNS RFCs and Recommendations

[Andrew Sullivan]

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 consensus on the much more bland
statement, "Some people rely on the reverse, and you might want to
take that into consideration when running your services."  

Now, IETF non-consensus on the way the Internet works is hardly a
surprise, but I thought I'd point this out just in case people want to
be prepared for flames from people who feel strongly about the matter.

Note, also, that there's an important distinction to be made between
matching reverse and mere existence of some reverse.  An lot of sites
don't require matching any more, because of the way it can bloat PTR
RRsets if there are a lot of forward names at the same IP address.

Best,

A

-- 
Andrew Sullivan
Dyn, Inc.
asulli...@dyn.com
v: +1 603 663 0448

Re: Reverse DNS RFCs and Recommendations

[Nick Hilliard]

> 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

Reverse DNS RFCs and Recommendations

[Nolan Rollo]

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 network 
operators  with difficult regex based filtering ( 
http://www.gossamer-threads.com/lists/nanog/users/113633 ) and we don't have to 
change things as per a recommendation down the road.

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 '_'
   (underscore) character, host names for hosts with any form of SMTP
   mail service MUST NOT use the '_' (underscore) character.  It is
   preferable to use the IP address in reverse format in the same way
   the the IN-ADDR.ARPA. domain is defined.

Now since it is only a first revision draft I'm taking what it has to say with 
a grain of salt and it seems has taken quite a bit of criticism on forums. I'm 
also not singling out on Time Warner, WOW, Comcast or Charter for their naming 
conventions nor do I think they are bad, I'm just using them as examples 
because they are local, well-known ISPs.

Actual Examples:
cpe-67-XX-XX-XX.stny.res.rr.com - 67.XX.XX.XX
d28-XX-XX-XX.dim.wideopenwest.com - 28.XX.XX.XX
c-68-XX-XX-XX.hsd1.mi.comcast.net - 68.XX.XX.XX
24-XX-XX-XX.static.bycy.mi.charter.com - 24.XX.XX.XX

*Most ISP Reverse DNS Hostnames (from what I've observed) seem to use the dash 
"-" character with the forward format, as opposed to the reverse IN-ADDR.ARPA. 
dotted scheme as recommended in the draft
*Comcast and Charter all have geographic based furthest-right-hand tokens.
*Charter, WideOpenWest, Time Warner, and Comcast all have some acronym that is 
not immediately clear, at least to me (HSD - High Speed Data?, BYCY - Bay City, 
MI?, DIM - Dynamic IP Mapping?, STNY - Southern Tier New York?)

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, it's short, detailed and to the point. Is there 
really anything bad about this?

What, if any would you name a network, gateway, broadcast address? Should the 
PTR be empty?

 I've seen a lot about naming what type of technology it is 
(wireless, adsl, cable, etc.) in order to filter out the "high speed spammers". 
It seems to me that this would open up the likelihood of a targeted attack. 
We've all heard of security though obscurity and of course no one relies on it 
but we have to face the fact there are CVEs every day for various networking 
hardware/firmware. If an attacker can query DNS and find out that the IP is for 
wireless they could filter all wireless gear exploits. Is this still a good 
practice given the abundance of high speed data connections or is this just 
opening yourself up to reconnaissance?

There is a Merit Network mailing list discussion that outlines most of what 
I've read that can be found here ( 
http://www.merit.edu/mail.archives/nanog/msg06843.html )

Nolan Rollo
VoIP Engineer
Main: 517.223.3610x114
Fax: 517.223.4120
www.kw-corp.com