>>>для них есть релей провайдера. Потому что даже если на
>>>100 тысяч абонентов ADSL найдётся хоть один такой, которому нужно, он
>>>попросит провайдера прописать нормальную обратку. А лопатить гигабайты спама в
>>>день от таких хостов -- просто глупо нагружать сервер.
>>
>>а вас таки не затруднит указать номер RFC который вы сейчас процитировали?
>
>Может меня поправят более опытные коллеги и такой RFC действительно существует.
>Но лично я процитировал RFC под названием "здравый смысл". Объясню
>почему. RFC эти базовые по DNS и очень старые.
RFC 1033
There should be one A record for each address of a host.
PTR's should use official names and not aliases.
To add a new host to your zone files:
Edit the appropriate zone file for the domain the host is in.
Add an entry for each address of the host.
Optionally add CNAME, HINFO, WKS, and MX records.
Add the reverse IN-ADDR entry for each host address in the appropriate
zone files for each network the host in on.
RFC1035:
3.5. IN-ADDR.ARPA domain
The Internet uses a special domain to support gateway location and
Internet address to host mapping.
The intent of this domain is to provide a guaranteed method to perform
host address to host name mapping,
and to facilitate queries to locate all gateways on a particular network
in the Internet.
...
Более свежее.
RFC2821:
4.3.1
[..]
Note: all the greeting-type replies have the official name (the
fully-qualified primary domain name) of the server host as the first
word following the reply code. Sometimes the host will have no
meaningful name. See 4.1.3 for a discussion of alternatives in these
situations.
[...]
RFC 2181
10.2. PTR records
Confusion about canonical names has lead to a belief that a PTR
record should have exactly one RR in its RRSet. This is incorrect,
the relevant section of RFC1034 (section 3.6.2) indicates that the
value of a PTR record should be a canonical name. That is, it should
not be an alias. There is no implication in that section that only
one PTR record is permitted for a name. No such restriction should
be inferred.
Note that while the value of a PTR record must not be an alias, there
is no requirement that the process of resolving a PTR record not
encounter any aliases. The label that is being looked up for a PTR
value might have a CNAME record. That is, it might be an alias. The
value of that CNAME RR, if not another alias, which it should not be,
will give the location where the PTR record is found. That record
gives the result of the PTR type lookup. This final result, the
value of the PTR RR, is the label which must not be an alias.
10.3. MX and NS records
The domain name used as the value of a NS resource record, or part of
the value of a MX resource record must not be an alias.
Ну, всем рекомендую RFC 2505.
