It's a bit weird from here:
TCP queries to m's IPv4 adress are working fine:
dns-test:~ # dig @202.12.27.33 . any
;; Truncated, retrying in TCP mode.
; <<>> DiG 9.7.0-P1 <<>> @202.12.27.33 . any
; (1 server found)
;; global options: +cmd
;; Got answer:
And:
dig @202.12.27.33 hostname.bind ch t
Chris Thompson wrote:
> On Mar 17 2010, sth...@nethelp.no wrote:
>
>> Should of course have checked hostname.bind, which reveals:
>>
>> % dig @202.12.27.33 hostname.bind ch txt +short
>> "M-CDG-3"
>> % dig @2001:dc3::35 hostname.bind ch txt +short
>> "M-CDG-4"
>>
>> So it seems my guess of Paris
Coming back to this unanswered question: from my point of view the color
matching seems a bit harsh with regard to operational reality. I
certainly won't get any nightmares for non exhaustive additional
sections in response to extremely large queries.
This said, while looking at this I noticed som
ementation, rather get an idea of
the reasoning behind the behaviour... (I do agree that the query is a
bit extreme). And if operators think that this might lead to problems.
Gilles
On 5/6/12 19:23 , Joe Abley wrote:
>
> On 2012-06-05, at 08:28, Gilles Massen wrote:
>
>> One set
On 10/07/2014 06:04 AM, Tim Wicinski wrote:
> This starts a Call for Adoption for
> draft-bortzmeyer-dns-qname-minimisation.
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-bortzmeyer-dns-qname-minimisation/
I support adoption, and am willing contribute/review.
Gille