On Tue, 07 Aug 2007 14:38:06 EDT, "Patrick W. Gilmore" said: >> In addition, any UDP truncated response needs to be retried via >> TCP- blocking it would cause a variety of problems.
> Since we are talking about authorities here, one can control the size > of ones responses. Barely. % dig aol.com txt ; <<>> DiG 9.5.0a6 <<>> aol.com txt ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57320 ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 4, ADDITIONAL: 2 ;; QUESTION SECTION: ;aol.com. IN TXT ;; ANSWER SECTION: aol.com. 218 IN TXT "v=spf1 ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" aol.com. 218 IN TXT "spf2.0/pra ip4:152.163.225.0/24 ip4:205.188.139.0/24 ip4:205.188.144.0/24 ip4:205.188.156.0/23 ip4:205.188.159.0/24 ip4:64.12.136.0/23 ip4:64.12.138.0/24 ptr:mx.aol.com ?all" ;; AUTHORITY SECTION: aol.com. 439 IN NS dns-02.ns.aol.com. aol.com. 439 IN NS dns-06.ns.aol.com. aol.com. 439 IN NS dns-07.ns.aol.com. aol.com. 439 IN NS dns-01.ns.aol.com. ;; ADDITIONAL SECTION: dns-02.ns.aol.com. 158598 IN A 205.188.157.232 dns-06.ns.aol.com. 158598 IN A 149.174.54.153 ;; Query time: 4 msec ;; SERVER: 2001:468:c80:6101:213:72ff:fefc:d5cc#53(2001:468:c80:6101:213:72ff:fefc:d5cc) ;; WHEN: Tue Aug 7 15:32:36 2007 ;; MSG SIZE rcvd: 512 So tell me what they should do if they wanted to add 1 more byte to those TXT records. Say they want to start announcing IPv6 addresses too... :) They're running just a bit tight on 'authority and 'additional' they can heave over the side - they *already* don't answer with the txt records if you try to do a 'dig aol.com any' because that 512 and the 497 returned on a 'dig aol.com mx' won't fit in one 512-byte packet. > Unless, of course, you are so incredibly stupid you can't figure out > the difference between an authority and a caching server. I wish people would keep straight what direction they're doing the measurement, and for who's benefit. If *XYZ* wants to find which of their servers I'm closest to, they'll most likely be poking at my *caching* nameservers, because that's where my recursive query arrived from[1]. So we're *not* talking about authorities here. We're talking about DNS servers that are quite possibly configured to not talk, or give only partial results via UDP, to queries coming from outside the provider's network (after all, those people probably *should* be using *their* provider's caching DNS, right?) [1] If they *want* to go to the added effort of digging up my PTR, and from that finding the SOA and NS and ask my *authoritative* DNS for timing info, that's their right. Of course, all 3 of my caching servers are *really close* to me netwise - but of the 5 NS entries we list, 3 are intentionally *far away*, being off-campus secondaries. Hell, they're not even in our AS. :)
pgpX4reCtHl4C.pgp
Description: PGP signature
