UDP packet/DNS server

Tatsuya Kawasaki wrote:

xyz.com. IN NS that.host
*.xyz.com In NS that.host

Gah!!

Illegal!

Never use "*" in DNS! Just makes /bad things/ happen.

@ IN SOA xyz.com. hostmaster.xyz.com. (
    1998092801 3600 1800 3600000 7200)

  ns ns1.xyz.com.
  ns ns2.xyz.com.

  mx 0 mail.xyz.com.

mail a 1.2.3.4
  mx 0 mail

.. etc ..

Jamie,

First of, I must correct that for the wild DNS entry,
there is a trailing '.' on the real entry.

Having said that.

Two questions.
#1
Why Illegal? what is the theory behide it. I don't see the problem?

#2
If I want to pass DNS inquiry to the primary server(ie server that does
not allowed ZONE transfer)

I thought for that, all I need to do is to pass NS record to
that server.

Any Suggestion?

Tatsuya

かわさき
TK3197

= = = = = =
Business Network Telecom (BNT)
ビジネスネットワークテレコム株式会社
〒111-0053 東京都台東区浅草橋3-8-5
31山京ビル6階
TEL 03-5687-3945 FAX 03-5687-6009
http://www.giganet.net

Allowable characters in hostnames are:

a-zA-Z0-9

I think / is also allowable, and there is an RFC on this subject. Go to
ftp://nic.ddn.mil/pub/rfc to check.

On a side note, some DNS implementations do not adhere to this standard,
for instance Lose9[5|8] and other microsuck "products".

BIND 8 will not load a zone containing illegal characters. Jamie is absolutely
right (suprise!).

PS: jamie.. o-line baby..

you have to admit, it does save one hell of a lot of typing for the 1918
IN-ADDR.ARPA delegations.

rfc1918.db

In article <19980928210036.A24460@qual.net>,

I think / is also allowable, and there is an RFC on this subject.

RFC 2181

randy

But it's perfectly ok for PTR records, though perhaps your example is less
than ideal. The objection to the use of "*" was specific to NS records.
An NS record should exist for a domain only if that domain exists. Since
"*" matches any subdomain whether the domain exists or not, an NS record
will be returned for non-existent subdomains and that violates the rule.
Some records of other types are incompatible with "*" for similar reasons.
The major point here is that any DNS record should reference either a valid
response or another record that will lead to a response, and an NS record
pointing to a zone file that doesn't exist is neither.

Some folks will contend that the use of "*" in PTR records is bad form even
though it is legal. That's a religious war, not a technical one. (I
happen to like the use of "*", though I also believe that one should first
apply specific host names whenever a static mapping allows).

Eric,

thank for your reply. Though I did not agree with RFC I understand
what you are saying.
Do you think it is about time to change RFC?

BTW, according to NDS and BIND 2nd Ed. by O'Reilly, it is okay for
MX record too. :slight_smile:

TIA,
Tatsuya

かわさき
TK3197

= = = = = =
Business Network Telecom (BNT)
ビジネスネットワークテレコム株式会社
〒111-0053 東京都台東区浅草橋3-8-5
31山京ビル6階
TEL 03-5687-3945 FAX 03-5687-6009
http://www.giganet.net

Yeah, and if you do then sendmail will be broken, according to the v8.9.1
dox. It's called a wild-card MX record and is specifically not recommended,
more than once, in the sendmail dox. I actually had NetCom tech support
recommend it once, then I found out why it's not recommended, the hard way.
When it comes to DNS, you're *much* better off by being specific, even if
it means being verbose.

Eric,

thank for your reply. Though I did not agree with RFC I understand
what you are saying.
Do you think it is about time to change RFC?

BTW, according to NDS and BIND 2nd Ed. by O'Reilly, it is okay for
MX record too. :slight_smile:

TIA,
Tatsuya

$B$+$o$5$-(B
TK3197

= = = = = =
Business Network Telecom (BNT)
$B%S%8%M%9%M%C%H%o!<%/%F%l%3%`3t<02q<R(B
$B")(B111-0053$B!!El5~ETBfEl6h@uAp66(B3-8-5
31$B;35~%S%k(B6$B3,(B
TEL 03-5687-3945 FAX 03-5687-6009
http://www.giganet.net

But it's perfectly ok for PTR records, though perhaps your example is less
than ideal. The objection to the use of "*" was specific to NS records.
An NS record should exist for a domain only if that domain exists. Since
"*" matches any subdomain whether the domain exists or not, an NS record
will be returned for non-existent subdomains and that violates the rule.
Some records of other types are incompatible with "*" for similar reasons.
The major point here is that any DNS record should reference either a valid
response or another record that will lead to a response, and an NS record
pointing to a zone file that doesn't exist is neither.

Some folks will contend that the use of "*" in PTR records is bad form even
though it is legal. That's a religious war, not a technical one. (I
happen to like the use of "*", though I also believe that one should first
apply specific host names whenever a static mapping allows).

>
>you have to admit, it does save one hell of a lot of typing for the 1918
>IN-ADDR.ARPA delegations.
>
>rfc1918.db
>----------
>
>@ IN SOA ns1.xxx.net. hostmaster.xxx.net. (
> 1997101001 ; serial
> 300 ; refresh
> 300 ; retry
> 604800 ; expire
> 600) ; minimum
>
> IN NS ns1.xxx.net.
> IN NS ns2.xxx.net.
>
>
>* IN PTR rfc1918.xxx.net.
>-----------
>
>then in named.bt
>
>primary 16.172.in-addr.arpa RFC1918.DB
>primary 17.172.in-addr.arpa RFC1918.DB
>primary 18.172.in-addr.arpa RFC1918.DB
>primary 19.172.in-addr.arpa RFC1918.DB
>primary 20.172.in-addr.arpa RFC1918.DB
>primary 21.172.in-addr.arpa RFC1918.DB
>primary 22.172.in-addr.arpa RFC1918.DB
>primary 23.172.in-addr.arpa RFC1918.DB
>primary 24.172.in-addr.arpa RFC1918.DB
>primary 25.172.in-addr.arpa RFC1918.DB
>primary 26.172.in-addr.arpa RFC1918.DB
>primary 27.172.in-addr.arpa RFC1918.DB
>primary 28.172.in-addr.arpa RFC1918.DB
>primary 29.172.in-addr.arpa RFC1918.DB
>primary 30.172.in-addr.arpa RFC1918.DB
>primary 31.172.in-addr.arpa RFC1918.DB
>

>repeat for 10.x.x.x and 192.168 space
>
>To reiterate the question posed by the original poster, (donning

asbestos),