Truncation Bit

[Kevin Darcy]

No, what you were measuring was the "human friendly" output of dig, not the raw
size of the packet. dig uncompresses labels, represents classes, types,
IP addresses, etc. with strings instead of binary values. All of this inflates
the size. dig reports the *real* size of the packet; see the MSG SIZE line
below:

fxiod01.is.chrysler.com% dig @ns2.altavista.com. ANY altavista.com

; <<>> DiG 8.2 <<>> @ns2.altavista.com. ANY altavista.com
; (1 server found)
;; res options: init recurs defnam dnsrch
;; got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6
;; flags: qr aa rd; QUERY: 1, ANSWER: 23, AUTHORITY: 3, ADDITIONAL: 8
;; QUERY SECTION:
;;      altavista.com, type = ANY, class = IN

;; ANSWER SECTION:
altavista.com.          2H IN NS        ns1.alta-vista.net.
altavista.com.          2H IN SOA       ns1.alta-vista.net.
postmaster.altavista.com. (
                                        2000080100      ; serial
                                        1H              ; refresh
                                        15M             ; retry
                                        1W              ; expiry
                                        2H )            ; minimum

altavista.com.          2H IN NS        ns2.alta-vista.net.
altavista.com.          2H IN NS        ns3.alta-vista.net.
altavista.com.          2H IN MX        50 mail1.sv.alta-vista.net.
altavista.com.          2H IN MX        50 mail2.pa.alta-vista.net.
altavista.com.          2H IN MX        30 download1.pa.alta-vista.net.
altavista.com.          2H IN MX        30 download2.pa.alta-vista.net.
altavista.com.          2H IN MX        40
inbound.altavista.com.criticalpath.net.
altavista.com.          2H IN A         204.152.190.19
altavista.com.          2H IN A         204.152.190.21
altavista.com.          2H IN A         204.152.190.69
altavista.com.          2H IN A         204.152.190.70
altavista.com.          2H IN A         204.152.190.71
altavista.com.          2H IN A         204.152.190.72
altavista.com.          2H IN A         204.152.190.25
altavista.com.          2H IN A         204.152.190.26
altavista.com.          2H IN A         204.152.190.60
altavista.com.          2H IN A         204.152.190.11
altavista.com.          2H IN A         204.152.190.13
altavista.com.          2H IN A         204.152.190.14
altavista.com.          2H IN A         204.152.190.16
altavista.com.          2H IN A         204.152.190.18

;; AUTHORITY SECTION:
altavista.com.          2H IN NS        ns1.alta-vista.net.
altavista.com.          2H IN NS        ns2.alta-vista.net.
altavista.com.          2H IN NS        ns3.alta-vista.net.

;; ADDITIONAL SECTION:
ns1.alta-vista.net.     2H IN A         204.152.190.79
ns2.alta-vista.net.     2H IN A         204.152.190.6
ns3.alta-vista.net.     2H IN A         204.152.190.1
mail1.sv.alta-vista.net.  2H IN A  128.177.243.127
mail2.pa.alta-vista.net.  2H IN A  204.152.191.65
download1.pa.alta-vista.net.  2H IN A  204.152.191.75
download2.pa.alta-vista.net.  2H IN A  204.152.191.76
inbound.altavista.com.criticalpath.net.  53m58s IN A  209.228.4.140

;; Total query time: 734 msec
;; FROM: fxiod01.is.chrysler.com to SERVER: ns2.altavista.com.  204.152.190.6
;; WHEN: Fri Aug  4 14:07:07 2000
;; MSG SIZE  sent: 31  rcvd: 693


- Kevin


Mark wrote:

> I got 2250 by piping the response to a file and checking the size. I'm sure
> that's wrong. How did you get the correct size of the response?
>
> Regards,
>
> Mark
>
> Kevin Darcy <kcd at daimlerchrysler.com> wrote in message
> news:3989F73E.DB97C5DE at daimlerchrysler.com...
> >
> > DNS UDP packets are arbitrarily limited to 512 bytes. The reason you're
> seeing
> > responses larger than 512 bytes is because smart resolvers (like dig)
> will, by
> > default, automatically retry truncated queries with TCP. Use a "+i"
> (ignore
> > truncation errors) on your dig command line to inhibit this behavior.
> >
> >
> > - Kevin
> >
> > P.S. I'm only getting about 700 bytes in response to that query. How did
> you
> > get 2250?
> >
> > Mark wrote:
> >
> > > Does anyone know how to get the truncation bit set in a dns response
> packet?
> > >
> > > I am assuming if the response from a nameserver won't fit into a single
> udp
> > > packet the truncation bit will be set in the Header of the response
> packet.
> > > Ideally this shouldn't happen too often but I would think you would see
> it
> > > from time to time. I have looked in the headers a lot of responses and I
> > > have never seen this bit set.
> > >
> > > If the maximum size of an IPv4 datagram is 65535 bytes it seems to me my
> udp
> > > payload can be of size
> > >                   udp payload + udp header + ip header = 65535 bytes or
> less
> > >
> > > digs such as
> > > $ dig  @ns2.altavista.com. ANY altavista.com
> > >
> > > produce quite a long response packet but even this is only 2250 bytes.
> This
> > > doesn't come close to exceeding the size limit.  It seems to me this
> feature
> > > is unnecessary since the size limit will never reached. Any insights
> > > appreciated.
> > >
> > > Regards,
> > >
> > > Mark
> >
> >
> >
> >
> >
> >