Il record PTR e A deve corrispondere?

RFC 1912 Sezione 2.1 stabilisce quanto segue:

Assicurarsi che i tuoi record PTR e A corrispondano. Per each indirizzo IP, dovrebbe essere un record PTR corrispondente nel dominio in-addr.arpa. Se un host è multi-homed (più di un indirizzo IP), assicurarsi che tutti gli indirizzi IP abbiano un record PTR corrispondente (non solo il primo). La mancata corrispondenza dei record PTR e A può causare la perdita di servizi Internet simile a non essere registrati nel DNS. Inoltre, i record PTR devono indicare un record valido A, non un alias definito da un CNAME. Si raccomanda vivamente di utilizzare un software che automatizza questo controllo o genera i dati DNS da un database che crea automaticamente dati coerenti.

Questo non ha alcun senso per me, se un ISP mantenga un record A per each record PTR? Mi sembra che sia importnte solo se l'indirizzo IP che il record PTR descrive ospita un servizio sensibile al DNS non corrispondente (ad esempio, hosting di posta elettronica). In questo caso la zona in avanti sarebbe configurata sotto un nome di dominio (esempi seguono il formato 'zona -> record'):

domain.tld -> mail IN A 1.2.3.4

E il record PTR sarebbe configurato per abbinare:

3.2.1.in-addr.arpa -> 4 IN PTR mail.domain.tld.

Ci sarebbe qualche ragione per l'ISP di ospitare una ricerca in avanti per un indirizzo IP nella loro networking come questa ?:

ispdomain.tld -> broadband-ip-1 IN A 1.2.3.4

  • Qual è la posta corretta impostata per più domini su un server?
  • Gli indirizzi DNS di Reverse Reverse non funzionano
  • Problema di configuration del server DNS, record PTR
  • Hotmail mi vuole modificare il mio record SPF
  • Devo impostare il record PTR in impostazione SPF?
  • Come configurare PTR (Reverse DNS) presso il responsabile DNS di Godaddy
  • Reverse DNS - come configurare correttamente per la distribuzione SMTP
  • Gli nomi ns1 & ns2 necessitano di un record PTR?
  • 2 Solutions collect form web for “Il record PTR e A deve corrispondere?”

    Ci sarebbe qualche ragione per l'ISP di ospitare una ricerca in avanti per un indirizzo IP nella loro networking come questa?

    Coerenza e completezza, soprattutto. Mentre potrebbe essere difficile immaginare perché sia ​​importnte, i RFC sono stati scritti per esattamente una buona ragione: così tutti su Internet hanno una comprensione basata sulla base di come tutti gli altri interagirà con loro. Senza questa base, Internet sarebbe un mucchio di protocolli, attuati comunque a nessuno, senza alcuna aspettativa di documentazione, compatibilità, integerperabilità o coerenza.

    I servizi che sono noti dipendono da questi ricerca avanti e inversa non dovrebbero essere quelli speciali che ricevono un trattamento adeguato RFC. Si supponga che se stai per partecipare con il resto di noi, stai giocando allo stesso livello di field di gioco come il resto di noi.

    Corrispondendo i record PTR e A consente di verificare l'affermazione effettuata nel record PTR con mezzi automatizzati .

    Se il record A non è fornito, bisogna andare ai record whois per verificare se il record PTR rappresenta in modo preciso l'entity framework; che controlla l'indirizzo IP, un process manuale noioso che è difficile da automatizzare ed è spesso sbagliato o obsoleto.

    Questo è importnte per motivi di sicurezza in molti contesti. Uno che conosco e ti darà un esempio è:


    Supponiamo di eseguire un sito web e di submit contenuti unici, ma hai scoperto che il tuo contenuto è stato copiato su altri siti web e, peggio, sono classificati più in alto rispetto a te nei motori di ricerca!

    Dopo ore a fissare i tuoi registri chiedendosi come qualcuno abbia scivolato un bot oltre le tue difese, alla fine avverti centinaia di richieste da Googlebot. Ma quando alla fine cerchi uno degli indirizzi IP, lo troverai registrato a Web Hosting Bulletproof Ukraine e non a Google. Pensavi di essere indicizzato ma invece hai giocato.

    Come risolvi questo problema? Facile, si confronta il record PTR con il record A. Google raccomanda anche questo approccio .

    Questo può essere automatizzato in molti linguaggi di programmazione Web (PHP è un'exception notevole, non è ansible farlo in modo affidabile in PHP ) in modo che un'applicazione Web possa controllare l'indirizzo IP, vedere che il PTR è *.google.com e quindi utilizza l'A registrare per confermare che *.google.com corrisponde allo stesso indirizzo IP. Se c'è un inconveniente da qualche parte, hai scoperto un falso Googlebot.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.