Чому теми для WordPress варто скачувати тільки з офіційних ресурсів

Чому теми для WordPress варто скачувати тільки з офіційних ресурсів

 

Ви вирішили створити новий сайт на WordPress, і ходите по інтернету в пошуках теми. Розробників тем для WordPress досить багато, а ресурсів, де можна скачати теми – ще більше. Цього і варто побоюватися. У нашій короткій статті, ми розповімо про те, чому не варто завантажувати теми з «сумнівних» ресурсів, які при цьому ризики, і які ресурси з шаблонами для WordPress, є перевіреними. Почнемо з першого, і самого простого правила:

 

Безкоштовні теми є тільки на WordPress.org

 

Це факт. На сьогоднішній день, в директорії WordPress.org налічується більше 1600 тем і, якщо чесно, потрапити туди не так вже просто. Складність полягає в тому, що команда професіоналів перевіряє теми на відповідність стандартам: безпека, кросбраузерну, відповідність ліцензії GPL, і так далі. У тому випадку, якщо автору не вдається пройти таку перевірку, він, швидше за все, викладе свою тему у себе в блозі, або на іншому сторонньому ресурсі. Подібні теми можуть поставити під загрозу безпеку вашого сайту, тому радимо уникати їх.

 

Крім того, існує велика кількість сторонніх ресурсів, які пропонують вам завантажити ту чи іншу тему з їх сайту. Найчастіше це копії тих же шаблонів з офіційної директорії (або теми, які не пройшли перевірку), але з деякими змінами: в більшості випадків додані закодовані (видимі або невидимі) посилання на сайти не мають відношення до розробника теми, а ще гірше – віруси. Розглянемо невеликий приклад:

wordpress-theme-footer mypassive

 

Тут у файлі footer.php, зловмисник вставив код, який відображає різні посилання на різних сторінках вашого сайту. Не читаючи код шаблону, це складно виявити, оскільки посилання відображаються тільки для анонімних користувачів. Є більш складні випадки: з використанням функцій base64_decode і eval.

 

Саме тому, якщо ви шукайте безкоштовну тему для WordPress, шукайте її в офіційному репозиторії на WordPress.org. Якщо її там немає, то найімовірніше, ця тема не пройшла перевірку, і користуватися такою темою не варто.

 

Відносно плагінів для WordPress, на жаль, перевірка на відповідність стандартам не передбачена, проте в директорії плагінів на WordPress.org періодично проводиться сканування всіх плагінів на вразливість, і віддаляються ті, які становлять загрозу безпеці. Так само як і у випадку з темами, сторонні ресурси можуть написати статтю про дійсно корисний плагін, але замість того, щоб дати посилання для скачування плагіна на сторінку WordPress.org, вони дають змінений файл, де знову ж таки, можуть бути посилання на їх сайти або віруси.

 

Комерційні або «преміум» теми для WordPress

 

З преміум-темами справа йде трохи складніше. У зв’язку з тим, що WordPress.org є ресурсом некомерційного характеру, платних (комерційних, або преміум) тем на ньому немає, проте є список компаній, які розробляють преміум теми під ліцензією GPL. Компаніям з цього списку, як правило, можна довіряти.

 

 

Деякі з цих компаній є «біржами» тем для WordPress, з великою кількістю авторів і компаній-розробників. Такі біржі чимось схожі на WordPress.org, однак потрапити на них дещо простіше, ніж в безкоштовну директорію, оскільки їх контроль якості менш суворий, ніж на WordPress.org.

 

Преміум теми є платними. Коли ви купуєте тему (середній ціновий діапазон $ 30-60), то крім самої теми для WordPress, розробник забезпечить вам ще і її технічну підтримку. Вас має насторожити те, що вам пропонують завантажити комерційну тему безкоштовно. У цьому випадку ризики ті, ж що і при скачуванні безкоштовної теми зі стороннього ресурсу.

 

Перед тим як зробити покупку, завжди звертайте увагу на те, звідки ви завантажуєте тему. Шукайте відгуки про автора і про ресурс в пошукових системах. Також корисно перевірити сама назва теми, оскільки іноді недобросовісні блогери запозичують теми у успішних компаній і, навіть не змінюючи назви, видають їх за свої.

 

Якщо у вас все-таки виникли сумніви з приводу тієї, чи іншої теми, напишіть нам – ми з радістю допоможемо вам розібратися. Задавайте питання використовуючи форму коментування, і підписуйтесь на щотижневу розсилку. І наостанок – не забувайте про резервне копіювання, перш ніж активувати нову тему для WordPres

Чи варто оновлювати WordPress

Чи варто оновлювати WordPress

Якщо коротко, то так. Оновлення WordPress виходять досить часто і, на жаль, не завжди проходять так гладко, як хотілося б. Часто виникають проблеми із сумісністю тем і плагінів. У цій статті ми розглянемо типи оновлень, і чому варто оновлювати WordPress якомога швидше.
WordPress-development mypassive
Оновлення WordPress

Оновлення WordPress діляться на два типи: основні релізи (major release) і технічні (point release або maintenance release). Основні релізи містять новий функціонал, великі зміни і доповнення в API, так само в них усуваються помилки, знайдені в попередніх версіях. Технічні релізи за змістом набагато менші, і як правило виходять частіше. Вони усувають помилки і уразливості системи, не роблячи при цьому великих змін.

Відрізнити основний реліз від технічного дуже легко. Основні релізи нумеруються головним числом версії, наприклад: 3.4, 3.5, 3.6. Технічні релізи використовують другорядне число: 3.4.1, 3.4.2, 3.5.1.

