Comments 15
Есть такая штука: pi-hole.net и куча blacklist для нее, например вот тут Убер-список на 1.4 млн доменов: raw.githubusercontent.com/CamelCase11/UnifiedHosts/master/hosts.all
Я еще использую список «Домены, замеченные в майнинге криптовалют на своих сайтах»:
github.com/Marfjeh/coinhive-block/blob/master/domains
Еще есть скрипт StopAD для Mikrotik stopad.kplus.pro — там тоже есть интересные стоп-листы.
Я еще использую список «Домены, замеченные в майнинге криптовалют на своих сайтах»:
github.com/Marfjeh/coinhive-block/blob/master/domains
Еще есть скрипт StopAD для Mikrotik stopad.kplus.pro — там тоже есть интересные стоп-листы.
И на сколько этот прокси — прокси? Каким образом на него направляются запросы?
Что-то мне подсказывает, что кэширование не поможет от DNS Amplification, и ваш сервер (если доступен по интернету) будет участвовать в DDoS.
Но так-как у нас нет одновременного read/write, то можно обойтись без мьютексов.
RWMutex — это, вроде бы, не больно. Почему решили не использовать?
Исходя из архитектуры приложения надобность в любом мьютексе отсутствует. С хеш-таблицой производятся только операции чтения. Обновление списка производится заменой указателя на новую таблицу.
github.com/GoWebProd/goDNS/blob/master/src/server/handlers.go#L40 — тут чтение
github.com/GoWebProd/goDNS/blob/master/src/server/black.go#L87 — тут запись.
Я не буду разводить нудятину про глобальные переменные, но про happens before тут есть что почитать — golang.org/ref/mem.
Теоретически же (в зависимости от компилятора) может быть так, что хэндлер вообще не будет видеть обновлённые данные.
github.com/GoWebProd/goDNS/blob/master/src/server/black.go#L87 — тут запись.
Я не буду разводить нудятину про глобальные переменные, но про happens before тут есть что почитать — golang.org/ref/mem.
Теоретически же (в зависимости от компилятора) может быть так, что хэндлер вообще не будет видеть обновлённые данные.
А, я имел ввиду другое место. Тем не менее ничего страшного, если хэндлер не сразу прочитает обновление. Я не считаю это критичным, но буду рад, если Вы объясните мне если я не прав.
Тем не менее ничего страшного, если хэндлер не сразу прочитает обновление
и запаникует
Почему же? Там всегда есть корректный указатель, старый или новый. Начальный задается еще до старта сервера: https://github.com/GoWebProd/goDNS/blob/master/src/server/main.go#L78
type T struct {
msg string
}
var g *T
func setup() {
t := new(T)
t.msg = "hello, world"
g = t
}
func main() {
go setup()
for g == nil {
}
print(g.msg)
}Тут в переменной g тоже всегда корректный указатель, но это не мешает «there is no guarantee that it will observe the initialized value for g.msg».
Другими словами оптимизатор может вначале выполнить config.go:66, заполнив указатель новым свежим конфигом, и только потом заполнить этот конфиг значениями, т.к он не знает что кто-то может этот самый конфиг читать. Т.е по факту может случиться так что часть полей конфига уже новые, а часть — какие угодно. Вроде бы паники тут быть нигде быть не должно.
package main
import (
"math/rand"
"sync"
"testing"
)
const (
N = 100000
)
var (
a []int
)
func TestRace(*testing.T) {
a = []int{1, 2, 3}
var wg sync.WaitGroup
wg.Add(2)
go func() {
for i := 0; i < N; i++ {
a = []int{rand.Int()}
}
wg.Done()
}()
go func() {
for i := 0; i < N; i++ {
_ = a
}
wg.Done()
}()
wg.Wait()
}go test -raceПопробуйте
Sign up to leave a comment.
Пишем DNS proxy на Go