-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
In message <76f43494-b863-4e1e-ad5d-29e34b650...@ogud.com>, Olafur
Gudmundsson <o...@ogud.com> writes
>Thus I would say the usage case is “a log processing tool MAY do PTR lookups”
>the real information about addresses can be extracted from other sources as
>well
>like
>whois and geo-location data bases etc.
the only valid thing that a logging system can record is the IP address
(and of course in IPv4 the port number)...
... everything after that is almost always just informed speculation :(
whois tells you the beneficial user of the address block, it doesn't
tell you whose announcement your local router is using
geo-location is of highly variable quality ... one of the suppliers of
connectivity to West Africa recently changed their headquarters address
as recorded in the whois for their AS and suddenly lots of IP address
space moved from being in NG to being in MU (with a consequent impact on
all sorts of logging and heuristics at large mail handling companies!)
and of course the actual name that is returned is controlled by the
someone who is not necessarily trustworthy -- you can really confuse
neophytes by returning mail.google.com as the result of the reverse
lookup for some IPs that are nothing to do with Google... which is why
of course the people who still believe in the value of PTR have to do a
reverse lookup and then come forward again in the hopes of a match.
This is my specialist subject, if bored there's lots more flawed
assumptions explained in my PhD thesis :)
>The other usage case that I can think of is network debugging.
Yes and no ... all that extra traffic for lookups can get in the way!
but the software tools could be improved to translate addresses into
useful text without relying on the crutch of reverse DNS
>Thus the real question in this case “what granularity in name is needed and
>when
>?”
What systems would actually like to know is "what range of addresses can
be considered to be the same as this one" ??
That allows them to start considering reputations and rate-limiting and
all the other sorts of things that we currently load onto single IP
addresses and which are the real problem to address with IPv6 -- as I
keep on saying, without apparently getting much traction :(
Now if that range gets some sort of human-friendly string when the data
is supplied that merely saves the receiving software from constructing
its own friendly string. This may seem like a win, but I bet you it
isn't if you normally use Thai or Chinese glyphs on a day-to-day basis.
>Below is short list of of possible requirement based on the needs of these two
>“usage cases”
>
>We all love having the names displayed by trace route for each hop ==>
> names of router interfaces are a SHOULD in my mind
Traceroute is terribly geeky -- and unless you actually own the devices
being traversed (and understand all the other gear that your packets
traverse) the replies have considerably less value than most people
expect....
>We all want big services to have PTR records, this web servers, mail servers,
>etc.
> Addresses that provide services SHOULD have a PTR record
I'm now puzzled ... where would you be doing a reverse lookup for a
server when you hadn't just done a forward lookup and would therefore be
able to keep track of what the IP address meant ???
Also... I suspect you're thinking that IPv6 servers will operate on
small numbers of addresses ... no reason for that, it might be
convenient to dish out a different IPv6 address for every DNS lookup,
and if so then the reverse lookups are going to be an expensive to
generate and cache nuisance -- so we ought to understand their value a
little better than just arguing that "you can do it in IPv4"
BTW: there is no sense in saying "you should not do in IPv4" that way
lies madness, but saying "but it won't work in IPv6" does seem helpful
>“End-user” addresses do not need a PTR record but could be simple wild card
>responses like “Customer.HNL.biz-ISP.net”
>as none is complaining about
>123.136.133.31.in-addr.arpa. 3600 IN PTR dhcp-887b.meeting.ietf.org.
>or
>9.5.9.d.7.4.e.f.f.f.9.e.f.c.a.2.6.3.1.0.0.7.3.0.c.7.6.0.1.0.0.2.ip6.arpa. 15
>IN
>PTR s2001067c037001362acfe9fffe47d959.hotel-wireless.v6.meeting.ietf.org.
It's not about complaining -- it's about saying "if you ask for a
reverse lookup you probably won't get a useful reply -- so think harder
about why you asked in the first place, it's probably just habit -- and
if you thought you were somehow creating some extra "trust" or
"security" then you are most likely rather mistaken.
[...]
>> What do people do with it? I have no idea. But as long as people want to
>query, the RIR are happy to anchor the domains.
>
>That to me indicates that people use log post processing all the time and
>Intrusion Detection Systems are doing PTR lookups
>by policy
>For IDS are their expectations any different than log processors?
>and if IDS’s are taking decisions based on the content of PTR records what
>granularity do they need?
If they're making significant decisions based on PTR records then they
probably need to be ground down into granules :(
- --
Dr Richard Clayton <richard.clay...@cl.cam.ac.uk>
tel: 01223 763570, mobile: 07887 794090
Computer Laboratory, University of Cambridge, CB3 0FD
-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1
iQA/AwUBVGOmxuINNVchEYfiEQKcVACfeJYHzaRc+kB8lhGY495IqRL4c+UAoOuz
aquwDeWYxf7pUYPIc8vA4M0E
=IDG8
-----END PGP SIGNATURE-----
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
