Quantos dados TXT antes de as consultas DNS não cabem em um pacote UDP?

Question

Eu tenho um domínio DNS com três registros TXT:

$ORIGIN example.com.
@   IN TXT "thing one veryveryveryveryveryverylong"
@   IN TXT "thing two veryveryveryveryveryverylong"
@   IN TXT "thing three veryveryveryveryveryverylong"

Quando eu faço uma consulta DNS ( dig example.com. txt ), a resposta se encaixa em um pacote UDP porque a carga é menor que 512 bytes (resultando em um pacote com menos de 576 bytes).

No entanto, sei que se a resposta for longa o suficiente, ela será truncada e o cliente DNS terá que repetir a solicitação usando o TCP, que tem limites de tamanho mais longos.

Como posso calcular se excedeu ou não o limite de comprimento sem gerar os registros DNS e fazer uma consulta?

Eu assumo que a fórmula é algo como:

N: the number of TXT records on that label.
P: the number of bytes in all the TXT records.
S: the total number of text segments (TXT records can have multiple text segments per record)

UDP is required if N*a + P*b + S*c is more than 512

Quais são os valores de a, b e c?

(ou eu estou indo na direção errada?)

    

Answer 1

Na prática, você não deve tentar calcular previamente o tamanho exato da resposta dos seus registros TXT antes de implementá-los. Existem muitas variáveis em jogo, algumas das quais você não controla. A maioria dos administradores generaliza com base no tamanho de uma resposta de registro TXT existente que eles observam de seu servidor autoritativo e a chamam de um dia. Como o foco da sua pergunta é como evitar a generalização, essa resposta vai se concentrar no motivo pelo qual é difícil usar cálculos precisos.

(Esta resposta não deve ser tomada como uma declaração a favor ou contra a tentativa de ficar dentro de 512 bytes, é um comentário sobre a abordagem usada para fazer isso.)

sDNSHeader + sQuestion + sAnswer + sAuthority + sAdditional

• A própria consulta aparece na seção de perguntas do pacote de resposta e deve ser levada em consideração.
• Como você imaginou, o número de respostas e seu comprimento de bytes também devem ser levados em consideração.
• Se o servidor autoritativo estiver configurado para listar os servidores de nomes na seção de autoridade e os registros de endereço correspondentes na seção adicional, eles também deverão ser incluídos no fator.
• Se a solicitação continha uma pseudo-seção EDNS0 dentro da seção adicional, um servidor compatível responderia com sua própria pseudo-seção. A consulta provavelmente solicitou um tamanho de mensagem maior que 512 bytes se EDNS0 estiver em execução, mas ainda é uma consideração, especialmente porque o hardware de rede no caminho de comunicação pode rejeitar incorretamente pacotes DNS > 512 bytes como inválidos e forçar o limite efetivo de mensagens de volta para as restrições originais.
• A compressão de mensagem RFC 1035 também é um fator.

Você pode escrever um programa ou script que fará todo esse cálculo para você? Certo. É um bom uso do tempo para o problema que você está tentando resolver? Provavelmente não. Use um registro TXT existente na zona como sua diretriz de dimensionamento aproximado e, se o crescimento de mais de 512 bytes for uma preocupação, certifique-se de estar familiarizado com qualquer funcionalidade "include" incorporada ao padrão relevante que aproveite os registros TXT. (SPF, etc.)

    

Answer 2

historicamente você obtém 512 octetos de carga útil do DNS, dos quais 10 octetos são um cabeçalho fixo. você tem que abrir espaço para a cópia da seção de perguntas que será incluída na resposta. é mais ou menos o nome da pergunta mais quatro octetos. cada RR TXT usará um ponteiro de compactação até o nome da pergunta, para seu nome de proprietário. são dois octetos. então 10 octetos de sobrecarga fixa (ttl, class, type e rdlen). você ajustará mais texto em um único TXT RR realmente longo do que em vários TXT RRs discretos. em geral, você deve tentar inserir um grupo de TXT RRs diferentes em uma de suas zonas e, em seguida, usar "escavar" para buscar cada um deles e ver quanto tempo "escavar" indica que a carga útil é útil.

o número histórico de 512 foi escolhido para o IPv4, mas não foi descontraído para o IPv6. no IPv4, o payload mais os piores cabeçalhos UDP e IP renderiam um datagrama IP de 568 octetos, que era o menor tamanho de buffer de remontagem mínimo permitido - um endstation IPv4 não é "compatível" se não puder remontar pelo menos tanto assim, ninguém pode supor que você pode remontar mais.

no DNS moderno, o tamanho do buffer será negociado usando um OPT RR ("EDNS0") e normalmente será 4096. isso reflete o tamanho muito maior que o de 568 octetos que as estações finais podem realmente remontar. Obviamente, tamanhos de buffer EDNS0 maiores do que seu MTU Ethernet (ou seu MTU de caminho, se você o descobrir) causarão fragmentação de IP, e isso geralmente leva a perdas, já que os firewalls não permitem isso. quando EDNS0 @ 4K falha, muitas vezes tentará novamente em 1460 (para deixar espaço para cabeçalhos IP e UDP mais sua carga útil e ainda caber em um pacote ethernet) e tente novamente em 512, e talvez tente novamente sem EDNS0 (que também é 512 ). Se você depender do EDNS, muitas vezes acabará enviando TC = 1 ("truncamento ocorreu"), caso em que o solicitante provavelmente tentará novamente usando TCP ou simplesmente falhará completamente.

O que isto significa é que se você depender de mais de 512, você usará muito o TCP. já que sua pergunta era sobre o UDP, isso provavelmente significa que você deve se encaixar em 512.

    

Answer 3

Se eu leio RFC1035 corretamente, você tem:

Header: 12 bytes
Question: querylen +1(null term)+4
Answer: N*(namelen+1+10+(S*(1+txtlen)))

Assim, para o seu exemplo (onde há apenas um segmento de texto S por registro TXT):

query = example.com
querylen = 11
name: I'm not sure if that would be blank or example.com in your example
but I think it would be example.com, so

namelen = 11
txtlen1 = 38
txtlen2 = 38
txtlen3 = 40

Então, temos 12 + 11 + 5 = 28 + respostas

P1 = Answer1 = 11+11+1+38 = 61
P2 = Answer1 = 11+11+1+38 = 61
P3 = Answer1 = 11+11+1+40 = 63

28+61+61+63=213

    

Answer 4

Os registros TXT podem conter no máximo 255 bytes de dados e os pacotes UDP podem ser de qualquer tamanho. O pacote UDP será fragmentado para caber em um IP em 65.507.