ВХОДЯЩ трафик при два доставчика

[MitkoS]

Ghost,
някои неща не са точно така. В конкретния случая проблема не е в самия майкрософтски DNS-сървър. (Става въпрос за описанието на проблема http://as112.ludost.net/faq.html) Проблема е, че когато същия майкрософтски DNS-сървър попадне в ръцете на начинаещ администратор, то той наистина може да бъде причина за огромно количество ненужен трафик. Типичен пример за този проблем/грешка е, при включване на домейн-контролера, на който е DNS-сървъра, то процеса на зареждане да трае 15-20 минути (и повече). Голямото забавяне е именно в опитите за регистрация на ненужни записи във висшестоящи DNS-сървъри. Често срещано явление, но това се дължи на лошо конфигуриране. Както можеш да се досетиш, и на мен нищо човешко не ми е чуждо и тая грешка съм я правил и аз.
А що се отнася до друг безплатен DNS-сървър, принципно това може да стане, но той трябва да си работи самостоятелно, да обслужва само външните интерфейси и да няма нищо общо с windows-домейна. Досегашните ми наблюдения, ми подсказват, че когато става въпрос за сравнително не много голям обем от допълнителни зони и записи (какъвто е моя случай) майкрософтския DNS-сървър в Win2003 си работи предостатъчно добре.
// Самото съществуване на windows-домейн, предполага задължително съществуване на майкрософтски DNS-сървър, който да го обслужва. И така или иначе, тоя DNS-сървър си присъства и е срамота да се ползва допълнителен друг, вместо да се положат необходимите усилия този да работи както трябва.

[etg]

някои неща не са точно така. В конкретния случая проблема не е в самия майкрософтски DNS-сървър. (Става въпрос за описанието на проблема http://as112.ludost.net/faq.html) Проблема е, че когато същия майкрософтски DNS-сървър попадне в ръцете на начинаещ администратор, то той наистина може да бъде причина за огромно количество ненужен трафик. Типичен пример за този проблем/грешка е, при включване на домейн-контролера, на който е DNS-сървъра, то процеса на зареждане да трае 15-20 минути (и повече). Голямото забавяне е именно в опитите за регистрация на ненужни записи във висшестоящи DNS-сървъри. Често срещано явление, но това се дължи на лошо конфигуриране.

И така не са някои неща. Всеки софтуер ако попадне в ръцете на неподходящ човек може да създаде достатъчно проблеми, не само майкрософтския. Само че е нормално като се пусне даден софтуер, то той и да не работи както трябва без допълнително конфигуриране най-малкото да не създава проблеми. А софтуер от рода на DNS се предполага, че ще бъде в ръцете на някой, който все пак отбира от нещо. И ако за някоя офис програма е оправдано "да се опитва да бъде по-умна" от човека който я ползва, то е защото се предполага, че е много вероятно да попадне в ръцете на човек, напълно незапознат с компютрите, но целта е все пак той успее да си свърши работата. Докато един DNS да проявява такава "интелигентност", че на всичкото отгоре и да се бърка в работата на другите програми по мрежата, без да му е указано... Не намирам оправдание.

[KoftiSector]

// Самото съществуване на windows-домейн, предполага задължително съществуване на майкрософтски DNS-сървър, който да го обслужва. И така или иначе, тоя DNS-сървър си присъства и е срамота да се ползва допълнителен друг, вместо да се положат необходимите усилия този да работи както трябва.

Не са така и други неща.МS услуги управлчвани от NT style DC (което също е виндовс-домайн) не се нуждаят от MS DNS имплементация - всъщност не се нуждаят от никakъв DNS . Там кой компютър с какво IP е, какви MS услуги предлага и тн. е на съвсем различен принцип (http://support.microsoft.com/kb/139608). За останалите услуги можеш да използваш какъвто DNS пожелаеш и намираш за редно според конкретните ти нужди.

[MitkoS]

При Windows NT сървър, няма Active Directory. Лошо съм се изразил в предишния пост. Написал съм "windows-домейн", а съм имал впредвид "W2K/2003-домейн
А иначе, може и да се прав, доколкото се вижда по-долу
...
DNS requirements for installing Active Directory
When you install Active Directory on a member server, the member server is promoted to a domain controller. Active Directory uses DNS as the location mechanism for domain controllers, enabling computers on the network to obtain IP addresses of domain controllers.
During the installation of Active Directory, the service (SRV) and address (A) resource records are dynamically registered in DNS, which are necessary for the successful functionality of the domain controller locator (Locator) mechanism.
To find domain controllers in a domain or forest, a client queries DNS for the SRV and A DNS resource records of the domain controller, which provide the client with the names and IP addresses of the domain controllers. In this context, the SRV and A resource records are referred to as Locator DNS resource records.
When adding a domain controller to a forest, you are updating a DNS zone hosted on a DNS server with the Locator DNS resource records and identifying the domain controller. For this reason, the DNS zone must allow dynamic updates (RFC 2136) and the DNS server hosting that zone must support the SRV resource records (RFC 2782) to advertise the Active Directory directory service. For more information about RFCs, see DNS RFCs.
If the DNS server hosting the authoritative DNS zone is not a server running Windows 2000 or Windows Server 2003, contact your DNS administrator to determine if the DNS server supports the required standards. If the server does not support the required standards, or the authoritative DNS zone cannot be configured to allow dynamic updates, then modification is required to your existing DNS infrastructure.
For more information, see Checklist: Verifying DNS before installing Active Directory and Using the Active Directory Installation Wizard.
Important
• The DNS server used to support Active Directory must support SRV resource records for the Locator mechanism to function. For more information, see Service location (SRV) resource records.
• It is recommended that the DNS infrastructure allows dynamic updates of Locator DNS resource records (SRV and A) before installing Active Directory, but your DNS administrator may add these resource records manually after installation.
After installing Active Directory, these records can be found on the domain controller in the following location: systemroot\System32\Config\Netlogon.dns

Copy/Paste от help-а на Win2003 Srv Std

[KoftiSector]

MitkoS мисля че ясно съм написал "NT style DC". Там понятието Active Directory (LDAP имплементация на МS) не съществува.

[Ghost]

Проблемът идва след Win2k, когато MS се опитват да ползат Internet DNS за определяне IP адрес на SMB ресурс. Фабричните настройки на всяко XP са: включен "File and Printer Sharing" (иначе казано SMB сървър) и да ползва NetBIOS over TCP/IP за транспорт. Къде е проблемът? Ами много просто - ако няма дефиниран WINS сървър, SMB сървърът обявява наличието на ресурсите си чрез broadcast. Понеже транспортът е TCP/IP, broadcast-ът стига само да точките в същия IP subnet.
- Как да решим проблема?
- Ми, дай да регистрираме всяка работна станция в DNS-a...
(речено-сторено)

Какво става, когато работната станция има частен(резервиран, "не-реален") ИП адрес?, да речем 192.168.0.1?

dig 192.168.0.1

; <<>> DiG 9.3.2 <<>> 192.168.0.1
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 35263
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0

;; QUESTION SECTION:
;192.168.0.1.          IN   A

;; AUTHORITY SECTION:
.            10800  IN   SOA   A.ROOT-SERVERS.NET. NSTLD.VERISIGN-GRS.COM. 2007011100 1800 900 604800 86400

;; Query time: 136 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Fri Jan 12 06:02:28 2007
;; MSG SIZE rcvd: 104

Няма "ANSWER SECTION"...тогава работната станция решава да обяви името си на сътветното AUTHORITY, в случая "A.ROOT-SERVERS.NET" с надеждата да бъде регистрирано...красота...

[MitkoS]

Да си представим, че имаш още една машина в същата мрежа с *NIX и IP 192.168.0.2

Не мислиш ли, че ще получиш същото при
dig 192.168.0.2

Това, което искам да кажа (1) е, че примера с dig 192.168.0.1 не е удачен - това че твоя DNS-сървър не знае нищо за 192.168.0.1, не значи непременно, че същия 192.168.0.1 е генерирал паразитен трафик
// Това което искам да кажа (2) е, че с примера, не доказваш, че след като WinXP-станцията не е могла да се регистрира в най-близкия DNS-сървър, не значи че е правила опити за регистрация нагоре.

// От сутринта, де що видя локална мрежа, първата ми работа е да dig-ам IP-тата на съседните работни WinXP компютри. Досега няма случай, да няма ANSWER SECTION. И при мрежички с W2003-домейни, и при мрежички без такива без да се интересувам какво има там за местен DNS-сървър.

[Ghost]

Кой каза, че имам DNS сървър? Сещаш ли се какво става, когато няма DNS server, настроен като мастер за този address pool? Помисли какво се случва с домашните компютри, които са свързани с Интернет...

П.П.
BTW, допуснал съм грешка - командата за обратен ресолвинг е "dig -x", но резултатът е същия. ;-)

[MitkoS]

... Сещаш ли се какво става, когато няма DNS server, настроен като мастер за този address pool? ...

Е не се сещам.
И ти не го знаеш това (не си го проверявал), а само гадаеш !

[Ghost]

[MitkoS]

Междувременно, в предварителния план, се забеляза един дефект. А именно "потенциално объркване в DC1 при избора на gateway при обратен отговор отвътре-навън". Сложил съм го в кавички, тъй като се чудех как точно да го формулирам.

Ако на някой му е интересно, можем да продължим да го мислим и обсъждаме заедно. Ако не - здраве.
(Така или иначе доста мислих по въпроса и стигнах до теоротичното разрешаване на проблема, което за мое съжаление, поне за момента, не знам как да го направя на практика)