Hello uanog, Тут много знатоков DNS & RFC. Проясните картину, pls. Мой сервер держит зону для d-sto.com и соответственно обратную. Моих IP из сетки 195 прова десяток, так что запись выглядит так: ... 10 IN PTR d-sto.com. $GENERATE 11-255 $ NS ns.пров.net. все работает нормально, так как при обратном резолвинге пров возвращает PTR. Есть мой второй сервер в другой сетке того-же прова. Для него на том же d-sto.com: 126 IN PTR plant.d-sto.com. $GENERATE 0-125 $ NS ns.пров.net. $GENERATE 127-255 $ NS ns.пров.net. Только вот провайдер возвращает на этот запрос CNAME. Ну и мой bind9 поступает в соответствии с пунктом Checking names своего man-а - обратный резолвинг _не работает_ %-( по умолчанию. Да, это решается прописыванием check-name fail; в опциях, но как бы в нарушение RFC. После бесед с админом прова он мне укащал на ftp://ftp.rfc-editor.org/in-notes/rfc2317.txt так что его действия полностью соответствуют RFC. Вот теперь и задачка - так кто виноват? или же кто нарушитель? -- Cheers, Konstantin Nikonenko http://www.kot.dp.ua/ =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hello uanog,
Тут много знатоков DNS & RFC. Проясните картину, pls. Мой сервер держит зону для d-sto.com и соответственно обратную. Моих IP из сетки 195 прова десяток, так что запись выглядит так: ... 10 IN PTR d-sto.com. $GENERATE 11-255 $ NS ns.пров.net. ^^^^^^^^^^ А что это за мода такая? 8-(
-- YY18-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hello! On Wed, 26 Feb 2003 at 10:21:13 (+0200), Konstantin Nikonenko wrote:
Тут много знатоков DNS & RFC. Проясните картину, pls. Мой сервер держит зону для d-sto.com и соответственно обратную. Моих IP из сетки 195 прова десяток, так что запись выглядит так: ... 10 IN PTR d-sto.com. $GENERATE 11-255 $ NS ns.пров.net. все работает нормально, так как при обратном резолвинге пров возвращает PTR. Есть мой второй сервер в другой сетке того-же прова. Для него на том же d-sto.com: 126 IN PTR plant.d-sto.com. $GENERATE 0-125 $ NS ns.пров.net. $GENERATE 127-255 $ NS ns.пров.net. Только вот провайдер возвращает на этот запрос CNAME.
Тебе надо у себя прописать, например, "$GENERATE 127-255 $ PTR $.reverse.d-sto.com." (обычная реверсная зона), а не "$GENERATE 127-255 $ NS ns.пров.net.".
Ну и мой bind9 поступает в соответствии с пунктом Checking names своего man-а - обратный резолвинг _не работает_ %-( по умолчанию. Да, это решается прописыванием check-name fail; в опциях, но как бы в нарушение RFC. После бесед с админом прова он мне укащал на ftp://ftp.rfc-editor.org/in-notes/rfc2317.txt так что его действия полностью соответствуют RFC.
Вот теперь и задачка - так кто виноват? или же кто нарушитель?
-- George L. Yermulnik [GLY1-RIPE] =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hello!
On Wed, 26 Feb 2003 at 10:21:13 (+0200), Konstantin Nikonenko wrote:
Тут много знатоков DNS & RFC. Проясните картину, pls. Мой сервер держит зону для d-sto.com и соответственно обратную. Моих IP из сетки 195 прова десяток, так что запись выглядит так: ... 10 IN PTR d-sto.com. $GENERATE 11-255 $ NS ns.пров.net. все работает нормально, так как при обратном резолвинге пров возвращает PTR. Есть мой второй сервер в другой сетке того-же прова. Для него на том же d-sto.com: 126 IN PTR plant.d-sto.com. $GENERATE 0-125 $ NS ns.пров.net. $GENERATE 127-255 $ NS ns.пров.net. Только вот провайдер возвращает на этот запрос CNAME.
Тебе надо у себя прописать, например, "$GENERATE 127-255 $ PTR $.reverse.d-sto.com." (обычная реверсная зона), а не "$GENERATE 127-255 $ NS ns.пров.net.".
Ну и мой bind9 поступает в соответствии с пунктом Checking names своего man-а - обратный резолвинг _не работает_ %-( по умолчанию. Да, это решается прописыванием check-name fail; в опциях, но как бы в нарушение RFC. После бесед с админом прова он мне укащал на ftp://ftp.rfc-editor.org/in-notes/rfc2317.txt так что его действия полностью соответствуют RFC.
Вот теперь и задачка - так кто виноват? или же кто нарушитель?
Админ "прова" правильно указал на документ который следовало бы изучить. После изучения - пропадут все вопросы о том кто виноват :) -- YY18-RIPE =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
Hi!
Тут много знатоков DNS & RFC. Проясните картину, pls. Мой сервер держит зону для d-sto.com и соответственно обратную.
Соответсвенно какую обратную? 195.24.131.10?
Моих IP из сетки 195 прова десяток, так что запись выглядит так: ... 10 IN PTR d-sto.com. $GENERATE 11-255 $ NS ns.пров.net.
И в какой зоне эти записи? Хм...
все работает нормально, так как при обратном резолвинге пров возвращает PTR.
Не, не работает нормально. По крайней мере для 195.24.131.10. В зоне 131.24.195.in-addr.arpa кто-то прописал 10.131.24.195.in-addr.arpa. 14400 IN NS ns.d-sto.com. что наверняка может работать (как мне кажется) но совершенно не соответствует тому самому RFC. В данный момент на ns.d-sto.com никто не отвечает, потому дальнейшая судьба этой зоны непонятна. Но чтобы back-resolving для 195.24.131.10 начал работать без изменений в 131.24.195.in-addr.arpa, нужно поднять на ns.d-sto.com. какой-нть name-server :), сделать его master по 10.131.24.195.in-addr.arpa. и в файле зоны вписать @ IN PTR d-sto.com. @ IN NS ns.d-sto.com. И так, возможно, заработает (хотя все равно некрасиво).
Есть мой второй сервер в другой сетке того-же прова. Для него на том же d-sto.com: 126 IN PTR plant.d-sto.com.
212.3.111.126? А этот как раз работает.
$GENERATE 0-125 $ NS ns.пров.net. $GENERATE 127-255 $ NS ns.пров.net. Только вот провайдер возвращает на этот запрос CNAME.
Да, все правильно, так и должно работать :) Только вот GENERATE NS писать не надо. И если это зона rev.lanscom.net (судя по 111.3.212.in-addr.arpa), то вместо этого в ней надо вписать @ IN NS ns.lanscom.net. так... для красоты. Но вообще-то для 126 уже работает :) Единственно что меня смущает - вот эта запись в 111.3.212.in-addr.arpa: *.111.3.212.in-addr.arpa. 86400 IN PTR apex-gw.apex.dp.ua. и, кстати, вопрос, почему она не работает... -- Michael Ты что, обалдел, родной? =================================================================== uanog mailing list. To Unsubscribe: send mail to majordomo@uanog.kiev.ua with "unsubscribe uanog" in the body of the message
participants (4)
-
George L. Yermulnik -
Konstantin Nikonenko -
Michael Petuschak -
Yury Yaroshevsky