3 ms·

> In order to squeeze as much information as possible into the 512 bytes... I appreciate that this is a work in progress but this section is misleading. As all

> In order to squeeze as much information as possible into the 512 bytes... I appreciate that this is a work in progress but this section is misleading. As all too briefly mentioned elsewhere on the page, EDNS allows extending this. In practice most of the resolvers I connect to do support EDNS and a buffer of 4096. So yes 512 may be needed as a fallback (depending on what you're doing) but you'll almost certainly have more room to breathe than that. IPv6 and DNSSEC practically make the extra space a necessity. > DNS names can (and often MUST) be compressed. I don't think I've ever seen label compression in actual use? RFC 6891 (https://tools.ietf.org/html/rfc6891 https://tools.ietf.org/html/rfc6891) seems to suggest they're obsolete. That critique aside, it seems like this will become a good tutorial. And if you're looking for a reference I'd point to the IANA's page on DNS parameters (https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml https://www.iana.org/assignments/dns-parameters/dns-paramete...) it lists and organises most of the relevant RFCs. RFC 6895 (https://tools.ietf.org/html/rfc6895 https://tools.ietf.org/html/rfc6895) is a particularly useful resource for best practices.

colmmacc 9y ago
Label compression is pretty common, I think all of the big name server implementations do it by default. Amazon Route 53 definitely does it - I wrote the code! But my favorite thing about DNS label compression is probably this quote from DJB's code where he implemented it ... https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c536beee2ef56d07a2/dns_packet.c#L2 https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c53...
- ChrisSD 9y ago
  Thanks! I've only been hacking around with dns as an amateur so i appreciate the correction.
- bluejekyll 9y ago
  Yeah, label compression is very much in use. It is annoying though, it’s one of the slower pieces during serialization.
muks 9y ago
> I appreciate that this is a work in progress but this section is misleading. As all too briefly mentioned elsewhere on the page, EDNS allows extending this. In practice most of the resolvers I connect to do support EDNS and a buffer of 4096. So yes 512 may be needed as a fallback (depending on what you're doing) but you'll almost certainly have more room to breathe than that. IPv6 and DNSSEC practically make the extra space a necessity. EDNS is fundamental DNS knowledge that any DNS server implementer knows and Bert is one. He's talking about "when DNS was created" in that context, i.e., the current DNS's RFC 1034/1035 times.
- ahubert 9y ago
  Hi Muks! The rest of the content is still appearing, but https://powerdns.org/hello-dns/optional.md.html https://powerdns.org/hello-dns/optional.md.html now talks about EDNS.
jedisct1 9y ago
This needs an update, but here is a study I made a while back on EDNS support and payload sizes: http://msync.c9x.org/PubDNS/ http://msync.c9x.org/PubDNS/

colmmacc 9y ago

Label compression is pretty common, I think all of the big name server implementations do it by default. Amazon Route 53 definitely does it - I wrote the code! But my favorite thing about DNS label compression is probably this quote from DJB's code where he implemented it ... https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c536beee2ef56d07a2/dns_packet.c#L2 https://github.com/abh/djbdns/blob/0715ca5de14ad5eae2c779c53...

ChrisSD 9y ago
Thanks! I've only been hacking around with dns as an amateur so i appreciate the correction.
bluejekyll 9y ago
Yeah, label compression is very much in use. It is annoying though, it’s one of the slower pieces during serialization.

muks 9y ago

> I appreciate that this is a work in progress but this section is misleading. As all too briefly mentioned elsewhere on the page, EDNS allows extending this. In practice most of the resolvers I connect to do support EDNS and a buffer of 4096. So yes 512 may be needed as a fallback (depending on what you're doing) but you'll almost certainly have more room to breathe than that. IPv6 and DNSSEC practically make the extra space a necessity. EDNS is fundamental DNS knowledge that any DNS server implementer knows and Bert is one. He's talking about "when DNS was created" in that context, i.e., the current DNS's RFC 1034/1035 times.

ahubert 9y ago
Hi Muks! The rest of the content is still appearing, but https://powerdns.org/hello-dns/optional.md.html https://powerdns.org/hello-dns/optional.md.html now talks about EDNS.

jedisct1 9y ago

This needs an update, but here is a study I made a while back on EDNS support and payload sizes: http://msync.c9x.org/PubDNS/ http://msync.c9x.org/PubDNS/