wildcard reverse lookups?

[Mark Andrews]

> According to RFC 1034:
> 
> RDATA           which is the type and sometimes class dependent data
>                  which describes the resource:
> 
> ...
>                  NS              a host name.
>                  PTR             a domain name.
> 
> having a name beginning with an asterisk label (wildcard) is legal in 
> the RDATA of the PTR.  I left "NS" above there to show the 
> distinction made between host names and domain names. (Host names are 
> a subset of domain names as defined in RFC 1123.)
> 
> There's nothing wrong with the PTR pointing to a wildcard as far as 
> the DNS protocol is concerned.  Perhaps the intent of the 
> administrator isn't going to be met though.  (Although what that 
> intent is, I can't really guess.)
> 
> IOW, if you do a lookup on the RDATA of the PTR, you will get back 
> the unexpanded wildcard.  If a wildcard is in the query, it is "Just 
> Another QNAME"  when the algorithm in RFC 1034, 4.3.2. is run.  The 
> wildcards in the QNAME and in the zone will match exactly, there is 
> no synthesis/expansion done.
> 
> Gin a wildcard RR meet a wildcard RR
> Coming thro' the search algorithm,
> Gin a wildcard RR kiss a wildcard RR -
> Need a wildcard RR cry?
> 
> (http://classiclit.about.com/library/bl-etexts/rburns/bl-rburns-comingrye.htm
> )
> 
> Thinking some more, maybe the intent is to say that any host name 
> under aaiprozy.ether.ch is acceptable for the IP address.  Well, 
> that's not what applications would get from the returned wildcard - 
> for one, applications don't have enough information to tell if the 
> synthesis would be applied correctly.  In fact, it wouldn't be. 
> Because if the forward host name was in the DNS, the wildcard 
> wouldn't apply to that name.
> 
> In summary, it's legal but not what is intended (most likely) in this 
> case.  It's like a car having a steering wheel but the road ahead is 
> straight.  There are times to turn but this ain't one of them.

	There is a difference between what's legal in the DNS and
	what is legal in the layer above the DNS.

	gethostbyaddr() etc. should reject the answer as it is not
	a hostname (RFC 952).  gethostbyname() etc. should also
	reject the hostname as it is invalid.

	named flags it as a error because the upper layers will
	flag it as a error.
 
> At 0:13 +1100 12/21/06, Karl Auer wrote:
> >Hi there.
> >
> >Due to a programming error (IMHO) we have a PTR entry in a reverse zone
> >that points to a wildcard. Try "dig -x 129.132.73.148" to see it.
> >
> >Now I reckon this is a Bad Thing. I reckon reverse lookups should
> >resolve to single real names. With this entry, no matter what name
> >someone uses, if they have the address 129.132.73.148, their address
> >will not resolve back to their name. I can see no use for this entry,
> >except to confuse machines that don't like asterisks in their DNS diet.
> >
> >Does anyone else have an opinion on this?
> >
> >Regards, K.
> >
> >PS: BIND loads the entry with a warning about a "bad name", Nominum's
> >ANS accepts it without comment.
> >
> >--
> >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> >Karl Auer (kauer at biplane.com.au)                   +61-2-64957160 (h)
> >http://www.biplane.com.au/~kauer/                  +61-428-957160 (mob)
> 
> -- 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> Edward Lewis                                                +1-571-434-5468
> NeuStar
> 
> Dessert - aka Service Pack 1 for lunch.
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: Mark_Andrews at isc.org