zhoreeq
Return NS record for xxx.meshname
Один из вариантов реализации полноценных поддоменов и служебных записей - возвращать помимо AAAA ещё и NS. Тогда дальнейшая реализация просто выводится за пределы собственно meshname/meship и перенести задачу поддоменов и служебных записей на DNS-сервер, поднимаемый на соответствующем IP
Originally posted by @Scondo in https://github.com/zhoreeq/meshname/issues/7#issuecomment-813316218
@Scondo Вроде как NS запись должна возвращать домен authoritative сервера, а не его IP
https://www.rfc-editor.org/rfc/rfc1035.html
3.3.11. NS RDATA format
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ NSDNAME /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
NSDNAME A <domain-name> which specifies a host which should be
authoritative for the specified class and domain.
NS records cause both the usual additional section processing to locate
a type A record, and, when used in a referral, a special search of the
zone in which they reside for glue information.
The NS RR states that the named host should be expected to have a zone
starting at owner name of the specified class. Note that the class may
not indicate the protocol family which should be used to communicate
with the host, although it is typically a strong hint. For example,
hosts which are name servers for either Internet (IN) or Hesiod (HS)
class information are normally queried using IN class protocols.
Да, IP по стандарту нельзя возвращать, а жаль
https://serverfault.com/questions/764937/why-dont-ns-records-contain-ip-addresses
Да, IP по стандарту нельзя возвращать, а жаль
https://serverfault.com/questions/764937/why-dont-ns-records-contain-ip-addresses
Первая же ссылка в ответе говорит о возможности возвращать вместе с NS записью AAAA запись https://serverfault.com/questions/309622/what-is-a-glue-record
Если по спецификации: в сообщении DNS https://tools.ietf.org/html/rfc1035#page-25 есть помимо секции непосредственно ответа (на запрос NS там будет DNS-имя нашего NS-сервера) есть секция дополнительной информации (последняя - Additional). Вот в этой секции и передаётся A или в нашем случае AAAA запись, связывающая имя из ответа на запрос NS с непосредственно IP-адресом
Другой вопрос - надо внимательнее проанализировать какие запросы формирует система. Возможно NS не хватит, надо будет ещё возвращать SOA запись.
https://en.wikipedia.org/wiki/Domain_Name_System#Circular_dependencies_and_glue_records
For example, if the authoritative name server for example.org is ns1.example.org, a computer trying to resolve www.example.org first resolves ns1.example.org. Since ns1 is contained in example.org, this requires resolving example.org first, which presents a circular dependency. To break the dependency, the nameserver for the org top level domain includes glue along with the delegation for example.org. The glue records are address records that provide IP addresses for ns1.example.org. The resolver uses one or more of these IP addresses to query one of domain's authoritative servers, which allows it to complete the DNS query.
Значит, на запрос NS xxx.meshname мы отвечаем сразу двумя resource records:
@ xxx.meshname NS ns1.xxx.meshname
ns1.xxx.meshname AAAA 200::abcd
Получается, надо захардкодить сабдомен для NS записи в имплементации или даже зарезервировать его в самом описании протокола meshname? Уже как-то не очень красиво получается.
Ну а что мешает считать собственно корневой домен NS доменом? Выделение в отдельный домен у существующих серверов нужно потому, что у них это физически отдельные сервера: сервер, который отдаёт главную страницу гугла не тот же, который отвечает за разрешение имён.
Ну а что мешает считать собственно корневой домен NS доменом?
Сейчас в протоколе написано
"xxx.meshname" name is itself managed by the DNS server derived from "xxx" and can point to any other IPv6 address.
Надо будет вместо этого написать, что xxx.meshname всегда резолвится в AAAA запись c раскодированным IP.
Надо будет вместо этого написать, что xxx.meshname всегда резолвится в AAAA запись c раскодированным IP.
Да. А если уже надо указывать другие адреса - использовать yyy.xxx.meshname, на которые указывает DNS сервер, поднятый на xxx.meshname
Но собственно почему я поднял этот вопрос в рамках альтернативной доменной зоны - поднятие своего DNS-сервера может быть сложнее чем нынешняя настройка, а без собственного DNS-сервера это всё не будет работать.
Пока не совсем понятно, как сделать имплементацию, возможно понадобится возвращать SOA+glue record https://www.cloudflare.com/learning/dns/dns-records/dns-soa-record/
Возможно. Как минимум ради скорости.
То есть возможно SOA с MNAME xxx.meshname приведёт к дальнейшему запросу A|AAAA xxx.meshname у "корневой" зоны meshname. Но если сразу приклеить - будет на 1 запрос короче и ergo быстрее