WordPress відомий своєю зворотною сумісністю, і правильно написані теми і плагіни для більш ранніх версій WordPress, будуть однаково добре працювати і в більш нових версіях. Тим не менше, користувачі часто стикаються з темами і плагінами, які з тієї чи іншої причини «ламаються» при оновленні WordPress, особливо якщо мова йде про основний реліз. Це одна з причин, по якій багато хто воліє не оновлювати WordPress до останньої версії, але не всі знають, що це небезпечно.

Оскільки WordPress є проектом з відкритим вихідним кодом, будь-який бажаючий може порівняти поточну версію з попередньою, і дізнатися які саме уразливості були знайдені в попередній версії. Це означає, що зловмисникам не доведеться навіть шукати уразливості, щоб ними скористатися. Це ставить під загрозу ті сайти, власники яких не оновлюють WordPress вчасно, особливо при технічних релізах.

Оновлюйте WordPress вчасно, і не забувайте про резервне копіювання. Якщо ви шукайте інструкцію по оновленню WordPress, радимо звернутися до документації.

Оновлення плагінів

Більшість конфліктів при оновленні WordPress відбуваються з плагінами. Автори популярних плагінів готуються до оновлення заздалегідь, і часто оновлюють свої плагіни для сумісності ще до виходу нової версії WordPress. Як правило з такими плагінами рідко виникають які-небудь конфлікти.

Є плагіни, які оновлюються після виходу нової версії. Автори таких плагінів зазвичай чекають скарг з боку користувачів, перш ніж випустити нову версію. З такими плагінами проблеми виникають частіше, і багато користувачів воліють відкласти оновлення WordPress до моменту поновлення плагіна, якщо такий плагін критичний для їхнього сайту.

Є плагіни, які абсолютно не оновлюються. Такими плагінами користуватися так само небезпечно, як і старою версією WordPress. З недавніх пір в директорії на WordPress.org з’явилося попередження про те, що плагін не оновлювався протягом двох років.

Так само як і сам WordPress, плагіни варто оновлювати вчасно і по тих же самих причин. Багато розробники плагінів ведуть список змін, до якого можна звернутися, щоб дізнатися, що конкретно змінилося в новій версії. У директорії на WordPress.org для кожного плагіна існує блок «Сумісність» (Compatibility), де можна дізнатися про сумісність плагіна з вашою версією WordPress.

Якщо при оновленні плагіна виникли неполадки, то обов’язково зверніться до автора через форум підтримки.

Оновлення тем

З темами все набагато простіше, ніж з плагінами, особливо якщо тема встановлена з офіційної директорії на WordPress.org, оскільки такі теми проходять ретельну перевірку при кожному оновленні. Проблеми з темами при оновленні WordPress виникають вкрай рідко, навіть з тими, що ні оновлювалися більше двох років.

Якщо ж ви користуєтеся темами не з офіційних ресурсів, то вірогідність збоїв набагато вище. Радимо звернутися до нашої статті: Чому теми для WordPress варто скачувати тільки з офіційних ресурсів.

Висновок

Отже, чи варто оновлювати WordPress? Так. З основними релізами можна трохи почекати, а ось з технічними релізами краще оновлюватися в цей же день.

Більшість зломів WordPress відбувається через застарілі версій системи і плагінів. Не забувайте про резервне копіювання, а по можливості, перевіряйте поновлення локально або на іншій копії живого сайту. При виникненні збоїв і конфліктів після поновлення обов’язково зверніться в форум підтримки.

Управління сайтом Sitemap

Про файли Sitemap

Файл Sitemap дозволяє повідомити Google та іншим пошуковим системам про те, як організовані дані на вашому сайті. Пошукові роботи (наприклад, Googlebot) переглядають цей файл, щоб більш точно індексувати ваші сторінки.

Якщо сторінки файлу коректно пов’язані один з одним, пошукові роботи можуть виявити більшу частину матеріалів. Тим не менш, за допомогою файлу Sitemap можна оптимізувати сканування сайту, особливо в таких випадках:

Розмір сайту дуже великий. Пошукові роботи Google можуть пропустити нещодавно створені або змінені сторінки.
Сайт містить великий архів сторінок, які не пов’язані один з одним. Щоб вони були успішно просканувати, їх можна перерахувати у файлі Sitemap.
Ваш сайт створений недавно, і на нього вказує мало посилань. Робот Googlebot і інші пошукові роботи сканують Інтернет, переходячи по посиланнях з однієї сторінки на іншу. Якщо на ваш сайт вказує мало посилань, його буде складно знайти.
На сайті використовується мультимедійний контент, він відображається в Новинах Google або використовує інші анотації, сумісні з файлами Sitemap. З файлів Sitemap може отримувати додаткову інформацію для відображення в результатах пошуку.
Файли Sitemap також можна використовувати для надання системі Google метаданих про ваших сторінках. Це такі відомості, як дата оновлення сторінки, періодичність її зміни і її важливість в порівнянні з іншими URL на сайті.

Файли Sitemap також можна використовувати для надання системі Google метаданих про типи контенту, включаючи відеофайли, зображення і матеріали для мобільних пристроїв. Наприклад, про зображення і відеофайли ви можете повідомити наступну інформацію:

У записі про відео може бути вказана його тривалість, категорія і придатність для сімейного перегляду.
Запис про зображення може містити відомості про його темі, тип і ліцензії.
Увага! Навіть якщо ви створили файл Sitemap, це не гарантує, що Google буде сканувати та індексувати всі ваші сторінки, так як ці процедури виконуються за допомогою складних алгоритмів. У більшості випадків ці файли приносять користь і не викликають помилок

Інстументи для веб-майстрів

