Subject: [lisp] rDNS with new "RLOC RR"

From: Michael Menth <[email-masked]>
Date: Fri, 12 Jun 2009 02:06:28 +0200

Hi all,

reverse DNS with a new RLOC resource record could be used to implement a 
service providing EID-to-RLOC mappings. Instead, LISP has defined 
multiple mapping systems. I guess there were reasons for that. Why is 
rDNS with "RLOC RR" a bad idea?

I have found the following presentation looking at similar ideas: 
http://www.dinof.net/~dino/ietf/lisp2.ppt
Scheme 1 of the presentation is essentially what I have described above 
(apparently an obvious solution ...). Is there an outdated draft related 
to this document?

Page 19 of the document says that the drawback of Scheme 1 is the fact 
that packets are dropped until the ITR receives the mapping. But that 
also holds for the current deployment of LISP+ALT. So what are other 
drawbacks of the DNS-based mapping system that prevented it from being 
used as the preferred option?

Regards,

    Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/8888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Vince Fuller <[email-masked]>
Date: Thu, 11 Jun 2009 23:04:02 -0700

> used as the preferred option?

The LISP authors considered a DNS-based approach early on in the design of
mapping systems. We even had a name for it: LISP variant 2.

During informal discussions with members of the Internet operations
community, we received a lot of push-back against that idea. If I recall
correctly, two of the key concerns were:

    1) adding EID-to-RLOC data to the DNS could potentially interfere with
       its normal role in name-to-address translation (as if the DNS isn't
       already being used as a kitchen sink for ENUM and other things...)

    2) creation of a circular dependency where the addresses of DNS servers
       might need to be looked up in an EID-to-RLOC mapping database that, in
       turn, needed to use those DNS servers to resolve them.

There are and were fairly obvious ways to avoid both of these problems:

    - for #1, use only the DNS protocols with a completely separate
      infrastructure of servers and resolvers for LISP and perhaps even a
      separate UDP port number

    - for #2, number the DNS infrastructure used for LISP out of RLOC space,
      which by definition does not need any EID-to-RLOC lookups

I think, though, that the real issue was a more vague and perhaps emotional
concern that the DNS infrastructure is already too fragile.

If someone wants to write an Internet Draft that specifies how the DNS could
be used to manage an EID-to-RLOC database, I suspect that my fellow LISP
authors would be very interested in the result. Similarly, if someone wants
to design and specify a DHT-based mapping database (which would be catagorized
as LISP variant 3), we'd be interested in that, too.

Note, though, that by "specify", I mean that there should be sufficient
detail that an implementor could build to it. That means figuring out the
nasty details that tend to turn something simple, elegant, and obvious
into a far more complicated implementation. 

	--Vince

---

From: Marshall Eubanks <[email-masked]>
Date: Fri, 12 Jun 2009 10:07:25 -0400

> concern that the DNS infrastructure is already too fragile.

Speaking as a small company person, I suspect that DNS is not the  
right instrument for this.
Just from my experience (so, anecdotal, not synoptic) :

- I would just observe that most of the small multi-homed companies I  
have dealt with use a hosting company
for their DNS. If that DNS was doing routing as well, that would  
probably have to change. That would mean you
would have to train / hire someone to do DNS.

Companies only have so much bandwidth to think about these sorts of  
things, and would not appreciate being forced to change the way they  
did their name service.

- In my experience small companies are more tolerant of short DNS  
outages than short
routing outages. (Existing flows are not interrupted by the first, but  
are by the second.)
- In my experience it is common for them not to use DNS at all for  
mission critical interactions. (This is of course connected with the  
previous point.)
- In my experience DNS TTLs are typically set fairly long, except for  
planned changes. This means that DNS changes typically take the form

    - lower the ttl
    - wait for old ttls to time out
    - make the change
    - test
    - raise the ttl

It would scare me if routing was required to undergo the same multi- 
day cycle to make changes. (Would
you buy a router that promised multi-day BGP convergence times ?)

- DNS is subject to DOS and DDOS type attacks. These can really hammer  
a DNS server. I don't think that
it would be a good idea if routing was subject to the same types of  
attacks.

Now, I am sure that most of the above could be engineered around, but  
I do think that such considerations mean that there would be push back  
from small companies (a logical constituency for LISP IMO) if DNS was  
part of the soup.

Regards
Marshall

> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Christopher LILJENSTOLPE <[email-masked]>
Date: Fri, 12 Jun 2009 07:55:01 -0700

Greetings Marshall,

On 12/06/2009, at 7:07 AM, Marshall Eubanks wrote:

>> [clip]
> - I would just observe that most of the small multi-homed companies  
> I have dealt with use a hosting company
> routing outages. (Existing flows are not interrupted by the first,  
> but are by the second.)
> - In my experience DNS TTLs are typically set fairly long, except  
> for planned changes. This means that DNS changes typically take the  
> form
>
>   - lower the ttl
> - DNS is subject to DOS and DDOS type attacks. These can really  
> hammer a DNS server. I don't think that
> Now, I am sure that most of the above could be engineered around,  
> but I do think that such considerations mean that there would be  
> push back from small companies (a logical constituency for LISP IMO)  
> if DNS was part of the soup.
>
> Regards
> Marshall
>
>> [clip]
>> 	--Vince
>
Remember that using DNS the protocol does not mean using the existing  
DNS infrastructure.  The protocol is interesting, however, I agree  
that the existing implementation can be a bit fragile (but that  
actually makes it more interesting, because, given it's fragile  
nature, it still works surprisingly well in the macro sense).  If  
someone were to pursue variant 2, I would suspect that you would want  
a different infrastructure to support it.

	Chris

- ---
李柯睿
Check my PGP key here:
https://www.asgaard.org/~cdl/cdl.asc

---

From: Christian Vogt <[email-masked]>
Date: Wed, 17 Jun 2009 14:15:02 -0700

Marshall -

New dependencies for routing, training of administrative personnel,
security -- all these are indeed important issues to take into account
when designing a mapping system.  Nonetheless, I don't see why a
DNS-based mapping system would be more susceptible to those issues than
any other type of mapping system -- in particular if a separate DNS
infrastructure with low TTLs was used.

- Christian

On Jun 12, 2009, Marshall Eubanks wrote:

> right
> instrument for this. Just from my experience (so, anecdotal, not
> synoptic) :
>
>   have dealt with use a hosting company for their DNS. If that DNS was
>   doing routing as well, that would probably have to change. That
>   would mean you would have to train / hire someone to do DNS.
>
>   outages than short routing outages. (Existing flows are not
>   interrupted by the first, but are by the second.) - In my experience
>   it is common for them not to use DNS at all for mission critical
>   interactions. (This is of course connected with the previous point.)
>   It would scare me if routing was required to undergo the same
>   multi-day cycle to make changes. (Would you buy a router that  
> promised
>   multi-day BGP convergence times ?)
>
> hammer a
>   DNS server. I don't think that it would be a good idea if routing
>   was subject to the same types of attacks.
>
> but I
> do think that such considerations mean that there would be push back
> Regards Marshall