[dns-operations] Delegation to IPs?

Roy Arends roy at dnss.ec
Mon Mar 19 15:27:31 UTC 2007

On Mar 13, 2007, at 4:22 PM, Mohsen Souissi wrote:

>  On 13 Mar, Joe Abley wrote:
>  |
>  | On 13-Mar-2007, at 07:45, Stephane Bortzmeyer wrote:
>  |
>  | >> Based on my read of section 3.3.11 of RFC 1035, it seems to  
> me this
>  | >> isn't allowed ...
>  | >
>  | > I agree with you. And BIND or nsd will probably agree, too :-)
>  |
>  | It's lexically legal, of course. There's nothing in the protocol
>  | which prohibits numeric labels. So you can expect your authority
>  | server not to blink when loading the zone containing such
>  | delegations; the non-functionality of the whole arrangement stems
>  | from the behaviour of recursive resolvers which
>  | will fail to follow the delegation as the misinformed registrant  
> intended.
>         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ==> This reminds me of a policy consideration: suppose if the
> root-zone allowed a new generation of numeric-only gTLDs and suppose
> if those gTLDs accepted on their turn registration of numeric-only
> domain names, and so on through the DNS tree... In that case, the
> resolution wouldn't fail but we would end up with a real confusion,
> wouldn't we?

I don't think we should endorse hacks to route around configuration  
bugs. I've seen proposals along the following:

1) let root be authorative for numeric hostnames.
2) let resolvers configure local zones for numeric hostnames.
3) let resolvers treat numeric hostnames as ip address

All these silly hacks will allow these misconfigs to exist, or worse,  
to become more popular.

The current average is about 4 to 7 queries per second to any root  
server. So this is basically noise. The cost of doing this at root  
will not justify the cost of simply returning rcode=3. Option (2): I  
can't really see anyone willing to configure a zone that has 2^32  
records. Option (3) needs a resolver side hack.

I prefer the status quo: do nothing.


More information about the dns-operations mailing list