Думаю після того як створили сайт пригодиться інструмент для веб-майстрів для цього
заходимо на сайт https://www.google.com/webmasters/
1
Натискаємо на кнопочку, увійти в інстументи веб-майстрів. З’єднуєм зі своїм обліковим записом
2
Добавляєм свій сайт3
Дані, які відображаються в Інструментах для веб-майстрів, можуть відрізнятися від даних в інших інструментах, наприклад в Google Analytics. Можливі причини описані нижче.

Інструменти для веб-майстрів виконують певну додаткову обробку даних, наприклад обробку дублюючого змісту та відвідувань роботів. Тому статистика може відрізнятися від даних інших джерел.
Деякі інструменти, наприклад Google Analytics, відстежують трафік тільки від тих користувачів, в браузерах яких включена підтримка JavaScript.
Google Analytics відстежує відвідування тільки тих сторінок, на яких є правильно налаштований фрагмент коду цієї системи на мові JavaScript. Якщо ж на сторінках сайту відсутній такий код, відвідування цих сторінок не відстежуються. При цьому відвідування сторінок без коду відстеження Google Analytics будуть враховуватися в Інструментах для веб-майстрів, якщо користувачі переходять на ці сторінки з результатів пошуку. Реєструються також відвідування, виконані системами Google.
У різних інструментах поняття “ключові слова” визначається по-різному. приклад:
На сторінці ключових слів в Інструментах для веб-майстрів відображаються найбільш значущі слова, виявлені Google на вашому сайті.
В Google AdWords інструмент “Ключові слова” показує загальну кількість запитів по цьому ключовому слову, зроблених користувачами в Інтернеті.
Google Analytics використовує термін “ключові слова” для опису як запитів в пошукових системах, так і ключових слів оголошень AdWords.
На сторінці “Пошукові запити” в Інструментах для веб-майстрів зазначена загальна кількість пошукових запитів за ключовим словом, які призвели до показу вашої сторінки в результатах пошуку. Це менше число.
Показники можуть відображатися з деякою затримкою. Це пов’язано з тим, що дані публікуються через певні інтервали, хоча їх збір йде постійно.
Якщо запит перестав відображатися на сторінці “Пошукові запити” в Інструментах для веб-майстрів, переконайтеся, що результати не фільтруються по країні або типу пошуку.

Інструменти для веб-майстрів накопичують інформацію про пошукові запити і показують її, коли по кожному із запитів досягнутий певний поріг. У журналах може бути зазначено, що у певного запиту був високий рейтинг в певний день або протягом певного періоду, але цей запит може не з’явитися в списку “Пошукові запити”. Проте якщо цей запит буде як і раніше популярним, він переміститься на верхні позиції зведених результатів і потрапить на сторінку “Пошукові запити”.

Крім того, в статистиці Google для веб-майстрів відображаються тільки запити в пошуку Google. Але у ваших журналах можуть бути дані і по інших пошуковим системам.

Як запросити повторне сканування сторінок
Змінивши якійсь із URL на сторінках, ви можете оновити відомості про них в Google Пошуку за допомогою функції Додати в індекс інструменту “Переглянути як Googlebot”. Ця функція дозволяє відправити в Google запит на сканування нового змісту.

Перш ніж зробити це, виконайте сканування (або сканування з відображенням) індексованою сторінки, щоб виявити можливі помилки. Після цього в таблиці ви побачите кнопку Додати в індекс. Вона відображається тільки при виконанні наступних умов:

Статус сканування: Готово, Частково виконано або переадресовано.
Платформа для сканування: ПК або Смартфон.
Сканування виконано не більше 4 год. Тому.
Після натискання кнопки Додати в індекс Google виконує сканування та індексування сторінки в її поточному вигляді. Якщо змінити зміст сторінки, яка чекає додавання в індекс, результати повторного сканування можуть відрізнятися від відомостей на сторінці “Переглянути як Googlebot”. Зверніть увагу, що Google сканує сторінку після відправлення запиту, тому використовуваний метод (сканування або сканування з відображенням) не має значення.
При натисканні кнопки Додати в індекс вам буде запропоновано вказати параметри запиту. Виконайте наведені нижче інструкції.

Як запросити сканування та індексування сторінки
Натисніть кнопку Додати в індекс поруч зі статусом успішного сканування в таблиці результатів сканування.
Щоб додати окрему адресу в індекс Google, виберітеСканіровать тільки цей URL. Цим способом можна додавати до 500 URL на тиждень.
Щоб додати URL і всі сторінки, на які він посилається, виберітеСканіровать цей URL і прямі посилання. Можна відправляти до 10 таких запитів в місяць.
Натисніть Надіслати.
Після додавання URL потрібно почекати, поки Google просканує і проиндексирует ваші сторінки. Ми не гарантуємо індексування всіх змін, т. К. Для оновлення інформації використовуються складні алгоритми.

Зв’язування Analytics і AdSense

Зв’язування Analytics і AdSense

Щоб в обліковому записі Google Analytics отримувати дані із системи AdSense, спершу потрібно вибрати ресурс Analytics для зв’язування з AdSense. Якщо ви ще не маєте облікового запису Analytics, перейдіть на веб-сайт Google Analytics, щоб зареєструвати новий обліковий запис.

Перш ніж розпочати зв’язування, переконайтеся, що ви використовуєте дані для входу в обліковий запис Google AdSense, який має як адміністративний доступ до облікового запису AdSense, так і дозвіл на редагування ресурсу Google Analytics.

