TXT против записи в DNS TXT записи

Question

Интересно, в чем разница между полем txt и полем записей в записи TXT, возвращаемой DNS-запросом с использованием PHP dns_get_record.

Например, если я вызываю dns_get_record для s1._domainkey.mydomain.com'для записи TXT я получаю:

entries: ["k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnVgd0NyrRE261IIiPqi+0H1baNyKcdj8Kea/VlSP4exzvKx8pJ01EWMwd094FV/6OCBIf7KGKgowMnWl3tW3Z5d++uZHkdgF+6xg7b9PynmX/NTo2kx92hlGgegwyulF5B7d2FM0doaCeoO4rD05jZzwi3cXx/156Gg9Xwd/Z/QIDAQAB"]

txt: "k=rsa; t=s; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCnVgd0NyrRE261IIiPqi+0H1baNyKcdj8Kea/VlSP4exzvKx8pJ01EWMwd094FV/6OCBIf7KGKgowMnWl3tW3Z5d++uZHkdgF+6xg7b9PynmX/NTo2kx92hlGgegwyulF5B7d2FM0doaCeoO4rD05jZzwi3cXx/156Gg9Xwd/Z/QIDAQAB"

Код, который дал такой результат:

function retrieve_spf_record($domain) { 
    $txtRecords = dns_get_record($domain, DNS_TXT); 
    foreach ($txtRecords as $txtRecord) { 
        if (startsWith($txtRecord['txt'], 'v=spf1')) { 
            return $txtRecord; 
        } 
    } 
    return FALSE; 
}

Мне кажется, что записи идентичны txt в этом случае.Но я полагаю, что они могут служить различным целям в некоторых других сценариях, иначе не было бы смысла иметь их обоих.

Так почему же существуют поля txt и entry?Может ли это быть связано со сценарием, в котором значение является слишком длинным (например, более 512 В), чтобы его можно было разделить и сохранить в записях?

Если приведенное выше предположение верно, то полное значение такогозапись TXT будет объединять все записи, а поле txt следует игнорировать - это правильно?

Любое объяснение приветствуется.Спасибо!

Обновление: вот что PHP возвращает dns_get_record на 'cisco.com':

Array
(
    [host] => cisco.com
    [class] => IN
    [ttl] => 3158
    [type] => TXT
    [txt] => v=spf1 ip4:173.37.147.224/27 ip4:173.37.142.64/26 ip4:173.38.212.128/27 ip4:173.38.203.0/24 ip4:64.100.0.0/14 ip4:72.163.7.160/27 ip4:72.163.197.0/24 ip4:144.254.0.0/16 ip4:66.187.208.0/20 ip4:173.37.86.0/24 ip4:64.104.206.0/24 ip4:64.104.15.96/27 ip4:64.102.19.192/26 ip4:144.254.15.96/27 ip4:173.36.137.128/26 ip4:173.36.130.0/24 mx:res.cisco.com mx:sco.cisco.com include:spf.protection.outlook.com ~all
    [entries] => Array
        (
            [0] => v=spf1 ip4:173.37.147.224/27 ip4:173.37.142.64/26 ip4:173.38.212.128/27 ip4:173.38.203.0/24 ip4:64.100.0.0/14 ip4:72.163.7.160/27 ip4:72.163.197.0/24 ip4:144.254.0.0/16 ip4:66.187.208.0/20 ip4:173.37.86.0/24
            [1] =>  ip4:64.104.206.0/24 ip4:64.104.15.96/27 ip4:64.102.19.192/26 ip4:144.254.15.96/27 ip4:173.36.137.128/26 ip4:173.36.130.0/24 mx:res.cisco.com mx:sco.cisco.com include:spf.protection.outlook.com ~all
        )

)

Answer 1

dns_get_record возвращает массив ассоциативных массивов .

Если вы запустите

 var_dump(dns_get_record("s1._domainkey.mydomain.com"));

что вы получите?

Выходизначально вы могли получить артефакт, вызванный попыткой распечатать массив ассоциативных массивов, интерпретируемый как некоторый более простой тип.

---

В обоих случаях все строки "записи" имеют длину менее 255 октетов (ASCIIсимволов), что является максимальной длиной общей записи TXT DNS.

Но поскольку вся запись TKT DKIM в исходном примере составляет менее 255 октетов, в подпункте «records» будет только одна строка-array.

В примере cisco.com общая длина записи DKIM составляет 405 октетов, поэтому она должна быть представлена ​​в DNS как две записи TXT, согласно RFC 4408 .И две строки в подмассиве entries имеют длину менее 255 октетов, поэтому, похоже, ваша теория максимальной длины верна.

Элемент txt основного ассоциативного массива содержит TXTзаписи уже объединены для вашего удобства.Если по какой-то причине вам нужны необработанные отдельные записи TXT, под массив elements может предоставить их вам.