wildcard reverse lookups?
Mark Andrews
Mark_Andrews at isc.org
Wed Dec 20 22:51:29 UTC 2006
> 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
More information about the bind-users
mailing list