2008/8/19 kevin graham <[EMAIL PROTECTED]>:
>
> On Tue, 19 Aug 2008, David Conrad wrote:
>
>> On Aug 19, 2008, at 6:40 AM, Masataka Ohta wrote:
>>>
>>> So what? NAT at airport must be, unlike NATs in enterprises,
>>> consumer friendly. Unlike highe end NAT, low end NAT won't
>>> bother to interfere DNS.
>>
>> Right. Because low-end consumer gear is always so much better implemented
>> than enterprise gear.
>
> At least in IOS's case, there was some gross misunderstanding that CNAME's
> should have their TTL's 0'ed (CSCsj10772) as a part of their translating
> payloads that contain A's and PTR's that are within nat address pools.
>
> The behavior is now configurable ("no ip nat service dns-reset-ttl"), but
> the stance was that "it's been this way so long we can't change the
> default". Ultimately, it was the breakage due to DNSSEC (rather than simple
> incorrectness) that got it addressed.
It took me hell lot of time and emails to explain this problem to tacman :-(.
Origin of this bug comes from broken implementation of RFC2694. And
unfortunatelly
I was not able to explain to them that they should modify TTL only in cases
covered by RFC2694.
The bad side of this bug is, that it breaks TSIG :(. I tried to have my own
public resolvers protected by TSIG.
Ondrej.
--
Ondřej Surý
technický ředitel/Chief Technical Officer
-----------------------------------------
CZ.NIC, z.s.p.o. -- .cz domain registry
Americká 23,120 00 Praha 2,Czech Republic
mailto:[EMAIL PROTECTED] http://nic.cz/
sip:[EMAIL PROTECTED] tel:+420.222745110
mob:+420.739013699 fax:+420.222745112
-----------------------------------------
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
