Subject: [Ietf-not43] dns mapping

From: Michael.Dillon at radianz.com ([email-masked])
Date: Mon Jul 28 11:17:33 2003

>For example, the FIRS
>specification for ASNs currently says that clients must use the LDAP
>servers associated with the asn.arpa zone by default, while the IPv4
>specification says that FIRS clients must use the LDAP servers associated
>with the in-addr.arpa zone by default, while the IPv6 specification says
>to use ip6.arpa by default.

This doesn't make sense. If you are using FIRS to look-up information 
about
the IP address block owner, then the mapping in in-addr.arpa or ip6.arpa
is useless because it refers to the domain name of the device currently
USING the address, not the owner of the address block. In a block of
256 IPv4 addresses owned by one entity there could be 256 different
user domains.

You cannot use the DNS reverse map to map the delegation hierarchy of 
IP address blocks. For one thing, the DNS reverse map has no way to
identify IP address ranges or blocks. It was intended to deal with
reverse mapping of hosts or individual IPv4 addresses.

Let's work through an example. I am the owner of 192.0.2/24 which is 
an IP address range from 192.0.2.0 to 192.0.2.255. Rather conveniently
this IP address range also corresponds to a CIDR block but that is not
always the case. Now I have a customer, example.com, who want to run
a web server in my data center so I set up a PTR record in my 
2.0.192.in-addr.arpa zone that reads:

      67   IN  PTR    www.example.com

Now my customer has registered the domain name example.com elsewhere and
made his own separate arrangements for DNS so he will be putting the 
following in his example.com zone:

      www   IN  A    192.0.2.67

You want to use FIRS to find out something about 192.0.2.67 so you start
by checking the reverse map for 67.2.0.192.in-addr.arpa but all that I
have there is a PTR record referring you to example.com. And since 
example.com
doesn't have their own IP address range, they have no SRV records for FIRS
in their DNS server.

Are you suggesting that I should have

      67   IN  PTR    www.example.com
           IN  SRV    _firs._tcp.mydomain.com

in my in-addr.arpa zone? Because this would case the size of the 
in-addr.arpa
zone to double with mostly redundant data which is not a good thing.

Remember, the IP address allocation hierarchy is orthogonal to the domain
name delegation hierachy. It is also orthogonal to the AS Number 
allocations.
A single entity can have multiple ASNs and multiple IP address ranges but 
does
not have to identify an address range with a specific ASN. There are also
address ranges that are allocated to entities who have no ASN at all.

As far as route registries go, there is a reason why the RIRs operate 
their
route registry separate from their IP address registry. That is because 
they are
orthogonal. There are many IP address ranges that do not have an 
associated
route. There can be many routes associated with a given IP address range. 
The
routing protocols are charged with choosing the best route which clearly 
implies
that there is more than one. The specific routes associated with an IP 
address
change dynamically with the network topology and are not in the route 
registry.

What the route registry does do is to identify the set of possible IP 
address
ranges that an ASN holder might choose to announce to their peers. The 
intent is
that the peers can filter out rogue announcements by double-checking the 
dynamic
unauthenticated routing protocols against a less dynamic better 
authenticated 
route registry.

If FIRS ever does become suitable to replace the RPSL used in route 
registries it
would only be after FIRS is used in practice for the simpler job of 
running
an IP address registry.

--Michael Dillon

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Jul 28 11:24:29 2003

on 7/28/2003 10:16 AM [email-masked] wrote:

>> For example, the FIRS specification for ASNs currently says that
>> clients must use the LDAP servers associated with the asn.arpa zone
>> by default, while the IPv4 specification says that FIRS clients must
>> use the LDAP servers associated with the in-addr.arpa zone by
>> default, while the IPv6 specification says to use ip6.arpa by
>> default.
> 
> about the IP address block owner, then the mapping in in-addr.arpa or
> ip6.arpa is useless because it refers to the domain name of the device
> currently USING the address, not the owner of the address block. In a
> block of 256 IPv4 addresses owned by one entity there could be 256
> different user domains.

You misread it. The default mapping is a top-level mapping.

EG, if a user enters *ANY* IPv4 address, the client says "oh this is an
IPv4 address" and issues lookups for _ldap._tcp.in-addr.arpa. The default
is to go ask the LDAP servers associated with the entire IPv4 address
space, not the servers associated with a specific address.

Separately, the model allows a user to override the default behavior and
ask for the servers associated with a particular address, but that's only
provided as a feature, as a way to circumnavigate the delegation servers
in those situations where this would be handy (EG, if there is a ~route
service definition, where user-to-user queries would be useful, and where
the entities are providing the service).

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Mon Jul 28 11:29:16 2003

> space, not the servers associated with a specific address.

And like Andy said, this is just placeholder/experimental stuff, until the
RIR community comes up with a mapping algorithm that it wants to use.