Following on on the rDNS track I did some investigation on the rDNS and DNS
side. The following issues were raised off list:
1) Is rDNS stable enough to depend on?
Maybe. The quality of the data registered for North America and
European zones is 'reasonable'. It is not great but not ridiculous. The
quality of the data in the Asian zones is not at all good.
One issue to consider is that some of the NICs have been proposing
to kill rDNS since "nobody uses it and it is no damn use".
The feeling I got was that if a proposal that depended on rDNS was
deployed it would probably create a sufficient incentive for folk to fix the
stuff that needs fixing.
2) Can rDNS support other record types?
I have not got a definitive answer here yet but the answer so far is
'don't see why not'. The 'reverse DNS' is only a chunk of the .arpa address
space that has been repurposed. There is nothing magic about it.
The state of rDNS suggests that if anyone has an app out there that
is so fragile that it would be broken by a few TXT records then the best
thing to do is to blow it up now and put it out of our misery. RTFM
There may be a theoretical chance that someone has built something
that depends on an assumption that rDNS is monolithic and unchanged. This
chance appears to be very small and the chance we should care is negligible.
3) (DNS and rDNS) Should we use TXT records or some new record type?
The issues here are political and technical. The technical issues
have been discussed at some length. Basically getting a new record type is
the Kosher way to do the job but the issue of what the impact on the
deployed infrastracture would be is somewhat muddy. I don't think we need to
bother with the clarification, the political issues determine the matter.
To get a DNS resource record assigned we have to have an (IETF)
standard. It is possible that the DNSEXT working group could act quickly,
this seems to mean order of 18 months to be realistic. That is not going to
be acceptable. It is not like we get a record type assignment and then get
to work with it.
I described the RMX and SPF approaches. Encoding protocol names into
the DNS is now acceptable and is compatible with 'fast' tracking through the
working group. When I described the idea of encoding IP addresses I got a
period of silence and then 'thats what folk call a domain name hack'. I did
not get a feeling that the process would be at all short. Basically this is
the sort of proposal where people start suggesting that you build something
other than DNS.
My take is that we should use TXT and if anyone criticizes us tell
them we will consider using a resource record if they tell us the numbers in
advance, otherwise no deal. [There is a reason I started using all those URI
based namespace designators, I loath registration processes, particularly
when they are used for control]
4) What are the realistic DNS spoofing and IPO address poisoning
vulnerabilities?
Good news here, I have not got a definitive word but BIND9 is highly
resistant to domain name cache poisoning. There are still a lot of people
using BIND8 for performance reasons but that is not a major concern for us.
If you are running BIND8 turn on LMAP and then find spammers are attacking
you with cache poisoning you upgrade to BIND9.
The IP spoofing issue seems to be unimportant. Although DNS is not
proof against this attack it is in practice pretty difficult with a low
probability of success and is very easy for the victim to detect.
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg