Re: PTR for IPv6 clients (Re: IPv6 NAT?)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Jeroen Massar wrote:
> Harald Alvestrand wrote:
>> Mark Andrews skrev:
>>> You also don't want to do it as you would also need massive churn in
>>> the DNS.
>>>
>>> Microsoft gets this wrong as they don't register the privacy addresses
>>> in the DNS which in turn causes services to be blocked because there
>>> is no address in the DNS.
> >
>> perhaps the advent of IPv6 will result in people finally (*finally*)
>> giving up on this sorry excuse for a security blanket? (calling it a
>> "mechanism" is too kind)
>>
>> Or perhaps it'll just make people register wildcard records at the /64
>> level in ip6.arpa :-(
>>
>>              Harald@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx (MY, what an useful
>> reverse map!)
>
> Like a lot of things, "it depends".
>
> For SMTP/SSH and for management-alike protocols requiring proper
> reverse -> forward -> reverse mapping is IMHO a good thing.
>
> Clients & servers using these protocols  should be on stable & 
> trackable addresses. (of course you an set a low TTL etc, that is why 
> one should always log the name + IP, the more information the better). 
> With management I mean for instance reverses on router IP addresses, 
> as it makes traceroute so much more informative, also reverses on 
> servers etc.
>
> For SSH you will most likely have firewall rules in place anyway. SMTP 
> should similarly only be allowed to clients that are in your client 
> list. One doesn't have to require r->f->r if the client is in your 
> client-list of course. Your server, which talks to other SMTP servers 
> outside of your control, should be on a stable IP and have functioning 
> r->f->r. For SMTP the current track of mind is: no reverse, no 
> communication. Which stops most of the spam already, as that client is 
> clearly not configured correctly to do inter-domain SMTP.
>
> For that matter anything that is 'stable' should (note should) IMHO 
> have a proper r->f->r.
>
> For any other protocol _requiring_ reverse is silly IMHO.
> You don't need it for HTTP, you don't need it for BitTorrent etc.
> Having reverse in those cases is nice, as it might give extra 
> information (eg the remote is most likely dsl as it contains 'dsl' in 
> the reverse), but it is always a guess and might quite well be faked.
>
> The biggest issue with the use of reverses tends to be with 
> applications which only lookup a reverse, but don't check if the 
> r->f->r link is complete. 
The biggest issue with reverse mapping for clients (any protocol) is 
that people try to make their applications treat it as anything but 
"here is some information you might find interesting".

I think draft-ietf-dnsop-reverse-mapping-considerations-05.txt has it right:

4.3 Application considerations

   Applications should not rely on reverse mapping for proper operation,
   although functions that depend on reverse mapping will obviously not
   work in its absence.  Operators and users are reminded that the use
   of the reverse tree, sometimes in conjunction with a lookup of the
   name resulting from the PTR record, provides no real security, can
   lead to erroneous results and generally just increases load on DNS
   servers.


FYI, I ssh out from the address I used as an example above every day. 
Thinking that SSH clients should be required to be on round-trippable 
mapped addresses is just silly.

                 Harald

_______________________________________________
IETF mailing list
IETF@xxxxxxxx
http://www.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]