Якщо ви хочете зв’язати новий обліковий запис, але ваш обліковий запис Google Analytics або Google AdSense закрито, то заново відкрийте закритий обліковий запис і видаліть зв’язок, а вже потім зв’язуйте інший обліковий запис.
Щоб зв’язати облікові записи Analytics і AdSense, виконайте описані нижче дії.

Увійдіть у свій обліковий запис Google Analytics.
Натисніть вкладку Адміністратор у верхній частині сторінки.
У стовпці “Обліковий запис” виберіть обліковий запис Analytics із ресурсом, який необхідно зв’язати з обліковим записом AdSense.
У стовпці “Ресурс” виберіть ресурс Analytics, який необхідно зв’язати, і натисніть Зв’язування AdSense.
На сторінці “Зв’язування AdSense” натисніть + Новий зв’язок АdSense.
Виберіть ресурс AdSense, який необхідно зв’язати з Analytics.
Натисніть Продовжити.
Виберіть представлення даних Analytics, у якому мають відображатися дані AdSense.
Натисніть Увімкнути зв’язок.
Натисніть Готово.
Облікові записи Analytics і AdSense зв’язано.
Зв’язавши ресурси AdSense і Analytics, потрібно налаштувати код для відстеження сайтів AdSense у системі Analytics.

Теми WordPress

Структура теми WordPress.За замовчуванням поточна версія WordPress містить у собі 3 стандартні теми — Twenty Ten, Twenty Eleven та Twenty Twelve. Проте розробники дали можливість створювати власні теми. Кожен шаблон теми WordPress повинен мати хоча б 2 головних файли.
Список основних файлів шаблонів WordPress
список основних шаблонів
Ієрархія теми WordPress
1280px-Wordpress_Template_Hierarchy
Функції WordPress для власних тем
Для звернення до файлів шаблонів WordPress або тієї чи іншої інформації з бази даних розробники створили спеціальні функції. Для прикладу, щоб вставити вміст файлу header.php, потрібно написати такий код:

або:

А для того, щоб вставити зміст поточного запису, потрібно написати такий код:

functions.php
Будь-яка тема WordPress може мати власний набір функцій для розширення можливостей. Так як і плагіни, код цього файлу може редагувати практично будь-який елемент цієї СКВ. Для прикладу наступний код замінить текст з «підвалу» панелі адміністратора посиланням на статтю «Wordpress» в українській Вікіпедії:
function replace_wiki(){
echo(“Детальніше про WordPress“);
}
add_filter(‘admin_footer_text’, ‘replace_wiki’);

Плагіни WordPress

Плагіни WordPress — це елементи для розширення функціональності системи керуванням вмісту.
Стандартними плагінами, які йдуть за замовчуванням у вордпресі є Akismet — перевірка «спаму» в коментарях та Hello Dolly — перший плагін WordPress. Створений для вивчення користувачами принципу написання плагінів. Коли він увімкнений, в правому верхньому кутку панелі адміністратора відображається довільна стрічка з пісні «Hello Dolly» Луї Армстронга)

Розробники WordPress дали можливість користувачам створювати власні плагіни. Всі файли плагінів розміщуються в теці wp-content/plugins. Його головний файл повинен бути написаний на мові PHP, та на початку файлу повинен бути наступний текст:

Як встановити Google AdSense

Реєстрація в Google AdSense. Зареєструватися в AdSense дуже просто, необхідно лише мати готовий сайт та обліковий запис в Google. Після чого заходим на основний сайт Google AdSense.

www.google.com/adsense/start

Натискаєм на кнопочку Get started now і в три кроки формуєм заявку. Крок перший пов’язуєм наявний або створюємо новий обліковий запис Google з AdSense
mypassive AdSense
Крок другий вказуєм інформацію про сайт
mypassive AdSense 2
І третій крок це формування та відправлення заявки, розгляд якої може тривати до семи днів.
Мою заявку розглядали один день і дали підтвердження. Далі переходимо по посиланні, яке в листі підтверджені направляє нас в особистий кабінет AdSense. Тепер ми можем створювати рекламні блоки, правда потрібно пройти ще одну перевірку, яка почнеться після того як ми розмістимо рекламний блок на сторінці свого сайту. На головній сторінці особистого кабінету нажимаєм на кнопку “добавити рекламний блок”.
Створюємо свій перший рекламний блок, я назвав свій “1”, згенерувавший код копіюєм
reklama
і всавляєм на сторінках свого сайту. У мене вийшло, пробуйте і у вас вийде))
ось так це виглядає.



WordPress

