Может казаться, не разрешает домен, но может вырыть его
В звездочке $[] выражение, неопределенные переменные не возвращают неявную пустую строку или нуль. Они не расширяются как "ничто" до оценки выражения, поэтому после того, как переменная расширена (ни к чему), это не видимо к синтаксическому анализатору выражения. Это вызывает ошибку, уже отмеченную Pablo Alsina:
GotoIf("IAX2/AtlantaTeliax-10086", "?CLOSED,1")
Существует два способа избежать этого:
- Всегда давайте Вашим переменным разумные значения по умолчанию перед использованием их (в качестве предложенного Pablo).
- В любом
$[]выражение, включите свои переменные и литералы с двойными кавычками. Это заставит неопределенную переменную быть обработанной как пустая строка, которая может все еще использоваться в целях сравнения.
Лично, я пытаюсь сделать обоих. Например:
exten => START,n,Set(FORCE_CLOSED=FALSE)
exten => START,n,GotoIf($["${FORCE_CLOSED}"="TRUE"]?CLOSED,1)
Отметьте двойные кавычки вокруг ${FORCE_CLOSED} и сравнительное значение. Даже если переменная будет неопределенной, то выражение будет иметь "" (пустая строка) для сравнения с "TRUE".
Действительно, можно использовать любой символ, который Вы любите, потому что он будет просто прикреплен на переменное расширение. Это просто дает Вам литеральное значение, которое, как гарантируют, будет там в случае, если переменная является неопределенной. Мне нравятся кавычки, потому что это заставляет код напомнить другие языки программирования. Вы могли столь же легко использовать что-то как $[x${FORCE_CLOSED}=xTRUE], который обычно замечается в сценариях Оболочки Bourne. Конечным результатом является то же.
Ну, я решил. Оказывается, системный администратор до меня принудительно отправлял все исходящие запросы на порт 53. Серверы имен extremehosting.ca, похоже, блокируют входящие соединения на порте 53, которые исходят из порта 53, и поэтому я не мог с ними связаться.
Удалив эти строки из named.conf:
query-source port 53;
query-source-v6 port 53;
и убедившись, что брандмауэр не вызовет никаких дополнительных проблем, разрешение имен снова работает.
Кроме того, я нашел эту статью , которая помогает определить источник вашего преобразователя имен - поведение порта очень полезно. Побочным эффектом решения этой проблемы DNS является то, что я также устранил потенциальную уязвимость, связанную с отравлением кэша имен.
Спасибо всем, кто прокомментировал.
Хм, что происходит, когда вы используете nslookup для связи с их серверами? IE:
$ nslookup
>server 204.15.193.162
Default server: 204.15.193.162
Address: 204.15.193.162#53
> www.digbypines.ca
Server: 204.15.193.162
Address: 204.15.193.162#53
www.digbypines.ca canonical name = digbypines.ca.
Name: digbypines.ca
Address: 204.15.193.162
>
Это должно дать вам знать, проблема ли это BIND или брандмауэра.