WordPress — це проста у встановленні та використанні система керування вмістом з відкритим кодом, яка широко використовується для створення веб-сайтів. Сфера застосування — від блогів до складних веб-сайтів. Вбудована система тем і плаґінів в поєднанні з вдалою архітектурою дозволяє конструювати на основі WordPress практично будь-які веб-проекти.
Написана на мові програмування PHP з використанням бази даних MySQL. Сирцевий код поширюється на умовах ліцензії GNU General Public License.
У 2003 році автори Open Source блогу b2 відмовляються від проекту. Метью Мюленвег і його друг продовжують його існування та змінюють назву на WordPress. Вже того ж року СКВ помічає велика компанія CNET та використовують її у якості блогу компанії. У 2004 році ця ж компанія пропонує Метью роботу, на яку він погоджується. В період роботи у CNET Метью не вистачає часу на роботу над WordPress і у 2005 році Метью покидає компанію і разом з Тонні Шнайдером створюють свою компанію з назвою «Automattic», яка орієнтувалась на проектах на базі WordPress. У 2006 році в Automattic було інвестовано 1,1 млн доларів декількома інвесторами (в тому числі і CNET), після чого компанія розширилась. На даний момент ринкова ціна Automattic оцінена в 30,6 млн доларів, а працюють в ній близько 30 чоловік.
Метью Мюленвег і Майк Літл були співзасновниками проекту. Серед головних розробників Райан Борен, Марк Джаквіт, Метью Мюленвег, Ендрю Озз, Пітер Вествуд та Ендрю Накін.
WordPress також розробляють члени спільноти, в тому числі WP тестери, група добровольців, які перевіряють кожний реліз. Вони отримують ранній доступ до нічних збірок, бета-версій та реліз-кандидатів. Помилки публікуються в спеціальній розсилці, або в інструменті Trac.
У вересні 2010 року, Automattic передав торгову марку WordPress в WordPress Foundation, організацію, що підтримує WordPress.org (включаючи програмне забезпечення та архіви для плагінів та тем), bbPress та BuddyPr
Можливості:
Дизайн, управління системою та інші можливості
простота встановлення, простота налаштувань;
підтримка веб-стандартів (XHTML, CSS);
модулі для підключення (плаґіни) з унікально простою системою їх взаємодії з кодом; можливість автоматичного встановлення та оновлення версії безпосередньо з панелі адміністратора;
підтримка так званих «тем», з допомогою яких легко змінюється як зовнішній вигляд, так і способи виведення даних;
можливість редагувати шаблони одразу в панелі адміністратора;
«теми» реалізовані як набори файлів-шаблонів на PHP (у HTML-розмітку вставляються PHP-мітки);
багато бібліотек «тем» і «плаґінів»;
потенціал архітектури дозволяє легко реалізовувати складні рішення;
СЕО-оптимізована система;
наявність українського перекладу.
Публікація та редагування
миттєва публікація;
підтримка RSS, Atom, trackback, pingback;
наявність ЛЗУ (людино-зрозумілий URL);
редагування WYSIWYG-редактором з можливістю вставлення форматованого тексту (наприклад з програми Microsoft Word) або редагування за допомогою HTML-розмітки.
Контент
наперед заплановані публікації;
багатосторінкові записи;
прикріплення файлів та зображень до записів;
можливість створення статичних сторінок;
можливість створення свого типу контенту у власних темах;
категорії, теги, коментування тощо.

Доменне ім’я

Щоб розібратись, що таке доменне ім’я я вирішив звернутись до вікіпедії.Досить доступно як на мене.
Доменне ім’я (англ. Domain name) має кілька значень:
Доменна система імен (англ. Domain Name System, DNS) — розподілена система перетворення імені хоста (комп’ютера або іншого мережевого пристрою) в IP-адресу. Кожен комп’ютер в Інтернеті має свою власну унікальну адресу — число, яке складається з чотирьох байтів. Оскільки запам’ятовування десятків чи навіть сотень — не досить приємна процедура, то всі (чи майже всі) машини мають імена, запам’ятати які (особливо якщо знати правила утворення імен) значно легше. Уся система імен в Інтернеті — ієрархічна. Це зроблено для того, щоб не підтримувати одне централізоване джерело, а роздати владу на місця.
Правила формування імен
Повне доменне (від англ. domain) ім’я машини (FQDN, Fully Qualified Domain Name) можна розбити на дві частини — ім’я області-домена та власне ім’я машини. Наприклад, m30.ziet.zhitomir.ua — повне доменне ім’я машини m30, яка перебуває у домені ziet.zhitomir.ua.
За порядок у доменах, як правило, відповідає певний комп’ютер, користувачі-адміністратори якого слідкують за тим, щоб не було, наприклад, різних машин з однаковими ІР-адресами. Наприклад, відповідальність за область-домен ziet.zhitomir.ua покладається на машину alpha.ziet.zhitomir.ua Ця влада делегується зверху вниз від машини ns.lucky.net, яка відповідає за домен zhitomir.ua. В свою чергу, відповідальність за область ua делегована машині зверху від так званих кореневих серверів (root server). Всю цю систему можна уявити у вигляді перевернутого дерева. Нижче наведений список імен доменів верхнього рівня (далеко не повний). Повний список географічних областей, в основному, відповідає двобуквеним ISO-кодам країн і його можна знайти, наприклад, на WWW-сервері ISOC
Необхідно розрізняти доменне ім’я, та поштову адресу. В поштовій адресі повинен бути знак «@», який розділяє поштову адресу на доменне ім’я та ім’я поштової скриньки. Коли мережа Інтернет була молода та невелика, таблиці відповідності імен та адрес зберігалися у звичайному текстовому файлі, який періодично просто розсилався всім учасникам електронною поштою. Після того, які кількість машин значно збільшилася, така схема перестала ефективно працювати і програмісти університету штату Каліфорнія в Берклі спроектували і написали програму BIND (Berkeley Internet Name Domain), яка відповідає на запити машин користувачів, які стосувалися імен та ІР-адресу.
Служба імен DNS (Domain Name System) — це розподілена база даних доволі простої структури. Для початкового знайомства можна вважати, що це кілька таблиць, у яких записано:
яку ІР-адресу має машина з певним іменем;
яке ім’я має машина з визначеною адресою;
що це за комп’ютер і яка операційна система встановлена на ньому;
куди потрібно направляти електронну пошту для користувачів цієї машини;
які псевдоніми є у даної машини.
Для прикладу розглянемо випадок, коли користувач посилає пошту з машини polesye.zhitomir.ua користувачу за адресою rozhik@ziet.zhitomir.ua (знак «@» носить назву commercial «at» sign). При встановленні на машину протоколів TCP/IP системний адміністратор вказує ІР-адресу комп’ютера — найближчого серверу імен. Поштова програма подає цьому найближчому серверу запит: «Куди посилати пошту для ziet.zhitomir.ua» Якщо найближчий сервер не може відповісти, то він, в свою чергу, посилає запит до більш «старшого» серверу. Нарешті, стає зрозумілим, що всю пошту для області ziet.zhitomir.ua необхідно відправляти на машину alpha.ziet.zhitomir.ua або relay2.lucky.net. Разом з цим відповіді містять ще адресу цієї машини. Поштова програма зв’язується з цим комп’ютером (використовуючи не ім’я, а адресу) та передає йому пошту.
Всі ці переговори та відправка пошти, як правило, відбувається протягом кількох секунд і користувач не помічає цього. Якщо машина ziet.zhitomir.ua недоступна то тоді пошта на час, в якій неможливо зв’язатися з машиною ziet.zhitomir.ua (наприклад під час профілактики каналу зв’язку) чекає своєї черги на пересилку на машині relay2.lucky.net. Це характерна для Internet-програм поведінка. Як правило, поштові програми подають доволі багато запитів службі DNS, і ці питання доволі складні. У більшості випадків у програмах користувачів намагаються дізнатися лише одне — яка ІР-адреса у машини з відповідним іменем.
Зрозуміло, що всередині цієї системи імен існує маса нюансів, правил та хитрощів. Докладніше з ними можна ознайомитися в описах стандартів Internet або в спеціальних книгах. Компанія «Хостмастер» спільно з ICANN в Україні ввела у дію локальний кореневий сервер DNS, що містить інформацію про домени верхнього рівня. Сервер є «дзеркалом» одного з 13-кореневих серверів ICANN, відомого під назвою «L-root».
Ієрархічна структура системи DNS
Як вже було відмічено, існує домен кореневого рівня, який позначається «„.“». Наступний рівень ієрархії — це домени верхнього рівня. Вся структура служби DNS є ієрархічною. Існують домени першого, другого, третього, n-го рівнів. Розглянемо доменне ім’я комп’ютера «www.department.firma.isp.ru». Тут доменом першого рівня є ru, isp — другого, firma — третього, а department — четвертого рівня. [1]
Типи серверів DNS
Існує три основні типи серверів DNS, які відрізняються покладеними на них завданнями: основний сервер DNS; резервний (вторинний) сервер DNS; кешуючий сервер DNS. Основний сервер DNS управляє зоною повноважень. Якщо потрібно додати/видалити домен або вузол або якось інакше модифікувати зону, зміни потрібно проводити на основному сервері DNS. Через певний час, який залежить від настройок сервера, основний сервер передасть зону резервному серверу DNS. Дане явище називається трансфером зони. Що ж до резервних серверів, то повинен бути хоч би один резервний сервер DNS. Тому є декілька причин: якщо клієнтів багато, то наявність резервного сервера DNS дозволить знизити навантаження на основний сервер DNS і прискорити доступ фізично віддалених від основного сервера клієнтів до бази даних доменних імен.
Ключові характеристики DNS
DNS володіє наступними характеристиками: Розподільність адміністрування. Відповідальність за різні частини ієрархічної структури несуть різні люди або організації. Розподільність зберігання інформації. Кожен вузол мережі в обов’язковому порядку повинен зберігати тільки ті дані, які входять в його зону відповідальності та (можливо) адреси кореневих DNS-серверів. Кешування інформації. Вузол може зберігати деяку кількість даних не зі своєї зони відповідальності, для зменшення навантаження на мережу. Ієрархічна структура, в якій всі вузли об’єднані в дерево, і кожен вузол може або самостійно визначає роботу нижчестоящих вузлів, або делегувати (передавати) їх іншим вузлам. Резервування. За зберігання та обслуговування своїх вузлів (зон) відповідають (зазвичай) кілька серверів, розділені як фізично, так і логічно, що забезпечує збереження даних і продовження роботи навіть у разі збою одного з вузлів. DNS важлива для роботи Інтернету, так як для з’єднання з вузлом необхідна інформація про його IP-адресу, а для людей простіше запам’ятовувати буквені (зазвичай осмислені) адреси, ніж послідовність цифр IP-адреси. У деяких випадках це дозволяє використовувати віртуальні сервери, наприклад, HTTP-сервери, розрізняючи їх по імені запиту. Спочатку перетворення між доменними та IP-адресами вироблялося з використанням спеціального текстового файлу hosts, який складався централізовано й автоматично розсилався на кожну з машин у своїй локальній мережі. З ростом Мережі виникла необхідність в ефективному, автоматизованому механізмі, яким і стала DNS. DNS була розроблена Полом Мокапетрісом в 1983 році; оригінальний опис механізмів роботи містяться в RFC 882 і RFC 883. У 1987 публікація RFC 1034 і RFC 1035 змінила специфікацію DNS і скасувала RFC 882, RFC 883 і RFC 973 як застарілі.
Термінологія і принципи роботи
Ключовими поняттями DNS є: Домен (англ.domain — область) — частина простору ієрархічних імен мережі Інтернет, що обслуговується групою серверів доменних імен (DNS-серверів) та централізовано адмініструється. DNS-сервери зберігають інформацію про вузли, імена яких належать домену і виконують трансляцію їх імен в адреси. Кожний домен має унікальне ім’я, а кожен комп’ютер, підключений до Інтернету, має, як правило, доменне ім’я. Домени мають між собою ієрархічні відношення. Два домени, що розташовані на сусідніх рівнях ієрархії, називаються відповідно доменом вищого та нижчого рівнів. Домени найвищого (верхнього) рівня можуть бути сформовані за організаційним або географічним ознаками. Домени, сформовані за географічним ознаками, об’єднують вузли, що належать конкретній державі. За географічними ознаками об’єднуються в основному комп’ютери, що містяться на території США.
Піддомен (англ. subdomain) — підлеглий домен (наприклад, wikipedia.org — піддомен домену org, а uk.wikipedia.org — домену wikipedia.org). Теоретично такий розподіл може досягати глибини в 127 рівнів, а кожна мітка може містити до 63 символів, поки загальна довжина разом з крапками не досягне 254 символів. Але на практиці реєстратори доменних імен використовують більш суворі обмеження. Наприклад, якщо у вас є домен виду mydomain.ua, ви можете створити для нього різні піддомени виду mysite1.mydomain.ua, mysite2.mydomain.ua і т. д.
Ресурсний запис — одиниця зберігання і передачі інформації в DNS. Кожний ресурсний запис має ім’я (тобто прив’язаний до певного доменного імені, вузлу в дереві імен), тип і поле даних, формат і зміст якого залежить від типу. Зона — частина дерева доменних імен (включаючи ресурсні записи), що розміщується як єдине ціле на деякому сервері доменних імен (DNS-сервері, див. нижче), а частіше — одночасно на декількох серверах (див. нижче). Метою виділення частини дерева в окрему зону є передача відповідальності (див. нижче) за відповідний домен іншій особі або організації. Це називається делегуванням (див. нижче). Як зв’язкова частина дерева, зона всередині теж являє собою дерево. Якщо розглядати простір імен DNS як структуру із зон, а не окремих вузлів/імен, теж виходить дерево; виправдано говорити про батьківських і дочірніх зонах, про старших і підлеглих. На практиці, більшість зон 0-го і 1-го рівня (‘.’, ua, com, …) складаються з єдиного вузла, якому безпосередньо підпорядковуються дочірні зони. У великих корпоративних доменах (2-го і більше рівнів) іноді зустрічається утворення додаткових підпорядкованих рівнів без виділення їх у дочірні зони. Делегування — операція передачі відповідальності за частину дерева доменних імен іншій особі або організації. За рахунок делегування в DNS забезпечується розподільність, адміністрування та зберігання. Технічно делегування виражається у виділенні цієї частини дерева в окрему зону, і розміщенні цієї зони на DNS-сервері (див. нижче), керованому цією особою чи організацією. При цьому в батьківську зону включаються «склеюючі» ресурсні записи (NS і А), що містять покажчики на DNS-сервера дочірньої зони, а вся інша інформація, що відноситься до дочірньої зоні, зберігається вже на DNS-серверах дочірньої зони. DNS-сервер — програма, призначена для відповідей на DNS-запити за відповідним протоколом. Також DNS-сервером можуть називати хост, на якому запущено відповідну програму.
DNS-клієнт (від англ. Domain Name System-client — доменних імен система — клієнт) — програма або модуль в програмі, що забезпечує з’єднання із DNS-сервером для визначення IP-адреси по його доменному імені. Авторитетність (англ. authoritative) — ознака розміщення зони на DNS-сервері. Відповіді DNS-сервера можуть бути двох типів: авторитетні (коли сервер заявляє, що сам відповідає за зону) і неавторитетні (англ. Non-authoritative), коли сервер обробляє запит, і повертає відповідь інших серверів. У деяких випадках замість передачі запиту далі DNS-сервер може повернути вже відоме йому (за запитами раніше) значення (режим кешування). DNS-запит (англ. DNS query) — запит від клієнта (або сервера) сервера. Запит може бути рекурсивним або нерекурсивний (див. Рекурсія). Система DNS містить ієрархію DNS-серверів, відповідну ієрархії зон. Кожна зона підтримується як мінімум одним авторитетним сервером DNS (від англ. Authoritative — авторитетний), на якому розташована інформація про домен. Ім’я та IP-адресу не тотожні — одна IP-адреса може мати безліч імен, що дозволяє підтримувати на одному комп’ютері безліч веб-сайтів (це називається віртуальний хостинг). Зворотне теж справедливо — одному імені може бути зіставлено безліч IP-адрес: це дозволяє створювати балансування навантаження. Для підвищення стійкості системи використовується безліч серверів, що містять ідентичну інформацію, а в протоколі є засоби, що дозволяють підтримувати синхронність інформації, розташованої на різних серверах. Існує 13 кореневих серверів, їх адреси практично не змінюються. Протокол DNS використовує для роботи TCP-або UDP-порт 53 для відповідей на запити. Традиційно запити та відповіді відправляються у вигляді однієї UDP дейтаграми. TCP використовується для AXFR-запитів.
Принцип роботи
Система імен DNS – це ієрархічна деревоподібна система. У цьому дереві існує корінь – він позначається «.» (root). Список кореневих серверів повинен бути у кожного сервера: він міститься у файлі named. са. Цей файл може називається і по-іншому – залежно від налаштувань сервера. Існує певна кількість доменів верхнього рівня. Найбільш відомі ви знаєте: com, gov, net, org та інші (у тому числі і домени країн – ru, ua, fr та ін.). Нехай користувач вводить у вікні браузера адрес http :// server . Проте адресація в локальній мережі (так само як і в Інтернет) побудована на основі IP-протоколу. Тому для того, щоб встановити з’єднання з комп’ютером server комп’ютеру користувача необхідно знати його IP-адресу, тому операційна система користувача намагається вирішити (перевести) ім’я комп’ютера в IP-адресу. З цією метою вона спочатку використовує свої стандартні засоби (той же файл hosts), а потім звертається до служби DNS. Розглянемо тепер інтернет-адресу www.yahoo.com (насправді абсолютно неважливо це інтернет-адреса або адреса в локальній мережі – все те ж саме). Сервер DNS спочатку намагається вирішити ім’я даного комп’ютера, використовуючи свій власний кеш імен. Якщо необхідне ім’я комп’ютера в нім відсутнє, то сервер DNS звертається до одного з кореневих серверів DNS, про які ми поговоримо пізніше. Запит обробляється рекурсивно: кореневий сервер звертається до сервера, який відповідає за домен com, а той, у свою чергу, до сервера DNS домена yahoo.com. Сервер DNS домена yahoo.com повертає IP-адресу комп’ютера www – 64.58.76.222 або всі адреси, які зіставлені цьому імені (багато мережевих операційних систем, у тому числі і Linux, дозволяють одному імені зіставляти декілька IP-адрес). А офіційне ім’я комп’ютера www.yahoo.com (це його канонічне ім’я – про канонічні імена і як їх використовувати буде сказано нижче) – www. yahoo . akadns. net Схеми запитів DNS-імен Нерекурсивна процедура: 1.DNS-клієнт звертається до кореневого DNS-сервера з вказівкою повного доменного імені; 2.DNS-сервер відповідає клієнту, вказуючи адресу наступного DNS-сервера, який виконує обслуговування домену верхнього рівня, заданого в наступній старшій частині імені; 3.DNS-клієнт виконує запит наступного DNS-сервера, який його надсилає до DNS-сервера потрібного піддомена і т.д., доти, доки не буде знайдено DNS-сервер, який повністю відповідає запитуваному імені IP-адреси. Сервер дає кінцеву відповідь клієнту. Рекурсивна процедура: 1.DNS-клієнт запитує локальний DNS-сервер, який обслуговує піддомен, якому належить клієнт; 2.Далі, якщо локальний DNS-сервер відповідь знає, то повертає її клієнту, в протилежному випадку виконує ітеративні запити до кореневого сервера до тих пір, поки не отримає відповідь. Після отримання відповіді сервер передає її клієнту. Таким чином, при рекурсивній процедурі клієнт фактично передоручає роботу власному серверу. Для прискорення пошуку IP-адрес DNS-сервери часто застосовують кешування (на час від годин до декількох днів) відповідей, які проходять через них. Записи DNS Записи DNS, або Ресурсні записи (англ. Resource Records, RR) – одиниці зберігання і передачі інформації в DNS. Кожний ресурсний запис складається з наступних полів: ім’я (NAME) – доменне ім’я, до якого прив’язана або яким «належить» даний ресурсний запис; TTL (Time To Live) – допустимий час зберігання даного ресурсного запису в кеші не відповідального DNS-сервера; тип’ (TYPE) ресурсного запису – визначає формат і призначення даного ресурсного запису; клас (CLASS) ресурсної записи; теоретично вважається, що DNS може використовуватися не тільки з TCP / IP, але і з іншими типами мереж, код в поле клас визначає тип мережі; довжина поля даних (RDLEN); поле даних (RDATA), формат та зміст якого залежить від типу запису.
Найбільш важливі типи DNS-записів
Запис A(address record) або запис адреси зв’язує ім’я хоста з адресою IP. Наприклад, запит A-запису на ім’я referrals.icann.org поверне його IP адресу – 192.0.34.164
Запис AAAA (IPv6 address record) зв’язує ім’я хоста з адресою протоколу IPv6. Наприклад, запит AAAA-запису на ім’я K.ROOT-SERVERS.NET поверне його IPv6 адресу – 2001:7 fd :: 1
Запис CNAME (canonical name record) або канонічний запис імені (псевдонім) використовується для перенаправлення на інше ім’я
Запис MX (mail exchange) або поштовий обмінник вказує сервер(и) обміну поштою для даного домену. Запис NS (name server) вказує на DNS-сервер для даного домену.
Запис PTR (pointer) або запис покажчика зв’язує IP хоста з його канонічним ім’ям. Запит в домені in-addr.arpa на IP хоста в reverse формі поверне ім’я (FQDN) даного хоста (див. Зворотній DNS-запит). Наприклад, (на момент написання), для IP адреси 192.0.34.164: запит запису PTR 164.34.0.192.in-addr.arpa поверне його канонічне ім’я referrals.icann.org. З метою зменшення обсягу небажаної кореспонденції (спаму) багато серверів-одержувачів електронної пошти можуть перевіряти наявність PTR запису для хоста, з якого відбувається відправлення. У цьому випадку PTR запис для IP адреси повинна відповідати імені відправляючого поштового сервера, яким він представляється в процесі SMTP-сесії.
Запис SOA (Start of Authority) або початковий запис зони вказує, на якому сервері зберігається еталонна інформація про даний домен, містить контактну інформацію особи, відповідальної за дану зону, таймінги (параметри часу) кешування зонної інформації та взаємодію DNS-серверів. SRV-запис (server selection) вказує на сервери для сервісів, використовується зокрема для Jabber і Active Directory.
Зарезервовані доменні імена
Документ RFC 2606 (Reserved Top Level DNS Names – Зарезервовані імена доменів верхнього рівня) визначає назви доменів, які слід використовувати в якості прикладів (наприклад, в документації), а також для тестування. Крім example.com, example.org і example.net, в цю групу також входять test, invalid і ін.
Інтернаціональні доменні імена
Доменне ім’я може складатися тільки з обмеженого набору ASCII символів, дозволяючи набрати адресу домену незалежно від мови користувача. ICANN затвердив засновану на Punycode систему IDNA, перетворюючи будь-який рядок в кодуванні Unicode в допустимий DNS набір символів.